Los cambios tecnológicos, producidos en los últimos 15 años, han permitido a los profesionales de administración tener un amplio acceso a los recursos informáticos ( hardware, software y comunicaciones).

En la actualidad una gran cantidad de estos recursos informáticos son manejados por los administradores; pues la misma tecnología va perfeccionando la interfaz usuario – computador; de modo tal que para muchas aplicaciones los usuarios ya no necesitan de un especialista en informática para mejorar sus procedimientos de trabajo.

Es así que las aplicaciones simples, como ser los procesadores de textos y las planillas de cálculo, pueden ser realizadas por los usuarios sin mayores dificultades. Pero, estos mismos usuarios, comienzan a tener dificultades, cuando precisan aplicar recursos que usan eventualmente o bien cuando interactúan con sistemas que exigen un conocimiento mas conceptual y específico de computación.

Es por ello, que en proyectos administrativos desarrollados por profesionales de administración en pequeñas y medianas empresas, con la utilización de microcomputación, se encuentra una gran dificultad en la utilización de las metodologías para la automatización de procedimientos administrativos; especialmente debido a las exigencias y al esfuerzo adicional que requiere la elaboración de modelos y a la gran cantidad de documentación necesaria.

Las herramientas y la metodología, que aquí veremos, apoyan las etapas de análisis del sistema, análisis de los requerimientos de los usuarios y el diseño del software, siendo adecuadas para proyectos que no requieran más de tres hombres por mes coordinados por un proyectista actuando individualmente.

Con referencia a las técnicas simplificadas, cabe aclarar que el término simplicidad de ninguna manera puede confundirse o asociarse al de sencillo, tosco o burdo; una técnica simplificada significa que cuando la finalidad de un proyecto informático se cumple satisfactoriamente y para ello se ha empleado en él, menos personal, una menor cantidad de recursos técnicos y un tiempo menor resulta pues un perfeccionamiento evidente del acto informático.

Puede decirse entonces que en informática aplicada a administración, simplificación y perfeccionamiento son la misma cosa, siempre en la inteligencia de que se cumpla el requisito fundamental de todo proyecto que es la solución de un problema, o al menos el mejoramiento de una situación dada.

En otras palabras se quiere decir que llegar al final por el camino más corto y sencillo, significa indudablemente un progreso, y cuando ante cualquier procedimiento se deja en el ánimo del observador la impresión de que el mismo ha sido fácil es, sin duda alguna, por que se ha efectuado con pulcritud, sencillez, tiempos bien reglados y con prescindencia de procedimientos redundantes y recursos inútiles, vale decir, se ha efectuado con una buena técnica. Partiendo de estos hechos de observación y razonamientos, los conceptos de simplificación y orden riguroso, son inversos a los equipos de trabajo numerosos y al instrumentismo exagerado.

Sin llegar a la torpeza de desarrollar un proyecto informático, en el área de administración, absolutamente solo, o sea, sin ayudante alguno, puede decirse que en la inmensa mayoría de estos proyectos se pueden realizar muy bien con un solo ayudante. El secreto está en saber disponer de las herramientas necesarias, seleccionarlas, según sea el problema a ser abordado, y desarrollar un buen plan para su uso.

Es por eso que, para el profesional joven que recién se inicia en su actividad, este concepto de operaciones o procedimientos es de mucho mas valor didáctico. Si en alguna circunstancia, el profesional, desarrolla su actividad en un medio mal provisto, sentirá un gran alivio de poder hacerlo sin mayores recursos de personal y herramientas. Si por el contrario tuviera que ejercer su desempeño en un medio mejor dotado, tendrá tiempo para rodearse de comodidades; que no siempre redundarán en beneficio del usuario.

Un modelo es una descripción capaz de ser comunicada y que busca:

• Comunicar un cierto aspecto (visión)
• De una parte de la realidad (sistema)
• Con cierto grado de detalle (abstracción)
• Conforme perseguido por alguien (autor del modelo)

• Con el objetivo de servir a los propósitos del usuario.

Sowa Argumenta que el conocimiento sobre alguna cosa es la habilidad de formar un modelo mental que represente esta cosa como así también las acciones que ella puede realizar o se puede realizar sobre ella. Cuando el individuo verifica acciones sobre este modelo él puede predecir las implicaciones que estas acciones tendrán sobre el mundo real.

Según Sowa al relacionar las cosas entre sí y al pensar en ellas nos lleva a un pensamiento estructurado y poder así, describir el funcionamiento de un sistema, y esto debería ser el propósito de todo modelo.

Los modelos pueden tener diferentes clases de estructuras; y las más comunes son la del lenguaje natural, la clase simbólica y la clase matemática.

En los modelos de lenguaje natural, las variables y sus relaciones se funden en forma de prosa. El manual de procedimientos, el manual de organización o la Lista de eventos, que describiremos próximamente, son ejemplos de modelos en lenguaje natural.

