Universidad Autónoma Metropolitana Iztapalapa
División de C.B.I.
-
Ciencias Básicas e Ingeniería Departamento de Ingeniería EléctricaArea de Computación y Sistemas
REPORTE DE INVESTIGACION
Proyecto
de Investigación I1
(‘Discordancias quepresentan sistemas de in
formación basados en una
arquitectura ClientdServidor con aplicaciones orientadas a Objetos accesando a Bases
de Datos Relacionales”
ALUMNO: GERARD0 CASTRO MERCADO
Universidad Autónoma Metropolitana
Iztapalapa 6 # M w e j m
División de C.B.I.
-
Ciencias Básicas e Ingeniería Departamento de Ingeniería EléctricaArea de Computación y Sistemas
REPORTE DE INVESTIGACION
Proyecto de Investigación I1
ALUMNO: GERARD0 CASTRO MERCADO
PROFESOR: FRANCISCO J. SOUZA SOTELO
Dedico este trabajo a
mispadres, Aurora
yVicente, con todo
mi
amor
INDICE
ABSTRACCION
Abstracción
...
OBJETIVO Y DESARROLLO
1
.
Objetivo...
2
.
Desarrollo del Proyecto...
CLIENTE/SERVIDOR
1
.
ARQUITECTURA CUENTE/SERVIDOR...
1.1. Objetivo del Modelo...
1.2. Características...
2.
EL MIDDLEWARE...
2.1. Clases de Middleware
...
2.2. Entendiendo la Distribución del Servicio...
2.2.1. ¿Clientes pesados o servidores pesados?
...
2.2.2. Arquitecturas multicapas (multi-tier)...
3.
SISTEMAS MANUADORES DE BASES DE DATOS...
3.1. Tecnología actual de B.D....
4.1. SQL.
...
4.2. Arquitecturas de Servidores de B.D. SQL...
4.
SERVIDORES DE B.D. SQL (SQL Database Servers)...
4.3. El Middleware un una arquitecura de BD Cliente/Servidor
...
4.3.1. ESQL (Embedded SQL)-
SQL Incrustado...
4.3.2. SQLAPIs...
4.3.3. Interfaces a Nivel de Llamadas SQL (SQL C U s-
Call LevelInterfaces)
...
4.3.4. Comparando ESQL VS.
CLIs...
4.3.5. Estándares sobre APIs SQL...
4.3.5.1. Microsoft ODBC C U...
5.
MECANISMOS DE CONSULTA REMOTOS...
5.1. SQL Remoto (Estático y Dinámico)
...
5.1.1. SOL Estático (modo compilado de SQL)...
5.1.2. SOL Dinámico (modo interpretativo)...
5.2. Procedimientos Almacenados (Stored Procedures)...
5.3. OLTP Online Transaction Processing (Procesamiento deTransacciones en Línea)
...
EL DESARROLLO DE APLICACIONES Y SU EVOLUCION
1
.
RESEÑA Y EVOLUCION...
2
.
EL ANAUSIS ESTRUCTURADO...
2.1. Tipos más comunes de Sistemas...
2.2. Herramientas del Análisis Estructurado...
2.2.1. El Diagrama de Flujo de Datos
...
2.2.2. El Diagrama de Entidad-Relación...
2.2.3. El Diagrama de Transición de Estados
...
2.3. ETAPA DEL D I S E ~ ~ O 2.2.4. Diagrama de Estructuras EN EL ANAUSIS ESTRUCTURADO 2.3.1. Metas y Objetivos del Diseño
...
2.4. Resumen...
3.
EL COMPUTO DISTRIBUIDO...
4.
EL ANAUSIS Y DISEÑO 00...
4.1. UML
...
5
.
4.2. Resumen EL COMPUTO BASADO EN COMPONENTES...
5.1. Objetos Distribuidos...
5.2. Distinguiendo los objetos clásicos de los objetos distribuidos....
5.3. Componentes...
5.4. Aplicando el concepto de componentes a las ArquitecturasMulticapas
...
5.5. Resumen...
...
...
...
PROPUESTA
1
.
OBJETIVO...
1.1. Planteamiento...
2.1. Surgen nuevas necesidades
...
2.2. Resumen...
3.1. Una Aplicación de Registro de Empleados...
3.1.1. Planteamiento y Especificaciones
...
2.
PRECEDENTES...
3
.
CASO DE ESTUDIO...
3.1.2. Análisis y Diseño
...
3.1.3. Implantación...
4.
DISCORDANCIAS...
4.1. ¿Objetos y Tablas?
...
4.2. Mapeo de Clases a Tablas...
4.3. Las Aplicaciones Multicapas...
4.4. Resumen...
5.1. Propuesta...
5.
¿ LA SOLUCION ?...
5.1.1. Desarrollar Aplicaciones que empaten perfectamente
....
(BDOO)...
5.1.1.1. Bases de Datos Orientadas a Objetos5.1.2. Conclusión y Trabajos Futuros
...
CONCLUSIONES FINALES
Conclusiones Finales
...
BIBLIOGRAFIA
32 33 34 40 41 42 43 44 45 46 47 47 48 49 50 51 51 52 52 54 55 55 55 55 57 58 58 59 62 63 64 64 64 64 66 67Abstracción
Hoy en día existe un gran cambio tecnológico en l a forma como se manipulan los
datos, propiciado en gran parte por las nuevas necesidades que emergen por parte de empresas y organizaciones, así como las tendencias en el uso de los sistemas de cómputo y sus diversas aplicaciones.
Tipos de datos complejos, tales como hypertexto, voz, datos, imágenes, video, etc.
que son exigidos en las aplicaciones y sistemas de información actuales impactan en su
implantación, la cual se basa en su mayoría en la tecnología de Bases de Datos
Relacionales, con lo que se vislumbra una cierta discordancia entre las aplicaciones que
manipulan la información y ésta misma
El cuestionamiento principal con los sistemas de Bases de Datos Relacionales es que requieren que el desarrollador del sistema o la aplicación force un modelo de datos obtenido del mundo real dentro de los confines de tablas que lo almacenan en forma de valores en la Base de Datos.
Este trabajo se enfoca en identificar las principales discordancias que se presentan al desarrollar un sistema de información con las caractensticas mencionadas anteriormente y
1.
I Objetivo
Presentar las principales discordancias que presentan sistemas de información
basados en una arquitectura Cliente - Servidor con aplicaciones orientadas a Objetos
accesando a Bases de Datos Relacionales.
1.2
Desarrollo del Proyecto
Semanas 1 y 2
Revisar y recordar las metodologías clásicas en el Análisis y Diseño de Sistemas, así
como la técnica de Diseño de BD Relacionales.
Semanas 3 , 4 y 5
Recopilar toda la Información correspondiente sobre la arquitectura Cliente - Servidor.
Semanas 5 , 6 y 7
Emplear una metodología de Análisis y Diseño representativa de Análisis y Diseño
estructurado de sistemas y emplearla en el Análisis y Diseño de un Sistema de
Información, cuyas Características representen una manipulación de Información
compleja y fuertemente interrelacionada.
Semanas 8 , 9 y 10
Plantear los problemas con los que se enfrentan las aplicaciones Cliente
-
Servidor hoyen día y sus posibles soluciones.
Semana 11 y 12
Reporte de Investigación.
Observación: Aunque el planteamiento del desarrollo del proyecto no concuerda con el de
nuestro documento, los temas y puntos planteados son reorganizados para definir el
1. ARQUITECTURA CLIENTE/SERVIDOR
La arquitectura clientekervidor representa un modelo, mediante el cual se define una relación de “servicio” entre dos o más entidades.
Como lo indica su nombre, esta relación se encuentra formada por una entidad
cliente y una entidad servidor, relacionadas a través de un símbolo “/”, el cual indica la
relación entre ambas entidades.
Dichas entidades se han identificado de acuerdo al ámbito dentro del cual se
establece cierta referencia al concepto clientdservidor, de tal forma que en diferentes ámbitos se les ha identificado de diferente forma:
En el ámbito de las Redes de Cornputadoras, por lo general la entidad Servidor es
representada por una computadora con amplio poder de cómputo y capacidad de
memoria que ofrece diversos servicios, como son: impresión, acceso multiusuario a
cierto tipo de información, seguridad, comunicación remota, etc. Y los clientes son
representados por computadoras menos capaces (con poder de cómputo y memoria limitados) las cuales solicitan los servicios que ofrece la computadora Servidor.
En el ámbito de los S.O. se puede mencionar que a un proceso se le denomina
Servidor si proporciona un servicio específico que puede ser solicitado por algún proceso cliente, lo cual se lleva a cabo de ésta forma con el objetivo específico de
definir ciertas tareas que corresponden a procesos específicos. En este sentido
podemos hablar de procesos demonios (como se les conoce en UNIX) que realizan
servicios específicos atendiendo peticiones de procesos clientes que las solicitan ocurrentemente.
0 En el ámbito de alsB.D., empleando la arquitectura cliente/servidor por lo general
existe un programa denominado servidor de B.D., el cual recibe solicitudes de
consulta y modificaciones a la B.D. por parte de aplicaciones clientes, representadas por programas construidos en alguna herramienta de desarrollo.
Hoy en día, en el mundo de la Internet, se habla de servidores de WEB, los cuales
proporcionan alspáginas que usualmente visualizamos en nuestras computadoras a
través de un programa denominado “browser”, el cual representa al cliente WEB,
Como hemos visto, podemos damos cuenta que existen diversas variantes en cuanto a implantaciones cliente/servidor se refiere:
Servidores de Archivos (File Servers)
Servidores de B.D. (Database Servers)
Servidores de Transacciones (Transaction Servers)
Servidores de Compartimiento en Grupo (Groupware Servers) - Lotus Notes
Servidores de Objetos (Object Servers) Servidores de Web (Web Servers)
... etc.
Sin embargo, el modelo que define la arquitectura clienteiservidor siempre es el
mismo, donde cada entidad por l o general es un proceso actuando el rol que le corresponde,
ya sea en un ámbito de redes, de S.O., de B.D., o de internet, ya sean vistos como objetos,
unidades de ejecución o simplemente procesos, el cliente y el servidor desempeñan su
función de acuerdo a alsnecesidades que se presenten y a la distribución de la carga de
procesamiento que le corresponde a cada cual.
proceso Solicita servicio proceso
cliente servidor
Proporciona servicio
Conceptos:
servicio: Cliente/Servidor es primordialmente una relación entre procesos ejecutándose en diferentes computadoras.
Proceso Servidor: El proceso Servidor es un proveedor de servicios.
1.1.
Objetivo del Modelo
En esencia, el objetivo del modelo clienteiservidor es proporcionar una separación clara de las funciones basándose en la idea de servicio.
Esta idea permite distribuir la carga de trabajo en cada uno de los procesos que conforman la arquitectura, asignando cierta cantidad de trabajo específica a cada uno de estos.
Ejemplo:
Cuando un paciente acude con un doctor, éste lo atiende, proporcionándole al paciente el servicio médico que éste solicita -aunque debe realizar algunas otras tareas- desde recibir al paciente, confirmar su cita, buscar su expediente y realizar el examen médico.
En este ejemplo, consideramos de forma análoga a un usuario (paciente) empleando los servicios de un programa de cómputo (médico).
Como vemos, el médico realiza todo el trabajo correspondiente para proporcionarle el servicio al paciente, así como el programa realiza todo el procesamiento necesario para proporcionar resultados al usuario.
Usuario programa
Para lograr agilizar el tiempo de respuesta para cada paciente que acuda a buscarlo, la opción del médico es contratar a una asistente que se encargue de las labores
administrativas (recibir al paciente, confirmar su cita y buscar su expediente), de tal forma
la carga de trabajo sea distribuida entre la asistente y el médico, donde éste último solicitará
los servicios de su asistente, en vez de realizarlos é1 mismo, convirtiéndose en “cliente” de
ésta en cuanto a servicios se refiere.
De esta forma, el médico puede mejorar su capacidad de servicio dedicándose por
completo a realizar su especialidad, mientras su asistente le proporciona los diferentes
De fonna análoga, el programa de cómputo que le proporciona al usuario los
servicios correspondientes puede ser disefiado de tal forma que parte del servicio que
proporciona sea realizado por otro programa ubicado en otra computadora con mayor poder de cómputo, de tal forma que la mayor carga de trabajo sea realizada por el programa ejecutándose en ésta última.
Programa Cliente
Usuario
Solicita Servicio
Proporciona Servicio
Programa servidor
Finalmente, como se ha visto, el objetivo principal es distribuir la carga de trabajo
separando las funciones que involucra un proceso determinado, de tal forma que se puedan
1.2 Características
Para finalizar, describiremos brevemente las características más importantes de lo
que una Arquitectura ClienteIServidor debe representar:
Recursos Compartidos
los recursos compartidos.
Un servidor puede servir a vanos clientes al mismo tiempo y regular sus accesos a
Transparencia de la localización
El servidor es un proceso que puede residir en la misma máquina que el cliente o en una máquina diferente a través de una red. El software clienteiservidor usualmente enmascara la localización del servidor de los clientes redireccionando las llamadas de servicio cuando sean requeridas. Un programa puede ser cliente, servidor o ambos.
Independiente de la plataforma
el software del sistema operativo.
El software ideal clientelservidor es independiente de las plataformas de hardware o
Intercambios basados en mensajes
Los clientes y servidores son sistemas débilmente acoplados que interactuan a
través de un mecanismo de paso de mensajes. El mensaje es el mecanismo de entrega para
las solicitudes y atención de servicios.
El servidor es un “especialista”
Un mensaje le dice al servidor qué servicio es solicitado; éste llega hasta el servidor
para determinar como obtener el trabajo hecho. Los servidores pueden ser actualizados sin
afectar a los clientes tanto como la interfaz publicada de mensajes no sea modificada.
Escalabilidud
Los sistemas clientelservidor pueden ser escalados horizontal o verticalmente. El
escalamiento horizontal significa añadir o quitar estaciones de trabajo clientes con
solamente un impacto insignificante en el rendimiento. El escalamiento vertical consiste de migrar a un servidor más grande y rápido o varios servidores.
Integridad
El código servidor y los datos del servidor son centralmente mantenidos, lo cual
2. EL MIDDLEWARE
Para entender el concepto de Middleware, es necesario recordar la relación de servicio que está presente en la arquitectura clientekervidor.
Dicha relación de servicio, se basa en un conjunto de elementos necesarios para
fundamentar tal relación, los cuales podemos deducir de la siguiente manera:
2
Cómo serealiza la petición del servicio desde un proceso cliente hacia un proceso servidor ?,
2
Qué es necesario para realizar talpetición ?, etc.De lo anterior, decimos que Middleware es el nombre que se le da al conjunto de
software distribuido necesario para soportar interacciones entre clientes y servidores, i.e. es la parte que permite que la relación clienteiservidor se lleve a cabo.
Cliente / Servidor
7
Middleware
El Middleware forma parte tanto del cliente como del servidor y éste es el
“pegamento” que hace posible la relación entre ambos. Del lado del cliente, utilizado para
invocar o solicitar un servicio cubriendo la transmisión de la petición sobre la red y la
respuesta resultante y del lado del servidor, recibiendo la petición e interpretándola para el servidor.
2.1 Clases de Middleware
Middleware general
Es el software que permite la mayoria de las interacciones cliente/servidor, incluye
las pilas o protocolos de comunicación (communication stacks), directorios distribuidos,
servicios de autentificación, RPC’s (Remote Procedure Calls), encolamiento de servicios y
extensiones del sistema operativo, como archivos distribuidos y servicios de impresión.
Algunos fabricantes y productos de este tipo de Middleware son: DCE, ONC+,
NetWare, Named Pipes, LAN Server, LAN Manager, Vines, TCPIIP, APPC y NetBIOS.
Middleware de servicio específico.
Es el software necesario para realizar un tipo de servicio particular entre un cliente y un servidor:
Middleware específico de la B.D., tales como ODBC, DRDA, EDNSQL, SAGiCLI y
Oracle Glue.
Middleware específico de OLTP tales como ATMI y I W S de Tuxedo, Transactional
EWC de Encina y TxRPC y XATMI de Xiopen.
Middleware específico de Groupware tales como MAPI, VIM, VIC, SMTP y llamadas
de Lotus Notes (Lotus Notes calls).
Middleware específico para objetos tales como CORBA de OMG y DCOM de
Microsoft.
Middleware específico de internet tal como HTTP, S’TTP y SSL.
Middleware específico del sistema de manejo tal como SNMP, CMIP y OBSs.
2.2 Entendiendo
ladistribución del servicio
Las aplicaciones ClienteIServidor también pueden ser diferenciadas por la forma en
que la aplicación distribuida es dividida entre el cliente y el servidor - específicamente,
hablando en términos de la carga de trabajo asignada a cada uno, como ya hemos visto
anteriormente.
Como vimos en las características de la arquitectura clienteJservidor, un proceso
puede ser cliente, servidor o ambos y puede residir en una computadora local junto con
otros procesos clientes o servidores o en una computadora separada físicamente conectada a
través de una red.
Lo anterior, nos permite distribuir o ampliar nuestra arquitectura, ya que podemos
implantar arquitecturas donde procesos que son cliente y servidor a la vez, sirven como
“puente” para lograr una arquitectura cliente
-
servidorkliente -servidor, con lo cualpodemos distribuir aún más la carga de trabajo, ya que tenemos más procesos involucrados en la relación de servicio.
solicita servicio
Proporciona servicio
Sollata servicio
cliente
Proporciona sewiclo
D
2.2.1
2Clientes pesados
o servidores pesados?
El término “fat” (“gordo”, “pesado”) se refiere a que existe una gran cantidad de
carga de trabajo realizada por alguno de los procesos, o lo que es l o mismo una gran
cantidad de funciones asignadas a cada uno de éstos.
El modelo del “Fat Sewer” (Servidor “Gordo”) coloca más funciones (mas carga de
trabajo) en el Servidor. Algunos ejemplos son: Servidores WEB, de transacciones y Groupware.
El modelo del “Fat Client” (Cliente “Gordo”) se define como lo contrario,
asignando más funciones (mas carga de trabajo) en el Cliente. Ejemplos de éste son: los servidores de B.D., de archivos y de objetos distribuidos.
2.2.2 Arquitecturas multicapas (multi-tier)
2-Tier versus 3-Tier (2 Capas vs. 3 Capas)
Por lo general, una aplicación clientelservidor se basa en una arquitectura de 2
capas, donde se tiene una relación entre un cliente y un servidor, varios clientes y un
servidor o varios clientes y varios servidores, pero tomando en cuenta que la relación
existente entre ambos componentes (cliente y servidor) es única, i.e.
Solicita
Proporciona
En muchas ocasiones, a los modelos de fat clients y fat servers se les ha dado
también el nombre de arquitecturas de 2 y 3 capas.
El concepto de “capa” se refiere a la forma en cómo se dividen las aplicaciones
clientelservidor en unidades funcionales relacionandose de tal forma que un cliente se
puede relacionar con un servidor y éste a su vez relacionarse con otro servidor, pero
tomando el papel de un cliente, formando “capas” por cada elemento involucrado en la relación.
Las unidades funcionales más típicas son la interfaz del usuario, la lógica de negocios y los datos compartidos.
Existen muchas variaciones posibles de las arquitecturas multi-capas (ó multi-tier)
dependiendo de cómo se divida la aplicación y el middleware que se utilice para comunicar
En los sistemas clienteiservidor de 2 capas, la lógica de la aplicación se encuentra incrustada dentro de la interfaz de usuario en el cliente o dentro de la B.D. en el servidor (o ambas).
En los sistemas cliente/servidor de 3 capas, la lógica de la aplicación (o procesos) viven en la capa de en medio (en la middle-tier); ÉSta es separada de los datos y la interfaz
de usuario. Los procesos llegan a ser ciudadanos de primera-clase; ellos pueden ser
manejados y desarrollados separadamente de la GUI y la base de datos. En teona, los
sistemas cliente/servidor de 3 capas son más escalables, robustos y flexibles.
-
En suma,ellos pueden integrar datos desde múltiples fuentes.
Ejemplos de sistemas de 3 capas son los monitores de transacciones, los objetos
Ejemplos de sistemas de 2 capas son los servidores de archivos y los servidores de
distribuidos y el WEB.
B.D. con procedimientos almacenados.
Sollcita servicio de A Sollcita servicio de B
clienteB
Proporciona servicio
3.
SISTEMAS MANEJADORES DE BASES DE DATOS
Aunque el término Base de Datos se aplica a cualquier modelo del mismo, cabe
mencionar que en la actualidad la gran mayoría de Sistemas Manejadores de Bases de
Datos son completamente relacionales (Modelo Relaciona1 - Codd), y aunque algunos
modelos aún se hayan vigentes d e b i d o a razones muy particulares, y algunos otros se aplican en algunos campos de la informática de forma especializada (BD deductivas, BD Inteligentes, etc.), los primeros representan la gran mayoría que conforma el universo de Sistemas de Información hoy en día.
En este apartado tomaremos en cuenta que el lector conoce los modelos clásicos de
Bases de Datos (modelo jerárquico, de red, relacional) y tiene una idea clara de los
conceptos que éstos implican.
Tomando en cuenta lo anterior, nos enfocaremos en la tecnología actual de
Manejadores de Bases de Datos Relacionales y de ahí partiremos para plantear los problemas que en la actualidad se presentan en ésta y sus posibles soluciones.
3.
I
Tecnoiogia Actual de B.
D.
La llegada de las redes de computadoras ha beneficiado a los sistemas de
información y aunque ha traído consigo nuevas responsabilidades con respecto al
desempeño y seguridad de las aplicaciones,
-
por mencionar algunas - han sido mayores susaportaciones en cuanto a las facilidades que proporcionan, como por ejemplo:
Acceso concurrente a la información (varios usuarios accesando al mismo tiempo los
Acceso remoto a la Información almacenada (acceso a los datos desde una computadora
Administración de la Información de forma centralizada (los datos están ubicados en un
... etc. datos)
alejada fisicamente)
solo lugar y administrados por un responsable)
Lo anterior ha llevado a que en la actualidad, la implantación de la mayoría de los
sistemas de información se basen en una arquitectura cliente/servidor, ya sea de 2, 3 o más
capas adaptándose y beneficiándose de tales facilidades.
Es el objetivo del presente capítulo, mostrar algunos de los componentes y
características más relevantes que presentan los sistemas de información basados en este tipo de arquitecturas.
4. SERVIDORES DE B.D. SQL (SQL
Database
Servers)
Como se menciona anteriormente, la mayoría de los sistemas de información se
basan en los Sistemas Manejadores de B.D. relacionales, por lo cual , nos enfocaremos en
los sistemas cliente/servidor en los cuales el servidor está representado por un programa Servidor que proporciona el Acceso a una Base de Datos Relaciona1 -denominado
comúnmente Servidor de B.D.- y 10s clientes por una aplicación desarrollada en algún
Lenguaje de Programación (no importando su tipo -visual orientado a eventos, estructurado, no estructurado, orientado a objetos, etc.).
Y quizá la tendencia más importante entre los servidores de B.D. de este tipo es la
emergencia de SQL corno la lengua nativa o lenguaje base para la manipulación, definición
y control de datos.
SQL, ahora un estándar de ISO, es un poderoso lenguaje orientado a la
manipulación de conjuntos consistente de unos pocos comandos; fue creado como un
lenguaje para B.D. que se apegan al modelo relacional, por l o cual también a un servidor de
B.D. Relacionales, se le conoce como Servidor de B.D. SQL.
Orígenes de SQL
1970
-
E.F. Codd, IBM’s San José Research LabObietivo: Construir un lenguaje parecido al inglés (English-Like) que
sirviera como un lenguaje de consulta de front-end al prototipo de B.D.
relacional System R.
1979 - ORACLE ofrece la primera versión comercial de SQL.
4.1
SQL
SQL, denominado - Structured Query Language (Lenguaje de Consulta
Estructurado) - consiste de una pequeña lista de comandos poderosos y altamente flexibles
que pueden ser utilizados para manipular información coleccionada en tablas. A través de SQL se manipulan y controlan conjuntos de registros a la vez.
Enseguida, describimos algunos de los roles que juega este multifacético lenguaje:
SQL es lenguaje de consulta interactivo para consultas a B.D. a la medida. SQL fue diseñado en principio como un lenguaje de consulta para usuario final, sin embargo, los
modernos front-ends gráficos para B.D. SQL son mucho más intuitivos de utilizar y éstos
realizan un buen trabajo ocultando la semántica subyacente SQL de los usuarios.
SQL es un lenguaje de programación de B.D. Puede ser incrustado en lenguajes
como C, C++, COBOL y en la actualizad en el código de lenguajes visuales O 0 u
Orientados a Eventos como Microsoft Visual Basic y PowerBuilder de Powersoft
(SYBASE) para accesar datos o pueden ser llamados utilizando la interfaz del conjunto de
llamadas AFT Esto incrementa la productividad del programador y ayuda a producir un
sistema más flexible y mantenible.
Resumiendo:
SQL es un lenguaje de definición y administración de datos SQL es un lenguaje de servidores de B.D. en red.
SQL proteje los datos en un ambiente de red multiusuario.
Los estándares ISO: SQL-89, SQL-92 y SQL3
Aunque han existido muchas implantaciones de SQL desde 1979, no hubo un
estándar oficial hasta 1986, cuando fue publicado uno por la Organización Internacional de
Estándares (IS0
-
International Standards Organization) en conjunto con el InstitutoNacional Americano de Estándares (ANSI - American National Standard Institute). El
estándar 1986 fue revisado en 1989 para introducir integridad referencia1 (check
4.2 Arquitecturas de Servidores de B.D. SQL
Los servidores de B.D. SQL, por lo general basan su servicio en el manejo y control
de procesos del S.O., de tal forma que su arquitectura puede clasificarse de acuerdo a la
administración de procesos de la siguiente forma:
Arquitectura de Procesos Por Cliente
Cada cliente de la B.D. tiene su propio espacio de direcciones.
La B.D. “corre” en uno o más procesos en Background por separado
Ventajas.- Protege a los usuarios de unos con otros y a la B.D. de los usuarios
Los procesos pueden asignarse a diferentes procesadores fácilmente en un sistema multiprocesador.
Desventajas.- Consume más memoria
Consume mas recursos del Procesador
Es lento debido a la sobrecarga que produce el intercambio de
contexto entre procesos.
Arquitectura Multithreaded (Multi-hilos)
Ejecuta todas las aplicaciones y conexiones de usuario en el mismo espacio de
Proporciona su propio scheduler y no se basa en los esquemas de protección de
direcciones.
direcciones y tareas del S.O. local.
Ventajas.- Es independiente del S.O.
Ahorra memoria y ciclos del procesador envitando los intercambios de
contexto.
Desventajas.- Una aplicación de usuario “pesada” puede causar la falla completa del
Servidor y todas sus aplicaciones.
Arquitectura Híbrida
En este tipo de arquitectura se utilizan ambos esquemas (procesos x cliente y
multithreaded) - i.e. se combinan para tratar de mejorar las posibles desventajas en cada
caso.
Se forma con 3 componentes:
l . Multithreaded Network Listeners
2. Dispatcher Tasks
3. Reusable shared Server worker process
Ventajas.- Proporciona un ambiente protegido para ejecutar las tareas del usuario sin asignar un proceso permanente a cada usuario.
4.3 El Middleware en
unaArquitectura de B.D. ClientdServidor
Como hemos visto anteriormente, el Middleware es todo el software necesario para establecer la relación clienteiservidor.
Y en este caso, diremos que el SQL Middleware es aquel software necesario para
establecer una relación de servicio entre una aplicación (cliente) y un RDBMS - Sistema
Manejador de Base de Datos Relacional (servidor).
Basándose en el SQL Middleware existen vanos tipos de mecanismos que permiten
a una aplicación escrita en un lenguaje de programación usual (como los mencionados
anteriormente para construir aplicaciones clientes), accesar a los datos que se encuentran en una B.D. Relacional, utilizando instrucciones SQL dentro del código de la misma. Esto se logra gracias a la tecnología respectiva que conforma el SQL Middleware.
Y por supuesto existen variantes en la tecnología empleada, de las cuales
presentaremos las más importantes: ESQL y CLIs.
4.3.1 ESQL (Embedded SQL)
-SQL Incrustado
A esta forma de hacer llamados a instrucciones SQL dentro del código de una
aplicación se le denomina SQL Incrustado (o embedded SQL), ya que se encuentra
inmerso, dentro del código de la aplicación.
El ESQL es un standard I S 0 SQL-92 definido para incrustar sentencias SQL "como
si fueran" parte ordinaria de los lenguajes de programación, el cual especifica la sintaxis para incrustar instrucciones SQL dentro de C, COBOL, FORTRAN, PL/I, Pascal, MUMPS y ADA.
Por lo general, cuando se hacen llamados a instrucciones SQL dentro del código de la aplicación, se utiliza una sentencia especial o palabra reservada del lenguaje para señalar el comienzo de las instrucciones SQL y otra para delimitar el uso de las mismas.
Esta tecnología consiste en correr el código fuentc SQL a través de u11
precompilador para generar un código fuente que el compilador del lenguaje entienda, 10
cual trae consigo algunas desventajas:
La
BD
debe ser conocida y estar disponible cuando el programa esté siendodesarrollado.
Los precompiladores se encuentran “atados” tradicionalmente a un producto en
particular de B.D., por lo que se debe recompilar su código incrustado SQL para cada
fabricante de servidores de
B.D.
al que se desee accesar.A TIEMPO DE COMPILACION
aplicación cliente
escrita en un programa
lenguaje “x” precompilador servidor SQL
-
B.D.Instrucciones Inst. SQL
SQL “x” Compiladas
A TIEMPO DE EJECUCION
aplicación cliente librería a
escrita en un tiempo de
lenguaje
“x”
ejecución/driverI
las Inst. SQL Inst. SQL Compiladasprograma
servidor SQL B.D.
4.3.2
SQL
APIs
Antes de introducimos al uso de las APIs SQL, entenderemos el concepto básico de
una Interfaz de Programación de Aplicaciones (API - Application Program Interface).
El objetivo principal de una API, es proporcionar un conjunto de funciones que permitan a dos programas “comunicarse” entre sí, considerando que cada uno utiliza un
conjunto de instrucciones con una sintáxis, semántica o gramática diferente.
Un conjunto de especificaciones es definido para proporcionar un formato standard en el cual serán escritas las funciones que conforman la API, de tal forma que pueden ser invocadas sin problema por cualquier aplicación desarrollada en cualquier lenguaje de programación.
Lenguaje x: Cómo se vería una API:
I
func dibuja-cuadrado (intx),
~ ~ , i ~ l l , l í ~ l ~ t l l ~ l , , l ! l l l ~ / r i l l
( l i / W / ‘ i ( l i t r ~ l i ~ i i í i , l < I ( ’ i l l . li’i ’:
[LENGUAJE C]
[LENGUAJE PASCAL]
void dibuja-cuadrado (int x);
procedure dibuja-cuadrado(integer dibuja-cuadrado(5);
1
x); :[LENGUAJE VISUAL BASIC 3.01
4.3.3 Interfaces a Nivel
de Llamadas SQL
(SQL CLIs
-
Call Level
Ittterfaces)
Tomando en cuenta lo anterior, diremos que una API SQL, es el conjunto de funciones definidas en un formato standard que tienen como objetivo manipular y controlar todo acceso a diferentes Manejadores de B.D., de tal forma que cualquier aplicación pueda comunicarse con cualquiere servidor de B.D.
A estas APIs SQL, también se les conoce como Interfaz a Nivel de Llamadas (CLIs
- Call Level Interfaces) lo cual representa la alternativa a utilizar en lugar de ESQL -
utilizar una API SQL que pueda ser “llamada“ para accesar una B.D.
En teoria, una API standard puede ayudamos a escribir aplicaciones portables que
son independientes de cualquier producto de B.D. - por supuesto, en la práctica la cosa no
es tan simple-.
Lenguaje x: Cómo se vería una CLI SQL (API SQL):
::: l i ( l i i l ~ l ~ i ~ l í! l / l ! l i i l l ~ / l ‘ l l ~ ( / c ; i l [ORACLE J
.
.
., coln) [SYBASE]. .
., coln) [SQL SERVER]i i ! \ ( j / . l insert into <table> values (coll, c012,
insert into <table> values (col 1, c012,
insert into empleados values (45849,
‘Pedro López, ‘M’)
insert into <table> values (coll, c012,
I I
A TIEMPO DE EJECUCION
aplicación cliente librería a
escrita en un tiempo de programa
lenguaje
“x”
ejecución/driver servidor SQL B.D.4.3.4
Conlparando
ESQL VS. CLIs
SQL Incrustado SQL a Nivel de
SQL
Librería a Tiempo de
PrecomDilador
Ejecución de la CLI Ejecución del
Librena a Tiempo de
I
Driver de la Base de DatosI
r"""""""""""-
r - - -
'I:
L i - ,SERVIDOR
Servidor de la B.D.
4.3.5
Estúndares sobre APIs SQL
Las APIs SQL generalmente son proporcionadas por organizaciones de fabricantes de
B.D.
o fabricantes por su cuenta, los cuales definen su implantación de acuerdo a la tecnología prevaleciente.WOpen SAG CLI
SAG- SQL Access Group es un consorcio creado por 44 fabricantes de
B.D.
en1988, el cual tendría como objetivo proporcionar un standard unificado para accesar a
B.D.
remotas, el cual debería ofrecer:
Una interoperabilidad standard que le permite a cualquier cliente de
B.D.
hablar concualquier servidor utilizando formatos de mensaje y protocolos comunes.
Proporcionar una Interfaz a nivel de llamada (CLI) que definía un colljunto de APIs
común para
B.D.
multifabricantes.En 1994, %Open se hace cargo de definir los estándares para la CLI que habían definido en el SAG, por lo cual toma el nombre de WOpen CLI.
Esta API se encuentra estructurada a través de una interfaz a nivel de llamadas, un
driver que recibe las llamadas e identifica la
B.D.
que va a ser accesada y un habilitador dela aplicación cliente:
r " " " " " " " " " " " "
"
-
4.3.6 Microsoft ODBC CLI
ODBC - Open Database Connectivity es la API standard definida por Microsoft
bajo Windows para SQL y es una versión extendida de la CLI de SAG.
En agosto de 1992, es lanzada la versión ODBC 1.0 SDK, la cual fue la respuesta esperada para el acceso a B.D. bajo Windows.
Driver Driver
Oracle
Driver
Driver DB2
ORACLE SYBASE SQL Server DB2
Cabe mencionar que ODBC es la API más conocida y utilizada para accesar B.D., ya que la mayoría de las aplicaciones que accesan a B.D. son aplicaciones implantadas sobre plataforma Windows, lo cual ha hecho de esta API de Microsoft una de las APIs con mayor preferencia en el mercado.
Su estructura se compone del conjunto de llamadas API ODBC, un Manejador de
5.
MECANISMOS DE CONSULTA REMOTOS
En esta sección, nos enfocaremos en los principales mecanismos de consulta remota que hacen uso del concepto clientelsewidor.
Aunque un Servidor de BD SQL puede hallarse ejecutándose en la misma computadora que alguna aplicación cliente (como mencionamos anteriormente, un proceso
cliente y uno servidor pueden convivir en la misma computadora), usualmente son
implantadas sobre un sistema en Red, ya sea sobre una LAN (Red de Area Local) o una
WAN (Red de Amplia Cobertura), con el fin, obviamente, de obtener el mejor provecho del sistema, de acuerdo a las necesidades que se presenten.
Por lo anterior, es importante enfocamos en el rendimiento que presenta el acceso a los datos desde nuestras aplicaciones clientes sobre el Servidor de B.D. teniendo en cuenta diversos factores:
El tráfico en la Red
0 La cantidad de usuarios accesando a los datos.
La topología de Red que se utilice. El Sistema Operativo subyacente Los protocolos de comunicación.
El mecanismo empleado para realizar la consulta
0 etc ...
Aunque todos estos factores son importantes, la mayoria depende más de la
implantación general del sistema, que de la ejecución de las consultas sobre la B.D. y el mecanismo que se aplique en las mismas.
Por lo tanto, centraremos nuestra atención en los mecanismos de consulta remotos que podemos establecer desde nuestras aplicaciones para accesar una B.D.
LA COMUNICACI~N ENTRE LA A P L I C A C I ~ N CLIENTE Y EL SERVIDOR DE
BD SQL
Para realizar la consulta desde una aplicación cliente sobre la B.D. SQL, como se
Una vez que ya conocemos las tecnologías empleadas para llevar a cabo las
llamadas SQL desde la aplicación cliente, nos enfocaremos en los diferentes tipos de
mecanismos que se pueden utilizar para realizar el acceso a la
B.D.
desde cualquieraplicación. Veremos sus ventajas y desventajas con el objetivo de comprender cuándo hacer uso de ellos.
Estos mecanismos se basan en alguna de las tecnologías mencionadas anteriormente
-
ya sea empleando un precompilador o una interfaz de programación a nivel de llamadas.Cada uno de éstos, presenta a la vez un conjunto de características propias que les permite ser utilizados de acuerdo a las necesidades que se presenten.
5.1
SQL Remoto (Estático
yDinámico)
5.1.2 SOL Estático (modo compilado de SQL)
-Las sentencias SQL estáticas son definidas dentro del código de la aplicación y
convertidas a un plan de acceso a tiempo de compilación del programa. -Las sentencias SQL son conocidas antes de que el programa se ejecute.
-Los objetos en la
B.D.
necesitan existir cuando son precompiladas las sentencias SQLestáticas.
Ventajas.-
Representa una característica de mejora de rendimiento.
-/ Es utilizado para escribir programas de transacción altamente optimizados.
J No es muy flexible
Desventajas.-
5.1.3 SOL Dirzámico (modo interpretativo)
-Las sentencias SQL dinámicas son creadas y ejecutadas a tiempo de ejecución. -Ofrecen mayor flexibilidad a expensas de la velocidad de ejecución.
-Los objetos de la
B.D.
no necesitan ser conocidos a tiempo de compilación.-La compilación es hecha a tiempo de ejecución y debe ser repetida cada vez que la misma sentencia es ejecutada de nuevo.
Ventajas.-
-/ Es utilizado para escribir utilerias genéricas para
B.D.
y para desarrollarherramientas de front-end que necesitan crear consultas a la medida.
J Es lento, debido a que necesita ser re-compilada cada vez que se ejecuta.
5.2
Procedintientos Altttacenados (Stored Procedures)
Un “stored procedure” (procedimiento almacenado) es un mecanismo que ofrecen
algunos fabricantes de DBMSs muy parecido a los RPC’s (Remote Procedure Calls -
Llamados a procedimientos remotos).
Un procedimiento almacenado es una colección de sentencias o instrucciones SQL
y lógica procedural que es compilada, verificada y almacenada en el servidor de la B.D.
Los procedimientos almacenados aceptan parámetros de entrada de tal forma que un
simple procedimientos puede ser utilizado a través de la red por múltiples clientes
utilizando diferentes datos de entrada.
Ventajas.-
J Un simple mensaje remoto dispara la ejecución de una colección de sentencias SQL
almacenadas - lo cual resulta en una reducción del tráfico a través de la red y mejor
rendimiento (comparado con el SQL remoto)
De dónde sureen los procedimientos almacenados ?
Este concepto fue desarrollado por Sybase en 1986 para mejorar el rendimiento de SQL en las redes.
Cuál es su utilidad ?
Los SP son utilizados para reforzar las reglas de negocio y la integridad de los datos
Para realizar mantenimiento del sistema y fünciones de administración
Para extender las funciones del servidor de la B.D.
Sin embargo, su principal uso es crear el lado del servidor de una lógica de la
aplicación.
Desventajas.-
4 Proporcionan menor flexibilidad ad hoc que el SQL dinámico remoto.
J Pueden actuar de forma muy precaria (lentos) si sus planes de ejecución no son
refrescados para tomar ventaja de las estadísticas del optimizador - el SQL dinámico
crea un plan nuevo con cada ejecución -
4 No existe sincronización transaccional -i.e. no se puede implantar el protocolo de
compromiso en 2 fases- cada SP se ejecuta como una transacción por separado.
5.3 OLTP Onlirte Transaction Processirlg (Procesamiento de Transacciotm
en Línea)
Para finalizar con este capítulo, haremos una observación sobre el procesamiento de consulta remoto, dentro del cual se puede utilizar el mecanismo de Transacción para lograr mantener la consistencia en los datos, lo cual es uno de los puntos más importantes en la manipulación de información y en particular cuando se trata de llevar a cabo un conjunto de
operaciones en línea. A este tipo de procesamiento se le denomina OLTP (Online
Transaction Processing).
Aunque este tema está fuera del alcance del presente trabajo, únicamente nos enfocaremos en hacer mención de las características de encapsulación que el Stored Procedure, la cuales son bien aprovechadas para la creación de aplicaciones de rendimiento
crítico (como las OLTP), en las cuales :
1. Se recibe un conjunto fijo de entradas desde clientes remotos
2. Se realizan múltiples comandos SQL precompilados sobre una B.D. local
3. Se compromete el trabajo
4. Se devuelve un conjunto fijo de resultados.
De esta forma, podemos identificar cuándo utilizar un determinado mecanismo de
consulta remoto, tomando en cuenta sus ventajas y desventajas y cómo cada uno de éstos es
1. RESEÑA Y EVOLUCION
Una vez que las empresas y organizaciones entendieron la gran importancia de los sistemas de cómputo y la forma en que éstos impactaban en el control y la administración,
no hubo marcha atrás - estaba visto que los sistemas de cómputo presentaban una gran
ventaja competitiva y de desarrollo, con lo cual, la inversión económica en éstos reflejaba
sus dividendos de forma clara y fructuosa.
Obviamente, la obligación de construir un Sistema completamente funcional, tolerante a fallas y adaptable a los cambios planteaba la necesidad de una metodología de desarrollo apropiada.
De esta manera, la importancia del Análisis y Diseño de Sistemas fortaleció sus raíces,
enfocándose en la optimización de técnicas y métodos para lograr un mejor análisis y
diseño con el fin de implantar un sistema suficientemente robusto, que fundamentaba su desarrollo en tales principios.
El Análisis y Diseño Estructurado (Yourdon) representó durante mucho tiempo la
metodología apropiada para el desarrollo de sistemas, sin embargo, las crecientes
necesidades en las empresas, la evolución en la tecnología y la aparición de nuevos
paradigmas como el cómputo distribuido y la programación O 0 influyeron en la forma de
cómo plantear y diseñar un sistema de información.
2. EL ANALISIS ESTRUCTURADO
Podemos definir al análisis estructurado como una metodología para el análisis de los diversos sistemas computacionales que son requeridos por los usuarios, el cual fue creado
para modelar y representar en papel dichos sistemas con el fin de definirlos de forma más
práctica y tangible.
El análisis estructurado se basa en el enfoque de sistemas, el cual centra su atención en el concepto del mismo:
Sistema:
Conjunto de elementos que forman parte de un todo y que están relacionados, debido a
0 Conjunto de elementos que se relacionan entre sí con un objetivo específico.
las interacciones que existen entre ellos.
2.1
Tiposmás comunes de Sistemas
Casi todo aquello con lo cual entramos en contacto es un sistema y éste se divide en
uno o vanos subsistemas, un ejemplo de esto podría ser el sistema solar, sistemas
moleculares, etc.
A manera de ejemplo podemos mencionar que todos los sistemas vivientes según Miller
se subdividen en otros, algunos de éstos son:
Sistema reproductor
0 El motor ( mueve al sistema y sus partes )
Transductor de entrada ( trae señales portadoras de información al sistema )
Etc.
Lo que a nosotros nos interesa son los sistemas automatizados y aunque existen diferentes
tipos de estos, tienden a tener componentes en común:
El hardware de la computadora: procesadores, discos, impresoras, etc.,
0 El software : los programas de sistemas tales como sistemas operativos, sistemas de
Las personas: las que operan el sistema, los que proveen su material de entrada y
Los datos: información que el sistema recuerda durante un periodo
Procedimientos: políticas formales e instrucciones de operación del sistema. bases de datos, etc.
Una división de categorías de los sistemas automatizados es la siguiente:
Sistemas en línea Sistemas de tiempo real Sistemas de apoyo a decisiones Sistemas basados en el conocimiento
2.2 Herramientas del Análisis Estructurado
El analista, al diseñar un sistema se involucra en el modelado de dicho sistema,
pero ... ¿qué es el modelo?, básicamente es un diagrama que nos permite comunicamos con
el usuario de una manera enfocada, sin distraemos con asuntos y características ajenas al sistema.
Debido a lo anterior el analista hace uso de herramientas de modelado para:
Concentrarse en las propiedades importantes del sistema
Discutir cambios y correcciones de los requerimientos del usuario a bajo costo y con
Verificar que el analista comprenda correctamente el ambiente del usuario y que lo haya
riesgo mínimo
respaldado con información documental.
Las herramientas de modelado son:
Diagrama de flujo de datos Diagrama de entidad-relación Diagrama de transición de estado.
El diagrama de flujo de datos ilustra las funciones que el sistema debe realizar, los
2.2.1
El Diagrama de Flujo de Datos
Para realizar un diagrama de flujo de datos debemos de tomar en cuenta las preguntas:
-¿Cuales son las funciones con las que debe desempeñarse el sistema? ¿Cuáles son las interacciones entre dichas funciones?
-¿Qué transformaciones debe llevar a cabo el sistema? ¿Qué entradas se transforman en qué salidas?
-¿Qué tipo de labor debe realizar el sistema? ¿De dónde obtiene la información para llevar a cabo dicha labor? ¿Dónde entrega los resultados de su labor?
Los diagramas de flujo de datos consisten en procesos, agregados de datos, flujos y
terminadores:
Los procesos se representan por medio de círculos, en el diagrama. Representan
diversas funciones individuales que el sistema lleva a cabo. Las funciones transforman entradas en salidas
Los flujos se muestran por medio de flechas curvas. Son las conexiones entre los
procesos y representan la información que dichos procesos requieren como entrada o la información que generan como salida
Los agregados de datos se representan por medio de dos líneas paralelas o mediante
una elipse, los agregados existirán como archivos o bases de datos.
Los terminadores muestran las entidades externas con las que el sistema se comunica.
Información
ombre del cllente,
C O B W - cliente,detalles
de la factura
CLIENTES
Diagrama de flujo de datos
El diagrama de flujo de datos proporciona una visión global, pero no da detalles de éstos, para mostrar detalles acerca de qué información se transforma y de cómo se transforma se usan dos herramientas adicionales:
2.2.2
El Diagrama de Entidad-Relación
El diagrama de flujo de datos sólo resalta las funciones, es por ello que tenemos otra herramienta que es el D.E.R. éste consta de 2 componentes principales:
1.- Tipos de objetos: Estos se representan por medio de un rectángulo en el diagrama, esto
representa una colección o conjunto de objetos pueden además ser identificados de manera
ímica y ser descritos por uno o más atributos.
2.- Relaciones: Se representan por medio de rombos en el diagrama y son la serie de
conexiones o asociaciones entre los tipos de objetos que están conectados con la relación por medio de flechas, como lo vemos en las siguiente figura:
i'l
PEDIDOLIBRO DE
CONTABILI-
2.2.3
EL Diagrama de Transición de Estados
La secuencia con la cual se hará el acceso a los datos y se ejecutarán las funciones
es un tercer aspecto de muchos sistemas complejos. La herramienta que usamos para
auxiliamos en éste caso es el diagrama de transición de estados, un ejemplo de esto es la
siguiente figura del comportamiento de una lavadora controlada por computadora. Los
rectángulos representan los estados en que se puede encontrar el sistema, las flechas que
conectan un rectángulo con otro representan el cambio de estado, Hay una o más
condiciones de un cambio de estado a otro.
Un ejemplo lo vemos a continuación:
I
I&
i
d
INACTIVO COMENZAR, ALTO,
HABILITAR EL LLENADO DESHABILITAR EL LLENADO LLENADO
MVADORA LLENA ALTO,
HABILITAR EL LAVADO DESAHlBlLlTAR EL LAVAD O LAVAD O
1
CICLO DE LAVADO CONCLUIDO CICLO DE SECADO HABILITAR EL SECADO CONCLUIDO
CENTRIFUGO
2.2.4
Diugrunza de
EstructurasSe usan en la creación de un sistema complejo, representa la jerarquía del software,
cada rectángulo representa un módulo ( una subrutina en algún lenguaje cualquiera ) Las
flechas que conectan los rectángulos representan las invocaciones de módulos( llamados a
subrutinas o procedimientos ).
El diagrama de estructuras también muestra los parámetros de entrada que se le dan
a cada módulo invocado, y los parámetros de salida devueltos por cada módulo cuando
termina su labor y le devuelve en control al que lo llama, éste tipo de diagrama no se mostraria normalmente al usuario.
Un ejemplo lo vemos a continuación:
p z ü q
EJECUTIVO
c a r a c t e L
,
,
r e g p \ k r a c t e , r,
\
caracte;/vf
,
\yg.ESCRIBIR REGISTRO ESCRIBIR EXTRAER INSERTAR CA-
CARACTER CARACTER RACTER EN
2.3
E T A P A D E L D I S E Ñ O E N E L A N A L I S I S E S T R U C T U R A D OAntes de pasar a la programación existe una actividad que se debe tomar en cuenta el
diseño. El analista tiene ciertas actividades y el diseñador otra, existen ocasiones en que las actividades de lo dos no se pueden separar. Por su parte el analista debe entender los
requerimientos del usuario, mientras que el diseñador debe asegurar que dichos
requerimientos se puedan implantar de manera realista con la tecnología computacional actual. Debido a esto, es importante entender el proceso que enfrenta el diseñador cuando
el analista termina su labor. En esta etapa unas de las caractensticas que se debe de tomar
en cuenta son el decidir sobre la mejor manera de asociar el modelo de los requerimientos
del usuario en diferentes configuraciones de procesadores, o tal vez se tenga que decidir
cómo implantar de la mejor manera el modelo lógico de datos (DER) con un sistema de administración de bases de datos, otro aspecto es decidir cómo asignar a las funciones del sistema las distintas tareas dentro de cada procesador.
Etapas
del diseñoPara elaborar el diseño se debe de seguir una serie de modelos, así como la que el analista
desarrolla modelos durante la fase de análisis de un proyecto. Estos modelos se bosquejan
a continuación en la siguiente figura:
MODELO ESENCIAL
/ __ __
Incorpora dnersos procesos esenciales
W
COMPUTADORA PRINCIPAL
Incorpora dwersos almacenes de datos modem
PROCESADOR
MODELO DE NIVEL DE
Enlace de telecomunlcaclones
TAREAS
MODELO DE NIVEL DE
w
REMOTO
DE PROGRAMA
Los modelos que tienen mayor importancia para el diseñador son el modelo de implantación de sistemas y el modelo de implantación de programas. El modelo de implantación de sistemas se divide luego en un modelo del procesador, y uno de tareas.
Lo primero en que debemos de enfocar la atención es decidir cómo asignar la parte automatizada del modelo de implantación del usuario a las piezas principales de hardware y software del sistema.
Por otra parte en el nivel del modelo del procesador, el diseñador del sistema trata principalmente de decidir cómo se asigna el modelo esencial a los distintos procesadores (CPU) y cómo deben comunicarse entre sí. En general existen una variedad de opciones:
a.- El modelo esencial completo se le puede asignar a un solo procesador. Esto se
conoce como la solución de computadora principal.
b.- Cada burbuja de la figura del DFD se puede asignar a un procesador distinto Esto se
conoce como solución distribuida.
c.- Se puede escoger una combinación de computadoras principales, minis y micros para minimizar costos, maximizar confiabilidad o lograr algún otro objetivo.
Los almacenes de datos se deben asignar igualmente, se debe decidir si un almacén
funcionará como base de datos en el procesador 1 o el 2., también se debe decidir si se
deben asignar copias del almacén a diferentes procesadores.
La implantación diferente de un almacén a la de un solo procesador involucrará
algún mecanismo de comunicación entre procesadores; los flujos de datos ahora deben
especificarse en términos fisicos. Algunas de las opciones a tomar por el diseñador del sistema para comunicación de procesador a procesador son:
1.- Conexión directa entre procesadores, conectando los procesadores mediante un
cable, un canal o una red local. Este tipo de comunicación permite que los datos se
transmitan de un procesador a otro a velocidades que van desde los 50 KB a vanos
millones de bits por segundo.
2.- Enlace de telecomunicaciones entre procesadores, si los procesadores están
separados fisicamente por algunos cientos de metros. Dependiendo de la naturaleza del enlace de telecomunicaciones, se transmiten datos entre procesadores a velocidades que van desde 300 hasta 50,000 bits por segundo.
3.- Enlace indirecto entre procesadores. los datos pueden escribirse en cinta magnética,
Como la comunicación de procesador a procesador generalmente es mucho más lenta que la comunicación entre procesos (burbujas) dentro de un mismo procesador. Por tanto, el diseñador generalmente tratará de agrupar procesos y almacenes que tienen gran volumen de comunicación dentro del mismo procesador Para hacer lo anterior el diseñador debe tomar en cuenta varios factores al hacer estas asignaciones:
costo
Dependiendo de la naturaleza del sistema, pudiera ser o no ser más barata una implantación de un solo procesador. Para algunas aplicaciones, la solución más económica
puede ser un grupo de microcomputadoras de bajo costo; para otras sería más práctico y
económico hacer la implantación en la computadora principal existente en la organización.
Eficiencia
Hay que considerar el tiempo de respuesta de los sistemas en línea y por la longitud del ciclo para los sistemas de cómputo por lote. Por tanto, debe escoger procesa- dores y dispositivos de almacenamiento de datos suficientemente rápidos y poderosos para
satisfacer los requerimientos de desempeño en el modelo de implantación. A veces al
mejor opción es una implantación de múltiples procesadores para que las diferentes partes del sistema se ejecuten de manera paralela, acelerando así el tiempo de res puesta.
Seguridad
Se pueden tener requerimientos de seguridad que dicten que algunos (o todos) los procesadores y10 datos delicados se coloquen en lugares protegidos. Estos requerimientos también dictaminan la naturaleza (o la ausencia) de la comunicación de procesador a
procesador. Un ejemplo que podemos citar aquí es : el diseñador podria estar impedido de
transmitir da tos de un procesador a otro mediante líneas telefónicas ordinarias si la
información es confidencial.
Confiabilidad
El usuario final especifica los requerimientos de confiabilidad para un nuevo sistema. Estos requerimientos pueden expresarse en términos de tiempo promedio entre
fallas (MTBF), tiempo promedio de reparación (MTTR) o disponibilidad del sistema. Esto
podemos entenderlo con la siguiente expresión:
Disponibilidad = MTBF / ( MTBF
+
MTTR )Como alternativa, se puede decidir tener copias redundantes de procesos yio datos en múltiples procesadores, tal vez incluso con procesadores extra que pueden usarse en caso de falla. incluso si llega a fallar el procesador activo (lo cual es tal vez más probable aún, dado que se trata de una computadora principal grande y compleja), los procesadores individuales de edición pueden continuar operando, recolectando transacciones, editándolas y almacenándolas para procesarlas posteriomlente.
De manera similar, si se descompone uno de los procesadores de edición, los demás pueden continuar operando.
Lo podemos ver de manera más clara en la figura siguiente:
J x
EDITAR/ I -
I
w
EDITARrespuesta
PROCESAR
J
Procesadores múltiples para mayor confiabilidad
Restricciones políticas
y
operacionales.La configuración de hardware puede verse influenciada también por restricciones políticas impuestas directamente por el usuario final, por otros niveles de administración dentro de la organización o por el departamento de operaciones a cargo del mantenimiento y operación de todos los sistemas de cómputo.
Esto puede llevar a la elección de una configuración específica de hardware, o
excluir la elección de ciertos proveedores. De manera similar, se pueden presentar
restricciones ambientales (por ejemplo, temperatura, humedad, exposición a radiaciones, polvo, tierra, vibraciones), y esto puede tener una influencia enorme sobre la configuración
de procesadores que se elija.
