3.5 - Responsabilidades del Sistema.

1. Actualizar o garantizar la edición de los datos con formularios personalizados para la entrada por filas en las correspondientes tablas (.DBF) como por ejemplo:

• Control de la gestión de la información de los profesionales a través de una tabla principal en donde se guardan, nombres, apellidos, dirección particular, datos laborales y profesionales.

2. Visualizar el contenido de las tablas sin posibilidad de modificaciones para usuarios con posibilidades limitadas de uso del sistema, o sea para obtener resultados del mismo solamente y no introducir datos.

3. Visualizar el contenido de informes guardados en disco como resultado de su obtención en otras ocasiones.

4. Imprimir el contenido de los informes que resultaron de consultas hechas a los datos almacenados.

5. Guardar en disco el contenido de los informes que resultaron de consultas hechas a los datos almacenados.

6. Realizar consultas que garantizan el cumplimiento del objetivo No 1 del sistema.

3.6 - Normalización de la base de datos.

Una base de datos (BD) es un modelo dinámico de información de un objeto del mundo exterior. Las características de ese objeto, la variación de sus elementos y la relación entre ellos, los procesos ocurridos en el objeto se almacenan y evolucionan en las bases de datos. [García, 88]. Una base de datos es un conjunto de tablas relacionadas entre sí a través de vínculos. De acuerdo a la teoría de las Bases de Datos Relacionales es mucho más conveniente fraccionar una base en diferentes tablas que mantener una sola tabla de gran tamaño y difícil manejo.

El diseño de la base de datos lógica es un proceso interactivo que consiste en dividir grandes estructuras heterogéneas de información en tablas homogéneas. Este proceso es conocido como Normalización. [Ullman, 97]. El diseño de este “fraccionamiento” debe hacerse de manera que no haya pérdida de información y que se eliminen al máximo las redundancias (información duplicada en diferentes tablas o entre diferentes artículos de una misma tabla).

La normalización de una base consiste en diseñar todas sus tablas de manera que cumplan con los requerimientos de mínima redundancia. Esto conduce a una base más compacta pero con múltiples vínculos entre sus tablas. La existencia de estos vínculos hace peligroso el manejo de cada tabla por separado con un software de propósito general (Paradox, Dbase o FoxPro, por citar algunos), pues la alteración de una tabla puede romper los vínculos existentes con el resto de las tablas de la base. Por ello, en esos casos es necesario un software de manejo que permita el acceso a los datos y la modificación de los mismos garantizando en todo momento la integridad de las relaciones entre las tablas. Ese es uno de los propósitos esenciales de SICOP.

Con el objetivo de hacer las tablas más eficientes en el aprovechamiento del espacio en disco y eliminar las redundancias, estas se diseñaron utilizando codificadores que se enlazan con otras tablas. Es importante también tener en mente que desde un punto de vista práctico, la normalización mientras generalmente facilita la actualización, tiende a tener un efecto adverso en recuperación. Los datos relacionados que pueden haber sido recuperados de una relación en un esquema no normalizado pueden haber sido recuperados de varias relaciones en forma normalizada. El diseñador de la BD puede por tanto ser tentado a tomar en cuenta los requerimientos de ejecución cuando decida si normalizar todas las relaciones completamente. Un acercamiento “pragmático” tal como este, demuestra que la integridad de la BD no está comprometida por el motivo de eficiencia.

El modelo lógico de la base de datos se diseñó usando la opción Relaciones que ofrece el Sistema General de Bases de Datos (SGBD) Microsoft Visual FoxPro el cual aparece en el Anexo # 7.

Una base de datos bien diseñada suele contener distintos tipos de consultas que muestran la información necesaria. Una consulta puede mostrar un subconjunto de datos, como todos los profesionales del municipio de Mayarí, o combinaciones de datos de tablas diferentes, como la información de pedidos combinada con la información de profesionales.

Cada campo es un hecho acerca de un tema determinado. Por ejemplo, puede que sea necesario almacenar los hechos siguientes acerca de los profesionales: nombre de la entidad, dirección, localidad, municipio o provincia, y número de teléfono. Deberá crear un campo independiente para cada uno de estos hechos. Al determinar qué campos son necesarios, tenga presente estos principios de diseño:

