Unidad 2

2.1 EL PROCESO DE DISEÑO

El diseño de una base de datos consiste en extraer todos los elementos relevantes de un problema, por ejemplo, saber que datos estàn implicados en el proceso de facturación de una empresa que vende refacciones automotrices, los datos necesarios para el proceso de inscripción de alumnos, etc.

Para la extracción de los datos se debe realizar un análisis minucioso del dominio del problema, y saber, de esta forma, que datos son los puramente necesarios o esenciales para almacenar en la base de datos y eliminar o simplemente no considerar aquellos datos o información que no sea de utilidad.

Una vez extraidos los datos se da inicio al MODELADO, es decir, la construcción, mediante alguna herramienta de diseño de base de datos, un esquema o gráfico que represente conPRECISIÓN TODOS los datos que el problema requiere almacenar.

Normalmente la recopilación de la información del problema se obtiene mediante reuniones con quienes será los usuarios del sistema, a través de entrevistas, platicas formales e informales y cuestionarios. Ahora bien, el problema no se resuelve con solo poner a disposición del usuario final la base de datos, sino que va a requerir un conjunto de programas o software que automaticen el acceso a los datos y su gestión.

Derivado de las diversas reuniones con los usuarios finales se extrae el documento de Especificaciones de Requisitos Software o E.R.S. y partir de éstos se obtiene la información necesaria para la modelización de los datos.

El modelado consiste en representar el problema realizando múltiples abstracciones para entender toda la información de un problema, y de esta manera, generar un mapa donde estén identificados todos los objetos de la base de datos.

El modelado de una base de datos considera lo siguiente:

1. La persona que modeliza la base de datos en la mayoría de las ocasiones no es experta en el dominio del problema a modelar, por lo que es indispensable contar con el apoyo de una persona experta en área del problema a resolver.

2. Se debe modelar siguiendo estándares para que el producto se entienda y sea comprensible por la comunidad informática. Esto implica el uso de herramientas de software del mercado para realizar diseños.

3. La base de datos estará gestionada por un SGBD, de esta manera no se tratará igual la implantación de la base de datos en un sistema MySQL que en Oracle.

Pasos para lograr la interacción y la calidad del modelado:

Se negocia con el usuario final el modelo conceptual, para después transformar el modelo conceptual a modelo lógico y este modelo lógico a físico.

2.2 MODELO ENTIDAD-RELACIÓN

El modelo conceptual es representado a través del modelo entidad-relación, el cual coloca el resultado del análisis del problema real mediante uno o varios diagramas, los cuales son elaborados mediante una serie de figuras, las cuales representan los diversos elementos e información del problema.

ENTIDAD

Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa, persona, concepto abstracto o suceso. Se representa mediante un cuadro o rectángulo.

Existen 2 tipos que son: entidad fuerte y entidad débil, éstas últimas son representadas por un recuadro doble y su existencia depende de una entidad fuerte. Una ocurrencia de una entidad se refiere a una instancia o unidad dentro de la entidad.

RELACIÓN

Es la asociación entre dos o más entidades, las relaciones se identifican con un nombre el cual expresa la finalidad de la relación, no se deben usar nombres que signifiquen muchas cosas. Las relaciones son representadas mediante rombos y el nombre debe colocarse dentro del símbolo sin excepción.

El nombre de una relación generalmente debe ser un verbo, ya que las relaciones describen acciones entre dos o más entidades. Las relaciones están clasificadas según su grado, éste se refiere al número de entidades que participan en la relación. Se recomienda que todas las relaciones sean binarias.

PARTICIPACIÓN

La participación de una ocurrencia de una entidad, indica, mediante una pareja de números, el mínimo y máximo número de veces que puede aparecer en la relación asociada a otra ocurrencia de entidad, éstas son:

(0,1) --------------------------> Mínimo cero, máximo uno
(1,1) --------------------------> Mínimo uno, máximo uno
(0,n) --------------------------> Mínimo cero, máximo n (muchos)
(1,n) --------------------------> Mínimo uno, máximo n (muchos)

CARDINALIDAD

La cardinalidad de una relación se calcula a través de las participaciones de sus ocurrencias. Se toma el número máximo de participaciones de cada una de ellas.

ATRÍBUTOS

