INTRODUCCINa) Presentacin y contextualizacin En esta unidad aprender los conceptos principales sobre las bases de datos relacionales, archivos de datos, y la diferencia que existe entre ellos. Entender la importancia de los sistemas de informacin, as como su relacin con el modelamiento de datos. El ciclo de vida de los sistemas de informacin con sus correspondientes etapas. Para terminar la unidad usted aprender el modelo conceptual ms popular, me refiero al modelo entidad relacin, diseara modelos conceptuales, utilizando los elementos del modelo entidad relacin como base. Le invito a tomar los valiosos conocimientos que contiene esta unidad, siguiendo detalladamente la metodologa planteada.

b) Competencia

Analiza y reconoce la importancia del modelamiento de datos en el desarrollo de sistemas de informacin.

c) Capacidades 1. Comprende los conceptos fundamentales de base de datos. 2. Distingue los distintos tipos de modelos para disear una base de datos y la forma de capturar los requisitos del cliente. 3. Comprende los conceptos y prcticas fundamentales del modelo entidad relacin. 4. Disea bases de datos utilizando el modelo entidad relacin. d) Actitudes

Lee con dedicacin todo lo concerniente a las generalidades del diseo de base de datos relacionales y modelo entidad relacin. Realiza preguntas sobre cualquier duda que tuviera en el contenido de la unidad. Practica los casos sobre modelo entidad relacin que se encuentran en el texto y las asignaciones de clase. Comparte sus conocimientos adquiridos investigando y desarrollando casos sobre el modelo entidad relacin, con sus compaeros de clase que lo necesiten.

e) Presentacin de ideas bsicas y contenido esenciales de la Unidad

La Unidad de Aprendizaje 1: Generalidades del Diseo de Base de Datos Relacional y Modelo Conceptual; comprende el desarrollo de los siguientes temas: TEMA 1: INTRODUCCIN A LAS BASES DE DATOS TEMA 2: MODELOS E INGENIERA DE REQUISITOS TEMA 3: MODELO ENTIDAD RELACIN TEMA 4: CASO COMERCIAL Y ALQUILER DE PELCULAS

Tema 01: Introduccin a las Bases de DatosLas bases de datos se encuentran en todo tipo de empresas y no siempre funcionando dentro de computadoras, se dividen en no informticas y informticas, las primeras, las encontramos, por ejemplo: En un estudio contable, los libros contables de las empresas seran una base de datos de libros contables, en una Universidad el listado de matriculados sera la base de datos de matriculados, aunque no siempre se sigue este patrn la idea inicial de base de datos. Base de datos Es un almacenamiento de datos formalmente definido, controlado centralmente para intentar servir a mltiples y diferentes aplicaciones. La base de datos es una fuente significativa de datos que son compartidos por numerosos usuarios para diversas aplicaciones. Kendall y Kendall Una base de datos informtica es la razn de ser del curso, es un conjunto de elementos relacionados entre s, que cumplen con los requerimientos de informacin de un rea o de toda la empresa. Analizando los conceptos antes descritos, la frase clave es datos relacionados y que son los datos?

Otros conceptos de Base de datos Una base de datos tiene una fuente de la cual se derivan los datos,

cierto grado de interaccin con los acontecimientos del mundo real y un pblico que est activamente interesado en el contenido de la base de datos. Ramez Elmasri y Shamkant B. Navathe

Elementos conocidos como por ejemplo el nombre, direccin, el nmero telefnico, el DNI, el RUC de la empresa entre otros, son atmicos es decir no pueden dividirse ms. Ejemplos de datos: Manuel - 16791125 - 25 - Mz. - T Lote 5 - 2,590.3 Archivos de datos Inicialmente los datos se almacenaban en archivos como por ejemplo txt, doc, etc., durante muchos aos los programas informticos utilizaron archivos para registrar los datos, pero el gran problema era la redundancia. Kendall y Kendall dice: Consiste en almacenar los datos en archivos individuales, exclusivos para casa aplicacin particular. En este sistema los datos pueden ser redundantes (repetidos innecesariamente) y la actualizacin de los archivos es ms lenta que en una base de datos. Ejemplo de archivo tradicional: Se cuenta con dos archivos alumno y matricula en el primero se encuentra los datos de los alumnos mientras que en el segundo se encuentra la matricula de los alumnos.

La redundancia radica en la repeticin de los nombres de los alumnos, otro problema aparece en los errores de digitacin, como se observa en el archivo matricula el nombre del alumno Pedro Marengo est mal escrito, lo que ocasionar problemas posteriores. Gestor de base de datos relacional (GBDR) Programa de computadora que permite crear y administrar una base de datos; en el mercado nacional encontramos a los de mayor uso al mysql, sqlserver y oracle. Es un sistema que rene, almacena, procesa y distribuye conjuntos de informacin entre los diferentes elementos que configuran una organizacin, y entre la organizacin misma y su entorno. Juan Antoni Pastori Collado Sistemas de informacin Tambin se dice que es un conjunto de elementos relacionados entre s, que se encarga de procesar manual y/o automticamente datos, en funcin de determinados objetivos. Para entenderlo mejor veamos el siguiente grfico:

Ciclo de vida de los sistemas de informacin Un buen desarrollo de software depende muchas veces del correcto modelamiento de la base de datos. El proceso de software comprende etapas como anlisis, diseo, desarrollo y pruebas, el modelamiento de la base de datos se encuentra en la etapa de diseo. Otra forma de representar el ciclo de vida de los sistemas de informacin es el propuesto por Kendall y Kendall.

Figura 02: Ciclo de vida de los sistemas de informacin Fuente: Kendall y Kendall En la etapa 4, Diseo del Sistema se encuentra la etapa de modelado de datos. La etapa 1, 2 y 3 del modelo de Kendall y Kendall, es la de anlisis, en esta etapa se planea los tiempos y objetivos del proyecto de software adems de los requerimientos de informacin. Despus de la captura de requisitos viene la etapa de diseo, una de las actividades es el modelamiento de datos, aspecto que veremos a profundidad en el transcurso del curso. En la etapa 5, 6 y 7 etapa de desarrollo del software o escritura del cdigo fuente, este cdigo se escribe en base al modelado realizado en la etapa de diseo. Al final se instala la aplicacin informtica en los equipos del cliente y se realiza casos de prueba, conversando previamente con el cliente.

INGENIERA DE REQUISITOSLa base de la ingeniera de requisitos, radica en conocer cules son las necesidades, especificaciones y requerimientos del cliente, parece muy fcil llegar a cumplir este objetivo, no obstante el principal problema en el diseo de los sistemas de informacin, incluso el diseo de base de datos, es la mala especificacin de los requerimientos del cliente, por la sencilla razn que muchas veces ni el cliente mismo sabe lo que necesita, en consecuencia la ingeniera de requisitos, es una rama de la ingeniera del software, que nos ayuda a entender al cliente y capturar mejor los requerimientos, un

ejemplo: En elprologo a un libro de Ralph Young sobre las prcticas efectivas en los requisitos, el autor de este libro escribi: Es tu peor pesadilla. Un cliente entra en tu oficina, se sienta, te mira directo a los ojos, y dice: Yo s que usted piensa que entiende lo que digo, pero lo que usted no entiende es que lo que digo no es realmente lo que quiero decir. Esto sucede de manera invariable cuando el proyecto est avanzado, despus de que han realizado los compromisos relativos al tiempo de entrega, las reputaciones estn en juego y el dinero est en serio peligro. Todos los que hemos trabajado en el negocio de los sistemas y el software por ms de unos cuantos aos hemos vivido esta pesadilla, y solo unos pocos de nosotros hemos aprendido a continuar aun con esta circunstancia. Nosotros tenemos dificultades cuando tratamos de obtener requisitos de nuestros clientes. Tenemos problemas al comprender la informacin que adquirimos. Con frecuencia, registramos los requisitos de una manera desorganizada e invertimos muy poco tiempo en verificar lo que registramos. Permitimos que el cambio nos controle en lugar de establecer mecanismos para controlarlo. En resumen, fallamos al establecer un cimiento slido para el sistema o software. Cada uno de estos problemas representa un reto. Cuando estos se combinan, la imagen es desalentadora incluso para los gerentes y profesionales del software ms experimentados. Pero existen soluciones. La ingeniera de requisitos proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solucin razonable, especificar la solucin sin ambigedades, validar la especificacin, y administrar los requisitos conforme stos se transforman en un

sistema operacional. El proceso de la ingeniera de requisitos se lleva a cabo a travs de siete distintas funciones: inicio, obtencin, elaboracin, negociacin, especificacin, validacin y gestin. PRESSMAN, Roger La captura de requisitos, est dividido en 7 fases: Por lo general, las semillas de los desastres ms importantes en software se siembran en los primeros tres meses desde el comienzo del proyecto. Capers Jones INICIO Inicio del proyecto, algunas veces se puede iniciar con una conversacin, pero generalmente inicia con la identificacin de necesidades del negocio OBTENCIN Realmente parece muy fcil preguntarle al cliente, cules son sus necesidades, mbito del proyecto o inclusive, el alineamiento que tiene con los objetivos estratgicos del negocio, pero muchas veces es complicado, los siguientes aspectos nos ayudarn a entender mejor porque es tan complicado:. Problemas de mbito Tamao del proyecto mal definido o no tan claro, esto puede confundir al analista con requisitos innecesarios para los objetivos del negocio. Problemas de comprensin Cuando los actores clave del negocio, los que usaran el sistema tienen poca comprensin de lo que necesitan, o simplemente no saben cmo comunicrselo al analista. Problemas de volatilidad Los requerimientos planteados al inicio del proyecto cambian

continuamente. ELABORACON Toda la informacin adquirida del cliente se plasma en un modelo. NEGOCIACIN Por lo general, el cliente siempre requiere ms de lo que se pueda lograr en el tiempo planeado, el ingeniero de requisitos tiene que negociar realizando estimaciones y costos del proyecto. ESPECIFICACIONES Una especificacin puede ser un documento escrito, un conjunto de modelos grficos, un modelo matemtico formal, una coleccin de escenarios de uso, un prototipo o cualquier combinacin de estos. VALIDACIN Proceso que verifica si las especificaciones son correctas. GESTIN Conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto. Cmo formular las primeras preguntas? Quin est detrs de la solicitud de este trabajo? Quin usar la solucin? Cul ser el beneficio econmico de una solucin exitosa? Existe otra fuente para la solucin requerida?

