UNIDAD 2

 DISEÑO DE BASE DE DATOS Y EL MODELO E-R

2.1 EL PROCESO DE DISEÑO

El proceso de diseño de una base de datos se guía por algunos principios. El primero de ellos es que se debe evitar la información 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 información sea correcta y completa. Si la base de datos contiene información incorrecta, los informes que recogen información de la base de datos contendrán también información incorrecta y, por tanto, las decisiones que tome a partir de esos informes estarán mal fundamentadas.

Un buen diseño de base de datos es, por tanto, aquél que:

·       Divide la información en tablas basadas en temas para reducir los datos redundantes.

·       Proporciona a Access la información necesaria para reunir la información de las tablas cuando así se precise.

·       Ayuda a garantizar la exactitud e integridad de la información.

·       Satisface las necesidades de procesamiento de los datos y de generación de informes.

El proceso de diseño consta de los pasos siguientes:

·       Determinar la finalidad de la base de datos

Esto le ayudará a estar preparado para los demás pasos.

·       Buscar y organizar la información necesaria

Reúna todos los tipos de información que desee registrar en la base de datos, como los nombres de productos o los números de pedidos.

·       Dividir la información en tablas

Divida los elementos de información en entidades o temas principales, como Productos o Pedidos. Cada tema pasará a ser una tabla.

·       Convertir los elementos de información en columnas

Decida qué información 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 podría incluir campos como Apellido y Fecha de contratación.

·       Especificar claves principales

Elija la clave principal de cada tabla. La clave principal es una columna que se utiliza para identificar inequívocamente cada fila, como Id. de producto o Id. de pedido.

·       Definir relaciones entre las tablas

Examine cada tabla y decida cómo se relacionan los datos de una tabla con las demás tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar las relaciones según sea necesario.

·       Ajustar el diseño

Analice el diseño 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 diseño.

·       Aplicar las reglas de normalización

Aplique reglas de normalización de los datos para comprobar si las tablas están estructuradas correctamente. Realice los ajustes necesarios en las tablas.

2.2 EL MODELO DE DATOS ENTIDAD-RELACION (E/R)

Cuando se utiliza una base de datos para gestionar información, se está plasmando una parte del mundo real en una serie de tablas, registros y campos ubicados en un ordenador; creándose un modelo parcial de la realidad. Antes de crear físicamente 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 construcción física de las tablas simultáneamente. El resultado de esto acaba siendo un sistema de información parcheado, con datos dispersos que terminan por no cumplir adecuadamente los requisitos necesarios.

Entidades y Relaciones

El modelo de datos más extendido es el denominado ENTIDAD/RELACIÓN (E/R) En el modelo E/R se parte de una situación real a partir de la cual se definen entidades y relaciones entre dichas entidades:

• Entidad.- Objeto del mundo real sobre el que queremos almacenar información (Ej: una persona). Las entidades están compuestas de atributos que son los datos que definen el objeto (para la entidad persona serían DNI, nombre, apellidos, dirección,...). De entre los atributos habrá uno o un conjunto de ellos que no se repite; a este atributo o conjunto de atributos se le llama clave de 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 número de cliente?.
• Que sea mínima, ya que será muy utilizada por el gestor de base de datos.
• Relación.- Asociación 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 relación se asocian una a una (Ej: la entidad HOMBRE, la entidad MUJER y entre ellos la relación MATRIMONIO).
• Relaciones 1-n.- Una ocurrencia de una entidad está asociada con muchas (n) de otra (Ej: la entidad EMPERSA, la entidad TRABAJADOR y entre ellos la relación TRABAJAR-EN).
• Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades de la relación, puede estar asociada con muchas (n) de la otra y viceversa (Ej: la entidad ALUMNO, la entidad EMPRESA y entre ellos la relación MATRÍCULA).

Representación gráfica de Entidades y Relaciones

Para asimilar fácilmente un diseño de datos cuando se emplea el modelo E/R se utilizan los siguientes elementos gráficos:

La utilización de estos elementos dará como resultado lo que se denomina el esquema entidad-relación de la base de datos. Los ejemplos que se incluyen en el apartado anterior, gráficamente quedarían como sigue:

2.3 RESTRICCIONES

Restricciones de llave

1.     Relacion “trabaja_en”

·       Un empleado trabaja en un departamento

·       Un departamento puede tener varios empleados

·       Sin embargo cada departamento puede tener a lo mas un jefe por la restricción de llave de la relación administrativa.

Restricciones estructurales

·       Es una notación alternativa a las restricciones de llave(cardinalidad) que incluye un par de números enteros(minimo maximo) a cada participación.

Restricciones de participación

·       La existencia de una entidad depende de que este relacionado con otra entidad a través de un tipo de vinculo.

2.4 LOS DIAGRAMAS E-R

Los diagramas E-R constituyen la representación gráfica de las clases entidad y las clases asociación necesarias para construir el modelo de datos asociado a las situación del mundo real que se quiere representar en la base de datos a diseñar.

El proceso para construir un modelo E-R y representarlo a través del diagrama E-R es un proceso iterativo mas que un proceso secuencial. A partir de una situación del mundo real los pasos a seguir son:

1. Identificar las clases entidad relevantes para el modelo, buscando en la situación planteada entes con características propias

2. Describir claramente lo que representa cada clase entidad

3. Identificar para cada clase entidad los atributos pertinentes

4. Identificar las relaciones jerárquicas (supertipo-subtipos) existentes entre las clase entidad

5.- Identificar las clases relaciones asociativas existentes entre las clases entidad

6. Describir claramente lo que representa cada clase asociación

7.- Definir la cardinalidad mínima y máxima de la clase relación

8.- Interactuar con el usuario, y repetir iterativamente los pasos anteriores hasta considerar completo el modelo

