Tecnolgico de Estudios Superioresde Cuautitln IzcalliOrganismo Pblico Descentralizado del Estado de Mxico

ING.INFORMATICA

Fundamentos de base de datosLuzma Alvares Monrroy

Jimnez Linares Fabin Axel

ndice

INTRODUCCION3 OBJETIVOS3 EL PROCESO DE DISEO.4 EL MODELO DE DATOS ENTIDAD-RELACION (E/R) ....5 RESTRICCIONES.6 DIAGRAMAS ENTIDAD-RELACION6 CONJUNTO DE ENTIDADES DEBILES..7 MODELO ENTIDAD-RELACION EXTENDIDO...7 OTROS ASPECTOS DEL DISEO DE BASE DE DATOS..9 NOTACION ENTIDAD-RELACION CON UML..10

INTRODUCCION

En esta unidad podremos ver en qu consiste el diseo de una base de datos, analizaremos las etapas en las que se puede descomponer y describiremos con detalle las etapas del diseo conceptual y lgico de una base de datos relacional.OBJETIVOS Una base de datos correctamente diseada permite obtener acceso a informacin exacta y actualizada. Puesto que un diseo correcto es esencial para lograr los objetivos fijados para la base de datos, parece lgico emplear el tiempo que sea necesario en aprender los principios de un buen diseo ya que, en ese caso, es mucho ms probable que la base de datos termine adaptndose a sus necesidades y pueda modificarse fcilmente Ser esencial aprender a decidir qu informacin necesita, a dividir la informacin en las tablas y columnas adecuadas y a relacionar las tablas entre s Evitar la informacin duplicada o, lo que es lo mismo, los datos redundantes, porque malgastan el espacio y aumentan la probabilidad de que se produzcan errores e incoherencias Divide la informacin en tablas basadas en temas para reducir los datos redundantes Ayuda a garantizar la exactitud e integridad de la informacin Satisface las necesidades de procesamiento de los datos y de generacin de informes

PROCESO DE DISEO

El proceso de diseo de una base de datos se gua por algunos principios. El primero de ellos es que se debe evitar la informacin duplicada o, lo que es lo mismo, los datos redundantes, porque malgastan el espacio y aumentan la probabilidad de que se produzcan errores e incoherencias. El segundo principio es que es importante que la informacin sea correcta y completa. Si la base de datos contiene informacin incorrecta, los informes que recogen informacin de la base de datos contendrn tambin informacin incorrecta y, por tanto, las decisiones que tome a partir de esos informes estarn mal fundamentadas.Un buen diseo de base de datos es, por tanto, aqul que:Divide la informacin en tablas basadas en temas para reducir los datos redundantes.Proporciona a Access la informacin necesaria para reunir la informacin de las tablas cuando as se precise.Ayuda a garantizar la exactitud e integridad de la informacin.Satisface las necesidades de procesamiento de los datos y de generacin de informes.El proceso de diseo consta de los pasos siguientes:Determinar la finalidad de la base de datosEsto le ayudar a estar preparado para los dems pasos.Buscar y organizar la informacin necesariaRena todos los tipos de informacin que desee registrar en la base de datos, como los nombres de productos o los nmeros de pedidos.Dividir la informacin en tablasDivida los elementos de informacin en entidades o temas principales, como Productos o Pedidos. Cada tema pasar a ser una tabla.Convertir los elementos de informacin en columnasDecida qu informacin desea almacenar en cada tabla. Cada elemento se convertir en un campo y se mostrar como una columna en la tabla. Por ejemplo, una tabla Empleados podra incluir campos como Apellido y Fecha de contratacin.Especificar claves principalesElija la clave principal de cada tabla. La clave principal es una columna que se utiliza para identificar inequvocamente cada fila, como Id. de producto o Id. de pedido.Definir relaciones entre las tablasExamine cada tabla y decida cmo se relacionan los datos de una tabla con las dems tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar las relaciones segn sea necesario.Ajustar el diseoAnalice el diseo para detectar errores. Cree las tablas y agregue algunos registros con datos de ejemplo. Compruebe si puede obtener los resultados previstos de las tablas. Realice los ajustes necesarios en el diseo.Aplicar las reglas de normalizacinAplique reglas de normalizacin de los datos para comprobar si las tablas estn estructuradas correctamente. Realice los ajustes necesarios en las tablas.