• Incluya toda la información que necesite.

• Almacene información en partes lógicas que sean lo más pequeñas posibles. Por ejemplo, los nombres de los profesionales suelen repartirse en tres campos, Nombre, Primer Apellido y Segundo Apellido, para que sea más fácil ordenar los datos por apellidos.

Determinar las tablas que se necesitan en la base de datos.

Cada tabla contiene información sobre un asunto. Los mismos se refieren en esta investigación a Municipios, Profesionales, Ministerios, Provincias, Categorías docentes, científicas y laborales, Especialidades de los profesionales, su estado civil, los organismos a que pertenecen.

Determinar a qué tabla pertenece cada campo.

Al decidir a qué tabla pertenece cada campo, tuvimos presente los siguientes principios de diseño:

Agregar el campo a una sola tabla.

No agregar el campo a una tabla si, como resultado, la misma información va a aparecer en varios registros de esa tabla. Si determina que un campo de una tabla va a contener mucha información duplicada, seguramente ese campo se encuentra en una tabla que no le corresponde.

Por ejemplo, si un campo tiene el número de identidad de un profesional, en la tabla de C_Prof, automáticamente todos los demás datos, serán buscados en las tablas correspondientes de ministerios, organismos, provincias, municipios, categorías, ya sean laborales, docentes o científicas, ya que todas las tablas del sistema se relacionan entre sí, a través de las claves principales, Anexo # 7. En el caso de que el registro ubicado en la tabla de las plantillas de profesionales, contenga en unos de sus campos relacionados un dato que no se corresponda o no se encuentre en alguna de las tablas antes mencionadas, se marcará un registro en blanco en la tabla que se corresponda con la búsqueda de información.

Cuando cada elemento de información se almacena una sola vez, se actualiza en un solo lugar. Esto resulta más eficaz y elimina la posibilidad de que existan entradas duplicadas que contengan información diferente.

Identificar el campo o los campos con valores únicos en cada registro.

Para que Microsoft Visual FoxPro conecte información almacenada en tablas distintas, por ejemplo, para conectar un Ministerio con todos los Organismos de su Ministerio, cada tabla de la base de datos debe incluir un campo o un conjunto de campos que identifican de forma exclusiva cada registro de la tabla. Este campo o conjunto de campos se denomina clave principal.

Determinar las relaciones entre las tablas.

Al dividir la información en tablas y ha identificado los campos de clave principal, necesita una forma de indicar a Microsoft Visual FoxPro cómo volver a reunir toda la información relacionada de un modo significativo. Para ello se definen relaciones entre las tablas.

3.7 - Recogida de la información primaria.

El sistema realiza la recogida de la información mediante 10 tablas normalizadas (acerca de la normalización consultar epígrafe 3.1.5 de este capítulo), de las cuales 9 se encargan de la recogida de los datos primarios, a la tabla restante le llamamos información secundaria, que son los datos de las planillas de los profesionales donde se recoge toda la información ya sea personal, laboral o profesional.

En esta tabla se almacenan todos los Ministerios. Tiene relación con la tabla C_PROF (CODMIN --- CODMIN) y la tabla C_ORG (CODMIN --- CODMIN) esta última tabla contiene una relación dependiente de C_MIN. Tipo de relación: uno a varios.

En esta tabla se almacenan todos los municipios detallados por provincias, es una tabla dependiente de la tabla de provincias. Tiene una relación con la tabla C_PROF (CODPROV+CODMUN ---- CODPROV+CODMUN) y a la vez con C_PROV (CODPROV -- CODPROV). Tipo de relación: uno a varios.

En esta tabla se almacenan todos los organismos relacionados por Ministerios, es una tabla dependiente de la tabla C_MIN, Tiene una relación con la tabla C_PROF (CODMIN+CODORG --- CODMIN+CODORG) y a la vez con la tabla C_MIN (CODMIN --- CODMIN). Tipo de relación: uno a varios.

Anexo # 7. Diseño de la base de datos.