Los modelos simbólicos generalmente son más específicos que los de lenguaje natural; Ellos representan un puente útil en el proceso de simbolizar un modelo de lenguaje natural; por ejemplo en un manual de organización se debe incluir un organigrama. La mayoría de los modelos simbólicos se usan para aislar variables y sugerir las direcciones de las relaciones, como lo veremos mas adelante al describir los Diagramas De Flujo de Datos y el Modelo Relacional de Datos pero pocos se diseñan para dar resultados numéricos específicos. El mayor beneficio de los modelos simbólicos está en la representación gráfica de los hechos a través de cuadros o nodos; y es así que el fenómeno se despoja de lo que no es esencial, permitiendo al investigador (observador) entender el conjunto y seleccionar las relaciones a examinar..

Algunos modelos pueden combinar componentes icónicos y análogos; como por ejemplo los flujogramas, dichos diagramas por lo general tienen carácter cualitativo pero pueden convertirse en modelos simbólicos cuantitativos muy exactos.

Los modelos también se pueden utilizar heurísticamente, es decir, utilizarlos para facilitar el descubrimiento. Con frecuencia son un medio efectivo para explorar la estructura asumida de una elección de situación, y para descubrir posibles cursos de acción que de otra manera se pasarían por alto.

Las primeras actividades de diseño de los sistemas, están especialmente influenciadas por la naturaleza de los requerimientos y éstos incluyen principalmente descripciones en lenguaje natural, que según lo visto en el tópico anterior; representan una realidad dada e interpretada de diferentes maneras según sea la visión y la capacidad de abstracción, de cada uno de los participantes del proyecto. En el caso de que los requerimientos, fuesen realizados en forma oral o escrita en lenguaje natural, es indispensable realizar un análisis profundo del texto para poder entender en detalle el o los significados de todos términos involucrados en el proyecto (libres de contradicciones e incongruencias). Luego esta lista estructurada, en el diseño inicial, será la base para la construcción de las entidades y sus relaciones, y que estarán representadas en los diagramas de flujo de datos y en el modelo relacional de datos.

A continuación es presentada una serie de reglas empíricas que ayudarán a la construcción, en forma estructurada, de la lista de eventos.

• Elegir el nivel apropiado de abstracción de para los términos.

• Evitar el uso de casos en lugar de conceptos generales

• Evitar las expresiones vagas o indirectas.

• Elegir un estilo estandarizado de enunciado.

• Verificar los sinónimos y los homónimos.

• Hacer explícitas las referencias entre términos

• Hacer un Diccionario de Datos

El objetivo del DFD es:

En otras palabras, el DFD permite representar de forma completa el sistema de información al relacionar los datos, almacenados en los archivos de datos del sistema, con los procesos que transforman a estos dados.

TÉCNICA DE DISEÑO:

En el diseño de un DFD, como ya lo dijimos anteriormente, son utilizados cuatro símbolos:

1. La Entidad externa
2. El Flujo de datos
3. El Proceso
4. El Archivo de datos.

Las Entidades externas, pueden representar a una persona como ser un Gerente o Jefe de División o a un grupo de persona, como Clientes, Bancos, Proveedores; o también pueden representar a un sistema como el de liquidación de sueldos y jornales.

En sí muestran a las entidades con las cuales el sistema se comunica y por lo tanto no forman parte del sistema en estudios, pues no es de interés para el proyecto lo que ocurre en estas entidades; si así lo fuera esto está indicando que la frontera es mas amplia de lo que se determinó y los procesos involucrados en esta entidad deben pasar a ser parte del sistema en estudio.

Son representadas por medio de un cuadrado, que puede tener un sombreado en dos de sus lados para otorgarle un relieve o .

En el centro del cuadrado se escribe el nombre de la entidad externa que está siendo representada.

Cuando una entidad externa provee datos al sistema, debe existir un flujo de datos saliendo de la entidad en dirección al sistema y cuando una entidad externa recibe datos del sistema, debe existir un flujo de datos que viene del sistema y termina en la entidad externa. Es por esto que a las entidades externas son conocidas también como Terminadores, pues representan el origen y el destino de los Flujos de datos para adentro y para fuera del sistema.

Las entidades externa pueden duplicarse, si fuese necesario darle claridad al diseño y evitar largos vectores, que representan a los flujos de datos o evitar gran cantidad de entrecurzamientos de los mismos.

Los Flujos de datos son representados por vectores direccionados. Ellos son las conexiones entre los procesos y representan a la información que los procesos exigen como entrada y/o las informaciones que ellos generan como salida. Los flujos pueden representar a una información compuesta por un solo elemento como por ejemplo: Precio, Cantidad, Apellido; o bien pueden representar a una información que contiene una estructura de elementos como por ejemplo: Orden de compra, Remito o Factura.