EL MODELO DE DATOS ENTIDAD-RELACION (E/R)Cuando se utiliza una base de datos para gestionar informacin, se est plasmando una parte del mundo real en una serie de tablas, registros y campos ubicados en un ordenador; crendose un modelo parcial de la realidad. Antes de crear fsicamente estas tablas en el ordenador se debe realizar un modelo de datos.Se suele cometer el error de ir creando nuevas tablas a medida que se van necesitando, haciendo as el modelo de datos y la construccin fsica de las tablas simultneamente. El resultado de esto acaba siendo un sistema de informacin parcheado, con datos dispersos que terminan por no cumplir adecuadamente los requisitos necesarios.Entidades y RelacionesEl modelo de datos ms extendido es el denominado ENTIDAD/RELACIN (E/R) En el modelo E/R se parte de una situacin real a partir de la cual se definenentidadesyrelacionesentre dichas entidades: Entidad.- Objeto del mundo real sobre el que queremos almacenar informacin (Ej: una persona). Las entidades estn compuestas deatributosque son los datos que definen el objeto (para la entidad persona seran DNI, nombre, apellidos, direccin,...). De entre los atributos habr uno o un conjunto de ellos que no se repite; a este atributo o conjunto de atributos se le llamaclavede la entidad, (para la entidad persona una clave seria DNI). En toda entidad siempre hay al menos una clave que en el peor de los casos estar formada por todos los atributos de la tabla. Ya que pueden haber varias claves y necesitamos elegir una, lo haremos atendiendo a estas normas: Que sea nica. Que se tenga pleno conocimiento de ella.- Por qu en las empresas se asigna a cada cliente un nmero de cliente?. Que sea mnima, ya que ser muy utilizada por el gestor de base de datos. Relacin.- Asociacin entre entidades, sin existencia propia en el mundo real que estamos modelando, pero necesaria para reflejar las interacciones existentes entre entidades. Las relaciones pueden ser de tres tipos: Relaciones 1-1.- Las entidades que intervienen en la relacin se asocian una a una. Relaciones 1-n.- Una ocurrencia de una entidad est asociada con muchas (n) de otra. Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades de la relacin, puede estar asociada con muchas (n) de la otra y viceversa.

RESTRICCIONES

Restricciones de llave1.Relacion trabaja_enUn empleado trabaja en un departamentoUn departamento puede tener varios empleadosSin embargo cada departamento puede tener a lo mas un jefe por la restriccin de llave de la relacin administrativa.

Restricciones estructuralesEs una notacin alternativa a las restricciones de llave(cardinalidad) que incluye un par de nmeros enteros(minimo maximo) a cada participacin.

Restricciones de participacinLa existencia de una entidad depende de que este relacionado con otra entidad a travs de un tipo de vinculo.

DIAGRAMAS ENTIDAD-RELACION

Los diagramas E-R constituyen la representacin grfica de las clases entidad y las clases asociacin necesarias para construir el modelo de datos asociado a las situacin del mundo real que se quiere representar en la base de datos a disear.El proceso para construir un modelo E-R y representarlo a travs del diagrama E-R es un proceso iterativo mas que un proceso secuencial. A partir de una situacin del mundo real los pasos a seguir son:1. Identificar las clases entidad relevantes para el modelo, buscando en la situacin planteada entes con caractersticas propias2. Describir claramente lo que representa cada clase entidad3. Identificar para cada clase entidad los atributos pertinentes4. Identificar las relaciones jerrquicas (supertipo-subtipos) existentes entre las clase entidad5.- Identificar las clases relaciones asociativas existentes entre las clases entidad6. Describir claramente lo que representa cada clase asociacin7.- Definir la cardinalidad mnima y mxima de la clase relacin8.- Interactuar con el usuario, y repetir iterativamente los pasos anteriores hasta considerar completo el modelo

CONJUNTO DE ENTIDADES DEBILES

Una entidad es identificada nicamente por medio de su llave mas la llave de la entidad padreUn conjunto de entidades padres y entidades dbiles deben participar en una relacin uno a muchos(un padre, muchas entidades debiles)Un conjunto de entidades dbiles debe tener participacin total en este conjunto de relaciones identificadores (o propietarias)Se denomina relacin identificadora a la relacin de un tipo de entidad dbil con su propietario

MODELO ENTIDAD-RELACION EXTENDIDO

Los diagramas Entidad-Relacin no cumplen su propsito con eficacia debido a que tienen limitaciones semnticas. Por ese motivo se suelen utilizar losdiagramas Entidad-Relacin extendidosque incorporan algunos elementos ms al lenguaje:Entidades fuertes y dbilesCuando una entidad participa en una relacin puede adquirir un papelfuerteodbil. 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 undoble 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 clavesin necesidad de identificar la entidad fuerte relacionada. Dependencia por identificacin.La entidad dbil no puede ser identificada sin la entidad fuerte relacionada. (Ejemplo: si tenemosuna entidad LIBRO y otra relacionada EDICIN, para identificar una edicin necesitamos conocer el identificador del libro).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.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"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.AgregacinEs 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.).

