Analisis de procesos

Análisis de Procesos

El Kaizen se enfoca pues en la mejora continua de los estándares en materia de calidad, productividad, costos, seguridad, y entrega. Para ello da primacía a la calidad como componente central que permite y facilita a través de su concreción el cumplimiento de los demás objetivos.
El Kaizen volcado en el plano de la informática implica tanto la aplicación de la filosofía y estrategias, como de los diversos instrumentos, métodos y herramientas de análisis y gestión que le son propias a la mejora continua de las actividades y procesos informáticos.
Las actividades y procesos informáticos para una empresa productora de bienes y servicios no informáticos constituyen actividades con valor agregado para la empresa, pero sin valor agregado para el consumidor. Por tal motivo el tamaño y costos relativos de estas actividades para la organización deben ser reducidos convenientemente. Así pues cada subactividad o subproceso que la componen deberán ser sometido a un análisis tendiente a verificar su utilidad y/o necesidad, como así también al nivel de eficiencia con el cual tienen lugar las mismas. Para ello se hace uso de los conceptos y herramientas del Kaizen.

En el actual orden de cosas los procesos informáticos y la información que estos brindan constituyen un elemento crítico a la hora tanto de prestar los servicios, como de organizar y controlar los procesos productivos, como de tomar decisiones acertadas en tiempo y forma. Por tal motivo aplicar un sistema que como el Kaizen permiten mejorar a un bajo costo y de manera continua los procesos, y los resultados que de ello se deriva, resulta fundamental tanto operativa como estratégicamente para la empresa.
Para cada uno de estos tipos fundamentales el personal del área informática, como así también los clientes del sistema, deberán identificar los desperdicios existentes, analizando su eliminación y aplicando medidas para evitar su reaparición.

De tal forma y sólo a título de ejemplo podemos mencionar los siguientes casos:

2.1. Sobreproducción

Impresión de informes en cantidades superiores a las necesarias, ya sea porque se efectúan con mayor frecuencia de la necesaria, porque se imprimen una cantidad de datos superiores a los requeridos, porque se imprime para sectores que no hacen uso de ellos o que haciendo uso de los mismos podrían compartir dichos impresos con otros sectores. La otra posibilidad es que se imprima información que pudiera ser fácilmente consultada por pantalla.

2.2. Inventario

Exceso de insumos y repuestos. Entre los insumos se tienen las resmas de papel, los monitores de repuestos entre muchos otros.

2.3. Procesamiento

Comprende tanto los diseños de información, procesamiento y carga de datos, como los procesamientos en si.

Así tenemos la duplicación de procesos, que lleva en algunos casos a cargar más de una vez los datos, exceso de datos o mala distribución de éstos en los impresos o pantallas, dejar de lado las necesidades de los usuarios o clientes. Diseños en función a la visión o punto de vista de los programadores.

Es menester subrayar que los errores motivados por una planificación y diseños inapropiados terminan elevando de manera significativa el funcionamiento del sistema, debido entre otros aspectos a los costosos arreglos y en algunas ocasiones severos perjuicios que los errores puedan ocasionar a los clientes de la empresa, a los usuarios internos y los provocados al adoptar decisiones incorrectas.

2.4 Esperas

Provocadas estas por un lado por los cuellos de botella, sean éstos generados por escasez de impresoras, problemas con las velocidades del software o del hardware, velocidades de impresión, o bien provocados dichos cuellos de botella por la existencia de funcionarios que haciendo las veces de filtro concentran poder y lentifican los procesos, haciendo depender al resto de personal y sectores de sus decisiones.

Entre otros motivos de espera se tienen las provocadas por reparaciones debidas a la falta de mantenimiento, y las que tienen lugar por ausencia de capacitación a nuevo personal, las acontecidas por falta de elementos u ordenes para los programadores o personal encargado de grabar datos.

2.5. Movimientos


Los distintos componentes tecnológicos utilizados para mejorar o reducir los movimientos en la carga de datos. Ejemplo: las lectoras de códigos de barras utilizadas en las cajas de los supermercados aceleran enormemente el proceso de facturación, al tiempo de que permiten actualizar de forma continua el estado de los inventarios y generar los pedidos de mercaderías. La utilización de teclados especiales que eviten la aparición de la enfermedad del túnel carpiano a los operadores, permitiendo así mayor descanso, aumento de la productividad y menor ausencia por enfermedad.

2.6. Transporte

Podemos disminuir la cantidad de personal, si en lugar de transportar impresos desde el sector cómputos, los mismos son impresos en cada sector.
De igual forma en lugar de imprimir normativas internas, las mismas tendrían que ser objeto de consulta por monitor vía Intranet. De tal forma se evita gastos de impresión, o de fotocopiado, tiempo de ensobrados, costos de envíos y posteriores tiempos de archivo, lo que a su vez implica costos de espacio, y al momento de la consulta el costo del tiempo de búsqueda de la información en los archivos de carpetas.

2.7. Reparaciones / Rechazos de productos defectuosos

Entre las reparaciones se tienen las de hardware y/o base de datos, provocadas por una falta de política de prevención en materia de protección (Ejemplo: la falta de uso de baterías de energía lleva a daños en los archivos o en los dispositivos internos, debido a los problemas de corte de suministro de energía).
Entre los rechazos de productos defectuosos se tienen desde la falta de calidad en los programas, a los problemas de defectos en las impresiones (por falta de mecanismos automáticos de control –autonomatización-).
Los casos dados anteriormente han sido mencionados tan sólo a título de ejemplo, pudiendo ser ampliados mediante la labor de los Círculos de Calidad o los Equipos de Mejoras de Procesos, haciendo para ello uso de las más diversas herramientas tales como la Tormenta de Ideas, el Diagrama de Ishikawa, el Diagrama de Pareto, los fluxogramas y las estratificaciones entre otros.

QFD

La calidad introducida en las etapas de planificación y diseño permite obtener una mayor eficiencia en base a una calidad elevada a bajo coste.
Al igual que en los procesos de desarrollo de productos, los procesos de desarrollo de software comienzan con las expectativas del cliente y concluyen con la salida del programa terminado. El papel del proceso de desarrollo consiste en traducir las expectativas del cliente interno (o externo) en especificaciones internas, transmitiendo fielmente dichas especificaciones a las distintas funciones implicadas.