Los Procesos pueden ser mostrados como burbujas o como rectángulos con sus vértices redondeados; según sea la metodología para modelar los procesos de Yourdon o la de Gane & Sarson; en el diagrama ellos representan las diversas funciones individuales que el sistema ejecuta. Estas funciones son las que transforman entradas en salidas.

Los Archivos de datos son mostrados por dos líneas paralelas según la metodología de Yourdon.; o como un rectángulo abierto por uno de sus lados en la metodología de Gane & Sarson. Ellos muestran la colección de datos que el sistema debe mantener en la memoria en un período de tiempo. Al terminar el diseño del sistema y la construcción del mismo, serán los archivos o las tablas de una base de datos.

Figura 2.2, Metodología de Yourdon para la Modelización de los Procesos, vistos desde una paleta de diseño de una herramienta CASE.

Figura 2.3, Metodología de Ganne y Sarson para la Modelización de los Procesos, vistos desde una paleta de diseño de una herramienta CASE.

Como regla general, el tratamiento de errores y de excepciones no deben ser representados en un DFD, a menos que sean muy relevantes para los usuarios del sistema. El DFD debe ser visto como una herramienta de planeamiento del sistema, y no como una especificación detallada. Su finalidad es mostrar el flujo normal de datos entre los principales elementos, y no los detalles de implementación del sistema.

Lo que queremos decir es que, el diagrama de flujo de datos ofrece una visión práctica y general de los principales componentes funcionales del sistema pero no provee detalles sobre esos componentes. Para mostrar los detalles de cuál es la información procesada y como es transformada, precisamos de una herramienta de soporte de modelización textual y una de ellas es el Diccionario de Datos.

El DFD Tampoco provee ninguna indicación explícita de la secuencia del procesamiento. El procesamiento o la secuencia puede estar implícitamente en el diagrama, pero la representación procedimental explícita generalmente queda pospuesta hasta el diseño del software con el flujograma.

FIGURA 2. 4. Diagrama de Flujo de Datos. Vista parcial, nivel 1 del procedimiento de pagos.

1. Los DFD son mas legibles si las entidades externas son diseñadas sobre los bordes del diagrama, de forma que la frontera del sistema (o contexto) se sitúe dentro del contorno de los terminadores o entidades externas
2. Si los flujos de datos principales van del lado izquierdo hacia el lado derecho del diagrama, la lectura se hará mas fácil y rápida.
3. Las duplicaciones de símbolos deben ser mantenidas al mínimo, y contener un número aceptable de líneas de flujo de datos cruzándose unas con otras.
4. Inicie la construcción del DFD por las entidades externas, a continuación siga con las entradas que de ellas son originadas, juntamente con las salidas que irán para ellas.
5. Los primeros diseños de un DFD siempre tendrán la finalidad de borrador. El objetivo es la identificación de todos las entidades externas, procesos y archivos de datos que formarán parte del sistema, además de incluir los flujos de datos entre ellos. Próximas versiones mejorarán las definiciones y el diseño.
6. Al diseñar el primer borrador del DFD, piense en como funciona el sistema realmente, cuál es la entrada o proceso que inicia, y por ahí comience el diseño.
7. El orden más lógico para diseñar un DFD es definir la entidad externa o proceso que genera una entrada de datos, después el proceso que trata esa entrada, y a continuación los archivos de datos que son utilizados para almacenarla y para garantizar el funcionamiento de los procesos afectados y finalmente definir las salidas que son generadas por el proceso.

El primer borrador puede ser realizado en papel, pero los posteriores deben ser realizados utilizando alguna herramienta de software automatizada específicamente diseñada para la modelización del sistema de información; estas herramientas cuentan con un diccionario de datos que almacenan los detalles del modelo lógico del sistema.

Un análisis del ámbito de información estaría incompleto si solo se considera el flujo de la información. Cada flecha del diagrama de flujo de datos representa uno o varios elementos de información. Cada almacén de información a menudo es una colección de elementos de datos individuales; incluso puede que el contenido de una entidad externa requiera ser expandido antes de que su significado pueda ser definido explícitamente. Por lo tanto, el analista debe disponer de algún método para representar el contenido de cada componente del modelo de flujo de datos.

Se ha propuesto el diccionario de datos como gramática casi formal para describir el contenido de los objetos definidos durante el análisis estructurado.

Esta importante notación ha sido definida de la siguiente marea:

El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que le permite al usuario y al analista del sistema tener una misma comprensión de las entradas, de las salidas, de los componentes de los repositorios y también de cálculos intermedios.

Contiene la siguiente información:

Nombre: el nombre principal del elemento de datos, del repositorio de datos o de una entidad externa.

Alias: otros nombres usados para la entrada

Dónde se usa/cómo se usa: Un listado de los procesos que usan un elemento de datos o de control de cómo lo usan.

Descripción del contenido: el contenido representado mediante una anotación

Existen muchos esquemas de anotación usados por los analistas de sistemas el que sigue es uno de los mas usados