OTROS ASPECTOS DEL DISEO DE BASE DE DATOS

Dominio:A veces es conveniente aadir informacin sobre el dominio de un atributo, los dominios se representan mediante hexgonos, con la descripcin del dominio en su interior.Diagrama:Un diagrama E-R consiste en representar mediante estas figuras un modelo completo del problema, proceso o realidad a describir, de forma que se definan tanto las entidades que lo componen, como las interrelaciones que existen entre ellas.La idea es simple, aparentemente, pero a la hora de construir modelos sobre realidad es concreta cuando surgen los problemas. La realidad es siempre compleja. Las entidades tienen muchos atributos diferentes, de los cuales debemos aprender a elegir slo los que necesitemos. Lo mismo cabe decir de las interrelaciones.Interrelacin:es la asociacin o conexin entre conjuntos de entidades.Tengamos los dos conjuntos: de personas y de vehculos.Grado:nmero de conjuntos de entidades que intervienen en una interrelacin.De este modo, en la anterior interrelacin intervienen dos entidades, por lo que diremos que es de grado 2 o binaria. Tambin existen interrelaciones de grado Pero las ms frecuentes son las interrelaciones binarias.Podemos establecer una interrelacin ternaria (de grado tres). Existen adems tres tipos distintos de interrelaciones binarias, dependiendo del nmero de entidades del primer conjunto de entidades y del segundo. As hablaremos de interrelaciones 1:1 (uno a uno), 1:N (uno a muchos) y N:M (muchos a muchos).Clave:es un conjunto de atributos que identifican de forma unvoca una entidad. Es muy importante poder identificar claramente cada entidad y cada interrelacin. Esto es necesario para poder referirnos a cada elemento de un conjunto de entidades o interrelaciones, ya sea para consultarlo, modificarlo o borrarlo. No deben existir ambigedades en ese sentido.Claves candidatas:Una caracterstica que debemos buscar siempre en las claves es que contengan el nmeromnimo de atributos, siempre que mantengan su funcin. Diremos que una clave es mnimacuando si se elimina cualquiera de los atributos que la componen, deja de ser clave. Si enuna entidad existe ms de una de estas claves mnimas, cada una de ellas es unaclavecandidataClaves de interrelaciones:Para identificar interrelaciones el proceso es similar, aunque ms simple. Tengamos en cuenta que para definir una interrelacin usaremos las claves primarias de las entidades interrelacionadas. De este modo, el identificador de una interrelacin es el conjunto de las claves primarias de cada una de las entidades interrelacionadas.

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 super clave.Clave primaria (Llave Primaria):Es la clave candidata escogida por el diseador. Atributo o conjunto de atributos que permiten identificar en forma nica una tupla en la tabla (una entidad en un conjunto de entidades) y ningn subconjunto de ella posee esta propiedad.Llave fornea:Es un atributo que es llave primaria en otra entidad con la cual se relaciona. Las llaves forneas son en ltimas las que permiten relacionar las tablas en las bases de datos.

NOTACION ENTIDAD-RELACION CON UML

El Lenguaje Unicado de Modelado preescribe un conjunto de notaciones y diagramas estndar paramodelar sistemas orientados a objetos, y describe la semntica esencial de lo que estos diagramas ysmbolos signican. Mientras que ha habido muchas notaciones y mtodos usados para el diseoorientado a objetos, ahora los modeladores slo tienen que aprender una nica notacin.UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware,y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. Diagramas de Casos de Uso para modelar los procesos business. Diagramas de Secuencia para modelar el paso de mensajes entre objetos. Diagramas de Colaboracin para modelar interacciones entre objetos. Diagramas de Estado para modelar el comportamiento de los objetos en el sistema. Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones. Diagramas de Clases para modelar la estructura esttica de las clases en el sistema. Diagramas de Objetos para modelar la estructura esttica de los objetos en el sistema. Diagramas de Componentes para modelar componentes. Diagramas de Implementacin para modelar la distribucin del sistema.UML es una consolidacin de muchas de las notaciones y conceptos ms usadas orientados a objetos.UML ofrece notacin y semntica estndar:UML preescribe una notacin estndar y semnticas esenciales para el modelado de un sistema orientadoa objetos. Previamente, un diseo orientado a objetos podra haber sido modelado con cualquiera de ladocena de metodologas populares, causando a los revisores tener que aprender las semticas ynotaciones de la metodologa empleada antes que intentar entender el diseo en s.

3