Metodología para el desarrollo de bases de datos relacionales

Concepto de metodología
En distintas áreas de la ingeniería del software se han realizado importantes esfuerzos para
encontrar las tecnologías más adecuadas; esto se debe al gran impacto que una metodología
tiene en el desarrollo de un producto software, ya sea en lo que e refiere en los costes y plazos
de entrega del mismo, como a la calidad y mantenimiento del producto.
Teniendo en cuenta que una metodología es “un conjunto de modelos, lenguajes y otras
herramientas que nos facilitan la representación de los datos en cada fase del proceso de
diseño de una base de datos, junto con las reglas que permiten el paso de una fase a la
siguiente”, el análisis de todos estos elementos es fundamental para poder comprender y
aplicar correctamente una metodología de diseño.
Entendemos por herramienta “cualquier recurso particular a disposición de la metodología
para realizar las operaciones que en ella se prevén”, BATINI et al. (1981); herramientas serán
los diagramas, grafos, teorías, etc. Que se han de aplicar a las distintas fases del desarrollo. Los
modelos, los lenguajes y la documentación son también herramientas, pero dado su especial
interés se consideran de forma individualizada.
Un modelo de datos es un conjunto de conceptos, reglas y convenciones que permiten
describir y manipular los datos de toda la información hacia lo que nosotros tenemos.
Un lenguaje de datos esta siempre basado en un determinado modelo de datos y es el
resultado de definir una sintaxis para el mismo, lo que va a permitir expresar un esquema
(basado, por ejemplo, en el modelo relacional) en una sintaxis concreta (como, por ejemplo, la
del SQL).
La documentación nos permitirá describir de forma normalizada los resultados de cada etapa,
facilitando así la labor del diseñador y ayudando al mantenimiento de la base.
Las reglas actuaran sobre los elementos de entrada en cada fase para conseguir la salida de
cada una de ellas, permitiendo en algunos casos elaborar distintas alternativas de diseño.
Estos cinco conceptos (modelos, lenguajes, documentación, otras herramientas y reglas), están
estrechamente ligados: un lenguaje permite la expresión organizada de los conceptos del
modelo, los modelos no pueden aplicarse de forma satisfactoria sin una metodología, y una
metodología será más eficaz con el apoyo de herramientas que faciliten su aplicación y con
reglas que permitan pasar de una etapa a otra, ayudando a resolver los problemas que van
apareciendo en el proceso de diseño, el cual debe estar perfectamente documentado para que
puedan llevarse a cabo las revisiones y el mantenimiento. Los participantes (directivos,
usuarios e informáticos) constituyen un elemento esencial del desarrollo.
Enfoque propuesto
La metodología propuesta pretende resolver uno de los principales problemas del desarrollo
de una BD, que es la comunicación entre las distintas personas que actúan o intervienen a lo
largo del proceso. Se trata normalmente de personas con diferentes mentalidades, formación
y experiencia que se ven obligadas a trabajar en equipo para desarrollar un sistema útil.
Hay 2 causas principales que conducen a un diseño incorrecto, que son:
- Falta de conocimiento del dominio de la aplicación; conocimiento que no posee el
diseñador informático, pero si el usuario (aunque no siempre lo tenga bien
estructurado ni sepa expresarlo en forma correcta y precisa).
- Falta de experiencia en el modelado: experiencia que si se le supone al diseñador, pero
q el usuario conocedor del dominio de la aplicación no suele poseer.
Para resolver el problema de comunicación entre el usuario y el diseñador, proponemos, al
igual que se hace en otras varias metodologías, utilizar un enfoque basado en el ME/R.
Este modelo, sencillo permite entablar un diálogo entre el usuario y el diseñador; dialogo que
facilitara que se despejen dudas y aclaren aspectos del universo del discurso a modelar.
Este modelo permite también la colaboración de los especialistas con los usuarios; de manera
que estos últimos pueden participar activamente como protagonistas del diseño. Como
sabemos, esto resulta imprescindible para que la implantación de la base de datos tenga éxito.
Como puede deducirse de un estudio general de varias metodologías existentes, parece que
tres grandes fases (que comprenden, a su vez, distintas actividades y tareas), resulta un
numero apropiado de niveles.
Estas fases, son las siguientes:
Modelado conceptual: cuyo objetivo es obtener una buena representación de los recursos de
información de la empresa, con independencia de usuarios o aplicaciones en particular, y fuera
de consideraciones sobre eficiencia del computador.
Diseño lógico: cuyo objetivo es transformar el esquema conceptual obtenido en la etapa
anterior, adaptándolo al modelo de datos en el que se apoya el SGBD que se va utilizar.
Nosotros nos vamos a referir al modelo relacional, pero de forma análoga se podría adaptar
esta etapa del diseño lógico a otro modelo de datos, como el jerárquico o el Codasyl.
Diseño Físico: cuyo objetivo es conseguir una implementación, lo más eficiente posible, del
esquema lógico.
Existe normalmente una realimentación entre las dos últimas fases, ya que pueden producirse
cambios en el diseño lógico derivados de requisitos del diseño físico; es decir, muchas veces es
preciso adaptar el diseño lógico para conseguir una mayor eficiencia del sistema. No es
conveniente, sin embargo, que exista realimentación de estos dos últimos niveles hacia el nivel
conceptual, ya que este debe representar los recursos de información de la empresa con
independencia de aspectos técnicos.
Existen otros enfoques de diseño relacional que no se apoyan en el modelo E/R, sino que
llegan directamente al esquema relacional a partir de los atributos considerados aisladamente
y de las restricciones semánticas (especialmente dependencias funcionales). La denominada
relación universal, que contiene el conjunto de atributos y las restricciones semánticas,
constituye en este caso el punto de partida de la siguiente etapa de diseño que consiste en la
normalización de esta relación.
El método, basado en la relación universal, presenta la ventaja de un diseño menos subjetivo,
que permite en gran parte aplicar procedimientos algorítmicos. Sin embargo, en el se suele
perder más semántica, las relaciones resultantes pueden no corresponder a hechos del mundo
real, surgen dificultades para expresar restricciones de integridad referencial y es más difícil
que los usuarios participen en el diseño; otro problema que se presenta en este caso es el de
recoger la presencia de más de una interrelación entre dos entidades determinadas. Además,
los costes de aplicar la teoría de la normalización crecen exponencialmente con el numero de
atributos por relación; por tanto, si se parte de la relación universal se necesita disponer de
herramientas de normalización potentes y sofisticadas que consumen gran cantidad de tiempo
y de recursos de máquina.
Nosotros, como ya hemos indicado, concedemos una gran importancia a la participación de los
usuarios en el proceso de diseño y pensamos, por tanto, que él ME/R ofrece un mejor punto
de partida, ya que se obtienen relaciones más estructuradas, facilita la normalización, y las
relaciones finales representan mejor las entidades e interrelaciones del universo del discurso.
Un posible inconveniente de este métodos es que exige cierta practica en el diseño, pero en
nuestra opinión, sus ventajas superan con mucho este posible inconveniente.
Con esto se consiguen una serie de ventajas:
- Se requiere menos especialización por parte del diseñador.
- Los usuarios pueden participar en el diseño.
- El diseño es más fácil de verificar por parte de las personas involucradas en el mismo.
- La estructura obtenida es flexible y fácil de mantener.
- El afinamiento físico es más sencillo.
- Cada fase tiene su propia documentación, más o menos formal, según las
características de la correspondiente fase.
Características de una metodología de diseño
a) Claridad y comprensibilidad
La metodología debe poseer una sencillez tal que permita que sea explicada a distintos
tipos de usuarios.
b) Capacidad de soportar la evolución de los sistemas
c) Facilitar la portabilidad
El estándar IEEE (1983) considera la portabilidad como “la facilidad con la que un
producto de programación puede ser transferido de un sistema informático a otro o
de un entorno a otro”. La portabilidad es esencial para conseguir sistemas abiertos.
d) Versatilidad respecto a tipos de aplicaciones
La metodología propuesta no está orientada a un tipo de aplicaciones concreto, sino
que puede utilizarse en aplicaciones diversas, como la gestión de una biblioteca, de un
hospital, de una universidad, etc.
e) Flexibilidad (independencia de la dimensión de los proyectos)
Se pretende que la tecnología pueda utilizarse tanto en proyectos grandes como
pequeños. Para abordar ambos tipos de proyectos se utilizan modelos, herramientas y
lenguajes análogos.
f) Rigurosidad
Se pretende imprimir un carácter riguroso a los principios metodológicos propuestos.
Siempre que ha sido posible (como en el caso de la normalización) nos hemos apoyado
en fundamentos teóricos, ya que creemos que la teoría no tiene por que ir en contra
de la practica.
g) Adopción de estándares
Se ha procurado aplicar todos aquellos estándares que para la ingeniería del software
en general y para las bases de datos en particular, recomiendan distintas
organizaciones internacionales (como ISO, ACM, IEE, etc.). Así, para la descripción del
esquema lógico estándar nos hemos basado en el estándar SQL92 de ISO.