FIGURA 3.1,  Diccionario de Datos - Descripción

FIGURA 3.2 Diccionario de Datos - Estructura

FIGURA 3.3 Diccionario de Datos - Definición de un elemento

Todos los sistemas almacenan y usan información sobre el ambiente con el cual interactúan, algunas veces la información es mínima, pero en la mayoría de los sistemas es bastante compleja. No solamente queremos saber, en detalle, qué información está contenida en cada depósito de datos, sino también que relaciones existen entre los depósitos de datos. Este aspecto del sistema no está representado por el diagrama de flujo de datos; pero sí está activamente representado por otro modelo que es el Modelo Relacional de Datos (Relational Data Model).

Como la anotación de los repositorios de datos en el DFD dice muy poco acerca de los detalles de los datos, es necesario que a partir de este modelo, se requiera una clara definición de las entidades y de sus relaciones, que conforman parte del proyecto y que por lo tanto son de especial interés para el usuario. Estos datos y relaciones deben ser almacenados a través de archivos que posteriormente formarán la base de datos del sistema.

Por lo tanto, el objetivo de un RDM es el de ilustrar la estructura de los datos del sistema, a través de la identificación de las entidades detectadas en el sistema y el diseño de sus relaciones.

Por lo tanto, considerando que las entidades de una base de dados están relacionadas, y que, a través de esa relación son generados informes, como por ejemplo: todos los productos vendidos a un cliente, es importante definir todas las relaciones entre las entidades y su correspondiente tipo de relación.

El RDM muestra los tres tipos de relaciones posibles entre las entidades y los eventos de un DFD: uno – a – uno, uno – a – varios y varios – a – varios.

La relación uno a varios es el tipo de relación más común. En este tipo de relación, un registro de la Tabla A puede tener muchos registros coincidentes en la Tabla B, pero un registro de la Tabla B sólo tiene un registro coincidente en la Tabla A.

En una relación varios a varios, un registro de la Tabla A puede tener muchos registros coincidentes en la Tabla B y viceversa. Este tipo de relación sólo es posible si se define una tercera tabla (denominada tabla de unión), cuya clave principal consta de al menos dos campos y que además, estos campos, correspondan a las claves externas de las Tablas A y B.

En una relación uno a uno, cada registro de la Tabla A sólo puede tener un registro coincidente en la Tabla B y viceversa. Este tipo de relación no es habitual, debido a que la mayoría de la información relacionada de esta forma estaría en una sola tabla. Puede utilizar la relación uno a uno para dividir una tabla con muchos campos, para aislar parte de una tabla por razones de seguridad o para almacenar información que sólo se aplica a un subconjunto de la tabla principal.

Los principales beneficios en la utilización del RDM son:

1. Da una visión de alto nivel de los repositorios de datos involucrados en el sistema.
2. Ayuda a descubrir los elementos o las entidades que no fueron detectadas por el DFD.
3. Simplifica la estructuración de los datos
4. Son definidas las Llaves primarias de cada repositorio de datos, como así también sus llaves foráneas, que son necesarias para establecer la relación entre las entidades; y que a través de las cuales podrán ser procesados y consultados los registros y obtener así la información necesaria.
5. Facilita la definición y el análisis del tipo de relación existente entre las entidades u objetos que conformarán la base de datos:

• uno – a – uno, en este caso se debe verificar que cada entidad sea única o pude ser formada por un conjunto de entidades de menor nivel.
• uno – a – varios,
• varios – a – varios; en este caso se debe subdividir en dos relaciones del tipo uno – a – varios. (ver diseño de la relación uno a uno)

Todos estos beneficios hacen que el modelo RDM sea fundamental para poder proyectar una base de datos.

Después de la construcción del RDM, también es necesario que sean incorporados al Diccionario de datos todos los datos que fueron definidos en este modelo y que serán almacenados en cada archivo y que formará la base de dados del sistema.

Por lo tanto, una PERSONA está relacionada a un DEPARTAMENTO (1,1) y un departamento está relacionado a ninguna o varias personas (0,N)

FIGURA 4.1.

En el ejemplo de la Fig. 4.2. cada venta involucra uno o mas productos vendidos (1,N); pero un producto es parte de solamente una venta (1,1).

FIGURA 4.2.

En el ejemplo de la Fig. 4.3. cada proveedor puede suministrar uno o mas productos (1,N) y cada producto puede ser provisto por uno o mas proveedores (1,N) o viceversa pues una relación entre dos entidades puede ser leída en cualquiera de las dos direcciones.

FIGURA 4.3.

Al ser identificada una relación uno a uno (1,1), se debe inicialmente verificar si los dos objetos relacionados son realmente distintos o pueden ser unidos en un único elemento.

Si cada elemento fue identificado con la misma llave principal y si ambos se complementan, hay una fuerte razón para unir a los dos elementos en uno solo. Por ejemplo tenemos a las entidades PRODUCTO Y STOCK.