Es mejor saber algo de la preguntas que todo de las respuestas. James Thurber Para comprender mejor el problema se debe realizar las siguientes preguntas: Cmo podra caracterizarse un buen resultado generado por una solucin exitosa? Cules problemas ataca esta solucin? Podra usted describir o mostrar el ambiente de negocios en el que se utilizar la solucin? Los aspectos especiales del desempeo o las restricciones que afectarn laforma en que se busque la solucin? Las siguientes preguntan permitirn evaluar la efectividad de las respuestas anteriores: Es usted la persona adecuada para contestar esta pregunta? Sus respuestas son oficiales? Mis preguntas son relevantes para su problema? Estoy haciendo demasiadas preguntas? Alguien ms puede proporcionar informacin adicional? El que pregunta es un tonto durante cinco minutos: el que no pregunta es un tonto por siempre. Proverbio Chino

MODELOS Un modelo es una representacin abstracta o conceptual de la realidad; en las bases de datos son tres los modelos que permiten disearla y son: modelo conceptual, modelo lgico y modelo fsico. Modelo Conceptual El diseo del modelo conceptual parte de la especificacin de requisitos. Es independiente del gestor de base de datos relacional, describe un conjunto de objetos de la realidad, el modelo conceptual que utilizaremos es el ENTIDAD/RELACIN. Modelo lgico Se obtiene del modelo entidad relacin, lo que cambia es la forma de presentacin, se dice que es una descripcin de la estructura de la base de datos, que puede ser procesada por el gestor de base de datos relacional (GBDR). El modelo lgico que utilizaremos en el curso, es el relacional, por ser el que utilizan los GBDR. Se podra decir que el modelo lgico es como un puente, porque se encuentra entre el modelo conceptual y el modelo fsico.

Modelo fsico Es una descripcin de la implantacin de una base de datos en un gestor de base de datos relacional como por ejemplo Sqlserver, Mysql y Oracle. El diseo de un modelo fsico depende enteramente del GBRD y parte del modelo lgico.

Tema 03: Modelo Entidad - RelacinMODELO ENTIDAD RELACINEl modelo entidad relacin, es el modelo conceptual ms utilizado, permite plasmar una realidad de la empresa, o una rea funcional, como por ejemplo comercial, finanzas, recursos humanos, tesorera, entre otras. Propuesto por Peter Chen en 1967, el objetivo del modelo es representar grficamente la realidad de la empresa. Los elementos bsicos del modelo entidad relacin son: Entidades, atributos y asociaciones.

Entre las notaciones ms utilizadas se encuentra la de Chen y la CW Bachman, ms conocida como notacin pata de gallo, en este curso ensearemos las dos, aunque despus veremos que la ms utilizada es la notacin pata de gallo. Es preciso explicar que inicialmente el modelo entidad relacin contaba con elementos como entidades, atributos, asociaciones, mas tarde se agregaron nuevos elementos, y ahora se conoce como el modelo entidad relacin extendido, con elementos como atributos compuestos y las jerarquas de generalizacin. ENTIDAD Es un objeto importante de la vida real que tiene atributos como por ejemplo ALUMNO, Cules son sus atributos?: cdigo, nombre, apellidos, telfono, direccin, correo; una de las maneras de identificar entidades, es preguntndonos si tiene atributos, sino tiene atributos no es entidad. Una entidad son los sujetos de inters para la organizacin y el modelo que se quiere construir. Otra Definicin De Entidad Cualquier tipo de objeto de donde se recoge informacin: cosa, persona, concepto abstracto. Por ejemplo: carro, casa, empleado, cliente, empresa, oficio, producto, concierto, excursin, etc. Las entidades se representan grficamente mediante rectngulos y su nombre aparece en el interior. Un nombre de entidad solamente puede aparecer una vez en el modelo entidad relacin. Existen dos tipos de entidades, fuertes y dbiles, una entidad dbil es una entidad cuya existencia depende de la existencia de una entidad fuerte.

PERSONA

CATEGORIA

TURNO CARRERAASOCIACIN

MATRICULA FACTURA

Ejemplo de entidades con su representacin grfica

Conexin entre dos entidades, a veces llamada relacin binaria, no obstante es preciso mencionar que existen entidades que se pueden relacionar con varias entidades. ATRIBUTO Caracterstica que describe una entidad o asociacin, adems los atributos representan las propiedades bsicas de las entidades y sus relaciones. Ejemplos: Con la notacin Chen se representa de la siguiente manera:

Explicando la figura Nro. 3, la entidad ALUMNO, tiene 4 atributos, cdigo, apellido, nombre y direccin, se debe considerar que la entidad ALUMNO, puede tener ms atributos, esto depender de la institucin educativa que se encuentre analizando.

El siguiente grfico representa la notacin pata de gallo. Figura Nro. 5 Entidad con atributos, notacin pata de gallo

La figura Nro. 4 representa prcticamente lo mismo que la figura Nro. 3, con la diferencia que los atributos en la notacin Chen se encuentran representados fuera de la entidad y en la notacin pata de gallo se encuentran dentro de la entidad, realmente no se debe preocupar mucho, por el aspecto de las notaciones, sino se debe tener en cuenta la correcta descripcin de los atributos de una entidad.Los atributos de una entidad se clasifican en diferentes tipos:

Atributos Simples y CompuestosUn atributo simple es aquel que no se puede dividir en partes, ejemplo de atributos simples: DNI, cdigo alumno, RUC, curso, grado, seccin, nivel, etctera. En cambio los atributos compuestos se pueden dividir en partes, como por ejemplo: datos cliente, se puede dividir en nombre, apellido paterno, apellido materno.

Figura Nro. 6 Partes del atributo datos cliente

La gran pregunta es cmo aplico la teora de los atributos compuestos?, aunque hay varias maneras, se explica utilizando el ejemplo de la figura Nro. 5.

Explicacin En la entidad ALUMNO, el atributo direccin puede estar compuesto por: calle, nmero, distrito, ciudad y provincia, entonces la entidad ALUMNO, quedara de la siguiente manera. IMPORTANTE Algunas veces ser difcil identificar atributos compuestos, no obstante la clave de todo, es la prctica en el desarrollo de los ejercicios y casos prcticos.

ALUMNOCdigo Apellido Nombre Calle Numero Distrito Ciudad Provincia Figura Nro 7 Atributo direccin sub-dividido ATRIBUTOS UNIVALORADOS Un atributo es univalorado cuando el dato que contiene el atributo es nico, por ejemplo una persona no puede tener ms de un nmero de DNI. ATRIBUTOS MULTIVALORADOS Es multivalorado cuando un atributo tiene ms de un valor, por ejemplo: direccin, un cliente puede tener ms de una direccin, en este caso el atributo direccin es multivalorado

El Seor Abraham Silberschatz, Henry presenta el siguiente ejemplo: Un banco puede limitar el nmero de direcciones almacenadas de un cliente a dos. Colocando lmites en este caso, se expresa que el atributo direccin_cliente del conjunto de entidades cliente puede tener entre cero y dos valores.

ATRIBUTOS NULOS Tipo de atributo cuyos datos no se conocen o no hay valor para el atributo, se da en algunos casos, por ejemplo: en el atributo telfono, se puede dar el caso, que un cliente no tenga telfono. ATRIBUTOS CLAVE DE UNA ENTIDAD Atributos cuyos datos en ningn caso son iguales, por ejemplo: el DNI, puede ser un atributo clave porque no pueden existir 2 clientes con el mismo DNI.Ejemplos atributos univalorados y multivalorados

CLIENTECdigo Apellido Nombre Direccin DNI Figura Nro. 8 Entidad CLIENTE con atributos IMPORTANTE El concepto de dato, se entender mejor al estudiar el modelo relacional.El campo DNI es una atributo univalorado porque no se puede dividir, veamos la

representacin grfica.

El valor del DNI de Manuel es nico y no le pertenece a otro cliente. En cambio el atributo direccin es multivalorado, porque puede tener 0, 1 o ms direcciones, siempre teniendo en cuenta lo que hemos registrado en el anlisis, algunas veces solamente necesitamos registrar una direccin, pero en otros casos, el cliente (empresa que nos contrata para realizar el modelamiento de datos), requiere registrar ms de una direccin, si ese fuera el caso, la entidad cambiara, ese cambio se explicar en el modelo relacional. Ver el ejemplo multivalorado:

Figura Nro. 10 Ejemplo atributos multivalorados Vemos en la figura 10, que Daniel tiene dos direcciones, entonces el atributo direccin es multivalorado.

Para Analizar Muchas veces no es fcil diferenciar si un atributo es entidad, ejemplo: ciudad es un atributo de cliente o es una entidad es si misma.

ASOCIACIONES O RELACIONES ENTRE ENTIDADESLa razn de ser del modelo entidad relacin, son las relaciones entre entidades. Existen varios tipos de relaciones que se explicarn a continuacin.Una relacin es una asociacin entre dos o ms entidades

RELACIN DE UNO A UNO Una entidad A se relaciona con solo una entidad B y una entidad B se relaciona con solo una entidad A.

Ejemplo de entidades con relaciones de uno a uno.

Otra forma de identificar relaciones de uno a uno es la siguiente:

En el caso presentado anteriormente se observa que Daniel tiene el cdigo de matrcula M00001 y Manuel la M00002, claramente se ve que es una relacin de uno a uno. RELACIN DE UNO A MUCHOS Una entidad A se relaciona con muchas entidades B, sin embargo una entidad B se relaciona solamente con una entidad A.

Otra forma de identificar relaciones de uno a muchos es la siguiente:

Esta tcnica es muy buena, usted tiene que ingresar valores al crculo de clientes y al de facturas, en general dentro de los crculos solo hay datos de las entidades cliente y factura, observamos que Mario tiene dos facturas y puede tener muchas ms, y Karina hasta el momento solamente tiene una, pero tambin puede tener ms, por lo tanto es una relacin de uno a muchos de cliente a factura

De factura a cliente, la factura con nmero F00001 solamente le puede pertenecer a Mario y no a otro cliente en ningn caso, entonces concluimos que es una relacin de uno a uno, de factura a cliente. RELACIONES DE MUCHOS A MUCHOS Una entidad A se relaciona con muchas entidades B y una entidad B se relaciona con muchas entidades A.

De ALUMNO a HABILIDAD Un alumno tiene una o muchas habilidades De HABILIDAD a ALUMNO

