2.1 EL PROCESO DE DISEÑO DE UNA BD
Si usa un proceso de diseño de base de datos
establecido, puede crear de forma rápida y efectiva
una base de datos bien diseñada que le proporciona acceso conveniente a la
información que desea. Con un diseño sólido tardará menos tiempo en construir
la base de datos y obtendrá resultados más rápidos y precisos.
A continuación se indican los pasos que hay que seguir en el proceso de diseño de una base de datos. Cada paso se trata con mayor detalle en los temas restantes de esta sección.
• 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.
A continuación se indican los pasos que hay que seguir en el proceso de diseño de una base de datos. Cada paso se trata con mayor detalle en los temas restantes de esta sección.
• 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 Elementos del modelo
entidad-relación
Entidad
Se trata de un objeto del que se recoge información de interés de cara a la base de datos. Gráficamente se representan mediante un rectángulo. Un ejemplo seria la entidad banco, donde se recogerían los datos relativos a ese banco, como puede ser el nombre, el número de sucursal, la dirección, etc.
Dentro de las entidades pueden ser fuertes o débiles. Las fuertes son las que no dependen de otras entidades para existir, mientras que las entidades débiles siempre dependen de otra entidad sino no tienen sentido por ellas mismas.
Relación
Podemos definir la relación como una asociación de dos o más entidades. A cada relación se le asigna un nombre para poder distinguirla de las demás y saber su función dentro del modelo entidad-relación. Otra característica es el grado de relación, siendo las de grado 1 relaciones que solo relacionan una entidad consigo misma. Las de grado 2 son relaciones que asocian dos entidades distintas, y las de grado n que se tratan de relaciones que unen mas de dos entidades.
Las relaciones se representas gráficamente con rombos, dentro de ellas se coloca el nombre de la relación.
Otra característica es el tipo de correspondencia entre dos relaciones;
Entidad
Se trata de un objeto del que se recoge información de interés de cara a la base de datos. Gráficamente se representan mediante un rectángulo. Un ejemplo seria la entidad banco, donde se recogerían los datos relativos a ese banco, como puede ser el nombre, el número de sucursal, la dirección, etc.
Dentro de las entidades pueden ser fuertes o débiles. Las fuertes son las que no dependen de otras entidades para existir, mientras que las entidades débiles siempre dependen de otra entidad sino no tienen sentido por ellas mismas.
Relación
Podemos definir la relación como una asociación de dos o más entidades. A cada relación se le asigna un nombre para poder distinguirla de las demás y saber su función dentro del modelo entidad-relación. Otra característica es el grado de relación, siendo las de grado 1 relaciones que solo relacionan una entidad consigo misma. Las de grado 2 son relaciones que asocian dos entidades distintas, y las de grado n que se tratan de relaciones que unen mas de dos entidades.
Las relaciones se representas gráficamente con rombos, dentro de ellas se coloca el nombre de la relación.
Otra característica es el tipo de correspondencia entre dos relaciones;
- 1:1. Uno a uno, a cada ocurrencia de una entidad le corresponde como máximo una ocurrencia de la otra entidad relacionada.
- 1:N. Uno a Mucho, a cada ocurrencia de la entidad A le pueden corresponder varias de la entidad B.
- N:M. Muchos a muchos, cada ocurrencia de una entidad puede contener varias de la otra entidad relacionada y viceversa.
Para finalizar las
características de la relación tenemos la cardinalidad que define el número
máximo y mínimo de ocurrencias de cada tipo de entidad. Se representa con los
valores máximo coma mínimo encerrados entre paréntesis encima de la relación.
(máximo, mínimo)
Atributo
Se define como cada una de las propiedades de una entidad o relación. Cada atributo tiene un nombre y todos los posibles valores que puede tener. Dentro de una entidad tiene que haber un atributo principal que identifica a la entidad y su valor tiene que ser único. Un ejemplo de atributo principal seria el dni dentro de la entidad persona.
Ponemos un ejemplo de lo que seria un esquema del modelo entidad-relacion.
Atributo
Se define como cada una de las propiedades de una entidad o relación. Cada atributo tiene un nombre y todos los posibles valores que puede tener. Dentro de una entidad tiene que haber un atributo principal que identifica a la entidad y su valor tiene que ser único. Un ejemplo de atributo principal seria el dni dentro de la entidad persona.
Ponemos un ejemplo de lo que seria un esquema del modelo entidad-relacion.
2.3
Restricciones
|
Especifica cuando la existencia de una entidad X depende de la
existencia de otra entidad Y.
Existen diferentes tipos de
restricciones de participación
- Parcial
Total o dependencia de
existencia
- Débil
|
2.4
Diagrama
entidad-relación
La
estructura lógica general de una base de datos puede expresarse en forma
gráfica por
medio de un
diagrama ER que se integra con los siguientes componentes:
Rectángulos:
representan conjuntos de entidades.
Elipses:
representan atributos.
Rombos:
representa conjuntos de relaciones.
Líneas: conectan
los atributos a los conjuntos
de entidades, y los
conjuntos de
entidades a
los conjuntos de relaciones.
Cada
componente se etiqueta con su nombre correspondiente.
Para
ilustrar lo anterior veremos los siguientes ejemplos.
En este ejemplo se ve conjuntos
de entidades, cliente y
cuenta, vinculados entre sí
mediante un
conjunto binario de relaciones clientecuenta.
Para
distinguir las cardinalidades de las relaciones se dibuja líneas con y sin
dirección.
En el
ejemplo anterior puede verse que el conjunto de relaciones clientecuenta es muchas
a
muchas (al
carecer de dirección, las líneas).
Los
diagramas Entidad-Relación representan la estructura lógica de una BD de manera
gráfica. Los símbolos utilizados son los siguientes:
2.5 Conjunto de Entidades Débiles
|
Las
entidades que no tienen atributos llave se conocen como entidades débiles.
Las
entidades de este tipo se identifican relacionándolas con otras entidades en
combinación con algunos de sus atributos. Esa otra entidad se denomina
entidad fuerte o propietaria.
Una
entidad débil siempre tiene una dependencia de existencia (restricción de
participación total) con respecto a la entidad fuerte.
Cada
entidad préstamo es la propietaria de las entidades pagos que se relacionan
con él.
· El
discriminador o (llave parcial) de una entidad débil es el conjunto de
atributos que pueden identificar de manera única a las entidades d´ebiles
relacionadas a la misma entidad propietaria.
· La llave
primaria se forma por la llave primaria de la entidad fuerte que es la entidad
propietaria m´as el discriminador de la entidad débil.
· La entidad
débil se especifica con un doble rectángulo.
· El
relación que asocia las entidades débiles con las fuertes se especifican con
un doble rombo.
· El
discriminador se subraya con una lınea discontinua.
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. Otro nuevo concepto incluido por el ERE es el de Categoría.
Asociado a estos conceptos está el importante mecanismo de Herencia de
atributos. Habrá que tener en cuenta que no existe una terminología
estandarizada para estos conceptos, por lo que usaremos la mas difundida.
Subclases, Superclases y Especialización.
En el modelo Entidad-Relación, una
entidad agrupa un conjunto de ocurrencias de entidad del mismo tipo. En muchos
casos, estas ocurrencias se pueden agrupar a su vez en otros subconjuntos que
tienen un significado propio para los propósitos de la Base de
Datos y, por tanto, deberían
representarse de forma explícita. Por ejemplo, la entidad EMPLEADO puede a su
vez subdividirse en SECRETARIA, INGENIERO, JEFE, TÉCNICO, ASALARIADO,
SUBCONTRATADO, etc. El conjunto de ocurrencias de entidad en cada una de estas
entidades será un subconjunto de las ocurrencias de entidad de EMPLEADO, ya que
por ejemplo, un ingeniero también es un empleado. Llamaremos a cada uno de
estos subconjuntos Subclases de la entidad EMPLEADO y a EMPLEADO una Supercalse
de cada uno de estos subconjuntos.
Llamaremos a la relación existente entre
las Superclases y las Subclases como relación Clase/Subclase. En el ejemplo
anterior, EMPLEADO/SECRETARIA y EMPLEADO/TÉCNICO son dos relaciones
Clase/Subclase. Hay que tener en cuenta que una ocurrencia de una Subclase
representa el mismo objeto real que alguna correspondiente a su Superclase, por
ejemplo la SECRETARIA "Concha Leco" será también la EMPLEADO
"Concha Leco". Por tanto, la ocurrencia de Subclase es la misma que
en la Superclase pero con un rol específico. Una ocurrencia de Subclase no
tienen sentido si no es a su vez ocurrencia de Superclase. Por otro lado, una
ocurrencia de superclase puede ser a su vez ocurrencia de varias subclases o de
ninguna. Por ejemplo, "Roberto Mate" como ocurrencia de EMPLEADO
puede a su vez pertenecer a subclases INGENIERO y ASALARIADO.
Herencia de atributos en la relación Clase/subclase.
Debido a que una subclase es a su vez
parte se una superclase, la subclase tendrá sus atributos específicos así como
los atributos correspondientes a la superclase a la que pertenece. Esto quiere
decir que la ocurrencia de entidad de una subclase hereda los atributos correspondientes a la superclase a la que
pertenece. De la misma manera hereda las relaciones en las que su
correspondiente superclase participa.
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 basándonos en distintos criterios. Por ejemplo, otra
especialización de EMPLEADO podría dar lugar a las subclases ASALARIADO y
SUBCONTRATADO, dependiendo del tipo de contrato.
. Diagramas ERE.
La figura 1 muestra como se representa la
especialización en un diagrama ERE. Las subclases definidas por una
especialización están unidas mediante líneas a un circulo, que conecta con la
superclase. El símbolo de pertenencia en las líneas entre las subclases y el
circulo representan la dirección de la relación clase/subclase. Los tributos
aplicables solamente a cada una de las subclases se unen a estas mediante arcos
(por ejemplo, velocidad en la
subclase SECRETARIA). Estos atributos se denominan atributos específicos de la subclase. Las subclases también pueden
tener relaciones especificas con otras entidades (por ejemplo, la relación
PERTENECE entre SUBCONTRATADO y EMPRESA). El símbolo d del círculo se explicará
mas adelante.
Utilización de subclases en los modelos de datos.
Hay dos razones principales para el uso
de la relación clase/subclase en los modelos de datos. La primera es que
ciertos atributos no pueden ser aplicados a todas las ocurrencias de entidad
correspondiente a la superclase. Una subclase se define para agrupar aquellas
ocurrencias de entidad donde el atributo es aplicable. Suele ocurrir que las
subclases comparten la mayoría de los atributos correspondientes a la
supercalse.
Modelado
Conceptual de Objetos mediante
Diagramas
de clase UML
•
El Lenguaje Unificado de Modelado
(Unified Modeling Language, UML) es un lenguaje estándar para escribir planos
de software.
•
UML puede utilizarse para visualizar,
especificar, construir y documentar un sistema que involucra una gran cantidad
de software.
•
UML
es sólo un lenguaje y por tanto es tan sólo una parte de un método de
desarrollo de software.
Las
funciones de UML
•
Visualizar: Utiliza
símbolos gráficos.
•
Especificar: Cubre la especificación de todas las
decisiones de análisis, diseño e implementación que deben realizarse al
desarrollar y desplegar un sistema .
•
Construir: Sus modelos pueden conectarse de forma
directa a una gran variedad de lenguajes de programación. Java, C++ o Visual
Basic, o incluso a tablas en una base de datos.
•
Documentar: Requisitos. Arquitectura. Diseño.
Código fuente. Planificación de proyectos. Pruebas
•
UML
está pensado principalmente para sistemas con gran cantidad de software.
Ha sido utilizado de forma efectiva
en dominios tales como: Sistemas de información de empresa. Bancos y servicios
financieros. Telecomunicaciones. Transporte. Defensa/industria aeroespacial.
Comercio. Electrónica médica. Ámbito científico. Servicios distribuidos basados
en la Web
¿Qué es lo básico que debemos
aprender de UML?
Bloques de construcción de UML
El vocabulario de UML incluye tres
clases de bloques de construcción:
Elementos.
Relaciones.
Diagramas.
Los elementos son abstracciones que
son ciudadanos de primera clase en un modelo; las relaciones ligan estos elementos
entre sí; los diagramas agrupan colecciones interesantes de elementos.
Elementos en UML.
Hay cuatro tipos de elementos en UML:
•
Elementos estructurales.
•
Elementos de comportamiento.
•
Elementos de agrupación.
•
Elementos de anotación
Relaciones en UML.
Hay cuatro tipos de relaciones en UML:
•
Dependencia.
•
Asociación.
•
Generalización.
•
Realización.
Diagramas en
UML.
•
Un
diagrama es la representación gráfica de un conjunto de elementos,
visualizado la mayoría de las veces como un grafo conexo-de nodos (elementos) y
arcos (relaciones). Los diagramas se dibujan para visualizar un sistema desde
diferentes perspectivas, de forma que un diagrama es una proyección de un
sistema. Para todos los sistemas, excepto los más triviales, un diagrama
representa una vista resumida de los elementos que constituyen un sistema.
UML incluye nueve de estos diagramas:
•
Diagrama de clases.
•
Diagrama de objetos.
•
Diagrama
de casos de uso.
•
Diagrama de secuencia.
•
Diagrama de colaboración.
•
Diagrama de estados (statechart).
•
Diagrama de actividades.
•
Diagrama de componentes.
•
Diagrama de despliegue.
Diagrama de
secuencia
Muestran las interacciones entre un conjunto de objetos, ordenadas según el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboración, es decir son instancias concretas de una clase que participa en la interacción. El objeto puede existir sólo durante la ejecución de la interacción, se puede crear o puede ser destruido durante la ejecución de la interacción. Un diagrama de secuencia representa una forma de indicar el período durante el que un objeto está desarrollando una acción directamente o a través de un procedimiento. En este tipo de diagramas también intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operación del objeto destino. Existen distintos tipos de mensajes según cómo se producen en el tiempo: simples, síncronos, y asíncronos. Los diagrama de secuencia permiten indicar cuál es el momento en el que se envía o se completa un mensaje mediante el tiempo de transición, que se especifica en el diagrama. Diagrama de colaboración Muestra la interacción entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan información similar, pero en una forma diferente. Formando parte de los diagramas de colaboración nos encontramos con objetos, enlaces y mensajes. Un objeto es una instancia de una clase que participa como una interacción, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad. Un enlace es una instancia de una asociación que conecta dos objetos de un diagrama de colaboración. El enlace puede ser reflexivo si conecta a un elemento consigo mismo. La existencia de un enlace entre dos objetos indica que puede existir un intercambio de mensajes entre los objetos conectados. Los diagramas de interacción indican el flujo de mensajes entre elementos del modelo, el flujo de mensajes representa el envío de un mensaje desde un objeto a otro si entre ellos existe un enlace. Los mensajes que se envían entre objetos pueden ser de distintos tipos, también según como se producen en el tiempo; existen mensajes simples, sincrónicos, balking, timeout y asíncronos. Durante la ejecución de un diagrama de colaboración se crean y destruyen objetos y enlaces. Diagramas de actividad Son similares a los diagramas de flujo de otras metodologías OO. En realidad se corresponden con un caso especial de los diagramas de estado donde los estados son estados de acción (estados con una acción interna y una o más transiciones que suceden al finalizar esta acción, o lo que es lo mismo, un paso en la ejecución de lo que será un procedimiento) y las transiciones vienen provocadas por la finalización de las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementación de un caso de uso o de un método (que tiene el mismo significado que en cualquier otra metodología OO). Los diagramas de actividad se utilizan para mostrar el flujo de operaciones que se desencadenan en un procedimiento interno del sistema. Diagramas de estado Representan la secuencia de estados por los que un objeto o una interacción entre objetos pasa durante su tiempo de vida en respuesta a estímulos (eventos) recibidos. Representa lo que podemos denominar en conjunto una máquina de estados. Un estado en UML es cuando un objeto o una interacción satisface una condición, desarrolla alguna acción o se encuentra esperando un evento. Cuando un objeto o una interacción pasa de un estado a otro por la ocurrencia de un evento se dice que ha sufrido una transición, existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas. Además una transición puede ser interna si el estado del que parte el objeto o interacción es el mismo que al que llega, no se provoca un cambio de estado y se representan dentro del estado, no de la transición. Como en todas las metodologías OO se envían mensajes, en este caso es la acción de la que puede enviar mensajes a uno o varios objetos destino Diagramas de Casos de Uso Unos casos de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la relación y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar como reacciona una respuesta a eventos que se producen en el mismo. En este tipo de diagrama intervienen algunos conceptos nuevos: un actor es una entidad externa al sistema que se modela y que puede interactuar con él; un ejemplo de actor podría ser un usuario o cualquier otro sistema. Las relaciones entre casos de uso y actores pueden ser las siguientes:
·
Un actor se
comunica con un caso de uso.
·
Un caso de uso
extiende otro caso de uso.
·
Un caso de uso
usa otro caso de uso
Diagramas de
Clases
Los diagramas de clases representan un conjunto de elementos del modelo que son estáticos, como las clases y los tipos, sus contenidos y las relaciones que se establecen entre ellos. Algunos de los elementos que se pueden clasificar como estáticos son los siguientes: Paquete: Es el mecanismo de que dispone UML para organizar sus elementos en grupos, se representa un grupo de elementos del modelo. Un sistema es un único paquete que contiene el resto del sistema, por lo tanto, un paquete debe poder anidarse, permitiéndose que un paquete contenga otro paquete. Clases: Una clase representa un conjunto de objetos que tienen una estructura, un comportamiento y unas relaciones con propiedades parecidas. Describe un conjunto de objetos que comparte los mismos atributos, operaciones, métodos, relaciones y significado. En UML una clase es una implementación de un tipo. Los componentes de una clase son: 
Reglas de UML
•
UML
tiene reglas semánticas para:
•
Nombres:
Cómo llamar a los elementos, relaciones y diagramas.
•
Alcance:
El contexto que da un significado específico a un nombre.
•
Risibilidad:
Cómo se pueden ver y utilizar esos nombres por otros.
•
Integridad:
Cómo se relacionan apropiada y consistentemente unos elementos con otros.
http://www.dccia.ua.es/dccia/inf/asignaturas/GPS/archivos/Uml.PDF
lsi.vc.ehu.es/ainhoa/docencia/DBD/.../ERE_eoi.doc
http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r2227.PDF
|