FIGURA 4.4

Como cada producto es almacenado en Stock, podemos considerar una única entidad de Productos en Stock.

En este caso, las entidades PRODUCTO Y STOCK no son realmente distintas y por ese motivo, debemos almacenarlas en un único archivo de datos, pues el Saldo es apenas un atributo de cada Producto.

FIGURA 4.5

Si los dos elementos fuesen realmente distintos, cada uno deberá ser identificado por un campo llave que lo distinga de forma inequívoca de los demás. Este dato llave es denominado llave primaria del elemento u objeto.

La relación entre los dos objetos deberá ser realizada a través de una llave relación, denominada llave foránea <FK> La llave foránea deberá estar indicada en el objeto relacionado, como se ilustra en la figura 4.6. La llave foránea recibe este nombre porque, en verdad ella no es un atributo del elemento relacionado, pero sí es la llave primaria del elemento al cual está se relaciona.

FIGURA 4.6.

En el caso de relaciones (1,1) entre una MATERIA y un PROFESOR que la dicta, vemos la llave primaria de la MATERIA (Código de la materia que la identifica) y la llave primaria del PROFESOR (Número de legajo). Si admitimos que un PROFESOR está relacionado a una MATERIA, entonces la llave foránea (identificada con la sigla <FK>), que hace la relación (Código de materia) debe ser archivada en el archivo que describe al PROFESOR, y apunta (también se la conoce como puntero) a la materia que él dicta, como ilustra la figura.

Por lo tanto, en el archivo PROFESOR, el dato "Código de la materia" es un campo llave foránea (FK), significando que se trata de un dato del archivo MATERIA, pero que precisa existir en el archivo PROFESOR para permitir la RELACIÓN entre ambos. Note que en esta relación, un PROFESOR puede dictar solamente una MATERIA.

Otra alternativa de relacionar a los archivos PROFESOR y MATERIA sería si admitimos que una materia solamente puede ser dictada por un profesor, esto significa que debemos incluir la llave foránea "Número del profesor" en el archivo MATERIA.

FIGURA 4.7

Aunque estas dos soluciones sean posibles para la relación entre PROFESOR y MATERIA, ninguna de ellas está totalmente correcta. Una mejor solución debe permitir que un profesor pueda dictar varias materias o que una materia pueda ser dictada por varios profesores. O sea, la relación entre PROFESSOR y MATERIA no es uno a uno, sino por lo menos uno a varios (que se trata en el punto siguiente)

A continuación se presentan cuatro preguntas, que sirven como ejemplo, para presentar el análisis que debe ser hecho al proyectarse una relación uno a uno:

La relación uno a varios ocurre cuando un único objeto está relacionado con otros objetos. Como cada objeto de información siempre posee un archivo de datos conteniendo sus atributos, la llave primaria del "objeto uno" debe ser una "llave foránea" en el archivo que describe al "objeto muchos", pudiendo ser parte de su llave primaria o no.

En el ejemplo ilustrado por la Fig. 4.8., mostrando la relación entre una MATERIA y varios PROFESORES, el atributo "Código de la materia" es la llave foránea de PROFESOR.

FIGURA 4.8.

En este caso, una materia puede ser dictada por uno o varios profesores (1,N), pero un profesor solamente puede dictar una única materia (1,1).

En el ejemplo ilustrado por la Fig. 4.9., muestra la relación entre un PROFESOR y varias MATERIAS, el atributo "Número del profesor" es la llave foránea de MATERIA.

FIGURA 4.9.

En este caso un profesor puede dictar una o varias materias (1,N) pero una materia puede ser dictada solamente por un profesor (1,1).

Si analizamos los ejemplos anteriores, percibimos que la relación más correcta entre PROFESOR Y MATERIA no es ni uno a uno ni tampoco uno a varios, pero sí lo es varios a varios, o sea, un profesor puede dictar muchas materias y una materia puede ser dictada por muchos profesores.

Una relación (N,N) siempre debe ser resuelta por dos relaciones (1,N), pues no es posible que tanto PROFESOR como MATERIA reciban llaves foráneas. En este caso, únicamente las llaves primarias de ambos objetos relacionados (N,N) deberán ser identificadas y, a continuación, un "objeto de intersección" deberá ser creado. La llave primaria del objeto de intersección será la combinación o concatenación de las llaves primarias de los dos objetos de origen.

En el ejemplo ilustrado por la figura 4.10, en que un PROFESOR dicta varias materias(1,N) y una MATERIA puede ser dictada por varios profesores(1,N). La única línea de relación (N,N) puede ser considerada como una combinación de dos relaciones (1,N), ambas con un objeto de intersección.

FIGURA 4.10

Para determinar los datos que deberán estar contenidos en los objetos de intersección a ser creados debemos analizar la relación (N,N) entre MATERIA Y PROFESOR haciendo las siguientes preguntas.