Esa habilidad la puede tener uno o muchos alumnos

Se observa que Mario tiene varias habilidades como leer rpido y aprender rpido, pero Karina tambin aprende rpido y canta, entonces es una relacin de muchos a muchos, porque un alumno Mario tienes varias habilidades, pero esas habilidades tambin las puede tener otro alumno, como Karina. IMPORTANTE En los ejemplos anteriormente descritos solamente se ha utilizado la notacin pata de gallo, en los ejemplos siguientes se desarrollarn utilizando la otra notacinNotacin CHEN:

Se nota la diferencia, las relaciones se representan por un rombo con los atributos fuera del recuadro de las entidades, los atributos clave, estn subrayados.

Tema 04: Caso Comercial y Alquiler de pelculas

Informacin sobre proveedores: cdigo, nombre, direccin, Telfono, ciudad, pas. Informacin sobre clientes: cdigo, DNI, nombre, direccin, telfono. Informacin sobre artculos: cdigo, nombre, precio unitario, Color, stock. Informacin sobre las facturas indicando cdigo_factura, numero,

CASO COMERCIAL Sea un sistema de informacin que represente la informacin de Proveedores, clientes y artculos disponibles en una determinada empresa de venta de computadoras. Contiene la siguiente informacin:

fecha, subtotal, IGV y total. Informacin sobre la relacin entre clientes y artculos.

Disear un diagrama entidad relacin que describa conceptualmente el sistema de informacin. 1. Encontrar las entidades de informacin:

Proveedor Cliente Articulo Factura

2. Disear las entidades y atributos:

Hasta el momento se ha identificado las principales entidades y atributos; ahora es el momento de relacionar las entidades y terminar de disear el modelo conceptual utilizando el modelo entidad relacin. RELACIN CLIENTE VS FACTURA

Para identificar el tipo de relacin que existe entre la entidad CLIENTE y la entidad FACTURA, se agregan clientes y facturas,

observamos que Mario puede tener en el tiempo varias facturas, pero la factura F00001 y F00002, solamente puede pertenecer a Mario y no a Karina, entonces se concluye que la relacin es de uno a muchos, ya que un cliente puede tener una o muchas facturas, pero esa factura solamente le pertenece a un cliente.

La relacin queda de la siguiente manera:

RELACIN ARTICULO VS FACTURA ARTICULO Codigo Nombre Precio_unitario Color Stock FACTURA Codigo_factura Numero Fecha Subtotal IGV Total

Se observa que un articulo puede estar en varias facturas, y en una factura pueden existir varios artculos, por lo tanto la relacin que se forma es de muchos a muchos.

La relacin final sera:

Relacin PROVEEDOR vs ARTICULO ARTICULO Codigo Nombre Precio_unitario ColorStock

PROVEEDOR Codigo Nombre Direccion Telefono Ciudad Pas

Se observa que un artculo puede ser vendido por varios proveedores, y un proveedor puede vender ms de un artculo a la vez, por lo tanto la relacin es de muchos a muchos.

La relacin que de la siguiente manera:

El modelo final quedara de la siguiente manera:

CASO ALQUILER DE PELICULASLa cadena de Video Clubs Gusters ha decidido, para mejorar su servicio, emplear una base de datos para almacenar la informacin referente a las pelculas que ofrece en alquiler. Esta informacin es la siguiente: Una pelcula se caracteriza por un titulo, nacionalidad, productora y fecha. En una pelcula pueden participar varios actores (nombre, nacionalidad, sexo) algunos de ellos como actores principales. Una pelcula est dirigida por un director (nombre, nacionalidad). De cada pelcula se dispone de uno o varios ejemplares

diferenciados por un nmero de ejemplar y caracterizados por su estado de conservacin. Un ejemplar se puede encontrar alquilado a algn socio (DNI, nombre, direccin, telfono). Se desea almacenar la fecha de comienzo del alquiler y la de devolucin. Un socio tiene que ser avalado por otro socio que responda de l en caso de tener problemas en el alquiler. 1. Identificamos las entidades Pelcula Actor Ejemplar Alquiler Socio

2. Definir entidades y atributos

Cuando el caso requiere mucho anlisis, sugiero leer el enunciado varias veces, para comprender mejor los requerimientos del cliente. RELACIN PELCULA VS ACTOR

La relacin que se forma, es de muchos a muchos, observamos que en la pelcula Tron, puede haber varios actores, y a la vez esos actores pueden participar de varias pelculas. Por ejemplo Cindy Morgan trabaj en Tron y Los viajes de Gulliver.

RELACIN EJEMPLAR VS PELICULA

Observamos que la pelcula Tron tiene varios ejemplares, pero ese ejemplar solamente le pertenece a la pelcula Tron, por lo tanto la relacin es de uno a muchos.

RELACIN EJEMPLAR VS ALQUILER

Se observa que un ejemplar puede ser alquilado por varios socios, y un socio puede alquilar varios ejemplares, por lo tanto la relacin es de muchos a muchos.

RELACIN SOCIO VS ALQUILER

Se observa que un socio puede alquilar una o muchas veces, pero ese alquiler solamente le pertenece a ese socio.

Para concluir, observamos el modelo entidad relacin final para este caso.

1. Introduccin 2. Base de datos relacionales 3. Diseo de las bases de datos relacionales 4. Microsoft access 5. Objetos de la base de datos 6. Conceptos bsicos de una base de datos

1. Introduccin El trmino base de datos fue acuado por primera vez en 1963, en un simposio celebrado en California. De forma sencilla podemos indicar que una base de datos no es ms que un conjunto de informacin relacionada que se encuentra agrupada o estructurada. El archivo por s mismo, no constituye una base de datos, sino ms bien la forma en que est organizada la informacin es la que da origen a la base de datos. Las bases de datosmanuales, pueden ser difciles de gestionar y modificar. Por ejemplo, en una gua de telfonos no es posible encontrar el nmero de un individuo si no sabemos su apellido, aunque conozcamos su domicilio.

Del mismo modo, en un archivo de pacientes en el que la informacin est desordenada por el nombre de los mismos, ser una tarea bastante engorrosa encontrar todos los pacientes que viven en una zona determinada. Los problemas expuestos anteriormente se pueden resolver creando una base de datos informatizada. Desde el punto de vista informtico, una base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulan ese conjunto de datos. Desde el punto de vista ms formal, podramos definir una base de datos como un conjunto de datos estructurados, fiables y homogneos, organizados independientemente en mquina, accesibles a tiempo real, compartibles por usuarios concurrentes que tienen necesidades de informacin diferente y no predecibles en el tiempo. La idea general es que estamos tratando con una coleccin de datos que cumplen las siguientes propiedades:

Estn estructurados independientemente de las aplicaciones y del soporte de almacenamiento que los contiene. Presentan la menor redundancia posible. Son compartidos por varios usuarios y/o aplicaciones.

2. Base de datos relacionales En una computadora existen diferentes formas de almacenar informacin. Esto da lugar a distintos modelos de organizacin de la base de datos: jerrquico, red, relacional y orientada a objeto. Los sistemas relacionales son importantes porque ofrecen muchos tipos de procesos de datos, como: simplicidad y generalidad, facilidad de uso para el usuario final, perodos cortos de aprendizaje y las consultas de informacin se especifican de forma sencilla. Las tablas son un medio de representar la informacin de una forma ms compacta y es posible acceder a la informacin contenida en dos o ms tablas. Ms adelante explicaremos que son las tablas. Las bases de datos relacionales estn constituidas por una o ms tablas que contienen la informacin ordenada de una forma organizada. Cumplen las siguientes leyes bsicas:

Generalmente, contendrn muchas tablas. Una tabla slo contiene un nmero fijo de campos. El nombre de los campos de una tabla es distinto. Cada registro de la tabla es nico. El orden de los registros y de los campos no est determinados. Para cada campo existe un conjunto de valores posible.