Para una mejor concreción de los objetivos de diseño se hace uso del QFD (Despliegue Funcional de la Calidad). La característica esencial del QFD es la de ser una herramienta de la calidad que actúa en la etapa de diseño del producto y su desarrollo.

El Despliegue Funcional de la Calidad es un método para desarrollar una calidad de diseño enfocada a satisfacer al consumidor (cliente interno o externo), de forma que se conviertan los requerimientos del mismo en objetivos de diseño y elementos esenciales de aseguramiento de la calidad a través de la fase de producción (de bienes o servicios –software en éste caso), por lo que podemos afirmar que el despliegue de funciones de calidad es un modo de asegurar la calidad mientras el producto o servicio está en fase de diseño.

Entre los beneficios derivados de la aplicación del QFD tenemos:

1. Integración de la calidad demandada y las características de calidad en un gráfico de calidad básico.

2. Fijación de las metas basadas en la cuantificación de las evaluaciones por parte de los usuarios.

3. Conversión de requerimientos de calidad demandados en elementos medibles de diseño e ingeniería.

4. La planificación del nuevo software resulta más específica.
5. Las actividades de planificación y desarrollo están más ligadas a las expectativas.

6. Jerarquiza las acciones de manera objetiva.
7. Reduce costes.
8. Mayor satisfacción del cliente (interno o externo).
9. Mayor transparencia en los procesos de desarrollo.
10. Mejora de la calidad y fiabilidad del producto.

Entre los resultados concretos cuantificables en las empresas que han hecho uso de esta herramienta se tienen:

• El ciclo de desarrollo se reduce entre un 30% y un 60%.
• Las modificaciones del producto y del proceso se reducen entre un 30% y un 50%.
• Los costes de lanzamiento se reducen entre un 20% y un 60%.
• Las reclamaciones de los clientes se reducen hasta en un 50%.

Análisis Modal de Fallos y Efectos (AMFE)

Conocida también como AMFE, es una metodología que permite analizar la calidad, seguridad y/o fiabilidad del funcionamiento de un sistema, tratando de identificar los fallos potenciales que presenta su diseño y, por tanto, tratando de prevenir problemas futuros de calidad. Se aplica por medio del estudio sistemático de los fallos.
El estudio tendrá como objetivo la corrección de los diseños para evitar la aparición de los fallos, estableciendo en lo necesario, un plan de control dimensional, como resultado del estudio de los fallos y su corrección en lo que sea necesario para evitar la aparición de los mencionados fallos.

Se trata pues de una herramienta de predicción y prevención.
La aplicación de la misma la podemos enmarcar dentro del proceso de diseño, siendo además aplicable a la mejora de productos o procesos existentes.

Autonomatización

Con la autonomatización, las propias máquinas se encargan de no producir fallos. Ejemplo de utilización de este sistema es su aplicación a las impresoras, evitando de tal modo la pérdida de material, y tiempo de proceso, como así también tener que disponer de personas para observar el proceso de impresión.
Los problemas informáticos

El coste de pasar por alto los problemas informáticos puede ser desastroso. El dicho "puede costarle esto ahora y el doble más tarde" resulta tan aplicable a un problema informático como a un problema de transmisión en un automóvil.

La mayoría de los problemas informáticos pueden ser reducidos a cinco causas fundamentales, siendo éstas las siguientes:

1.Planificación insuficiente.

La causa principal de la mayoría de los fallos en los sistemas informáticos es la insuficiencia de los recursos y esfuerzos que se dedicaron a la planificación. A menudo los ordenadores se adquieren por impulso y más para satisfacer un capricho que para cubrir una necesidad de proceso de información. Los sistemas se desarrollan sin planificar su interconexión con los sistemas manuales. La asignación de personal se basa en limitaciones presupuestarias, y no en la capacitación y el número de empleados que se requieren para llevar a efecto de forma eficaz las aplicaciones del ordenador.

La planificación es una función gestora que los técnicos frecuentemente prefieren ignorar, o que la llevan a cabo con el único fin de satisfacer lo que consideran una manía superior pero no para establecer unas pautas que deban seguirse en la automatización de la empresa.

2.Incapacidad de integrar el ordenador en la estructura empresarial.

El principal objetivo de los ordenadores es satisfacer las necesidades de proceso de información de la empresa. Los datos pueden ser el recurso primordial de una organización: no son propiedad del departamento de proceso de datos, ni de los usuarios individuales que crean y utilizan los datos. Mientras que los datos no se administren como un recurso más de la empresa, no recibirán la atención adecuada por parte de la dirección y quedarán relegados a un nivel en el que su utilización puede estar mal planificada y peor dirigida. Es una verdadera pena que no se obtenga provecho de los datos, tratándolos como cualquier otra inversión de la empresa.
A la dirección tal vez no le preocupe que los datos se deterioren, pero no permitirá nunca que le ocurra lo mismo a la maquinaria y las instalaciones.


3.Negligencia en conseguir la necesaria formación del personal de proceso de datos.

Es responsabilidad de la dirección asegurarse de que el personal esté debidamente formado. Ello supone contratar a las personas adecuadas, proporcionarles la formación adicional necesaria para desarrollar o mejorar sus aptitudes, y evaluar su actuación a fin de asegurarse de que el personal está llevando a cabo su trabajo tal como es debido.
Dada la naturaleza técnica del proceso de datos, la dirección puede sentirse insegura a la hora de evaluar las aptitudes necesarias, viéndose obligada a apoyarse en terceras personas para contratar nuevo personal y a considerar la experiencia previa como signo de competencia. Los usuarios necesitan también una formación técnica.

4.Incapacidad para determinar las auténticas necesidades del usuario.