¿Cuál debe ser el objeto que posea una llave primaria que corresponda a la concatenación de un determinado "Código de la materia" y de un determinado "Número de profesor"?

¿Qué datos o atributos dependen exclusivamente de esta combinación?

¿Qué datos pueden ser obtenidos si sabemos que estamos tratando con una determinada MATERIA dictada por un determinado PROFESOR?.

Al tratar de responder estas preguntas verificamos que diferentes materias pueden ser dictadas por diferentes profesores en diferentes horarios y aulas y, diferentes profesores dictan diferentes materias en determinadas aulas y en determinados horarios.

Por lo tanto; como una determinada materia puede ser dictada por diferentes profesores en diferentes aulas y en diferentes horarios, podemos crear un objeto de intersección denominado COMISIÓN. De esta forma, un determinado profesor podrá dictar varias materias, cada una en su respectiva aula y horario; así como cada materia podrá ser dictada por varios profesores, y para cada profesor habrá una determinada aula y horario.

La figura 4.11. ilustra la relación (N,N) entre MATERIA Y PROFESOR resuelta por una relación (1,N) entre MATERIA Y COMISIÓN y una relación (1,N) entre PROFESOR Y COMISIÓN.

FIGURA 4.11

En este caso, la llave primaria de COMISIÓN es compuesta por dos llaves foráneas. O sea, para que una COMISIÓN sea identificada es preciso saber cual es la materia y cual es el profesor. Como el "Código de la materia" pertenece a la MATERIA y el "Número de profesor" pertenece a PROFESOR ambos son llaves foráneas en COMISIÓN y concatenadas forman su llave primaria, pues la identifican.

El proceso de la construcción del Modelo Relacional de Datos (RDM), tiene como objetivo:

• Minimizar la duplicación de datos;
• Proporcionar la flexibilidad necesaria para soportar requisitos funcionales y
• Que el modelo se estructure sobre una amplia variedad de diseños alternativos de bases de datos.

La mayor dificultad en este proceso es que se depende de la buena comprensión del analista acerca de lo que realmente es una Entidad, un Atributo y una Relación. Para evitar tal circunstancia es que se aplica el proceso de NORMALIZACIÓN.

Entonces denominamos NORMALIZACIÓN al proceso de simplificación de archivos de datos que componen una base de datos relacional (diseño eficaz de tablas); y que persigue como objetivo principal minimizar la duplicidad de información, prevenir inconsistencias, evitar redundancias, garantizar que no existan pérdidas de información. En resumen son las técnicas y algoritmos que ayudan, al proyectista de una base de datos relacional, a construir relaciones normalizadas, según sea el significado y el contenido del universo a ser modelado, evitando, anomalías en el manejo de estos datos

El proceso de normalización consiste, básicamente, en la aplicación de un conjunto de reglas para definir adecuadamente los datos o campos que compondrán los archivos de datos. Esas reglas buscan:

Fueron establecidos cinco tipos de archivos normalizados, denominados, en orden creciente de simplicidad: primera forma normal (1FN), segunda forma normal (2FN), tercera forma normal (3FN), cuarta forma norma (4FN) y quinta forma normal(5FN).

En general, las tres primeras reglas básicas de normalización son suficientes para resolver la gran mayoría de casos. Es por ello que definiremos a continuación las tres primeras formas normales y discutiremos la manera de simplificar los archivos de datos hasta la tercera forma normal. Se podría resumir a estas tres formas normales mas utilizadas, de la siguiente manera:

• Eliminar campos repetitivos;
• Eliminar datos redundantes;
• Eliminar atributos no dependientes.

Además la 1FN, 2FN y la 3FN son mecanismos para identificar entidades y relaciones perdidas.

Asegurar que todas las entidades son identificadas de forma única por una combinación de atributos y/o relaciones.

Se refiere a cualquier archivo que posea un valor por campo; la relación entre la llave primaria de un archivo y cada uno de los otros campos debe ser de uno a uno.

De una manera práctica, debemos eliminar grupos repetidos de datos, hasta que cada dato tenga una llave primaria para cada ocurrencia.

El archivo de datos ejemplificado a continuación no está normalizado; entre otras cosas, hay mas de un valor o supermercado en cada campo de Negocio.

Como puede percibirse, en el campo Negocio existen varios valores de datos (grupos repetidos). A través de este archivo podemos obtener la información de que existe, por ejemplo, arroz en los supermercados Coto, Tía, Disco, Carrefour, Jumbo. Mientras tanto ¿cómo podríamos llegar a saber la cantidad existente de cada uno de los productos, en cada uno de los negocio?.

De acuerdo con la primera forma normal este archivo debe ser revisado para que sean eliminados los grupos repetidos, o sea, en el campo Negocio debe existir el nombre de apenas un supermercado. Esto implicará, la creación de un número mayor de filas o registros en el archivo. Pues deberá haber una fila para cada producto en cada negocio. A partir de esto, podremos fácilmente registrar la cantidad existente de cada producto en cada negocio.