3. Diseo de las bases de datos relacionales El primer paso para crear una base de datos, es planificar el tipo de informacin que se quiere almacenar en la misma, teniendo en cuenta dos aspectos: la informacin disponible y la informacin que necesitamos. La planificacin de la estructura de la base de datos, en particular de las tablas, es vital para la gestin efectiva de la misma. El diseo de la estructura de una tabla consiste en una descripcin de cada uno de los campos que componen el registro y los valores o datos que contendr cada uno de esos campos. Los campos son los distintos tipos de datos que componen la tabla, por ejemplo: nombre, apellido, domicilio. La definicin de un campo requiere: el nombre del campo, el tipo de campo, el ancho del campo, etc. Los registros constituyen la informacin que va contenida en los campos de la tabla, por ejemplo: el nombre del paciente, el apellido del paciente y la direccin de este. Generalmente los diferente tispos de campos que su pueden almacenar son los siguientes: Texto (caracteres), Numrico (nmeros), Fecha / Hora, Lgico (informaciones lgicas si/no, verdadero/falso, etc., imgenes. En resumen, el principal aspecto a tener en cuenta durante el diseo de una tabla es determinar claramente los campos necesarios, definirlos en forma adecuada con un nombre especificando su tipo y su longitud. 4. Microsoft access Posiblemente, la aplicacin ms compleja de la suite Office, sea Access, una base de datos visual. Como todas las modernas bases de datos que trabajan en el entorno Windows, puede manejarse ejecutando unos cuantos clic de mouse sobre la pantalla. Access contiene herramientas de diseo y programacin reservadas a los usuarios con mayor

experiencia, aunque incluye bases de datos listas para ser usadas; estn preparadas para tareas muy comunes, que cualquiera puede realizar en un momento determinado ordenar libros, archivar documentacin, etc.-. 5. Objetos de la base de datos Tablas: unidad donde crearemos el conjunto de datos de nuestra base de datos. Estos datos estarn ordenados en columnas verticales. Aqu definiremos los campos y sus caractersticas. Ms adelante veremos qu es un campo. Consultas: aqu definiremos las preguntas que formularemos a la base de datos con el fin de extraer y presentar la informacin resultante de diferentes formas (pantalla, impresora...) Formulario: elemento en forma de ficha que permite la gestin de los datos de una forma ms cmoda y visiblemente ms atractiva. Informe: permite preparar los registros de la base de datos de forma personalizada para imprimirlos. Macro: conjunto de instrucciones que se pueden almacenar para automatizar tareas repetitivas. Mdulo: programa o conjunto de instrucciones en lenguaje Visual Basic 6. Conceptos bsicos de una base de datos Campo: unidad bsica de una base de datos. Un campo puede ser, por ejemplo, el nombre de una persona. Los nombres de los campos, no pueden empezar con espacios en blanco y caracteres especiales. No pueden llevar puntos, ni signos de exclamacin o corchetes. Si pueden tener espacios en blanco en el medio. La descripcin de un campo, permite aclarar informacin referida a los nombres del campo. El tipo de campo, permite especificar el tipo de informacin que cargaramos en dicho campo, esta puede ser:

Texto: para introducir cadenas de caracteres hasta un mximo de 255 Memo: para introducir un texto extenso. Hasta 65.535 caracteres Numrico: para introducir nmeros Fecha/Hora: para introducir datos en formato fecha u hora Moneda: para introducir datos en formato nmero y con el signo monetario Autonumrico: en este tipo de campo, Access numera automticamente el contenido S/No: campo lgico. Este tipo de campo es slo si queremos un contenido del tipo S/No, Verdadero/Falso, etc. Objeto OLE: para introducir una foto, grfico, hoja de clculo, sonido, etc. Hipervnculo: podemos definir un enlace a una pgina Web Asistente para bsquedas: crea un campo que permite elegir un valor de otra tabla o de una lista de valores mediante un cuadro de lista o un cuadro combinado.

Registro: es el conjunto de informacin referida a una misma persona u objeto. Un registro vendra a ser algo as como una ficha. Campo clave: campo que permite identificar y localizar un registro de manera gil y organizada. Propiedades generales de los camposPROPIEDAD Tamao del campo DESCRIPCIN Permite establecer la longitud mxima de un campo de texto numrico. Permite determinar la apariencia de presentacin de los datos, utilizando los formatos predefinidos o nuestros propios formatos Permite especificar el nmero de cifras decimales para mostrar los nmeros. Permite controlar y filtrar los caracteres o valores que los usuarios introducen en un control de cuadro de texto, evitando errores y facilitando su escritura. TIPO DE CAMPO Texto, numrico, contador

Formato

Todos, excepto OLE y Memo

Lugares decimales

Numrico y moneda

Mscara de entrada

Texto, numrico, fecha/hora, moneda

Ttulo

Permite definir una etiqueta de campo predeterminada para un formularios o informe Introduce en el campo un valor cuando se agregan nuevos registros (long. Mx. 255 caracteres) Permite escribir la condicin que deben satisfacer los datos introducidos para ser aceptados

Todos

Valor predeterminado

Todos, excepto OLE y contador

Regla de validacin

Todos, excepto OLE y contador

Texto de validacin

Define el texto del mensaje que se visualiza cuando los datos no Todos excepto OLE y contador cumplen las condiciones enumerdas en la regla de validacin Permite especificar si es necesario que exista un valor en un campo. Permite especificar si una cadena de longitud cero ("") es una entrada vlida para el campo Define un campo como ndice o campo clave. Todos excepto contador

Requerido

Permitir longitud cero

Texto, memo

Indexado

Texto, numrico, contador, fecha/hora.

Las propiedades de un campo, se establecen seleccionando el campo y haciendo clic en la propiedad deseada del cuadro PROPIEDADES DEL CAMPO situado en la parte inferior de la ventana DISEO DE TABLA. Access tiene una configuracin predeterminada para las propiedades de cada uno de los tipos de campo. Sin duda la ms importante es el tamao del campo, ya que este nos permitir hacer una estimacin del espacio ocupado por nuestra base de datos en el disco fijo.

Ingeniera de requisitosDe Wikipedia, la enciclopedia libre Saltar a: navegacin, bsqueda

En la ingeniera de sistemas y la ingeniera de software, la Ingeniera de requisitos o Ingeniera de requerimientos comprende todas las tareas relacionadas con la determinacin de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos. Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traduccin del ingls. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al ingls como request. El propsito de la ingeniera de requisitos es hacer que los mismos alcancen un estado ptimo antes de alcanzar la fase de diseo en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigedades o contradicciones, etc.

Contenido

[ocultar]

1 Implicaciones 2 Fases de implementacin 3 Tcnicas principales o 3.1 Entrevistas o 3.2 Talleres o 3.3 Forma de contrato o 3.4 Objetivos medibles o 3.5 Prototipos o 3.6 Casos de uso 4 Especificacin de requisitos del software 5 Identificacin de las personas involucradas 6 Problemas o 6.1 Relacionados con las personas involucradas o 6.2 Relacionados con los analistas o 6.3 Relacionados con los desarrolladores o 6.4 Soluciones aplicadas 7 Fuentes

[editar] ImplicacionesLa Ingeniera de Requisitos implica todas las actividades del ciclo de vida dedicadas a:

La educcin (a veces llamada "elicitacin", debido a una mala traduccin de "elicitation") de los requisitos de usuario. El anlisis y negociacin de requisitos para derivar requisitos adicionales. La documentacin de los requisitos como especificacin. La validacin de los requisitos documentados contra las necesidades de usuario. As como los procesos que apoyan estas actividades.

[editar] Fases de implementacinDesde un punto de vista conceptual, las actividades son de cinco clases.

Obtener requisitos: a travs de entrevistas o comunicacin con clientes o usuarios, para saber cules son sus expectativas. Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseo. Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados. Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la aplicacin.

Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretenda.

[editar] Tcnicas principalesLa ingeniera de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicolgicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, as que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias tcnicas para obtener los requisitos del cliente. Histricamente, esto ha incluido tcnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Tcnicas ms modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista emplear una combinacin de estos mtodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

[editar] EntrevistasLas entrevistas son un mtodo comn. Por lo general no se entrevista a toda la gente que se relacionar con el sistema, sino a una seleccin de personas que represente a todos los sectores crticos de la organizacin, con el nfasis puesto en los sectores ms afectados o que harn un uso ms frecuente del nuevo sistema.

[editar] TalleresLos requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es til la seleccin de un secretario dedicado a la documentacin de la discusin, liberando al analista del negocio para centrarse en el proceso de la definicin de los requisitos y para dirigir la discusin.

[editar] Forma de contratoEn lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos stos pueden tener centenares de pginas.

[editar] Objetivos mediblesLos requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos crticos del funcionamiento interno que luego darn forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el

progreso en la construccin, para evaluar en cualquier momento qu tan avanzado se encuentra el proyecto.

[editar] PrototiposUn prototipo es una pequea muestra, de funcionalidad limitada, de cmo sera el producto final una vez terminado. Ayudan a conocer la opinin de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

[editar] Casos de usoUn caso de uso es una tcnica para documentar posibles requisitos, graficando la relacin del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y slo se representa su interaccin con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta prctica es mejorar la comunicacin entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta tcnica se enfrenta a los siguientes peligros potenciales.

A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseo final. Los diseadores tienden a reutilizar el cdigo de los prototipos por temor a perder el tiempo al comenzar otra vez. Los prototipos ayudan principalmente a las decisiones del diseo y de la interfaz de usuario. Sin embargo, no proporcionan explcitamente cules son los requisitos. Los diseadores y los usuarios finales pueden centrarse demasiado en el diseo de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.

Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseo grfico, se realizan en una variedad de documentos de diseo grficos y a menudo elimina todo el color del diseo del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusin sobre la apariencia final de la aplicacin.

[editar] Especificacin de requisitos del softwareUna especificacin de requisitos del software es una descripcin completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevn que los usuarios tendrn con el software. Tambin contiene requisitos no funcionales (o suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseo o funcionamiento del sistema (tal como requisitos de funcionamiento, estndares de calidad, o requisitos del diseo).

Las estrategias recomendadas para la especificacin de los requisitos del software estn descritas por IEEE 830-1998. Este estndar describe las estructuras posibles, contenido deseable, y calidades de una especificacin de requisitos del software. Los requisitos se dividen en tres:

Funcionales: son los que el usuario necesita que efecte el software. Ej: el sistema debe emitir un comprobante al asentar la entrega de mercadera. No funcionales: son los "recursos" para que trabaje el sistema de informacin (redes, tecnologa). Ej: el soporte de almacenamiento a usar debe ser MySQL. Empresariales u Organizacionales: son el marco contextual en el cual se implantar el sistema para conseguir un objetivo macro. Ej: abaratar costos de expedicin.

[editar] Identificacin de las personas involucradasDebido a que los cambios que introduce un sistema nuevo tienden a afectar a ms de un tipo de usuario, los analistas de requisitos han de tomar en consideracin a todos los implicados para que se obtengan y depuren sus requisitos de la forma ms fidedigna posible. Entre las personas implicadas hay que considerar:

Organizaciones que integran la organizacin del analista que est diseando el sistema Organizaciones o sistemas de respaldo Direccin Usuarios

[editar] Problemas[editar] Relacionados con las personas involucradasLas vas que pueden dificultar la determinacin de los requisitos son:

Los usuarios no tienen claro lo que desean Los usuarios no se involucran en la elaboracin de requisitos escritos Los usuarios insisten en nuevos requisitos despus de que el coste y la programacin se hayan fijado. La comunicacin con los usuarios es lenta Los usuarios no participan en revisiones o son incapaces de hacerlo. Los usuarios no comprenden los problemas tcnicos Los usuarios no entienden el proceso del desarrollo

Esto puede conducir a la situacin donde las exigencias del consumidor cambian, incluso cuando el desarrollo del producto ya est en marcha.

[editar] Relacionados con los analistas

La correcta redaccin de las Especificaciones de requisitos del Software es imprescindible para el correcto desarrollo del proyecto. Por ello, en su redaccin hay que evitar:

Uso de terminologa ambigua en la redaccin de los documentos de requisitos Sobreespecificacin de los requisitos Escritura poco legible, voz pasiva, abuso de negaciones Uso de verbos en condicional, expresiones subjetivas Ausencia de trminos y verbos del dominio de la aplicacin

[editar] Relacionados con los desarrolladoresLos problemas posibles causados por los desarrolladores durante anlisis de requisitos son:

El personal tcnico y los usuarios finales pueden tener diversos vocabularios y pueden llegar a creer incorrectamente que estn de acuerdo, no dndose cuenta del desacuerdo hasta que se provee el producto final. Los desarrolladores pueden intentar encajar el sistema en un modelo existente, en vez de desarrollar un sistema adaptado a las necesidades del cliente. El anlisis de requisitos se puede realizar a menudo por los ingenieros o programadores, en vez de personal con las habilidades de relacin con la gente y el conocimiento apropiados para entender las necesidades de un cliente correctamente.

[editar] Soluciones aplicadasUna solucin aplicada en los problemas de comunicaciones ha sido emplear a especialistas en anlisis del negocio o del sistema. Las tcnicas introducidas en los aos 90 tienden al uso de prototipos, lenguaje unificado de modelado, casos de uso, y el desarrollo gil de software. Otros tipos de herramientas aplicadas para salvar las diferencias entre los usuarios y las organizaciones de tecnologa de la informacin y que permiten la comprobacin de las aplicaciones son:

pizarras electrnicas para bosquejar los algoritmos y para probar alternativas capacidad de capturar la lgica del negocio y los datos necesarios capacidad de generar los prototipos que imitan fielmente el producto final interactividad la capacidad para agregar requisitos contextuales y otro comentarios capacidad para que usuarios remotos y distribuidos operen con el prototipo

Por ltimo, se requieren herramientas que permitan medir, de forma objetiva, la calidad de una especificacin de requisitos.

Modelo entidad-relacin

De Wikipedia, la enciclopedia libre Saltar a: navegacin, bsqueda Este artculo o seccin necesita referencias que aparezcan en una publicacin acreditada, como revistas especializadas, monografas, prensa diaria o pginas de Internet fidedignas. Puedes aadirlas as o avisar al autor principal del artculo en su pgina de discusin pegando:{{subst:Aviso referencias|Modelo entidad-relacin}} ~~~~

Ejemplo de diagrama E-R.

Un diagrama o modelo entidad-relacin (a veces denominado por sus siglas en ingls, ER "Entity relationship", o del espaol DER "Diagrama de Entidad Relacin") es una herramienta para el modelado de datos que permite representar las entidades relevantes de un sistema de informacin as como sus interrelaciones y propiedades.

Contenido[ocultar]

1 Modelado Entidad-Relacin 2 Base terica y conceptual o 2.1 Entidad o 2.2 Atributos o 2.3 Relacin o 2.4 Conjunto de relaciones 3 Restricciones o 3.1 Correspondencia de cardinalidades o 3.2 Restricciones de participacin 4 Claves 5 Diagrama entidad-relacin o 5.1 Entidades

5.2 Atributos 5.3 Relaciones 6 Diagramas extendidos o 6.1 Entidades fuertes y dbiles o 6.2 Cardinalidad de las relaciones o 6.3 Atributos en relaciones o 6.4 Herencia o 6.5 Agregacin 7 Vase tambin

o o

[editar] Modelado Entidad-RelacinEl Modelo Entidad-Relacin.1. Se elabora el diagrama (o diagramas) entidad-relacin. 2. Se completa el modelo con listas de atributos y una descripcin de otras restricciones que no se pueden reflejar en el diagrama.

El modelado de datos no acaba con el uso de esta tcnica. Son necesarias otras tcnicas para lograr un modelo directamente implementable en una base de datos. Brevemente:

Transformacin de relaciones mltiples en binarias. Normalizacin de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa). Conversin en tablas (en caso de utilizar una base de datos relacional).

[editar] Base terica y conceptualEl modelo de datos entidad-relacin est basado en una percepcin del mundo real que consta de una coleccin de objetos bsicos, llamados entidades, y de relaciones entre esos objetos.

[editar] EntidadRepresenta una cosa u "objeto" del mundo real con existencia independiente, es decir, se diferencia unvocamente de otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad. Algunos Ejemplos:

Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos). Un automvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrn atributos diferentes, por ejemplo, el nmero de chasis). Una casa (Aunque sea exactamente igual a otra, an se diferenciar en su direccin).