Los técnicos no suelen opinar que la determinación de las necesidades reales del usuario sea una función productiva.
El diseño, la programación y las pruebas del sistema son trabajos cuyos resultados resultan visibles. Ahora bien, un gran número de sistemas se construyen antes de que su proyecto se haya estructurado por completo, y son muchos los usuarios que aprueban un sistema antes de saber exactamente qué es lo que se les está ofreciendo.
Materializar lo que otros dicen que desean o aquello a lo que dan su aprobación, no tiene ninguna utilidad, si luego no sirve para el trabajo que hay que hacer.

5.Negligencia en el establecimiento de los controles informáticos adecuados.

En un entorno ideal, en el que todo funciona a la perfección, los controles son innecesarios. Por desgracia, los sistemas informáticos rara vez son ideales y requieren, por tanto, un control.

Como ya se explicó con anterioridad, los controles manuales pueden no ser eficaces en un sistema automatizado. Los controles diseñados para una sistema automatizado deben complementar las características del ordenador. Ello implica una reestructuración de los controles por parte de una persona que conozca a fondo la empresa y el ordenador.

Estas causas fundamentales de los problemas informáticos pueden exponerse a través de las siguientes cinco reglas esenciales:

Primera regla: "Desarrollar planes informáticos tanto a largo como a corto plazo, ateniéndose luego a ellos".

Segunda regla: "Nombrar un directivo que se haga responsable de los datos y de integrar la utilización del ordenador en la estructura empresarial"

Tercera regla: "Contratar a los mejores técnicos disponibles, desarrollando de forma continua sus aptitudes y evaluando sus capacidades para desempeñar de forma adecuada sus cometidos. Sustituyendo a quienes no lleguen a alcanzar las aptitudes necesarias".

Cuarta regla: "No adquirir ni poner en funcionamiento una aplicación informática hasta que todas las necesidades se hayan definido correctamente y todas las partes interesadas hayan dado su conformidad".
Quinta regla: "Diseñar y mantener un sistema adecuado de controles de ordenador que aseguren un proceso de datos exactos, completo, profesional y a tiempo".

Instrumentos de diagnóstico

La Matriz de Diagnóstico y Resolución de Problemas puede y debe complementarse con otros instrumentos siendo éstos los siguientes:

• Test de intuición: consistentes en prueba para saber si el ordenador se está o no utilizando correctamente.
• Test analítico: consiste en una evaluación matemática para poner de manifiesto con datos numéricos los buenos y malos aspectos de la función de proceso de datos.
• Test de exploración: conformado por cuestionarios estructurados cuyo fin es descubrir los defectos de las aplicaciones del proceso de datos propuestas o implantadas.
• Plan de actuación para erradicar los problemas informáticos
• Para erradicar un problema informático es necesario que la alta dirección dé el primer paso. La información es un recurso de la empresa y, por consiguiente, ha de ser gestionado como cualquier otro. La alta dirección debe establecer las directrices requeridas para esa gestión.

A continuación se enumeran las cuatro etapas del plan de actuación:

• Etapa 1: establecer directrices de calidad en el proceso de datos. En esta etapa, la dirección debe especificar el nivel de calidad que espera del proceso de la información.

• Etapa 2: nombrar a una persona que asuma la responsabilidad. Las directrices sólo funcionan cuando se asigna a una sola persona la responsabilidad de su cumplimiento.

• Etapa 3: establecer una función de garantía de calidad. Es la que se hace cargo del adecuado funcionamiento del proceso de tratamiento de la información.

• Etapa 4: establecer una función de control de calidad.
El control de calidad ha de efectuarse durante el desarrollo y ejecución de cada uno de los sistemas de aplicaciones. Esta función se encarga de garantizar que los productos elaborados por la función de proceso de datos cumplan las normas establecidas por la dirección en sus directrices de calidad.

• Principales síntomas de problemas informáticos

• A los efectos de su detección, posterior análisis y resolución del problema de acuerdo a los patrones antes expuestos, se despliega a continuación una lista de 43 síntomas que manifiestas algún tipo de problema en el sistema informático.
Se aconseja a los responsables encarar dicho análisis como tarea grupal o bien realizar dicho test de manera individual, reuniéndose posteriormente dichas personas para evaluar sus respuestas. Es conveniente para cada punto manifestar si se da o no tal problema, ejemplificando con posterioridad el mismo. Si muchos puntos son coincidentes en cuando a respuesta y si a ello se agregan los mismos ejemplos tendremos ante nosotros puntos bien precisos de mejora a realizar.


Base de datos distribuida

es una colección de datos que pertenecen lógicamente a un sólo sistema, pero se encuentra físicamente esparcido en varios "sitios" de la red.

Un sistema de base de datos distribuidas se compone de un conjunto de sitios, conectados entre sí mediante algún tipo de red de comunicaciones, en el cual :

• Cada sitio es un sistema de base de datos en sí mismo, pero,
• Los sitios han convenido en trabajar juntos ( si es necesario ) con el fin de que un usuario de cualquier sitio pueda obtener acceso a los datos de cualquier punto de la red tal como si todos los datos estuvieran almacenados en el sitio propio del usuario.

El sistema de administración de Base de Datos Distribuida (DDBMS), esta formado por las transacciones y los administradores de base de datos distribuidos de todas las computadoras. Tal DDBMS en un esquema genérico implica un conjunto de programas que operan en diversas computadoras. Estos programas pueden ser subsistemas de un producto único DDBMS, concesionado por un sólo fabricante, o también pudiera resultar de una colección de programas de fuentes dispares : algunos considerados por fabricantes y algunos otros escritos en casa.

Un administrador de base de datos (DTM) es un programa que recibe solicitudes de procesamiento de los programas de consulta o de transacciones y a su vez las traduce en acciones para los administradores de la base de datos . Una función importante del DTM es coordinar y controlar dichas acciones.

Cada sitio tiene sus propias bases de datos "reales" locales, sus propios usuarios locales, sus propios DBMS y programas para administración de transacciones y su propio administrador local de comunicación de datos. La diferencia principal entre los sistemas de bases de datos centralizados y los distribuidos es que en los primeros, los datos residen en una sola localidad, mientras que, en lo últimos, se encuentran en varias localidades. Cada localidad puede procesar transacciones locales , es decir, aquellas que sólo acceden a datos que residen en esa localidad. Además, una localidad puede participar en la ejecución de transacciones globales , es decir, aquellas que acceden a datos de varias localidades, ésta requiere comunicación entre las localidades.