Después de la aplicación de la primera regla de normalización, el archivo de datos de los productos en Stock asume la siguiente estructura de datos:

Eliminar atributos que dependen solamente de una parte del identificador único

Si una entidad tiene un identificador único compuesto de más de un atributo y/o relación, y si otro atributo depende sólo de una de las partes de este identificador compuesto, entonces el atributo, y la parte del identificador del que depende, deberán formar la base de una nueva entidad. La entidad nueva, se identifica por la parte emigrada del identificador único de la entidad original, y tiene una relación de uno a varios unida con la entidad original.

Para testear si un archivo de datos está en la segunda forma normal debemos hacer inicialmente las siguientes preguntas:

• ¿Cuál es el campo o conjunto de campos que constituye la llave primaria del archivo?

• ¿Hay algún campo no-llave que dependa de apenas, de una parte de la llave primaria?

• ¿La cantidad depende apenas de una parte de la llave?

• ¿El Precio depende apenas de una parte de la llave?

• ¿El Teléfono depende apenas de una parte de la llave?

Cuando un archivo de datos no está en la segunda forma normal, la base de datos no estará correcta por las siguientes razones:

• El archivo de datos ocupará mas espacio en el disco del que será necesario, pues el número de Teléfonos se repite para cada Producto almacenado en el mismo archivo;
• Si un negocio cambia el número de Teléfono, todos los registros de Productos para aquel Negocio deberá tener el campo Teléfono modificado;
• Si ocurre algún problema con el proceso de actualización de datos, un mismo Negocio podrá aparecer con números de Teléfonos diferentes, dependiendo de cual registro sea por el que se accede, o sea, la integridad de la base de datos estará perdida;
• Cuando un negocio posee un único Producto y su registro fuese eliminado (por inexistencia en stock), también será eliminado el Teléfono del Negocio, pues podrá no existir otro lugar en la base de datos que lo almacene.

Para evitar estos problemas, el archivo anterior deberá ser dividido en dos, como se ilustra a continuación:

Ahora los dos archivos están en la segunda forma normal. El archivo de PRODUCTOS EN STOCK está en la segunda forma normal porque los campos no-llave(Cantidad, Precio y Total) son dependientes de toda llave primaria concatenada Producto + Negocio y de nada más.

El segundo archivo, NEGOCIOS, también está en la segunda forma normal porque él no posee una llave concatenada y, por lo tanto, una columna no-llave como Dirección o Teléfono naturalmente será dependiente del único campo llave, que es Negocio.

Analizando desde otra perspectiva, es fácil percibir que el archivo anterior, a pesar de estar en la primera forma normal, contiene datos que describen dos cosas distintas y que son por un lado PRODUCTOS y por el otro NEGOCIOS.

Como regla general es importante, que un archivo de datos en una base de datos debe almacenar datos que describan apenas una entidad o evento. Por lo tanto, un archivo de datos para estar en la segunda forma normal debe contener datos apenas sobre un único objeto de información o una única clase de objetos. En nuestro ejemplo, el primer archivo ahora contiene apenas datos sobre productos en stock y el segundo sobre negocios.

Eliminar los atributos dependientes de atributos que no son parte del identificador único.

Un archivo en la segunda forma normal también estará en la tercera forma normal si un campo no-llave depende de otro campo no-llave.

Para verificar si un archivo en la segunda forma normal también está en la tercera forma normal debemos preguntar: ¿Algún campo no-llave es dependiente de cualquier otro campo no-llave?

El archivo de los PRODUCTOS EN STOCK posee tres campos (o columnas) no-llave: Cantidad, Precio y Total. Si sabemos la Cantidad y el Precio, sabremos el Total. Por lo tanto, el campo "Total" es dependiente de dos campos no-llave, pues puede ser obtenido a partir de la Cantidad multiplicada por el Precio.

Concluimos entonces, que el archivo de PRODUCTOS EN STOCK no está en la tercera forma normal.

Si el campo "Total" fuese eliminado, el archivo de PRODUCTOS EN STOCK pasa a estar en la tercera forma normal, ocupando menos espacio en el disco, y sin pérdida de información.

Como se señaló anteriormente el DFD es una herramienta muy adecuada para modelizar una red de procesos comunicantes asincrónicos. Es por eso que precisamos de otra herramienta para presentar la lógica y la secuencia de un procedimiento.

El flujograma es la representación gráfica que muestra el comienzo y el fin de un proceso de tratamiento de datos y las operaciones de decisiones necesarias para cumplirlo, en el orden secuencial correspondiente.

No hay duda de que de las herramientas tales como los flujogramas, son una excelente forma gráfica de describir fácilmente los detalles procedimentales.

El flujograma es la representación gráfica más ampliamente usada para el diseño procedimental. Desgraciadamente, es también el método del que más se ha abusado.

