|
|
Lic. José Ronald Argüello Venegas
Lic. Adolfo Di Mare Hering |
Tradicionalmente se ha dicho que existen dos niveles en el diseño de Bases de Datos:
En este artículo se justifican la necesidad de tres niveles de diseño y la necesidad de un estudio integral de la empresa donde se desea implantar un Sistema de Bases de Datos.
Un Sistema de Bases de Datos es un conjunto de registros, datos y relaciones que refleja las necesidades de información de una empresa. Estos registros datos y relaciones se agrupan en unidades independientes que satisfacen los requerimientos de información de la empresa. Para un conjunto de aplicaciones que cumplen con algún criterio dado de similitud. Cada una de estas unidades es una base de datos.
Todos los datos pertenecientes a una misma Base de Datos están interrelacionados:
Es claro que, una empresa puede necesitar una o más Bases de Datos según la clase de información que requiera. Por ejemplo, una Base de Datos es necesaria para todos los procedimientos de administración de personal, y otra distinta para todos los procedimientos de inventario.
Una de las principales ventajas de implantar un Sistema de Bases de Datos es que hace posible un Sistema de Información Gerencial (SIG), que necesita una gran integración de datos y de sistemas. Esta integración sólo es posible si cada Base de Datos en todo el Sistema está diseñada de tal manera que no entre en conflicto con los demás.
Tradicionalmente, se ha seguido en las empresas la práctica de diseñar Bases de Datos según aplicaciones particulares. Esto se ha hecho por diferentes razones, e.g. costos, falta de organización, falta de conocimeinteo, proyectos grandes o riesgozos, etc. Como resultado los diseños de Bases de Datos han estado ligados a los Sistemas desde su concepción inicial, lo que obviamente atenta contra la independencia de datos (1). Es por esta rezón que integrar Bases de Datos así diseñados resulta ser una labor titánica para el Adrninistrador de la Base de Datos (ABD), pues muchas veces los problemas no se presentarán por requerimientos conflictivos de índices alternos o de almacenamiento físico sino debido a la estructura con que fueron concebidas las diferentes Bases de Datos.
Por todo esto es necesario hacer un estudio integral de datos en toda la empresa antes de comenzar a implantar sistemas. Solo así podrá garantizarse una plena integración: no solamente se asegura el éxito de cada proyecto individual, sino que también el del proyecto de implantación de Bases de Datos como un todo. Lo anterior justifica un nuevo enfoque en el diseño de Sistemas de Información, que considere primero la definición de las necesidades de información (Diseño de la Base de Datos) y luego las soluciones prácticas que satisfacen esas necesidades (Implantación de los Sistemas). Lo dicho se aplica tanto a empresas pequeñas y medianas como a empresas de gran envergadura.
Además, el enfoque es también vá1ido para sistemas y programas de aplicación.
Por supuesto lo anterior queda sujeto a que exista un método que permita hacer un estudio integral con un costo mínimo, y a que la Administración Superior apoye el proyecto de diseño de la Base de Datos (5). Si estas condiciones no se dan es casi seguro que todo el proyecto fracasará. En este artículo discutiremos únicamente las ventajas del enfoque propuesto.
Los dos tipos de diseño tradicionales son el lógico y el físico (1), (4) y (5).
El diseño físico depende de los dispositivos al almacenar la Base de Datos, así como el Sistema Administrador de Base de Datos (SABD) que se use.
En el diseño lógico, llamado también diseño conceptual o esquema (4), deben describirse todos los elementos que forman la Base de Datos. Más aún, el diseño lógico debe condicionar al diseño físico. Algunos sistemas comerciales (como los que siguen la convención Codasyl) llaman diseño lógico a una definición global que debe hacerse para el SABD, y diseño físico a la forma en que la Base de Datos es almacenada dentro del computador.
Estos dos diseños se encuentran generalmente ligados a la arquitectura del SABD y especifican muchos detalles de implementación. Esta mezcla de parámetros lógicos y físicos hace que se pierda independencia de datos.
Una mejor alternativa sería describir, a un nivel adecuado, la estructura y organización que deben tener los datos sin especificar exactamente parámetros que pueden definirse cuando se implante la Base de Datos (ver (3), CAP. 5; Pag. 62).
Dada esta mezcla de parámetros lógicos y físicos deben distinguirse tres tipos de diseño de Bases de Datos:
El primero de ellos, y el más importante es el DLGBD, el cual debe reflejar las necesidades de información y la organización estructural de los datos de la empresa. El DLGBD debe ser un modelo de datos en el que se reflejen los datos y su estructura (ver figura 1).
El segundo tipo de diseño, el diseño lógico- fisico, sirve para ajustar el DLGBD a las facilidades y restricciones; que el SABD brinda para implantar el di diseño lógico. Por ejemplo, si el SABD es enteramente jerárquico será necesario implantar con redundancia, aquellas relaciones N:M que aparezcan en DLGBD (ver figura 2).
El tercer tipo de diseño, el diseño físico, debe ser congruente con el diseño físico antes de descrito, el tradicional. En él se deberán especificar los dispositivos y métodos de acceso usados para almacenar cada registro de la Base de Datos (ver figura 3).
No debe confundirse el DLGBD con el diseño lógico- físico, ni éste último con el diseño físico. Esta confusión a veces se da debido a la arquitectura del SABD o debido a la ausencia tanto del diseño lógico como del diseño físico.
Debe destacarse que producir los diseños lógico- físico y físico a partir del diseño lógico es una tarea relativamente fácil, pues solo es necesario conocer los detalles del SABD por usar.
El diseño Lógico Global de la Base de Datos (DLGBD) surge de manera natural de la necesidad de integración de información en la empresa. Este diseño debe producirse antes de tomar cualquier decisión de implantación de sistemas, pues si no se procede de esta forma, es muy probable que luego no puedan integrarse las Bases de Datos diseñadas. Además, dado que los sistemas deben ser eficaces, es necesario que el sistema de Bases de Datos refleje y atienda las necesidades de información y los requerimientos de la empresa el diseño de las Bases de Datos debe ser un reflejo de la realidad de la misma. Debe ser lo suficientemente completo como para almacenar toda la información necesaria y como para reflejar también la estructura de los archivos de la empresa, pues la Base de Datos debe permitir acceso a los datos no sólo su almacenamiento. El DLGBD debe ser un reflejo de la realidad de la empresa porque debe ser producto de un estudio integral de la misma.
Aunque puede objetarse el invertir recursos al producir un DLGBD, se debe destacar que no es frecuente que en una empresa haya cambios drásticos y repetidos en la estructura de sus archivos. De hecho, lo que generalmente sucede es que se cambian los procedimientos sin modificar los archivos, y cuando se modifican archivos, generalmente lo que se hace es añadir información nueva o desechar información existente. Por esta razón es altamente rentable hacer el estudio integral de datos, pues el diseño continuará vigente durante un largo plazo aunque se produzcan pequeños cambios en ese lapso de tiempo.
Además, un diseño integral de la Base de Datos permitirá escoger con mejor criterio tanto los sistemas que han de mecanizarse, como la parte global de la Base de Datos que se implantará. Este diseño puede verse como un mapa o plano en el que están definidas claramente todas las necesidades de información operacional. Con este marco de referencia, la empresa puede planear su desarrollo computacional.
El DLGBD puede usarse para decidir cuáles nuevos sistemas se implementarán, permitiendo, además, predecir el impacto del nuevo sistema en el conjunto de los sistemas ya implantados. El contar con un DLGBD reduce la labor del implantador de sistemas, pues le evita considerar las partes de la Base de Datos innecesarias para su sistema, ya sea por costo relativo o simplemente por ser inatingentes, lo que implica inatigencia en otros sistemas. Esto le permitirá concentrarse únicamente en la parte de la Base de Datos que utilizará.
De hecho en el DLGBD debe describirse tanto la Base de Datos como cada uno de los elementos que forman el recurso de datos de la empresa. Este documento es de gran valor para el implantador de sistemas, pues ahí él puede encontrar definidas todas las necesidades de información de la empresa y, en particular, las necesidades de información del sistema a su cargo. El ABD puede beneficiarse también enormemente con el DLGBD, pues éste le permite conocer las necesidades de información de toda la empresa y no solo las de los usuarios de los sistemas actualmente mecanizados. Esto permite al ABD administrar mejor al recurso de datos de la empresa. (2) CAP 7.
Por otro lado, conocer la organización de todos los datos, organización que se describe en el diseño lógico de la Base de Datos, permite planear con mayor eficacia y eficiencia toda la gestión administrativa de la empresa.
Si el DLGBD no estuviera hecho, cada implantador de sistemas tendría que diseñar, junto con el ABD, su propia Base de Datos. Esta pequeña Base de Datos podría dejar afuera requerimientos de información de otros sistemas por implantar en el futuro, y para hacer necesario grandes ajustes cuando se implanten esos nuevos sistemas. Es mucho más fácil no considerar lo que no interesa que construir sólo lo que interesa. Tom de Marco en (3), aplica este mismo criterio en la construcción de diagramas de flujo de datos lógicos y al derivar el límite Hombre-Máquina. (CAP. 10).
El DLGBD debe estar compuesto por los registros, datos y relaciones que forman la Base de Datos. La descripción de estos tres componentes debe ser suficientemente completa como para que no haya ambigüedades en el diseño pero no tan detallada corno para que condicione demasiado la implantación de la Base de Datos. Por esta razón, en el diseño lógico deben describirse los objetivos y las razones de ser de los datos, los registros y las relaciones, sin describir detalles de implantación. Estos detalles deben describirse en el diseño lógico-físico o en el diseño físico de la Base de Datos. Por ejemplo, códigos y datos respectivos deben usarse conjuntamente en el diseño lógico global sin pensar en eliminar o separar ninguno de los dos. Los rangos y ciertos valores para los datos deben dejarse para el diseño lógico-físico o para el diseño físico. (ver (3) CAP. 5, pág. 62).
Nótese que los objetivos y las razones de ser de los datos es lo que se describe usualmente en un Diccionario de Datos, (3) CAP. 12, de donde puede concluirse que uno de los subproductos del DGLBD es esta importante documentación.
Si se desea, puede incluirse en el DLGBD la descripción de las restricciones necesarias para mantener la integridad, seguridad y privacidad del Sistema de Bases de Datos.
Es conveniente que en el DLGBD se incluya un diagrama que describa los registros y relaciones que forman la Base de Datos. Este tipo de diagrama es muy útil para obtener una visión global de la Base de Datos, pues de un solo vistazo pueden observarse los registros y las relaciones que la forman. ((5), p. 4). Este diagrama debe corresponder al modelo de datos escogidos antes de hacer el diseño. Como se mencionó, uno de los subproductos obtenidos al hacer el DLGBD es el Diccionario de Datos, herramienta de conocida utilidad y necesidad para la administración de la Base de Datos.
Si se desea, hacer una estimación del tamaño de la Base de Datos, deberá recogerse información sobre el volumen de los datos y sobre los registros de la empresa. De esta manera la estimación podrá hacerse fácilmente y con toda la exactitud que se quiera.
Aunque el DLGBD puede orientarse a la arquitectura de un SABD específico ((5), p. 10), es mejor no hacerlo así, porque puede falsearse o diluirse la organización de los datos que debe reflejar el diseño sobre las facilidades y restricciones del SABD. Además, no es conveniente tomar decisiones prematuras sobre el tipo de Base de Datos o respecto de la implantación de la misma, pues esto puede generar ineficiencias o complicaciones en el desarrollo del futuro sistema.
Por último es necesario destacar que los tres tipos de diseño deben ser hechos o coordinados por el ABD, de tal forma que se asegure la compatibilidad de todas las Bases de Datos. Si cada analista hace su parte del DLGBD, es muy probable que las Bases de Datos resultantes no puedan integrarse después.
(1) | James Martin.
Computer Data Base Organization.
Prentice Hall. 1975.
|
(2) | Ronald G. Ross
Data Base Systems Amacon, 1978.
|
(3) | Tom De Marco
Structured Analysis and System Specification,
Prentice Hall, 1979.
|
(4) | C. J. Date
An Introduction to Data Base Systems,
Addison-Wesley. 1977.
|
(5) | Molina, Francisco, et al.
Developing Methods & Models For Data Bases,
en Data Base, Vol. 11 No. 1 1979.
|
(6) | Molina, Francisco W.
A Practical Data Base Design Method.
|
[I] | OBJETIVO
|
[II] | INTRODUCCION
|
[III] | EL DISEÑO LOGICO GLOBAL DEL SISTEMA
|
[IV] | RESUMEN
|
|
|
Bibliografía
|
|
Indice
|
|
Acerca de los autores
|
|
Acerca de este documento
|
|
Principio
Indice
Final
|
Los señores Argüello y Di Mare son Licenciados en Ciencias de la Computación, título otorgado por la Universidad de Costa Rica. Asimismo son profesores en la Escuela de Ciencias de la Computación e Informática de dicha Universidad. El Lic. Di Mare está realizando estudios de postgrado en la Universidad de Calfornia en Los Angeles. (UCLA).
Adolfo Di Mare <adolfo@di-mare.com>
José Ronald Argüello Venegas <jarguell@cariari.ucr.ac.cr>
Referencia: | Argüello Venegas, José Ronald & Di Mare, Adolfo:
Necesidad de un diseño lógico para una base de datos,
Revista COMPUTING, pp 26-30, 1981.
http://www.di-mare.com/adolfo/p/dslgbd.htm
|
Internet: |
http://www.di-mare.com/adolfo/p/dslgbd.htm
|
Autores: | José Ronald Argüello Venegas
<jarguell@cariari.ucr.ac.cr>
Adolfo Di Mare
<adolfo@di-mare.com>
|
Contacto: | Apdo 4249-1000, San José Costa Rica Tel: (506) 207-4020 Fax: (506) 438-0139 |
Revisión: | ECCI-UCR, Marzo 1981
|
Visitantes: |
|
|