Una transacción local es la que accede a cuentas en la localidad individual donde se inicio. En cambio, una transacción global accede a cuentas de una localidad distinta a la localidad donde se inicio o a cuentas de varias localidades diferentes.
Por qué son deseables las bases de datos distribuidas?
La respuesta básica a esta pregunta es que por lo regular las empresas ya están distribuidas, por lo menos desde el punto de vista lógico ( en divisiones, departamentos, proyectos, etc ) y muy probablemente en el sentido físico también ( en plantas, talleres, laboratorios, y demás ), de lo cual se desprende que en general la información ya está también distribuida, porque cada unidad de organización dentro de la empresa mantendrá por fuerza los datos pertinentes a su propio funcionamiento. Así pues, un sistema distribuido permite que la estructura de la base de datos refleje la estructura de la empresa : los datos locales se pueden mantener en forma local, donde por lógica deben estar, pero al mismo tiempo es posible obtener acceso a datos remotos en caso necesario.

• principio fundamental de las bases de datos distribuidas :

Desde el punto de vista del usuario, un sistema distribuido deberá ser idéntico un sistema no distribuido. En otras palabras, los usuarios de un sistema distribuido deberán comportarse exactamente como si el sistema no estuviera distribuido. Todos los problemas de los sistemas distribuidos son (o deberían ser ) internos o a nivel de realización, no externos o a nivel del usuario. Llamaremos al principio fundamental recién identificado la "regla cero" de los sistemas distribuidos.

La regla cero conduce a varios objetivos o reglas secundarios - doce en realidad- siguientes :

• Autonomía local.
• No dependencia de un sitio central.
• Operación continua.
• Independencia con respecto a la localización.
• Independencia con respecto a la fragmentación.
• Independencia de réplica.
• Procesamiento distribuido de consultas.
• Manejo distribuido de transacciones.
• Independencia con respecto al equipo.
• Independencia con respecto al sistema operativo.
• Independencia con respecto a la red.
• Independencia con respecto al DBMS.

Ventajas


Existen cuatro ventajas del procesamiento de bases de datos distribuidas.

La primera , puede dar como resultado un mejor rendimiento que el que se obtiene por un procesamiento centralizado. Los datos pueden colocarse cerca del punto de su utilización, de forma que el tiempo de comunicación sea más mas corto. Varias computadoras operando en forma simultánea pueden entregar más volumen de procesamiento que una sola computadora.

Segundo , los datos duplicados aumentan su confiabilidad. Cuando falla una computadora, se pueden obtener los datos extraídos de otras computadoras. Los usuarios no dependen de la disponibilidad de una sola fuente para sus datos .

Una tercera ventaja , es que los sistemas distribuidos pueden variar su tamaño de un modo más sencillo. Se pueden agregar computadoras adicionales a la red conforme aumentan el número de usuarios y su carga de procesamiento. A menudo es más fácil y más barato agregar una nueva computadora más pequeña que actualizar una computadora única y centralizada. Después, si la carga de trabajo se reduce, el tamaño de la red también puede reducirse.

Por último , los sistemas distribuidos se puede adecuar de una manera más sencilla a las estructuras de la organización de los usuarios.

Desventajas


Las primeras dos desventajas de las bases de datos distribuidas son las mismas que las dos primeras ventajas.

Primero,
el rendimiento puede ser peor para el procesamiento distribuido que para el procesamiento centralizado. Depende de la naturaleza de la carga de trabajo, la red, el DDBMS y las estrategias utilizadas de concurrencia y de falla, así como las ventajas del acceso local a los datos y de los procesadores múltiples, ya que éstos pueden ser abrumados por las tareas de coordinación y de control requeridas. Tal situación es probable cuando la carga de trabajo necesita un gran número de actualizaciones concurrentes sobre datos duplicados, y que deben estar muy distribuidos.

Segundo ,
el procesamiento de base de datos distribuida puede resultar menos confiable que el procesamiento centralizado. De nuevo, depende de la confiabilidad de las computadoras de procesamiento, de la red, del DDBMS, de las transacciones y de las tasas de error en la carga de trabajo. Un sistema distribuido puede estar menos disponible que uno centralizado. Estas dos desventajas indican que un procesamiento distribuido no es ninguna panacea. A pesar de que tiene la promesa de un mejor rendimiento y de una mayor confiabilidad, tal promesa no está garantizada.

Una tercera desventaja es su mayor complejidad, a menudo se traduce en altos gastos de construcción y mantenimiento. Ya que existen más componentes de hardware, hay más cantidad de cosas por aprender y más interfaces susceptibles de fallar. El control de concurrencia y recuperación de fallas puede convertirse en algo complicado y difícil de implementar, puede empujar a una mayor carga sobre programadores y personal de operaciones y quizá se requiera de personal más experimentado y más costoso.

El procesamiento de bases de datos distribuido es difícil de controlar.
Una computadora centralizada reside en un entorno controlado, con personal de operaciones que supervisa muy de cerca, y las actividades de procesamiento pueden ser vigiladas, aunque a veces con dificultad. En un sistema distribuido, las computadoras de proceso, residen muchas veces en las áreas de trabajo de los usuarios. En ocasiones el acceso físico no está controlado, y los procedimientos operativos son demasiado suaves y efectuados por personas que tienen escasa apreciación o comprensión sobre su importancia. En sistemas centralizados, en caso de un desastre o catástrofe, la recuperación puede ser más difícil de sincronizar.

• Propagación de Actualizaciones

El problema básico con la réplica de datos, es la necesidad de propagar cualquier modificación de un objeto lógico dado a todas las copias almacenadas de ese objeto. Un problema que surge es que algún sitio donde se mantiene una copia del objeto puede NO estar disponible, y fracasaría; la modificación si cualquiera de las copias no esta disponible.

Para tratar este problema se habla de " una copia primaria " y funciona así :