Una entidad puede ser un objeto con existencia fsica como: una persona, un animal, una casa, etc. (entidad concreta); o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un nombre,etc. (entidad abstracta). Una entidad est descrita y se representa por sus caractersticas o atributos. Por ejemplo, la entidad Persona las caractersticas: Nombre, Apellido, Gnero, Estatura, Peso, Fecha de nacimiento, etc...

[editar] AtributosLos atributos son las caractersticas que definen o identifican a una entidad. Estas pueden ser muchas, y el diseador solo utiliza o implementa las que considere ms relevantes. Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades. En un conjunto de entidades, cada entidad tiene valores especficos asignados para cada uno de sus atributos, de esta forma, es posible su identificacin unvoca. Ejemplos: A la coleccin de entidades alumnos, con el siguiente conjunto de atributos en comn, (id, nombre, edad, semestre), pertenecen las entidades:

(1, Sofa, 38 aos, 2) (2, Josefa, 19 aos, 5) (3, Carlos, 20 aos, 2) ...

Cada una de las entidades pertenecientes a este conjunto se diferencia de las dems por el valor de sus atributos. Ntese que dos o ms entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos. En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su nmero de id. Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que ser almacenado o a restricciones en los valores que el atributo puede tomar (cadenas de caracteres, nmeros, solo dos letras, solo nmeros mayores que cero, solo nmeros enteros...). Cuando algn atributo correspondiente a una entidad no tiene un valor determinado, recibe el valor nulo, bien sea porque no se conoce, porque no existe o porque no se sabe nada al respecto del mismo.

[editar] Relacin

Describe cierta dependencia entre entidades o permite la asociacin de las mismas.Ejemplo: Dadas dos entidades "Habitacin 502" y "Henry Jonshon Mcfly Bogard", es posible relacionar que la habitacin 502 se encuentra ocupada por el husped de nombre Henry.

Una relacin tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, un husped (entidad), se aloja (relacin) en una habitacin (entidad).

[editar] Conjunto de relacionesConsiste en una coleccin, o conjunto, de relaciones de la misma naturaleza. Ejemplo: Dados los conjuntos de entidades "Habitacin" y "Husped", todas las relaciones de la forma habitacin-husped, permiten obtener la informacin de los huspedes y sus respectivas habitaciones. La dependencia o asociacin entre los conjuntos de entidades es llamada participacin. En el ejemplo anterior los conjuntos de entidades "Habitacin" y "Husped" participan en el conjunto de relaciones habitacin-husped. Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades participantes en la relacin.

[editar] RestriccionesSon reglas que deben mantener los datos almacenados en la base de datos.

[editar] Correspondencia de cardinalidadesDado un conjunto de relaciones en el que participan dos o ms conjuntos de entidades, la correspondencia de cardinalidad indica el nmero de entidades con las que puede estar relacionada una entidad dada. Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser:

Uno a Uno: Una entidad de A se relaciona nicamente con una entidad en B y viceversa (ejemplo relacin vehculo - matrcula: cada vehculo tiene una nica matrcula, y cada matrcula est asociada a un nico vehculo). Uno a varios: Una entidad en A se relaciona con cero o muchas entidades en B. Pero una entidad en B se relaciona con una nica entidad en A (ejemplo vendedor - ventas).

Varios a Uno: Una entidad en A se relaciona exclusivamente con una entidad en B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en A (ejemplo empleadocentro de trabajo). Varios a Varios: Una entidad en A se puede relacionar con 0 o muchas entidades en B y viceversa (ejemplo asociaciones- ciudadanos, donde muchos ciudadanos pueden pertenecer a una misma asociacin, y cada ciudadano puede pertenecer a muchas asociaciones distintas).

[editar] Restricciones de participacinDado un conjunto de relaciones R en el cual participa un conjunto de entidades A, dicha participacin puede ser de dos tipos:

Total: Cuando cada entidad en A participa en al menos una relacin de R. Parcial: Cuando al menos una entidad en A NO participa en alguna relacin de R.

[editar] ClavesEs un subconjunto del conjunto de atributos comunes en una coleccin de entidades, que permite identificar unvocamente cada una de las entidades pertenecientes a dicha coleccin. Asimismo, permiten distinguir entre s las relaciones de un conjunto de relaciones. Dentro de los conjuntos de entidades existen los siguientes tipos de claves:

Superclave: Es un subconjunto de atributos que permite distinguir unvocamente cada una de las entidades de un conjunto de entidades. Si se aade un atributo al anterior subconjunto, el resultado seguir siendo una superclave. Clave candidata: Dada una superclave, si sta deja de serlo quitando nicamente uno de los atributos que la componen, entonces sta es una clave candidata. Clave primaria: Es una clave candidata, elegida por el diseador de la base de datos, para identificar unvocamente las entidades en un conjunto de entidades.

Los valores de los atributos de una clave, no pueden ser todos iguales para dos o ms instancias. Para poder distinguir unvocamente las relaciones en un conjunto de relaciones R, se deben considerar dos casos:

R NO tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de las claves primarias de todos los conjuntos de entidades participantes.

R tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de los atributos asociados y las claves primarias de todos los conjuntos de entidades participantes.

Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria est compuesto de relaciones binarias, con los conjuntos de entidades participantes A y B, se consideran los siguientes casos, segn sus cardinalidades:

R es de muchos a uno de A a B entonces slo se toma la clave primaria de A, como clave primaria de R. R es de uno a muchos de A a B entonces se toma slo la clave primaria de B, como clave primaria de R. R es de uno a uno de A a B entonces se toma cualquiera de las dos claves primarias, como clave primaria de R. R es de muchos a muchos de A a B entonces se toma la unin de los atributos que conforman las claves primarias de A y de B, como clave primaria de R.

[editar] Diagrama entidad-relacinAnteriormente detallamos los conceptos relacionados al modelo ER, en esta seccin profundizaremos en como representarlos grficamente. Cabe destacar que para todo proceso de modelado, siempre hay que tener en claro los conceptos, estos nos brindan conocimiento necesario y adems fundamentan nuestro modelo al momento de presentarlo a terceros. Formalmente, los diagramas ER son un lenguaje grfico para describir conceptos. Informalmente, son simples dibujos o grficos que describen informacin que trata un sistema de informacin y el software que lo automatiza.

[editar] EntidadesLas entidades son el fundamento del modelo entidad relacin. Podemos adoptar como definicin de entidad cualquier cosa o parte del mundo que es distinguible del resto. Por ejemplo, en un sistema bancario, las personas y las cuentas bancarias se podran interpretar como entidades. Las entidades pueden representar entes concretos, como una persona o un avin, o abstractas, como por ejemplo un prstamo o una reserva. Se representan por medio de un rectngulo.