Los atributos de una entidad son las características o propiedades que la definen como entidad. Se representan mediante elipses que se conectan a la entidad.

ATRÍBUTO CLAVE

Designa a un campo que no puede repetirse. Además es posible tener un atributo clave constituido por más de un campo. Cuando se tiene una clave como esta se denomina clave compuesta. Cuando es formada por un único atributo se dice que es atómica.

ATRÍBUTO DE RELACIÓN

Propio de una relación y que no puede ser cedido a las entidades.

TIPOS DE ATRÍBUTOS

Atributos simples: Son aquellos que no están divididos en sub partes.

Atributo compuesto: Cuando está formado por más de un atributo.

Atributos monovalorados: Son los que tienen un solo valor

Atributos multivalorado: Son atributos que pueden representar varios valores simultáneamente para una misma ocurrencia de una entidad.

Atributos almacenado: Son los atributos cuyo valor guardan una cantidad que se utiliza para realizar cálculos con otros atributos en otras entidades o en la misma entidad.

Atributo derivado: Son aquellos cuyo valor se puede derivar del valor de otros atributos.

Atributos con valor nulo: Toma un valor nulo cuando una entidad no tiene un valor.

DOMINIOS

El dominio representa la naturaleza del dato, es decir, el conjunto de valores permitidos para un atributo dentro de la figura que le corresponde.

2.3 DISEÑO CON DIAGRAMAS E-R

El modelo de datos E-R da una flexibilidad sustancial en el diseño de un esquema de bases de datos para modelar una empresa dada. Un diseñador de bases de datos puede seleccionar entre el amplio rango de alternativas, éstas son:

Si se usa un atributo o un conjunto de entidades para representa un objeto.

Si un concepto del mundo real se expresa más exactamente mediante un conjunto de entidades o mediante un conjunto de relaciones.

Si se usa una relación ternaria o un par de relaciones binaras.

Un conjunto de entidades fuertes y sus conjuntos de entidades débiles dependientes se pueden considerar como un objeto en la base de datos, debido a que la existencia de las entidades débiles depende de la entidad fuerte.

Un modelo de datos de alto nivel sirve para proporcionar un marco conceptual en el que especificar de forma sistemática los requisitos de datos de los usuarios de la base de datos que existen, y cómo se estructurará la base de datos para completar estos requisitos. La fase inicial del diseño de bases de datos, por tanto, es caracterizar completamente las necesidades de datos esperadas por los usuarios de la base de datos. El resultado de esta fase es una especificación de requisitos del usuario. Esta estructura general se puede expresar gráficamente mediante un diagrama E-R.

El diseñador elige un modelo de datos y, aplicando los conceptos del modelo de datos elegido, traduce estos requisitos a un esquema conceptual. El esquema desarrollado en esta fase de diseño conceptual proporciona una visión detallada del desarrollo.

El diseñador revisa el esquema para confirmar que todos los requisitos de datos se satisfacen realmente y no hay conflictos entre sí. También se examina el diseño para eliminar características redundantes. Lo importante en este punto es describir los datos y las relaciones, más que especificar detalles del almacenamiento físico.

Un esquema conceptual completamente desarrollado indicará también los requisitos funcionales de la empresa. En una especificación de requisitos funcionales los usuarios describen los tipos de operaciones que se realizarán sobre los datos.

El proceso de trasladar un modelo abstracto de datos a la implementación de la base de datos consta de dos fases de diseño finales. En la fase de diseño lógico, el diseñador traduce el esquema conceptual de alto nivel al modelo de datos de la implementación del sistema de base de datos que se usará. El diseñador usa el esquema resultante, en la que se especifican las características físicas de la base de datos.

2.4 MODELO E-R EXTENDIDO

El Modelo Entidad-Relación Extendido incluye todos los conceptos del Entidad-Relación e incorpora los conceptos de Subclase y Superclase con los conceptos asociados de Especialización y Generalización respectivamente.

ESPECIALIZACIÓN:

El proceso por el que se definen las diferentes subclases de una superclase se conoce como especialización. El conjunto de subclases se define basándonos en características diferenciadoras de las ocurrencias de entidad de la superclase. Por ejemplo, el conjunto se subclases {SECRETARIA, INGENIERO, TECNICO} es una especialización de la superclase EMPLEADO mediante la distinción del tipo de trabajo en cada ocurrencia de entidad. Podemos tener varias especializaciones de una misma entidad. Por ejemplo, otra especialización de EMPLEADO podría dar lugar a las subclases ASALARIADO y SUBCONTRATADO, dependiendo del tipo de contrato.