• Una de las copias del objeto se designa como copia primaria, y las otras serán secundarias.
• Las copias primarias de los distintos objetos están en sitios diferentes.
• Las operaciones de actualización se consideran completas después de que se ha modificado la copia primaria.
. El sitio donde se encuentra esa copia se encarga entonces de propagar la actualización a las copias secundarias.
Recuperación

Basado en el protocolo de compromiso de dos fases.
El compromiso de dos fases es obligatorio en cualquier ambiente en el cual una sola transacción puede interactuar con varios manejadores de recursos autónomos, pero tiene especial importancia en un sistema distribuido porque los manejadores de recursos en cuestión ( o sea los DBMS locales ) operan en sitios distintos y por tanto son muy autónomos.

En particular, son vulnerables a fallas dependientes. Surgen los siguientes puntos :

• El objetivo de "no dependencia de un sitio central" dicta que la función de coordinador no debe asignarse a un sitio específico de la red, sino que deben realizarla diferentes sitios para diferentes transacciones. Por lo regular se encarga de ella el sitio en el cual se inicia la transacción en cuestión.

• El proceso de compromiso en dos fases requiere una comunicación entre el coordinador y todos los sitios participantes, lo cual implica más mensajes y mayor costo extra.

• Si el sitio Y actúa como participante en un proceso de compromiso en dos fases coordinado por el sitio X, el sitio Y deberá hacer lo ordenado pro el sitio X ( compromiso o retroceso, según se aplique ), lo cual implica otra pérdida de autonomía local.

• En condiciones ideales, nos gustaría que el proceso de compromiso en dos fases funcionara aun en caso de presentarse fallas de sitios o de la red en cualquier punto. Idealmente, el proceso debería ser capaz de soportar cualquier tipo concebible de falla. Por desgracia es fácil ver que este problema es en esencia imposible de resolver; es decir, no existe un protocolo finito que garantice el compromiso al unísono de una transacción exitosa por parte de todos los agentes, o el retroceso al unísono de una transacción no exitosa en caso de fallas arbitrarias.

Concurrencia

Este concepto tiene que ver con la definición de un agente.

El manejo de transacciones tiene dos aspectos principales, el control de recuperación y el control de concurrencia. En un sistema distribuido, una sola transacción puede implicar la ejecución de código en varios sitios ( puede implicar actualizaciones en varios sitios ), entonces se dice que una transacción esta compuesta por varios agentes, donde un agente es el proceso ejecutado en nombre de una transacción dada en determinado sitio. Y el sistema necesita saber cuando dos agentes son parte de la misma transacción.

Un Panorama de las Bases de Datos Orientadas a Objetos

Como cualquier base de datos programable, una base de datos orientada a objetos (BDOO) da un ambiente para el desarrollo de aplicaciones con un depósito persistente listo para su explotación. Una BDOO almacena y manipula información que puede ser digitalizada (representada) como objetos, proporciona una estructura flexible con acceso ágil, rápido, con gran capacidad de modificación. Además combina las mejores cualidades de los archivos planos, las bases jerárquicas y relaciónales.
Actualmente, el creciente uso de las metodologías de programación orientadas a objetos está promoviendo la aparición de manejadores de BDOO en el mercado. Esto tiene sentido, puesto que la tecnología de objetos proviene del desarrollo de metodologías avanzadas de programación. Más aún, la comunidad internacional está convencida de que los manejadores de BDOO tienen la flexibilidad tanto en la definición del modelo de datos como en el desempeño tan anhelado por muchos desarrolladores de aplicaciones, lo que es imposible encontrar en los modelos jerárquicos de red o relaciónales.
Los objetos pueden estar compuestos por cualquier tipo de información que, eventual mente, puede almacenarse en forma digital; por ejemplo, imágenes barridas, voz, sonido, dibujos, planos arquitectónicos complejos, esquemas electrónicos y diagramas desarrollados por ingenieros, así como los tradicionales tipos de datos alfanuméricos. Comúnmente, las aplicaciones que producen este tipo de objetos complejos, al terminar, los guardan en archivos de datos en distintos formatos. Cuando el programa es reactivado, los objetos, se cargan nuevamente. En estos ambientes, los objetos son accesibles sólo a un usuario en cada momento, no existen mecanismos de seguridad, no hay manera de protegerse ante la eliminación accidental de un objeto complejo. Las BDOO superan todas estas dificultades porque permiten que múltiples usuarios compartan objetos complejos para manipularlos en ambiente seguro y estructurado.
Una base de datos relacional tiene una estructura más flexible, pero no puede manejar tipos de datos complejos. Para sobreponerse a estas limitaciones, algunos proveedores han desarrollado las bases de datos orientadas a objetos, las cuales son diseñadas para manipular los objetos con los conceptos de la programación orientada a objetos, proporcionando un concepto persistente en un ambiente multiusuario seguro.
Existen niveles en los cuales las bases de datos incorporan los conceptos alrededor de la metodología de objetos. La primera clase, puede denominarse BDOO pasivas o "estructuralmente orientadas a objetos", que permiten manejar objetos compuestos. Una base de datos pasiva puede almacenar objetos complejos pero no puede definir comportamientos. Este tipo de bases de datos se utiliza para almacenar objetos de otras aplicaciones. Una BDOO pasiva incluye conceptos como "jerarquía parte de", pero no incluye mecanismos para tipos definidos por el usuario o aspectos que definen comportamientos. Una BDOO es activa u "orientada a objetos por comportamiento" si permite definir y ejecutar comportamiento de los objetos dentro de la base de datos, incorpora conceptos como la "herencia" y permite el manejo de tipos definidos por el usuario. Si se incorporan todos los aspectos se denomina "plenamente orientada a objetos". En bases de datos activas, es sencillo programar una señal de alerta en un objeto inventario cuando se llega a un nivel mínimo.
Ventajas en BDOOs
Entre las ventajas más ilustrativas de las BDOOs está su flexibilidad, soporte para el manejo de tipos de datos complejos. Por ejemplo, en una base de datos convencional, si una empresa adquiere varios clientes por referencia de clientes servicio, pero la base de datos existente, que mantiene la información de clientes y sus compras, no tiene un campo para registrar quién proporcionó la referencia, de qué manera fue dicho contacto, o si debe compensarse con una comisión, sería necesario reestructurar la base de datos para añadir este tipo de modificaciones. Por el contrario, en una BDOO, el usuario puede añadir una "subclase" de la clase de clientes para manejar las modificaciones que representan los clientes por referencia.
La subclase heredará todos los atributos, características de la definición original, además se especializará en especificar los nuevos campos que se requieren así como los métodos para manipular solamente estos campos. Naturalmente se generan los espacios para almacenar la información adicional de los nuevos campos.
Esto presenta la ventaja adicional que una BDOO puede ajustarse a usar siempre el espacio de los campos que son necesarios, eliminando espacio desperdiciado en registros con campos que nunca usan.
La segunda ventaja de una BDOO, es que manipula datos complejos en forma rápida y ágilmente.
La estructura de la base de datos está dada por referencias (o apuntadores lógicos) entre objetos.
No se requieren búsquedas en tablas o uniones para crear relaciones. Esta capacidad resulta atractiva en aplicaciones de la ingeniería, donde las relaciones entre componentes dependen de factores diversos.
Por ejemplo, considérese una aplicación en el diseño de vehículos automotores.
El fabricante que quiere determinar una lista de partes necesarias para un auto, para un modelo particular requiere de diferentes decisiones subsecuentes para elaborarla, Si el modelo es automático o estándar, se necesita de un chasis particular como de la caja de velocidades correspondientes.