Entradas y salidas del proceso de desarrollo
Podemos considerar que en el proceso de desarrollo de una BD existen una serie de entradas y
de salidas que pasamos a resumir.
Entradas:
- Requisitos de información y objetivos.
- Requisitos de los procesos.
- Especificaciones del SGBD.
- Configuración del equipo físico y del S.O.
Salidas:
- Estructura lógicas de datos.
- Estructura de almacenamiento.
- Especificaciones para los programas de aplicación.

MODELADO CONCEPTUAL
Etapas del modelado conceptual
El modelado conceptual, también denominado diseño conceptual, constituye la primera fase
de desarrollo de bases de datos, y puede subdividirse en dos etapas claramente diferenciadas:
A) Análisis de requisitos
Esta primera etapa, en general común para datos y procesos, es la etapa de percepción,
identificación y descripción de los fenómenos del mundo real a analizar.
En el análisis de requisitos, se ha de responder a la pregunta: “¿Qué representar?”
Mediante el estudio de las reglas de una empresa (que proveen el marco para el análisis del
sistema) y de entrevistas a los usuarios de los diferentes niveles de la organización (que
proveen los detalles sobre los datos) se llega a elaborar un esquema descriptivo de la realidad.
Son varias las propuestas existentes respecto a la forma de expresar el esquema descriptivo,
pero en general (y esta también nuestra propuesta) se utiliza el lenguaje natural para recoger
esta primera información.
“Como ven los usuarios a los analistas” “Como ven los analistas a los usuarios”
- No entienden el negocio, es decir, la
actividad de la empresa.
- Intentan decirnos como realizar nuestro
trabajo
- No consiguen instrumentar de manera
aceptable las especificaciones del sistema.
- Dicen NO a todas nuestras sugerencias.
- Ponen demasiado énfasis en aspectos
técnicos.
- Siempre piden más presupuesto.
- Siempre se retrasan.
- Nos piden tiempo y esfuerzo en
detrimento de nuestro trabajo.
- No pueden responder de forma rápida y
satisfactoria a los cambios necesarios en el
sistema.
- No saben lo que quieren.
- Tienen muchas necesidades “políticas”.
- Quieren todo YA.
- No son capaces de establecer prioridades
entre las necesidades.
- Quieren poner sus necesidades
específicas por delante de las de la
compañía u organismo.
- Rehúsan responsabilidades sobre el
sistema.
- No son capaces de dar una definición
clara del sistema para que funcione.
- Son incapaces de respetar la
planificación.
- No dicen todo lo que saben sobre el
sistema.