GENERALIZACIÓN:

Es el proceso inverso al de la especialización. Se aplican ambos procesos para construir el esquema E-R extendido. Se basa simplemente en agrupar entidades con atributos comunes en una entidad superior de nivel más alto.

Es decir "La generalización es el resultado de tomar la unión de dos o más conjuntos disjuntos de entidades para producir un conjunto de entidades de nivel más alto.

Entidades agrupadas: subclases de nivel más bajo.

Proceso aplicado dentro de una estrategia de diseño bottom-up, definiendo entidades simples y agrupándolas. Agrupamiento de entidades elimina la redundancia. El proceso de diseño puede ser también de forma ascendente en vez de descendente, de manera que distintos grupos de entidades se sintetizan en grupos de entidades de nivel más alto. Basada en sus similitudes, la generalización sintetiza distintos conjuntos de entidades en uno sólo. La generalización es la inversa de la especialización.

AGREGACIÓN

La agregación es una abstracción a través de la cual las relaciones se tratan como entidades de nivel más alto. Así, se considera el conjunto de relacionestrabaja-en como un conjunto de entidades de nivel más alto denominado trabaja-en.

Tal conjunto de entidades se trata de la misma forma que cualquier otro conjunto de entidades. Se puede crear una relación binaria dirige entre trabaja-en y director para representar quién dirige las tareas, como se muestra a continuación.

2.5 LA NOTACIÓN E-R CON UML

Los diagramas entidad-relación ayudan a modelar el componente de representación de datos de un sistema software. La representación de datos, sólo forma parte de un diseño completo de un sistema complejo de notaciones.

Otros componentes son modelos de interacción del usuario con el sistema, especificación de módulos funcionales del sistema y su interacción, etc. El lenguaje de modelado unificado, propuesto para la creación de especificaciones de componentes de un sistema software. Algunas de las partes principales de UML son:

Diagrama de clase. Un diagrama de clase es similar a un diagrama E-R.
Diagrama de caso de uso. Los diagramas de caso de uso muestran la interacción entre los usuarios y el sistema, en particular los pasos de las tareas que realiza el usuario.
Diagrama de actividad. Los diagramas de actividad describen el flujo de tareas entre varios componentes del sistemaa que se encuentra en uso.
Diagrama de implementación. Muestran los componentes del sistema y sus interconexiones tanto en el nivel del componente software como el hardware.

La siguiente figura muestra varios constructores de diagramas E-R y sus constructores equivalentes de los diagramas de clase UML. UML muestra los conjuntos de entidades como cuadros y a diferencia de E-R, muestra los atributos dentro del cuadro en lugar de como elipses separadas. Unified Modeling Language modela realmente objetos, mientras que E-R modela entidades. Los objetos son como entidades y tienen atributos, pero además proporcionan un conjunto de funciones que se pueden invocar para calcular valores en términos de los atributos de los objetos, o para modificar el propio objeto. Los diagramas de clase pueden describir métodos además de atributos.

Los conjuntos de relaciones binarias se representan en UML dibujando simplemente una línea que conecte los conjuntos de entidades. Se escribe el nombre del conjunto de relaciones adyacente a la línea. También se puede especificar el papel que juega un conjunto de entidades en un conjunto de relaciones escribiendo el nombre del papel en un cuadro, junto con los atributos del conjunto de relaciones, y conectar el cuadro con una línea discontinua a la línea que describe el conjunto de relaciones.

Este cuadro se puede tratar entonces como un conjunto de entidades. Las relaciones no binarias no se pueden representar directamente en UML se deben convertir en relaciones binarias . Las restricciones de cardinalidad se especifican en UML de la misma forma que en los diagramas E-R, de la forma i..s, donde i denota el mínimo y s el máximo número de relaciones en que puede participar una entidad.

Sin embargo, se debería ser consciente que la ubicación de las restricciones es exactamente el inverso de la ubicación de las restricciones en los diagramas Entidad-Relación, como se muestra en la siguiene figura a continuación.

Fuentes de Información

Modelo entidad relación