Escoger un tipo de motor obliga a decidir sobre otras partes requeridas, todo esto hasta el nivel de componentes y piezas individuales. Armar esta lista de componentes resulta más ágil en una BDOO que en una base de datos relacional. En un modelo relacional las tablas deben ser barridas, buscadas cada vez que se indica una condición, resultando, posiblemente, en miles de direccionamientos.
Posibles Problemas

Al considerar la adopción de la tecnología orientada a objetos, la inmadurez del mercado de BDOO constituye una posible fuente de problemas por lo que debe analizarse con detalle la presencia en el mercado del proveedor para adoptar su producto en una línea de producción sustantiva. Por eso, en este artículo proponemos que se explore esta tecnología en un proyecto piloto.

El segundo problema es la falta de estándares en la industria orientada a objetos. Sin embargo, el "Object Managenent Group" (OMG), es una organización Internacional de proveedores de sistemas de información y usuarios dedicada a promover estándares para el desarrollo de aplicaciones y sistemas orientados a objetos en ambientes de cómputo en red.

La implantación de una nueva tecnología requiere que los usuarios iniciales acepten cierto riesgo. Aquellos que esperan resultados a corto plazo y con un costo reducido quedarán desilusionados. Sin embargo, para aquellos usuarios que planean a un futuro intermedio con una visión tecnológica de avanzada, el uso de tecnología de avanzada, el uso de tecnología orientada a objetos, paulatinamente compensará todos los riesgos.

La tecnología de bases de datos orientadas a objetos está en su infancia, sin embargo, establece amplios signos de madurez. Ante la disyuntiva de tomar una decisión estratégica, recalcamos que las empresas e industrias que desean conformar un liderazgo tecnológico están en la posibilidad de explorar los productos comercialmente disponibles o los prototipos de los centros de investigación para iniciar la experimentación y desarrollo de proyectos pilotos.
La asociación de proyectos piloto con instituciones de investigación, permitirá establecer el vínculo entre tecnología, estrategia empresarial y mercado. Las empresas que inicien ahora la exploración de la BDOO podrán apropiarse de esta tecnología y consolidar una ventaja competitiva determinante cuando dominen e incorporen las BDOO en sus procesos productivos.

EL MODELO RELACIONAL

Al utilizar una base de datos se está tratando de modelar los datos y sus conexiones en un problema del mundo real. Para definir el modelo relacional se inicia con una definición de lo que es un modelo de datos en general.
Un modelo de datos es un sistema formal y abstracto que permite describir los datos de acuerdo con reglas y convenios predefinidos. Es formal pues los objetos del sistema se manipulan siguiendo reglas perfectamente definidas y utilizando exclusivamente los operadores definidos en el sistema, independientemente de lo que estos objetos y operadores puedan significar [Rivero].

Según el mismo autor, un modelo de datos tiene tres componentes que son:

Componentes:

Estructuras de datos:
es la colección de objetos abstractos formados por los datos.
Operadores entre las estructuras: el conjunto de operadores con reglas bien definidas que permiten manipular a dichas estructuras.

Definiciones de integridad:
es una colección de conceptos y reglas.
Que permite expresar que valores de datos pueden aparecer válidamente en el modelo.
En el manejo de bases de datos hay tres modelos de datos principales que son el jerárquico, permite modelar los datos en base a una jerarquización; el de red, donde los datos forman retículas; y el relacional basado en el concepto matemático de relación.

Como modelo de datos el modelo relacional tiene las siguientes componentes:
Estructuras de datos: son los conceptos de relación, entidades, atributos y dominios.
Operadores: sus operadores incluyen los de actualización y la llamada álgebra relacional.
Definiciones de integridad: está dada por el concepto de llave, posibilidades de valores nulos y dos reglas de integridad.

ESTRUCTURAS DE DATOS DEL MODELO RELACIONAL

En el modelo relacional las estructuras de datos son los conceptos de relación, dominio, atributo y entidad
.
Relación: denota una colección ó conexión entre objetos que tienen los mismos tipos de características o atributos.

Entidad: es un elemento de datos con un conjunto finito de atributos. También se le llama eneada por consistir de n valores, uno para cada atributo.
Atributo o característica, cada atributo tiene un dominio asociado.
Dominio es el conjunto de valores que puede tomar un atributo.

Las relaciones se representan por tablas donde las columnas son los atributos o características. En los renglones se almacenan los elementos de datos con sus valores para cada atributo. En el modelo relacional no se consideran ordenados los renglones. Una representación de una relación es indicar su nombre y entre llaves el conjunto de atributos.
A esta representación también se le llama esquema de la relación.

DEFINICIONES DE INTEGRIDAD EN EL MODELO RELACIONAL