[editar] AtributosSe representan mediante un crculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta. Por motivos de legibilidad, los atributos suelen no aparecer representados en el diagrama entidad-relacin, sino descritos textualmente en otros documentos adjuntos.

[editar] RelacionesSe representan mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir mediante lneas con las entidades (rectngulos) que relaciona, para as saber cul es la relacin que lleva cada uno.

[editar] Diagramas extendidos

DER extendido

Los diagramas Entidad-Relacin no cumplen su propsito con eficacia debido a que tienen limitaciones semnticas. Por ese motivo se suelen utilizar los diagramas Entidad-Relacin extendidos que incorporan algunos elementos ms al lenguaje:

[editar] Entidades fuertes y dbilesCuando una entidad participa en una relacin puede adquirir un papel fuerte o dbil. Una entidad dbil es aquella que no puede existir sin participar en la relacin; es decir, aquella que no puede ser unvocamente identificada solamente por sus atributos. Una entidad fuerte (tambin conocida como entidad regular) es aquella que s puede ser identificada unvocamente. En los casos en que se requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad dbil para que esta ltima se pueda identificar. Las entidades dbiles se representan- mediante un doble rectngulo; es decir, un rectngulo con doble lnea. Se puede hablar de la existencia de 2 tipos de dependencias en las entidades dbiles:

Dependencia por existencia.

Las ocurrencias de la entidad dbil pueden identificarse mediante un atributo identificador clave sin necesidad de identificar la entidad fuerte relacionada.

Dependencia por identificacin.

La entidad dbil no puede ser identificada sin la entidad fuerte relacionada. (Ejemplo: si tenemos una entidad LIBRO y otra relacionada EDICIN, para identificar una edicin necesitamos conocer el identificador del libro).

[editar] Cardinalidad de las relacionesEl tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relacin, respectivamente: "1:1", "1:N" y "N:M", aunque la notacin depende del lenguaje utilizado, la que ms se usa actualmente es el unificado. Otra forma de expresar la cardinalidad es situando un smbolo cerca de la lnea que conecta una entidad con una relacin:

"0" si cada instancia de la entidad no est obligada a participar en la relacin. "1" si toda instancia de la entidad est obligada a participar en la relacin y, adems, solamente participa una vez. "N" , "M", "*" si cada instancia de la entidad no est obligada a participar en la relacin y puede hacerlo cualquier nmero de veces.

Ejemplos de relaciones que expresan cardinalidad:

Cada esposo (entidad) est casado (relacin) con una nica esposa (entidad) y viceversa. Es una relacin 1:1. Una factura (entidad) se emite (relacin) a una persona (entidad) y slo una, pero una persona puede tener varias facturas emitidas a su nombre. Todas las facturas se emiten a nombre de alguien. Es una relacin 1:N. Un cliente (entidad) puede comprar (relacin) varios servicios (entidad) y un servicio puede ser comprado por varios clientes distintos. Es una relacin N:M.

[editar] Atributos en relacionesLas relaciones tambin pueden tener atributos asociados. Se representan igual que los atributos de las entidades. Un ejemplo tpico son las relaciones de tipo "histrico" donde debe constar una fecha o una hora. Por ejemplo, supongamos que es necesario hacer constar la fecha de emisin de una factura a un cliente, y que es posible emitir duplicados de la factura (con distinta fecha). En tal caso, el atributo "Fecha de emisin" de la factura debera colocarse en la relacin "se emite".

[editar] HerenciaLa herencia es un intento de adaptacin de estos diagramas al paradigma orientado a objetos. La herencia es un tipo de relacin entre una entidad "padre" y una entidad "hijo". La entidad "hijo" hereda todos los atributos y relaciones de la entidad "padre". Por tanto, no

necesitan ser representadas dos veces en el diagrama. La relacin de herencia se representa mediante un tringulo interconectado por lneas a las entidades. La entidad conectada por el vrtice superior del tringulo es la entidad "padre". Solamente puede existir una entidad "padre" (herencia simple). Las entidades "hijo" se conectan por la base del tringulo.

[editar] Agregacin

Ejemplo agregacin

Es una abstraccin a travs de la cual las relaciones se tratan como entidades de un nivel ms alto. Se utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Se representa englobando la relacin abstrada y las entidades que participan en ella en un rectngulo. En la figura se muestra un ejemplo de agregacin en el que se representa la situacin en la que un profesor, cuando est impartiendo una clase, puede poner una incidencia ocurrida a lo largo de sta (se fue la luz, falta la configuracin de un determinado software, etc.).

[editar] Vase tambin

Ingeniera del software. Disciplina donde se encuadra el anlisis y diseo de datos. Modelo de datos. Es la visin esttica de un sistema de informacin. Base de datos. Es la implementacin de un modelo de datos. Modelo relacional. Una tcnica formal para describir modelos de datos. UML. Otro lenguaje que permite describir modelos de datos (entre otras cosas). Peter Chen. El autor del modelo entidad-relacin.

RESUMEN UNIDAD DE APRENDIZAJE I:Una base de datos es un conjunto de objetos que se relacionan entre s para cumplir con los objetivos del negocio o rea funcional. El modelamiento de datos se encuentra en la etapa cuatro del diseo del ciclo de vida clsico de los sistemas de informacin. Para modelar correctamente una base de datos se necesita registrar los requisitos del cliente, para lograr esta meta, se utilizan preguntas clave en el momento de la entrevista, luego se documenta toda la informacin, y se elabora el modelo entidad relacin. El proceso de registrar correctamente los requerimientos del cliente se divide en 7 etapas: La etapa de Inicio representa el inicio del proyecto, identificando las necesidades del cliente. En Obtencin, capturars los requisitos del cliente alineados a los objetivos del negocio. En Negociacin la empresa desarrolladora negocia tiempos y costos, es posible que negocie hasta el alcance del proyecto, luego documenta o grafica las especificaciones del cliente, esta es la etapa de Especificaciones. En Validacin se verifica si lo conversado, documentado y graficado va de acuerdo con lo pensado por el cliente. En Gestin, se rastrea los requisitos y los cambios a estos en mientras se desarrolla el proyecto. El modelo entidad relacin es el modelo conceptual ms utilizado, est formado por entidades, atributos y relaciones. Actualmente se le conoce como el modelo entidad relacin extendido, al agregar elementos como la generalizacin y especializacin y la agregacin, aspectos que sern explicados ms adelante. Ya sea en un sistema de ventas o alquiler, el fin es describir en un diagrama entidad relacin el sistema de informacin, para ello debemos saber cmo se realizan las actividades del negocio, luego identificamos las entidades involucradas, agregamos los atributos necesarios para cada entidad y establecemos las relaciones entre entidades.

Para un sistema de venta las entidades principales son: Proveedor, clente, producto, factura. A diferencia, en el sistema de alquiler las entidades necesarias son: Pelcula, actor, socio, ejemplar y alquiler.

MODELO LOGICO

Introduccina)Presentacin y contextualizacinEn esta unidad aprender los conceptos y aplicaciones sobre el Modelo Lgico con relaciones de generalizacin o especializacin, relaciones entre muchos a muchos, la conversin de tabla en el modelo relacional. Le invito a tomar los valiosos conocimientos que contiene esta unidad, siguiendo detalladamente la metodologa planteada.

b)CompetenciaComprende los conceptos del modelo relacional y desarrollar casos prcticos.

c) Capacidades1. Modela bases de datos utilizando especializacin-generalizacin cuando sea necesario. 2. Comprende y aplica los conceptos fundamentales del modelo relacional. 3. Transforma el modelo entidad relacin a modelo relacional. 4. Desarrolla casos prcticos utilizando el modelo relacional.

d)Actitudes Analiza a conciencia los conceptos fundamentales sobre especializacin y generalizacin. Genera hbitos estudiando los conceptos sobre el modelo relacional. Responsable en la entrega de trabajos prcticos. Comparte sus conocimientos con su grupo de trabajo en cuanto a los casos sobre el modelo relacional.

e) Ideas bsicas y contenido esenciales de la Unidad:La Unidad de Aprendizaje 02: Modelo Lgico comprende el desarrollo de los siguientes temas: TEMA 01: ESPECIALIZACIN Y GENERALIZACIN TEMA 02: MODELO RELACIONAL

TEMA 03: MAPEO DE TABLASTEMA 04: CASO VIDEO CLUBS

Tema 01: Especializacin y GeneralizacinLa especializacin se forma cuando se incluyen subgrupos de entidades que se diferencian de alguna forma de las otras entidades del conjunto. Abraham Silberschatz

La especializacin se centra en agrupar entidades comunes, por ejemplo: la entidad cuenta se divide en cuenta de ahorros y cuenta corriente.

CUENTA_AHORRONro_cuenta moneda Tipo_interes

CUENTA_CORRIENTENro_cuenta Moneda Saldo_minimo

La especializacin quedara de la siguiente manera.

CUENTA_AHORRO Generalizacin EspecializacinNro_cuenta moneda

CUENTA_AHORROTipo_interes

CUENTA_CORRIENTESaldo_minimo

En cambio la Generalizacin se basa en entidades que tienen atributos comunes, se forma entonces una entidad super tipo con

atributos generales y otras entidades sub tipo con atributos diferentes, por ejemplo:

ALUMNOCdigo Nombre Paterno Materno Carrera facultad

PROFESORCdigo Nombre Paterno Materno tipo pensin

Observamos que la entidad ALUMNO y PROFESOR tienen atributos comunes: cdigo, nombre, paterno, materno, estos atributos forman parte de la entidad super tipo, que llamaremos PERSONA.

PERSONACdigo Nombre Paterno Materno El modelo terminado quedara de la siguiente manera:

PERSONA Generalizacin EspecializacinCdigo Nombre Paterno Materno

ALUMNOcarrera facultad

PROFESORTipo_pensin

IMPORTANTESi hay confusin en diferenciar la Generalizacin de la especializacin, hay que verlo de la siguiente manera, la generalizacin agrupa atributos comunes en diferentes entidades, en cambio la especializacin extiende entidades, como cuenta, la extendi a cuenta corriente y cuenta de ahorros.

AGREGACIN

Construccin que se utiliza principalmente cuando existen relaciones de muchos a muchos.