Un flujograma es un gráfico muy sencillo. Las tres construcciones de la programación estructurada se representan como en la figura. La secuencia se representa como dos cuadros de procesamiento conectados por una línea de control. La condición, también denominada IF-THEM-ELSE (si- entonces - sino), se dibujo como un rombo de decisión que, si es verdad, hace que se realice el procesamiento de la parte them y, si es falso, pasa al procesamiento e la parte else.

Los flujogramas son usados principalmente para la documentación física o las interfaces del hardware dentro de un sistema.

Un flujograma contiene dos tipos e elementos.

1. Los bloques, que indican los pasos del proceso, o funciones de los programas.
2. Las líneas de dirección o flechas que comunica los bloques y determinan el orden secuencial en que deben ser considerados.

Los bloques pueden representar acción o decisión.

Un bloque de acción representa una actividad: efectuar una operación aritmética entre dos números, convertir un valor en cero, etc. Su descripción implica siempre aplicar un verbo (hacer algo): sumar, transferir, borrar, etc.

Un bloque de decisión: es una forma de expresar una consulta acerca del cumplimiento o no de una determinada condición o alternativa. Según sea la respuesta que se dé a dicha consulta (verdadero o falso) se seguirán diferentes caminos.

FIGURA 5.1 FLUJOGRAMA

El objetivo de este tópico es presentar, aquellos esquemas que anteriormente descriptos que facilitan la creación de una Base de Datos y poder así adquirir conocimiento sobre un procedimiento determinado.

Las herramientas tecnológicas utilizadas son de uso cotidiana por parte de la mayoría de los profesionales en administración. Por ejemplo, para realizara la Lista de Eventos fue utilizado el procesador de texto Word 97; para el diseño del Cursograma fue utilizado el asistente de diseño de la planilla electrónica Excel 97; para el diseño del Diagrama de Flujo de Datos, el Modelo Relacional y el Diccionario de Datos fue utilizada una herramienta CASE (Ingeniería de Software Asistida por el Computador).

Se quiere dejar bien aclarado, que no se pretende hacer alarde en el uso métodos particulares, si no el de presentar una metodología que permita mantener la atención en la resolución del problema (Dadiv Marr).

En referencia a la esquematización a través del Cursograma se ha decido su inclusión, por ser ésta una herramienta altamente utilizada por los profesionales argentinos y formar parte de la currícula de distintas asignaturas en el ámbito de las Ciencias Económicas; Igualmente, y en referencia a la técnica de diseño y a las características del mismo, se recomienda la lectura de los trabajos publicados por Carlos Ferrari.

Decidimos la utilización de la Metodología ANSI/X3/SPARC de tres esquemas. para la realización de la arquitectura de este procedimiento de compras. Esta metodología presenta 3 niveles de abstracción de datos y una arquitectura triesquemátcia (ver Figura 1).

El primer nivel corresponde a la visión que cada usuario tiene del Sistema de Información, esta visión conforma la Estructura lógica del Usuario, y que es representado por el Esquema Externo.

El segundo nivel tiene un mayor grado de abstracción que el anterior y corresponde a la visión de un conjunto de usuarios; lo que implica una perspectiva de empresa, esta Estructura Lógica Global es representada por un Esquema Conceptual.

El tercer nivel es la forma en que se organiza la base de datos; Esta Estructura Física está representada por el Esquema Interno.

Estos tres Esquemas nos permiten una mejor conceptualización del Modelo de Datos que precisamos para proyectar y conformar una base de datos.

FIGURA 1 Arquitectura ANSI/SPARC

Fueron consideradas 4 etapas básicas, en nuestro procedimiento a ser modelizado, que son:

1. SOLICITUD DE COMPRA
2. SELECCIÓN DEL PROVEEDOR
3. DECISIÓN DE COMPRA
4. RECEPCIÓN DE LA COMPRA
5. ALMACENAJE DE LA MERCADERÍA

Para la construcción del Esquema Externo fueron utilizadas 2 herramientas: la LISTA DE EVENTOS y el CURSORAMA.

Para la construcción de los Esquemas Conceptuales fue utilizado el Diseño de Flujo de Datos según Yourdon.

Para el Esquema Interno fue utilizada una extensión conceptual del Modelo Entidad - Relación de Chen

Con este trabajo buscamos presentar distintas herramientas de esquematización que faciliten el aprendizaje de los sistemas administrativos; o sea, promover los cambios necesarios en el sistema, que permitan llevar a cabo los procedimientos de una forma más eficiente y eficaz.

Esta mayor eficiencia y eficacia estará dada por: el mejor manejo y almacenamiento de la información computada y la mejor comprensión que logremos de los sistemas; así es que podremos llegar a tener un mayor entendimiento o comprensión de los negocios; pudiendo alcanzar mayores niveles de efectividad. Y por último y esto sí dependiendo de la capacidad del profesional actuante, se podrá lograr una forma más de desarrollo de los objetivos organizacionales.