Los conceptos de definiciones de integridad para el modelo relacional son llave primaria y foránea, los valores nulos y dos reglas de integridad que se enuncian a continuación.

Dentro de los atributos debe haber uno o varios que sirvan para distinguir cada entidad en la relación. Es a lo que se llama llave primaria.



Ejemplo:
En la relación Alumnos anterior la llave primaria es
No.Cta.; en la relación Materias la llave es Clave-mat
y en Evaluaciones es la unión de No.Cta y Clave-mat.
Llave Foránea: hace referencia a una llave primaria en
otra relación. Una relación puede tener una o varias
llaves foráneas.
Ejemplo:
Los atributos No.Cta y Clave-mat son llaves foráneas
en la relación Evaluaciones.

Una relación puede tener varias llaves. La que se elige para
identificar a una relación se le llama llave primaria. En el modelo
relacional es el concepto de llave la única forma de encontrar una
entidad.
Un valor nulo denotado por ``?'', proporciona la posibilidad de manejar situaciones como las siguientes:

1.- Se crea una eneada y no se conocen los valores de los atributos.
2.- Se agrega un atributo a una relación ya existente.
3.- Se usan para no introducir valores numéricos al hacer cálculos.

A fin de mantener la integridad a lo largo del tiempo en una base de datos relacional, se debe cumplir con algunas restricciones en cuanto a los valores de las llaves primarias.
Integridad de Relaciones : Ningún componente de la llave primaria puede tener valores nulos.
Integridad Referencial: Si se tiene una relación q con una llave primaria A de dominio D, y r otra relación con atributo A no llave. Entonces cualquier valor del campo de A en r debe ser:
i) nulo o,
ii) el valor de una llave primaria de la otra relación q donde se tiene la llave primaria sobre D.

OPERADORES DEL MODELO RELACIONAL

Los operadores del modelo relacional son de dos tipos: operadores de actualización de entidades y operadores del álgebra relacional.
Operadores de actualización

Para actualizar los valores de los atributos en las entidades se pueden efectuar las operaciones de agregar, borrar o modificar.

El manejo de llaves foráneas hace necesario establecer reglas que determinan como manejar las operaciones de actualización de relaciones para no introducir inconsistencias, a continuación se indican dichas reglas :
Reglas:
Reglas para agregar. Al insertar una entidad en una relación, el valor de un atributo que es llave foránea puede ser nulo, o algún valor del dominio de la llave primaria.

Reglas para borrar. Si se va a borrar una entidad en una relación r1 con cierta llave primaria y otra relación r2 tiene ese campo como llave foránea, hay 3 casos:
Casos de Borrado:
Borrado restringido.
No se puede borrar una entidad en r1 que tenga entidades en r2 con el mismo valor como llave foránea.
Borrado encascada.
Al borrar una entidad en r1 se borrarán todas las entidades en r2 con ese valor.

Borrado con nulificación. Al borrar la entidad en r1,a todas las entidades con igual valor en r2 se les pone el valor nulo.
Regla para Modificar.

i) Modificación en cascada :
Al modificar una llave primaria en r1 se le cambian los valores correspondientes en r2.
ii)Modificación con nulificación :
Al cambiar los valores de la llave primaria en r1 a los correspondientes en r2 se les pone el valor nulo.


Estructura de Base de Datos Distribuidas

Un sistema distribuido de base de datos consiste en un conjunto de localidades, cada una de las cuales mantiene un sistema de base de datos local. Cada localidad puede procesar transacciones locales, o bien transacciones globales entre varias localidades, requiriendo para ello comunicación entre ellas.

Las localidades pueden conectarse físicamente de diversas formas, las principales son:

Red totalmente conectada
Red prácticamente conectada
Red con estructura de árbol
Red de estrella
Red de anillo

Las diferencias principales entre estas configuraciones son:
Coste de instalación: El coste de conectar físicamente las localidades del sistema
Coste de comunicación: El coste en tiempo y dinero que implica enviar un mensaje desde la localidad A a la B.

Fiabilidad: La frecuencia con que falla una línea de comunicación o una localidad.
Disponibilidad: La posibilidad de acceder a información a pesar de fallos en algunas localidades o líneas de comunicación.

Las localidades pueden estar dispersas, ya sea por un área geográfica extensa (a lo largo de un país), llamadas redes de larga distancia; o en un área reducida (en un mismo edificio), llamadas redes de área local. Para las primeras se utilizan en la comunicación líneas telefónicas, conexiones de microondas y canales de satélites; mientras que para las segundas se utiliza cables coaxiales de banda base o banda ancha y fibra óptica.

Consideraciones al distribuir la base de datos

Existen varias razones para construir sistemas distribuidos de bases de datos que incluyen compartir la información, fiabilidad y disponibilidad y agilizar el procesamiento de las consultas. Pero también tiene sus desventajas, como desarrollos de software más costosos, mayor posibilidad de errores y costos extras de procesamiento.

Ventajas de la distribución de datos

La principal ventaja de los sistemas distribuidos es la capacidad de compartir y acceder a la información de una forma fiable y eficaz.
Utilización compartida de los datos y distribución del control
La ventaja principal de compartir los datos por medio de la distribución es que cada localidad pueda controlar hasta cierto punto los datos almacenados localmente. En un sistema centralizado, el administrador de base de datos de la localidad central controla la base de datos. En un sistema distribuido existe un administrador global de la base de datos que se encarga de todo el sistema. Parte de esta responsabilidad se delega al administrador de base de datos de cada localidad. Dependiendo del diseño del sistema distribuido, cada administrador local podrá tener un grado de autonomía diferente, que se conoce como autonomía local.

La posibilidad de contar con autonomía local es en muchos casos una ventaja importante de las bases de datos distribuidas.

Fiabilidad y disponibilidad

Si se produce un fallo en una localidad de un sistema distribuido, es posible que las demás localidades puedan seguir trabajando. En particular, si los datos se repiten en varias localidades, una transacción que requiere un dato específico puede encontrarlo en más de una localidad. Así, el fallo de una localidad no implica necesariamente la desactivación del sistema.