2.6 CONJUNTO DE ENTIDADES DEBILES

Una entidad es identificada únicamente por medio de su llave mas la llave de la entidad padre

·       Un conjunto de entidades padres y entidades débiles deben participar en una relación uno a muchos(un padre, muchas entidades debiles)

·       Un conjunto de entidades débiles debe tener participación total en este conjunto de relaciones identificadores (o propietarias)

·       Se denomina relación identificadora a la relación de un tipo de entidad débil con su propietario

2.7 MODELO ENTIDAD-RELACION EXTENDIDO

Los diagramas Entidad-Relación no cumplen su propósito con eficacia debido a que tienen limitaciones semánticas. Por ese motivo se suelen utilizar los diagramas Entidad-Relación extendidos que incorporan algunos elementos más al lenguaje:

Entidades fuertes y débiles

Cuando una entidad participa en una relación puede adquirir un papel fuerte o débil. Una entidad débil es aquella que no puede existir sin participar en la relación; es decir, aquella que no puede ser unívocamente identificada solamente por sus atributos.

Una entidad fuerte (también conocida como entidad regular) es aquella que sí puede ser identificada unívocamente. En los casos en que se requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad débil para que esta última se pueda identificar.

Las entidades débiles se representan- mediante un doble rectángulo; es decir, un rectángulo con doble línea.

Se puede hablar de la existencia de 2 tipos de dependencias en las entidades débiles:

• Dependencia por existencia.

 Las ocurrencias de la entidad débil pueden identificarse mediante un atributo identificador clave

sin necesidad de identificar la entidad fuerte relacionada.

• Dependencia por identificación.

La entidad débil no puede ser identificada sin la entidad fuerte relacionada. (Ejemplo: si tenemos

una entidad LIBRO y otra relacionada EDICIÓN, para identificar una edición necesitamos conocer el identificador del libro).

 Cardinalidad de las relaciones

El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relación, respectivamente: "1:1", "1:N" y "N:M", aunque la notación depende del lenguaje utilizado, la que más se usa actualmente es el unificado. Otra forma de expresar la cardinalidad es situando un símbolo cerca de la línea que conecta una entidad con una relación:

• "0" si cada instancia de la entidad no está obligada a participar en la relación.
• "1" si toda instancia de la entidad está obligada a participar en la relación y, además, solamente participa una vez.
• "N" , "M", ó "*" si cada instancia de la entidad no está obligada a participar en la relación y puede hacerlo cualquier número de veces.

Ejemplos de relaciones que expresan cardinalidad:

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

Atributos en relaciones

Las relaciones también pueden tener atributos asociados. Se representan igual que los atributos de las entidades. Un ejemplo típico son las relaciones de tipo "histórico" donde debe constar una fecha o una hora. Por ejemplo, supongamos que es necesario hacer constar la fecha de emisión 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 emisión" de la factura debería colocarse en la relación "se emite"

 Herencia

La herencia es un intento de adaptación de estos diagramas al paradigma orientado a objetos. La herencia es un tipo de relación 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 relación de herencia se representa mediante un triángulo interconectado por líneas a las entidades. La entidad conectada por el vértice superior del triángulo es la entidad "padre". Solamente puede existir una entidad "padre" (herencia simple). Las entidades "hijo" se conectan por la base del triángulo.

 Agregación

Es una abstracción a través de la cual las relaciones se tratan como entidades de un nivel más alto. Se utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Se representa englobando la relación abstraída y las entidades que participan en ella en un rectángulo. En la figura se muestra un ejemplo de agregación en el que se representa la situación 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 configuración de un determinado software, etc.).

LA UML

UML [UML] es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software .

UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo  estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios  de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión, por poner un ejemplo.

Las diferencias son muy marcadas y afectan a todas las faces del proceso. El método del UML recomienda utilizar los procesos que otras metodologías tienen definidos.

Herramientas UML

Pero volviendo a la definición de UML como "conjunto de herramientas", si nos imaginamos UML como una caja de herramientas con su martillo, destornillador, alicates, etc. Veamos qué contiene nuestra caja de herramientas:

• Diagrama de casos de uso
• Diagrama de clases
• Diagrama de estados
• Diagrama de secuencias
• Diagrama de actividades
• Diagrama de colaboraciones
• Diagrama de componentes
• Diagrama de distribución

Pero siguiendo con la analogía, si vamos a colgar un cuadro no usaremos todas las herramientas de nuestra caja, posiblemente sólo usemos el martillo para clavar el clavo.

Lo mismo pasa con UML, una vez que conozcamos las herramientas usaremos en cada momento las más adecuadas a nuestras necesidades. Nos os voy a decir que esto sea fácil, pues hay que saber para qué sirven y qué limitaciones tienen unas y otras para conocer su utilidad. Pero se puede alcanzar este conocimiento con un poco de práctica y sentido común.

Qué no es UML

UML no es un método de desarrollo. No te va a decir cómo pasar del análisis al diseño y de este al código. No son una serie de pasos que te llevan a producir código a partir de unas especificaciones.

UML al no ser un método de desarrollo es independiente del ciclo de desarrollo que vayas a seguir, puede encajar en un tradicional ciclo en cascada, o en un evolutivo ciclo en espiral o incluso en los métodos ágiles de desarrollo.

REFERENCIAS

·       usuarios.multimania.es/cursosgbd/UD4.htm

·       www.slideshare.net/emnero2/​diseo-de-base-de-datos-360943

·       usuarios.multimania.es/cursosgbd/UD4.htm

·       www.cs.us.es/cursos/bd-2002/HTML/​modeloER.htm

·       www.ingenierosoftware.com/analisisydiseno/​uml.php

·       http://uml.org/