En el modelo entidad relacin no se rompe las relaciones de muchos a muchos, solamente se deja expresado, la agregacin se utiliza cuando existen entidades que se tienen que relacionar con la entidad resultante de la relacin de muchos a muchos, observe el siguiente ejemplo: En el caso alquiler de video, haba una relacin PELICULA ACTOR, donde un actor poda participar en muchas pelculas y en una pelcula participaban varios actores, pero la problemtica radica en cul de las dos entidades se debe colocar el atributo tipoactor(principal o secundario), cuyo propsito sera definir cules son actores principales y cuales son actores secundarios, observe la

solucin:

PELICULATitulo Nacionalidad Productora fecha director Cdigo tipo

ACTORNombre Nacionalidad Sexo

TIPO_ACTOR

Con esta constru ccin si se podra contest ar quienes son los actores principa les y secund arios de

una pelcula en especial. En el captulo modelo relacional, se describe y explica la forma de transformar este modelo conceptual a relacional.

Tema 02: Modelo RelacionalEs el tipo de modelo lgico ms utilizado, sus principales componentes son las tablas, campos, datos y registros (tuplas), adems es empleado por casi todos los gestores de base de datos relacionales.

Modelo propuesto por E.F Cood en los laboratorios de IBM en California. Se trata de un modelo lgico que establece una estructura sobre los datos, aunque posteriormente estos puedan ser almacenados de mltiples formas.

TABLAEs todo aquello que se le puede registrar datos o recoger informacin importante para la empresa. Una tabla contiene informacin y est compuesta por datos, a la vez estos datos tienen tipos de datos y

una longitud.

CAMPOCaracterstica que describe a una tabla, adems los campos representan las propiedades bsicas de las tablas y sus relaciones.

DATOElementos conocidos que van dentro de los campos, por ejemplo: el campo nombre el dato Manuel, el campo telfono el dato 2700860, el campo edad el dato 25.

REGISTRO

Contiene una fila de datos en una tabla de informacin.

Para entender mejor los conceptos ver el siguiente grfico:

En

la

tabla

anterior

se

explica del

los

conceptos

fundamentales

modelo

relacional, como se observa la tabla est compuesta por campos como CODIGO,

PATERNO, MATERNO, NOMBRE, datos como 001, Arenas, Olivera, 002, etctera, registros o fila, como 001

MarengoCribilleros Mario, ese conjunto de datos forman un registro. Esa es una forma de representar a una tabla la otra forma es muy parecida a una entidad, con la diferencia que a los campos se le agrega tipos de dato, longitud y si el campo es nulo o no nulo. Antes de representar la otra forma de una tabla, echemos un vistazo a los tipos de datos ms comunes: Cuando el dato es un nmero numrico

Cuando el dato es cadena de caracteres, como un nombre Cuando el dato es fecha u hora hora Cuando el dato es imagen Cuando el tipo de dato tiene dos estados Otra forma de representar la tabla es la siguiente imagen booleano cadena fecha o

ALUMNOCdigo Nombre Paterno Materno IMPORTANTE Cundo colocar nulo a un campo?,Solamente se debe colocar nulo a un campo, si en algn caso, existiera un dato que se dejara en blanco, por ejemplo el campo telfono. CODIGO PATERNO MATERNO NOMBRE TELFONO cadena(3)no nulo cadena(40)no nulo cadena(40)no nulo cadena(40)no nulo

001 002 003 004

Marengo Daz Velarde De los palotes

Cribilleros Arenas Olivera Prez

Mario Carolina Jorge Perico

998998855 981186286

988889563

Se observa en la tabla anterior que el alumno Jorge no tiene nmero telefnico, entonces el campo telfono es de tipo nulo.

CLAVE CANDIDATA

Campos de la tabla a ser clave primaria, una de sus caractersticas es que sus datos no se repiten. Por lo general se debe seleccionar varios campos si los hubiera, aunque en la mayora de los casos solamente uno ser el primario. Observe el siguiente ejemplo: TABLA: AUTOMOVIL NMATRICULA CCA-341 OFG-851 XTV-657 WGB-959 NMOTOR 91123659802 53244659887 12236698988 50602233598 MARCA Toyota Fiat Ford Toyota MODELO Yaris Fiorino Mustang Avensis

En la tabla anterior el campo NMATRICULA y NMOTOR, sus datos no se repiten, por lo tanto son las claves candidatas, porque son las candidatas a ser primarias.

IMPORTANTE Finalmente las claves candidatas solamente sirven para seleccionar al campo primario. En el modelo relacional el campo primario y forneo son los nicos elementos que se contemplan.

CLAVE PRIMARIAEs un campo cuyos datos no se repiten y sirven para las relaciones entre tablas. Observe la explicacin de clave primaria en el siguiente ejemplo: TABLA: AUTOMVIL NMATRICULA CCA-341 OFG-851 XTV-657 WGB-959 NMOTOR 91123659802 53244659887 12236698988 50602233598 MARCA Toyota Fiat Ford Toyota MODELO Yaris Fiorino Mustang Avensis

Realmente cualquiera de las dos claves candidatas puede ser clave primaria, para este caso se escoge al campo NMOTOR como clave principal. Observe la tabla con otro tipo de vista:

AUTOMOVILNmatriculacadena(7) no nulo Nmotor(PK) cadcena(11)no nulo Marca cadena(40) no nulo Modelo cadena(40)no nulo

No siempre la clave primaria se encuentra entre los campos de una tabla sino se debe agregar un campo para definir la clave principal de la tabla. El motivo es por supuesto que tanto para el caso del campo NMOTOR y NMATRICULA, el usuario final ingresara los datos y estara latente el posible error de ingreso de datos.No se debe permitir que el usuario final ingrese los datos del campo clave principal, sino ms bien el sistema gestor o un algoritmo de programacin deben generarlo. Realmente cualquiera de las dos claves candidatas puede ser clave primaria, para este caso se escoge al campo NMOTOR como clave principal. Observe la tabla con otro tipo de vista:

AUTOMOVILCdigo (PK) cadena(10)no nulo no nulo

Nmatricula cadena(7) Nmotor Marca Modelo

cadena(11)no nulo cadena(40)no nulo cadena(40)no nulo NMOTOR 91123659802 53244659887 12236698988 50602233598 MARCA Toyota Fiat Ford Toyota MODELO Yaris Fiorino Mustang Avensis

NMATRICULA CCA-341 OFG-851 XTV-657 WGB-959

Ahora la clave primaria de la tabla AUTOMOVIL, es cdigo, este campo cumple con las caractersticas de campo primario, porque sus datos no se repiten. Otra caracterstica importante es que los datos no sern ingresados por el usuario final, por lo tanto no existe la posibilidad de tener errores en el ingreso de

datos.

CLAVE FORNEA, AJENA O EXTERNATiene varios nombres, no obstante alguna de sus caractersticas son las siguientes:

oConsta de un campo que es primario en latabla origen oPermite relacionar tablas afines oMecanismo para asegurar la integridad de los datos Observen el siguiente grfico:

CLIENTE

FACTURA