El sistema debe detectar cuando falla una localidad y tomar las medidas necesarias para recuperarse del fallo. El sistema no debe seguir utilizando la localidad que falló. Por último, cuando se recupere o repare esta localidad, debe contarse con mecanismos para reintegrarla al sistema con el mínimo de complicaciones.
La disponibilidad es fundamental para los sistemas de bases de datos que se utilizan en aplicaciones de tiempo real. Por ejemplo, si una línea aérea no puede tener acceso a la información, es posible que pierda clientes a favor de la competencia.

Agilización del procesamiento de consultas

Si una consulta comprende datos de varias localidades, puede ser posible dividir la consulta en varias subconsultas que se ejecuten en paralelo en distintas localidades. Sin embargo, en un sistema distribuido no se comparte la memoria principal, así que no todas las estrategias de intersección se pueden aplicar en estos sistemas. En los casos en que hay repetición de los datos, el sistema puede pasar la consulta a las localidades más ligeras de carga.

Desventajas de la distribución de los datos

La desventaja principal de los sistemas distribuidos es la mayor complejidad que se requiere para garantizar una coordinación adecuada entre localidades.

El aumento de la complejidad se refleja en:
Coste del desarrollo de software: es más difícil estructura un sistema de bases de datos distribuidos y por tanto su coste es menor
Mayor posibilidad de errores: puesto que las localidades del sistema distribuido operan en paralelo, es más difícil garantizar que los algoritmos sean correctos.
Mayor tiempo extra de procesamiento: el intercambio de mensajes y los cálculos adicionales son una forma de tiempo extra que no existe en los sistemas centralizados.

Transparencia y Autonomía

En la sección anterior se vio que una relación r puede almacenarse de varias formas en un sistema de base de datos distribuida. Es esencial que el sistema reduzca al mínimo la necesidad de que el usuario se dé cuenta de cómo está almacenada una relación. Como veremos. un sistema puede ocultar los detalles de la distribución de la información en la red. Esto se denomina transparencia de la red.

La transparencia de la red se relaciona, en algún modo, a la autonomía local. La transparencia de la red es el grado hasta el cual los usuarios del sistema pueden ignorar los detalles del diseño distribuido. La autonomía local es el grado hasta el cual el diseñador o administrador de una localidad pueden ser independientes del resto del sistema distribuido . Los temas de transparencia y autonomía serán considerados desde los siguientes puntos de vista:
Nombre de los datos.
Repetición de los datos.
Fragmentación de los datos.
Localización de los fragmentos y copias.
Asignación de nombres y autonomía local
Todo elemento de información de una base de datos debe tener un nombre único. Esta propiedad se asegura fácilmente en una base de datos que no esté distribuida. Sin embargo, en una base de dalos distribuida, las distintas localidades deben asegurarse no utilizar el mismo nombre para dos datos diferentes.
Una solución para este problema es requerir que se registren todos los nombres en un asignador central de nombres. Sin embargo, este enfoque tiene varias desventajas:
Es posible que el asignador de nombres se convierta en un cuello de botella.
Si el asignador de nombres se cae, es posible que ninguna de las localidades del sistema distribuido pueda seguir trabajando.
Se reduce la autonomía local, ya que la asignación de nombres se controla de forma centralizada.
Un enfoque diferente que origina una mayor autonomía local es exigir que cada localidad ponga como prefijo un identificador de localidad a cualquier nombre que genere. Esto garantiza que dos localidades nunca generarán el mismo nombre (ya que cada localidad tiene un identificador único). Además, no se requiere un control central.
Esta solución al problema de asignación de nombres, logra autonomía local, pero no transparencia de la red, ya que se agregan identificadores de localidad a los nombres. Así, la relación depósito podría llamarse localidad17.depósito en vez de depósito simplemente.
Cada copia y fragmento de un elemento de información deben tener un nombre único. Es importante que el sistema pueda determinar qué copias son copias del mismo elemento de información y qué fragmentos son fragmentos del mismo elemento de información.
Transparencia de la repetición y la fragmentación
No es conveniente requerir que los usuarios hagan referencia a una copia específica de un elemento de información. El sistema debe ser el que determine a qué copia debe acceder cuando se le solicite su lectura, y debe modificar todas las copias cuando se produzca una petición de escritura.
Cuando se solicita un dato, no es necesario especificar la copia. El sistema utiliza una tabla-catálogo para determinar cuáles son todas las copias de ese dato.
De manera similar, no debe exigirse a los usuarios que sepan cómo está fragmentado un elemento de información. Es posible que los fragmentos verticales contengan id-tuplas, que representan direcciones de tuplas. Los fragmentos horizontales pueden haberse obtenido por predicados de selección complejos. Por tanto, un sistema de bases de datos distribuido debe permitir las consultas que se hagan en términos de elementos de información sin fragmentar. Esto no presenta problemas graves, ya que siempre es posible reconstruir el elemento de información original a partir de sus fragmentos. Sin embargo, este proceso puede ser ineficiente.
Transparencia y actualizaciones
De alguna forma es más difícil hacer transparente la base de datos para usuarios que la actualizan que para aquellos que sólo leen datos. El problema principal es asegurarse de que se actualizan todas las copias de un dato y también los fragmentos afectados.
En el caso más general, el problema de actualización de información repetida y fragmentada está relacionado con el problema de actualización de vistas.
Conclusiones y consideraciones:
A lo largo de este documento se ha intentado dar una visión global y genérica de los problemas y características que contiene el diseño de una base de datos. Se ha hecho especial hincapié en las técnicas de fragmentación horizontal y vertical a través de métodos y algoritmos muy frecuentes en la literatura referida al tema.
Se espera que el lector no haya tenido demasiados problemas para su comprensión, las técnicas son sencillas y se ha procurado incluir distintos ejemplos para facilitar el entendimiento. Igualmente, la puesta en práctica de los algoritmos, es decir, su codificación, no es un proceso complicado si se poseen nociones en el desarrollo de algoritmos. Piense, por ejemplo, que los dos algoritmos de partición vertical presentados, no hacen más que manipular matrices.