Se caracteriza por utilizar una serie de símbolos y reglas para representar los datos y sus relaciones. Este modelo consiste en plasmar el resultado de análisis de problemas mediante el diagrama entidad/relación.
Generalmente,
el termino aplicación de base de datos se refiere a una base de datos en particular
(por ejemplo la base de datos BANCO que mantiene las cuentas de ahorro de sus
clientes) y a los programas asociados, que implementan las consultas y
actualizaciones de la base de datos (por ejemplo, programas que implementan
actualizaciones de la base de datos correspondientes a los depósitos y
reintegros de clientes). Por lo tanto, parte de la aplicación de base de datos requeriría
el diseño, implementación y prueba de estos programas de aplicación, pero también
requiere el diseño, implementación y prueba de la base de datos en sí misma.
Sin embargo,
cada vez es más obvio que existe algo en común entre las metodólogas de diseño de
bases de datos y las de ingeniera del software. Es cierto que esas características
comunes aumentarían, ya que las metodologías de diseño de base de datos tratan
incluir conceptos de especificación de operaciones sobre objetos de base de
datos, y que las metodologías de ingeniera del software especifican con más
detalle la estructura de la base de datos.
En el diseño
de bases de datos se distinguen principalmente dos fases de diseño; la fase
de modelado
conceptual, que es la descripción del mundo real (una organización) de acuerdo
con un
modelo altamente semántico e independiente del SGBD en el que posteriormente se
vaya hacer
la implementación de la base de datos, y la fase de diseño lógico, en la cual
se ha
de obtener
un esquema que responda a la estructura lógica especifica del SGBD que se vaya
utilizar en
cada caso, por lo que dicho esquema está sometido a las restricciones que
imponga
el modelo
del SGBD en concreto.
De este
modo, el proceso de diseño de una base de datos puede ser dividido en cuatro pasos:
1. Análisis
de requisitos, el primer paso es entender que datos van a ser almacenados en la
base de datos, que aplicaciones deben ser construidas sobre ella y que
aplicaciones son más frecuentes y por lo tanto requieren un cuidado especial
para obtener un rendimiento adecuado.
Esta fase es
un proceso que incluye discusiones con los grupos de usuarios, estudio de los
actuales sistemas operacionales y como se espera que cambien, examen de
cualquier información disponible sobre las aplicaciones existentes que van a
ser sustituidas o completadas por la aplicación de base de datos que se va diseñar,
etc. Existen multitud de metodologías para realizar este paso, incluso existen
herramientas que lo automatizan.
2. Diseño
Conceptual, la información recogida en el paso anterior es usada para desarrollar
el esquema conceptual. Este paso se suele realizar con el modelo Entidad- Relación.
3. Diseño Lógico,
una vez elegido el SGBD a utilizar, se convierte el diseño conceptual de la
base de datos en un esquema de base de datos del SGBD elegido. Este esquema se
suele llamar, como apuntamos anteriormente, el esquema lógico.
4. Diseño Físico,
en este paso se deben considerar las cargas de trabajo que debe soportar la BD
que se esta diseñando para refinarla de modo que cumpla con los requisitos de rendimiento
especificados. Este paso puede implicar cosas tan simples como construir índices
sobre algunos ficheros, o puede implicar un rediseño importante del esquema obtenido
de los pasos anteriores.
Una vez
terminado el proceso de diseño, seguramente se requiera sucesivas puestas a
punto (tunning en ingles), donde los pasos anteriores se intercalan y se
repiten hasta que el diseño es satisfactorio.
Los
conceptos y técnicas que incluye un SGBD son claramente útiles para alguien que
desea implementar o mantener las interioridades de un sistema de bases de
datos. Sin embargo, es importante reconocer que usuarios responsables, diseñadores
de bases de datos deben conocer también cómo funciona el SGBD.
Un buen
conocimiento de las interioridades del SGBD es esencial para aquellos usuarios
que deseen aprovechar al máximo el SGBD y realizar buenos diseños de bases de
datos.
Problemas
con los modelos E/R
En esta sección
examinaremos un tipo de problemas que pueden aparecer cuando se está creando un
diagrama ER. Estos problemas se llaman las trampas de conexión, y normalmente
ocurren debido a una mala interpretación del significado de ciertas relaciones.
Examinaremos
los dos tipos principales de trampas de conexión, llamadas la trampa del abanico
y la trampa del sumidero, e ilustraremos cómo identificar y resolver estos
problemas en diagramas ER.
En general,
para identificar las trampas de conexión, debemos asegurarnos de que el significado
de un tipo de relación está completamente entendido y claramente definido. Si
no entendemos las relaciones, podríamos crear un modelo que no es una representación
fidedigna del “mundo real”.
La trampa
del abanico
La trampa
del abanico ocurre cuando un modelo ER representa una relación entre tipos de
entidad, pero el camino entre algunas entidades es ambiguo.
Una trampa
de abanico puede aparecer si dos o más relaciones 1:N salen del mismo tipo de entidad.
En la siguiente figura se presenta un caso potencial de trampa de conexión. Se
presentan dos tipos de relación 1:N, (Trabaja-Para y Trabaja-En), que emanan
del mismo tipo de entidad (Departamento).
Este modelo
representa el hecho de que un Departamento puede trabajar en una o más secciones
de la empresa y tiene uno o más empleados. Sin embargo, aparece un problema cuando
deseamos saber que empleados trabajan en una Sección particular. Para apreciar el
problema, examinamos algunas instancias de los tipos de relación Trabaja-Para y
Trabaja-En, tal y como se muestra en la en la siguiente figura:
Ejemplo de
trampa de de abanico utilizando conjuntos de entidades e instancias de tipos de
relación.
Si
formulamos la consulta:” ¿en que Sección trabaja el empleado e1?”, somos
incapaces de dar una respuesta concreta. Solo podemos decir que e1 trabaja en
la sección s1 o en la s2. La imposibilidad de responder esta pregunta es el
resultado de la trampa del abanico asociada a la mala interpretación de las
relaciones entre Empleado, Departamento y Sección. Podemos resolver el problema
reestructurando el modelo ER original para representar la asociación correcta
entre esas entidades, tal y como se muestra en la siguiente figura.
Modelo reestructurado.
Ahora ya es
posible contestar a la pregunta que nos hacíamos anteriormente. Podemos
observar fácilmente que el empleado e1 trabaja en la Sección s1 y en el
Departamento d1.
La trampa
del sumidero
La trampa
del sumidero ocurre cuando existe un tipo de relación entre dos tipos de
entidad, pero no existe camino entre algunas entidades.
La trampa
del sumidero puede aparecer cuando hay uno o más tipos de relación donde los tipos
de entidad tienen una participación parcial. En la siguiente figura se presenta
un diagrama ER con una trampa del sumidero potencial.
Ejemplo
utilizando conjuntos de entidades e instancias de tipos de relación del modelo
ER.
El diagrama
representa el hecho de que un Departamento tiene uno o más empleados que pueden
dirigir proyectos, y no todos los proyectos son dirigidos por un empleado
concreto. Suponemos que un proyecto (a diferencia de ejemplos anteriores) es
realizado por un único departamento.
Ejemplo de la trampa del sumidero.
Para
ilustrar el problema se puede observar la siguiente figura.
Ejemplo de conjuntos de entidades e instancias de relación
para la Figura.
Si realizamos la pregunta: “¿qué departamento
realiza el proyecto p2?”, no es posible obtener respuesta, dado que la entidad p2
no está ligada a ningún empleado. Esta imposibilidad de contestar a la pregunta
se conoce como una pérdida de información (dado que sabemos que el proyecto lo
realiza un departamento), y el resultado es la trampa del sumidero.
La participación
de Empleado y Proyecto en el tipo de relación Dirige es parcial en ambos casos,
lo que significa que algunos proyectos pueden no estar asociados a un departamento
a través de un empleado. Por lo tanto para resolver este problema, necesitamos
identificar la relación faltante, que en este caso es el tipo de relación Realiza,
entre los tipos de entidad Departamento y Proyecto.
El nuevo
modelo ER se muestra en la siguiente figura eliminando la trampa sumidero:
Y en la
siguiente imagen, es el nuevo esquema eliminando la trampa sumidero:
Mas adelante de este blog se iràn viendo mas detalles sobre estos y mas temas.
No hay comentarios:
Publicar un comentario