El diseño de bases de datos en el ciclo de vida de los sistemas de información

El sistema de información de una empresa es un conjunto de actividades que regulan la

distribución y el compartimiento de la información, y el almacenamiento de los datos relevantes
para la administración de la empresa. Una base de datos es cualquier conjunto grande de datos
estructurados almacenado dentro de un computador. Los sistemas de gestión de bases de datos
(DBMS son paquetes de software para la gestión de las bases de datos; en particular, para
almacenar, manipular y recuperar datos de un computador. Las bases de datos son sólo uno de los
componentes de los sistemas de información, que también incluyen programas de aplicación,
interfaces para usuarios y otros tipos de paquetes de software. Sin embargo, las bases de datos
son esenciales para la supervivencia de cualquier organización, porque los datos estructurados
constituyen un recurso esencial para todas las organizaciones, incluidas no sólo las grandes
empresas sino también pequeñas compañías y usuarios individuales.

El diseño de un sistema de información es una actividad complicada, que incluye la planificación,

especificación y desarrollo de cada componente del sistema. El típico desglose del ciclo de vida de
un sistema de información incluye; un estudio de factibilidad, recolección y análisis de
requerimientos, diseño, elaboración de prototipos, implantación, validación y prueba y operación.

Estudio de factibilidad. El estudio de factibilidad trata de determinar la rentabilidad de las

distintas alternativas de diseño del sistema de información y las prioridades de los diversos
componentes del sistema.

Recolección y análisis de requerimientos. La recolección de requerimientos y su análisis se

ocupan de la comprensión de la, así llamada, “misión del sistema de información”, es decir, las
áreas de aplicación del sistema dentro de una empresa y los problemas que el sistema debe
resolver. Esta fase centra su atención en la interacción con los usuarios del sistema de
información. Los usuarios describen sus necesidades a los diseñadores y esas descripciones se
reúnen en lo que se llama las “especificaciones de requerimientos”. En general, las
especificaciones de requerimientos son más bien informales y desorganizadas; se expresan, por lo
común, en lenguaje natural o en lenguajes semiformales (por ejemplo, combinación de palabras
clave y lenguaje natural).

Diseño. El diseño se ocupa de la especificación de la estructura del sistema de información. Se

distingue entre el diseño de bases de datos y el diseño de aplicaciones. El primero es el diseño de
la estructura de la base de datos; el segundo es el diseño de los programas de aplicación. Ambas
actividades de diseño son muy complejas y pueden dividirse aún en fases.

Creación de prototipos. La creación de prototipos es un añadido reciente al ciclo de vida. La

mayoría de los paquetes de software incluyen actualmente herramientas para un rápido
desarrollo de prototipos, incluyendo los llamados lenguajes de cuarta generación. Con estas
herramientas, un diseñador puede producir con eficiencia un prototipo del sistema de información
o de algunas de sus partes. Un prototipo es una realización simplificada, quizá poco eficiente, que
se produce para verificar en la práctica que las fases anteriores de diseño se condujeron de forma
correcta. El prototipo permite a los usuarios verificar si el sistema de información satisface sus
necesidades. Un prototipo que funciona es útil para la corrección o adición de requerimientos
sobre la base de la experimentación.
Implantación. La implantación o realización se refiere a la programación de la versión final y
operativa del sistema de información. En esta etapa, las alternativas de realización se verifican con
cuidado y se comparan, para así lograr que el sistema final cumpla los requerimientos en cuanto a
rendimiento.

Validación y prueba. Validación y prueba es el procedimiento mediante el cual se garantiza que

cada fase del proceso de desarrollo es de calidad aceptable y es una evolución correcta de la fase
anterior. Esto implica verificar si la aplicación refleja las especificaciones de diseño.

Operación. La operación empieza con la carga inicial de datos y termina cuando el sistema se
vuelve obsoleto y tiene que ser reemplazado. Durante la operación, se necesita el mantenimiento
para hacer que el sistema se adapte a nuevas condiciones, mejorarlo con nuevas funciones o
corregir errores no detectados durante la validación.

El ciclo de vida es más que nada un marco de referencia; en muchos proyectos de diseño reales,
las diferencias entre las fases son a veces poco claras, algunas fases no se desarrollan y se requiere
un gran nivel de retroalimentación entre las fases para mejorar y corregir los resultados de fases
anteriores. Sin embargo, el ciclo de vida plantea que al diseño de bases de datos le debe anteceder
un análisis de las necesidades, debe conducirse en paralelo con el diseño de aplicaciones y le debe
seguir la implantación ya sea de un prototipo o de un sistema final.

Fases del diseño de bases de datos

El diseño de una base de datos es un proceso complejo que abarca varias decisiones a muy
distintos niveles. La complejidad se controla mejor si se descompone el problema en
subproblemas y se resuelve cada uno de éstos independientemente, usando métodos y técnicas
específicas. El diseño de bases de datos se descompone en diseño conceptual, diseño lógico y
diseño físico. El diseño de bases de datos, tal como se expone en este apartado, representa un
enfoque orientado a los datos para el desarrollo de los sistemas de información: la atención
completa del proceso de diseño se centra en los datos y sus propiedades. Con un enfoque
orientado a los datos, primero se diseña la base de datos, luego las aplicaciones que la usan. Este
método se desarrolló en la década de 1970, con el establecimiento de la tecnología de bases de
datos.

Diseño conceptual. El diseño conceptual parte de la especificación de requerimientos y su

resultado es el esquema conceptual de la base de datos. Un esquema conceptual es una
descripción de alto nivel de la estructura de la base de datos, independiente del software de DBMS
que se use para manipularla. Un modelo conceptual es un lenguaje que se usa para describir
esquemas conceptuales. El propósito del diseño conceptual es describir el contenido de
información de la base de datos, más que las estructuras de almacenamiento que se necesitarán
para manejar esta información. En realidad, el diseño conceptual debe hacerse aun cuando la
implantación final no use un DBMS, sino archivos convencionales y lenguajes de programación.

Diseño lógico. El diseño lógico parte del esquema conceptual y da como resultado un esquema
lógico. Un esquema lógico es una descripción de la estructura de la base de datos que puede
procesar el software de DBMS. Un modelo lógico es un lenguaje usado para especificar esquemas
lógicos; los modelos lógicos más usados pertenecen a tres clases: relacional, de redes y jerárquico.
El diseño lógico depende de la clase de modelo de datos usado por el DBMS, no del DBMS
utilizado (en otras palabras, el diseño lógico se efectúa de la misma forma para todos los DBMS
relacionales porque todos utilizan el modelo relacional).

Diseño físico. El diseño físico parte del esquema lógico y da como resultado un esquema físico. Un
esquema físico es una descripción de la implantación de una base de datos en la memoria
secundaria; describe las estructuras de almacenamiento y los métodos usados para tener un
acceso efectivo a los datos. Por esta razón, el diseño físico se adapta a un sistema DBMS
específico. Hay una retroalimentación entre el diseño físico y el lógico, porque las decisiones
tomadas durante el diseño físico para mejorar el rendimiento pueden afectar la estructura del
esquema lógico.

Una vez completo el diseño físico de una base de datos, los esquemas lógico y físico se expresan
haciendo uso del lenguaje de definición de datos del DBMS objetivo; la base de datos se crea y se
carga, y puede ser probada. Más que eso, las aplicaciones que usan las bases de datos pueden
especificarse, implantarse y probarse completamente. De este modo, la base de datos se vuelve
paulatinamente operacional.

¿Por qué es valioso el diseño conceptual?

Primero, se debe subrayar que el diseño conceptual no se ayuda mucho de herramientas

automáticas. El diseñador asume total responsabilidad sobre el proceso de entender y transformar
los requerimientos en esquemas conceptuales. A partir de la primera conceptualización, muchos
sistemas de bases de datos ofrecen herramientas para la creación rápida de prototipos, usando
lenguajes de cuarta generación para la generación de aplicaciones, formatos de pantallas e
informes. Estas herramientas pueden ser usadas directamente por no profesionales para
desarrollar bases de datos simples y facilitan el trabajo de los creadores profesionales de bases de
datos. Así pues, creemos que el diseño conceptual es con mucho la fase más crucial del diseño de
bases de datos, y el desarrollo posterior de la tecnología de bases de datos no cambiará esta
situación.

Aun si se supone que el diseño conceptual está dirigido por un profesional, se alcanzan resultados
satisfactorios sólo mediante cooperación con los usuarios de bases de datos, quienes tienen la
obligación de describir las necesidades y de explicar el significado de los datos. Las características
básicas del diseño conceptual y de los modelos conceptuales de datos son relativamente simples y
su entendimiento no requiere mayor conocimiento técnico previo sobre sistemas de bases de
datos. De este modo creemos que los usuarios pueden aprender fácilmente lo suficiente sobre
diseño conceptual para orientar a los diseñadores en sus decisiones e incluso para diseñar bases
de datos simples.

Una influencia fuerte del usuario final sobre las decisiones de diseño tiene muchas consecuencias
positivas: mejora la calidad del esquema conceptual, eleva la probabilidad de que el proyecto
converja hacia el resultado esperado, y reduce los costos de desarrollo. Más importante, los
usuarios que estén más comprometidos con el proceso de toma de decisiones son los más
inclinados a aceptar y usar un sistema de información. Entender las características de las bases de
datos mejora la claridad contractual entre los grupos implicados, es decir, usuarios y diseñadores.

Otro argumento de fuerza a favor del diseño conceptual es su independencia de un DBMS

particular. Esta característica genera algunas ventajas:
 - La elección del DBMS se puede posponer, y el esquema conceptual puede sobrevivir a una
decisión tardía de cambiar el DBMS objetivo.
- Si el DBMS o los requerimientos de la aplicación cambian, el esquema conceptual puede
aún usarse como punto de partida de la nueva actividad de diseño.
- Las diferencias de bases de datos, descritas mediante su esquema conceptual, se pueden
comparar en un marco homogéneo de trabajo. Esta característica facilita la construcción
de sistemas consolidados a partir de varias bases de datos ya existentes y la creación de
un diccionario de datos integrado.

El argumento final en favor del diseño conceptual subraya la utilidad de los esquemas
conceptuales después de finalizado el proceso de diseño. El esquema conceptual no se debe
considerar un documento de diseño intermedio a ser ignorado después del diseño lógico y físico;
más bien, debe permanecer como parte de las especificaciones de la base de datos, organizado
con una variedad de documentos que también detallan la recolección de requerimientos y el
proceso de diseño. Así, la ventaja final y posiblemente más importante del diseño conceptual se
hace evidente durante la operación de la base de datos, cuando el modelo conceptual y su
documentación facilitan el entendimiento de los esquemas de datos y de las aplicaciones que los
utilizan y, por ende, su transformación y mantenimiento.