Ya señalábamos que uno de los problemas más importantes con los que se enfrenta el diseño
de una base de datos es el de la comunicación entre las distintas personas que participan en el
mismo, el lenguaje natural servirá para que los usuarios de la base de datos especifiquen
fácilmente sus necesidades.
Los posibles problemas que presenta esta primera especificación se irán solucionando a lo
largo del resto de las etapas de diseño. Podemos afirmar que este primer esquema percibido
bruto se irá refinando hasta llegar a un esquema más correcto: el esquema conceptual.
B) Etapa de conceptualización
En ella se transforma este primer esquema descriptivo, refinándolo y estructurándolo
adecuadamente. Esta etapa responde a la pregunta: “¿Cómo representar?”
En esta etapa de conceptualización se habrá de buscar una representación normalizada que se
apoye en un modelo de datos que cumpla determinadas propiedades, a saber; coherencia,
plenitud, no redundancia, simplicidad, fidelidad, etc., para llegar así al denominado esquema
conceptual.
Una característica importante del esquema conceptual, es que sea infologico, en el sentido de
que no describa los aspectos ligados a la instrumentación del esquema en un SGBD, sino que
permita ver la información con todo su contenido semántico.

En la figura pueden observarse, a modo de resumen, las dos fases del diseño conceptual con
sus entradas y salidas. Se parte del análisis del universo del discurso (lo que también podría
denominarse realidad empresarial), analizando los listados, pantallas, normativas, etc. Y
realizando un conjunto de entrevistas a varios niveles de la empresa.
Posteriormente se elabora un esquema percibido, expresado en lenguaje natural, que nos
facilita la obtención del esquema conceptual, esto es, delimita que entidades, atributos,
interrelaciones y restricciones semánticas vamos a considerar.
Este proceso se realiza de forma iterativa hasta que se introducen y clasifican todos los objetos
del universo del discurso de forma satisfactoria.