Codigocliente(PK) cadena(6) no nulo Apellido Codigofactura(PK) cadena(40) no nulo Nombre cadena(40 cadena(10 ) no nulo Codigocliente(FK) cadena(6) no nulo Fecha fecha noLa relacin entre CLIENTE y FACTURA es de uno a muchos, se identifica que la clave primaria de cliente es codigocliente y de FACTURA codigofactura.

Entonces se observa que la pata de gallo (relacin de muchos) se encuentra en factura, por lo tanto la clave primaria de CLIENTE se agrega como campo de la tabla FACTURA pero como clave fornea. Un aspecto clave a considerar es que el tipo de dato y la longitud debe ser el mismo tanto en la tabla CLIENTE como en la tabla FACTURA.Para que quede claro, observe la relacin entre PELICULA a EJEMPLAR:

PELICULAIdpelicula(PK) cadena(6) no

EJEMPLAR

nulo Titulo

cadena(60) no nulo

Nro(PK)

cadena(10)

no nulo Estado cadena(1)no nulo Idpelicula(FK) cadena(6) no nulo no

Nacionalidad cadena(50) no nulo Productora cadena(50) no nulo Fecha fecha

nulo Director cadena(60) no nulo La duda se encuentra en seleccionar la clave primaria de PELICULA o la clave primaria de EJEMPLAR, la respuesta es fcil, observe siempre donde se encuentra la pata de gallo (marcada con color rojo en esta ocasin), para este caso est en EJEMPLAR, entonces la clave primaria de PELICULA, se agrega como campo forneo en EJEMPLAR, con la misma longitud y tipo de dato. El nombre del campo clave no es necesario que sea el mismo, si se cambia no hay ningn error. Observe ahora el resultado pero con datos para ambas tablas: TABLA: PELICULA

idpelicula P00001 P00002

Titulo Las crnicas

nacionalidad productora fecha Inglesa Warner Bros Warner Bros

Director

15/10/2010 Michael Apted 10/02/2000 Luis Llosa

Anaconda Peruana

TABLA: EJEMPLAR Nro Estado idpelicula

0000000001 0000000002 0000000003

1 1 1

P00001 P00002 P00003

Solo para terminar la idea, existen dos ejemplares para las crnicas y un ejemplar para Anaconda.

INTEGRIDAD REFERENCIAL DE LOS DATOSEn la tabla ejemplar no pueden existir datos de pelculas que no existan en la tabla PELCULA, porque se romperan las reglas de integridad de los datos, es ms los gestores de base de datos validan esta regla. La integridad referencial de los datos se refiere a que los datos que se agregan en el campo forneo tienen que existir en el primario.

RELACIONESEn cuanto a las relaciones, son las mismas que se explicaron en el modelo entidad relacin, es decir de uno a muchos, de muchos a muchos y de uno a uno.

Tema 03: Mapeo de TablasQU ES EL MAPEO?Es el proceso mediante el cual una entidad del modelo entidad relacin se convierte en tabla

del modelo relacional.

Observemos el caso matriculaSe observa la entidad ALUMNO relacionada con la entidad MATRICULA:

ALUMNOidalumno Apellido Nombre direccion

MATRICULAidmatricula mat_fecha mat_grado mat_seccion mat_nive El mapeo de estas dos tablas a modelo relacional, se representa de la siguiente forma.

ALUMNO

MATRICULA

Idalumno(PK) cadena(6) no nulo Apellido no nulo cadena(40)

Idmatricula(PK) cadena(10) no nulo mat_fechafechano nulo mat_gradocadena(15) no

Nombre no nulo

cadena(40)

nulo mat_seccion cadena(5) no

Direccincadena(60) no nulo

nulo mat_nivelcadena(15) no nulo

idalumno(FK)cadena(6)no nulo Como se observa el mapeo es cosa fcil, solamente consiste en lo siguiente:

oCambiar el nombrede la entidad por tabla.

o Agregar el tipo dedato a los campos de la tabla. o Agregar la longitud del campo. o Especificar si el campo es nulo o no nulo.

oAgregar la claveprimaria y fornea si existiera.

oSe cambia elnombre atributo por campo.La segunda forma de representar una tabla es la siguiente TABLA: ALUMNO

IDALUMNO000001

APELLIDODaz Arenas

NOMBREDaniel

DIRECCIONCalle Moyobamba 425 Urb. La Primavera Jr. Los precursores 567 Urb. Los vicus Av. Los prncipes 678Urb. Los tallanes

000002

Vaca Toro

Pedro

000003

Velsquez Pesantes

Mara

TABLA: MATRICULAIDMATRICULA MAT_FECHA MAT_GRADO MAT_SECCION MAT_NIVEL IDALUMNO

0000000001 10/02/2011 Primero 0000000002 10/02/2011 Segundo

A A

Secundaria Secundaria

000002 000001

En este tipo de vista se muestran adems de las

relaciones los datos de las tablas, por lo tanto es muy valioso, es una forma de comprobar si las relaciones del modelo entidad relacin son correctas.

El siguiente caso representa la relacin entre cliente y factura, veamos cmo queda con el modelo relacional.

CLIENTE

FACTURA

Codigo Apellido Nombre Dni ruc

Codigofactura Fecha Nroserie Total Subtotal igv El modelo Mapeado queda de la siguiente manera:

CLIENTE

FACTURA

Codigocliente(PK)cadena(6)no nulo Apellidocadena(40) no nulo Nombrecadena(40) no nulo Dnicadena(8)no nulo Ruccadena(11) no nulo

Codigofactura(PK) cadena(10) no nulo Codigocliente(FK)cadena(6)no nulo Fechafecha no nulo Nroserie numricono nulo Totaldecimalno nulo Subtotaldecimalno nulo Igv decimalno nulo

Si recordamos el modelo entidad relacin, cada vez que se encontraba una relacin de muchos a muchos, se dejaba sin desarrollar, aunque se sabe que este tipo de relaciones se rompe para formar otras tablas.Estas acciones de formar nuevas tablas con las relaciones de muchos a muchos se desarrollan con el modelo relacional, veamos un ejemplo:

La relacin entre alumno y habilidad es de muchos a muchos como se ve expresada en el siguiente grfico:

Se agrega la tabla ALUMNO_HABILIDAD con las claves primarias correspondientes deALUMNO y

HABILIDAD,por este motivo las dos relaciones son de uno a muchos tanto de la tabla ALUMNO a ALUMNO_HABILIDAD y HABILIDAD a ALUMNO_HABILIDAD. Aplicando la lgica, se necesita una construccin de este tipo para almacenar los datos correspondientes a alumnos con sus respectivas habilidades, a continuacin se explica con el siguiente grfico. TABLA: ALUMNO

CODIGO000001 000002

APELLIDODaz Arenas Marengo Cribilleros

NOMBREDaniel Karina

DNI16791125 10544342

TABLA: HABILIDAD

CODIGOHABILIDAD00001 00002 00003 TABLA: ALUMNO_HABILIDAD

NOMBRE_HABILIDADCantar Lectura veloz Bailar

CODIGO00001 00002

CODIGOHABILIDAD00001 00002

00003

00003

De esta forma queda terminado el mapeo de una relacin de muchos a muchos.

MAPEO DE UNA GENERALIZACIN/ESPECIALIZACINLa entidad supertipo PERSONA tiene dos entidades subtipo ALUMNO y PROFESOR. El modelo entidad relacin se expresa en el siguiente grfico

Generalizacin entidad PERSONA El mapeo se representa en el siguiente grfico:

La PK (primary key o clave primaria) de persona aparece tanto en la tabla ALUMNO como en PROFESOR, as se establece un nexo entre ALUMNO y PERSONA o PROFESOR o PERSONA. Es preciso recalcar que la clave primaria de PERSONA, sera fornea (FK) tanto en la tabla PROFESOR como en la tabla ALUMNO.

Tema 04: Caso Video Clubs

La cadena de Video Clubs Gusters ha decidido, para mejorar su

servicio, emplear una base de datos para almacenar referente a la las

informacin

pelculas que ofrece en alquiler. Esta informacin es la siguiente: Una pelcula se caracteriza por un titulo, nacionalidad, productora y fecha. En una pelcula pueden participar varios actores (nombre,

nacionalidad, sexo) algunos de ellos como actores principales. Una pelcula est dirigida por un director (nombre, nacionalidad). De cada pelcula se dispone de uno o varios ejemplares diferenciados por un nmero de ejemplar y caracterizados por su estado de conservacin. Un ejemplar se puede encontrar alquilado a algn socio (DNI, nombre, direccin, telfono). Se desea almacenar la fecha de comienzo del alquiler y la de devolucin. Un socio tiene que ser avalado por otro socio que responda de l en caso de tener problemas en el alquiler. Veamos el modelo entidad relacin del caso alquiler de video

El mapeo a modelo relacionar comienza cambiando las entidades a tablas. Primero se selecciona las tablas que tienen relaciones de muchos a muchos.

PELICULAIdpelicula(PK)cadena(5) no nulo Titulocadena(40)no nulo Idactor nulo

ACTOR(PK)cadena(5)no

Nombrecadena(60)no nulo Nacionalidadcadena(50)no

nulo Productoracadena(50)no nulo Fechacadena(50) no nulo Directorcadena(50)no nulo

Nacionalidadcadena(50)no nulo Sexocadena(1)no nulo Tipoactorcadena(15)no nulo

Una vez que las tablas han sido mapeadas, se rompen las relaciones de muchos a muchos, y se agrega una nueva tabla, en este caso PELICULA_ACTOR.

EJEMPLARNro Estado Se mapea de la siguiente manera

ALQUILERFecha_inicio Fecha_final

En la tabla DETALLE_EJEMPLAR, la clave primaria es una clave compuesta formada por idejemplar y idalquiler. El modelo final quedara de la siguiente manera:

El modelo relacional.

1

EL MODELO RELACIONALEn captulos anteriores hemos estudiado que existen distintos modelos segn los cuales la informacin puede ser almacenada y relacionada entre s. Actualmente, para la mayora de las aplicaciones de gestin que utilizan bases de datos, el modelo ms empleado es el modelo

relacional, por su gran versatilidad, potencia y por los formalismos matemticos sobre los que se basa. Este modelo permite representar la informacin del mundo real de una manera intuitiva, introduciendo conceptos cotidianos y fciles de entender por cualquier inexperto. Asimismo, mantiene informacin sobre las propias caractersticas de la base de datos (metadatos), que facilitan las modificaciones, disminuyendo los problemas ocasionados en las aplicaciones ya desarrolladas. Por otro lado, incorpora mecanismos de consulta muy potentes, totalmente independientes del S.G.B.D., e incluso de la organizacin fsica de los datos; el propio S.G.B.D. es el encargado de optimizar estas preguntas en formato estndar, a sus caractersticas propias de almacenamiento. El modelo relacional fue propuesto por E.F. Codd en los laboratorios de IBM en California. Se trata de un modelo lgico [Irene Luque Ruiz- Ed. Ra-ma], que establece una estructura sobre los datos, aunque posteriormente stos puedan ser almacenados de mltiples formas para aprovechar caractersticas fsicas concretas de la mquina sobre la que se implante la base de datos realmente. Es algo as como guardar unos libros en una biblioteca; dependiendo del nmero de salas de la biblioteca, del tamao y forma de cada una de ellas, su nmero de estanteras, y en definitiva, de las caractersticas fsicas del recinto, podremos disponer los libros de una forma u otra para hacer ms cmoda y fcil su consulta y acceso. Los libros son los mismos, pero pueden ubicarse de muy distintas formas. Vamos a estudiar entonces, las caractersticas concretas de este modelo de datos, sin entrar para nada en cmo los almacena fsicamente cada ordenador, o cada S.G.B.D.

Estructura general.El nombre de modelo relacional viene de la estrecha relacin que existe entre el elemento bsico de este modelo, y el concepto matemtico de relacin. Podemos decir que una relacin R sobre los conjuntos D1, D2, .., Dn, se define como: R D1 D2 ... Dn donde los conjuntos D1, D2, .., Dn pueden ser cualesquiera, e incluso estar repetidos.El modelo relacional.

2Juan Antonio Pedro Cocinero 100 Botones 200 500 700 1200

Nombre Oficio Sueldo- Juan Cocinero 100

- Pedro Botones 700 - Juan Cocinero 200 - Pedro Cocinero 700 - Juan Cocinero 1200Esto e s una relacin.Dado q ue se trata de un con ju nto n o pued e haber elemen to s repetid os.

Nombre Oficio Sueldo

Los conjuntos pueden ser cualesquiera, aunque en el momento en que se trabaja con ordenadores, hay que imponer ciertas restricciones de discretizacin. Si nos fijamos en el dibujo adjunto, podemos ver que una de estas relaciones no es ms que una lista de lneas, donde cada lnea est dividida en trozos. Para observar bien el porqu ha surgido el mtodo relacional, pensemos en cmo almacenaramos las lneas de la lista anterior, si los ordenadores no existiesen. Para almacenar estas lneas, tendramos que emplear papel, de manera que en un folio escribiramos todas las lneas de la lista, empezando por la primera y continuando en el folio secuencialmente; si el folio se acaba, cogemos otro, y hacemos la misma operacin, de forma que, al final, la lista est escrita o almacenada en varios folios. Este mtodo, que es el ms directo, tiene el problema de qu ocurre cuando se desean introducir nuevas lneas. Inicialmente, la tarea parece fcil, pues nos basta con seguir escribiendo lneas tras la ltima lnea de la ltima pgina, e ir tomando nuevos folios a mediada que las pginas se vayan llenando. No obstante, este mtodo slo es adecuado si las lneas no estn ordenadas segn un criterio. Si las lneas ya estn ordenadas, y deseamos introducir una nueva, cmo lo hacemos?, escribiendo una lnea por enmedio con letra ms pequea?, o bien escribiendo de nuevo todas las lneas, pero esta vez con la que se desea insertar? Est claro que ninguna de estas p