UNIVERSIDAD NACIONAL DEL ALTIPLANO

ESCUELA DE POSTGRADO
MAESTRÍA EN INFÓRMATICA

PROYECTO DE TESIS

MODELO RELACIONAL USANDO AGENTES INTELIGENTES EN LAS BASES DE

DATOS DE LA DIRECCIÓN DE SERVICIOS ACADÉMICOS DE LA UNAMBA 2013

PRESENTADO POR:
MARCO ANTONIO AGUILAR ESPINOZA

PARA OPTAR EL GRADO ACADÉMICO DE:

MAGISTER SCIENTIAE EN INFORMÁTICA

APURÍMAC – PERÚ
C.U. 2013

0
 ÍNDICE
RESUMEN……………………………………………………………………………………..3
I. PLANTEAMIENTO DEL PROBLEMA………………………………………………..…4
1.1. DESCRIPCIÓN DEL PROBLEMA……………………………………………………..4
1.2. ENUNCIADO DEL PROBLEMA………………………………………………………..5
II. JUSTIFICACIÓN…………………………………………………………………………..5
III. MARCO TEÓRICO……………………………………………………………………….5
3.1. SISTEMA DE BASE DE DATOS………………………………………………………..5
3.2. ARQUITECTURA DE LOS SISTEMAS DE BASES DE DATOS…………………….6
3.3. EL SISTEMA DE ADMINISTRACIÓN DE BASE DE DATOS………………………7
3.4. ENFOQUES DE LOS SGBD……………………………………………………………..7
3.5. HISTORIA DE LOS SISTEMAS DE BASE DE DATOS………………………………8
3.6. CLASIFICACIÓN DE LOS SGBD………………………………………………………9
3.7. LENGUAJES DE BASES DE DATOS……………………………………………….…11
3.8. EL MODELO RELACIONAL…………………………………………………………..12
3.9. AGENTE RACIONAL…………………………………………………………………...20
3.10. AGENTES Y SU ENTORNO…………………………………………………………..20
3.11. ESTRUCTURA DE LOS AGENTES………………………………………………….21
3.12. AGENTE INTELIGENTE……………………………………………………………..21
3.13. PROPIEDADES DE LOS AGENTES INTELIGENTES……………………………21
3.14. CLASIFICACIÓN DE LOS AGENTES INTELIGENTES………………………….22
3.15. TAXONOMÍA DE LOS AGENTES……………………………………………………22
3.16. METODOLOGÍA PROMETHEUS……………………………………………………24
IV. ANTECEDENTES………………………………………………………………………..33
4.1. A NIVEL INTERNACIONAL…………………………………………………………..33
4.2. A NIVEL NACIONAL…………………………………………………………………...34
V. HIPÓTESIS………………………………………………………………………………...34
5.1. HIPÓTESIS PRINCIPAL……………………………………………………………….34
5.2. HIPÓTESIS ESPECÍFICAS…………………………………………………………….34
VI. OBJETIVOS………………………………………………………………………………35
6.1. OBJETIVO GENERAL………………………………………………………………….35
6.2. OBJETIVOS ESPECÍFICOS..………………………………………………………….35
VII. MATERIALES Y MÉTODOS…………………………………………………………35
7.1. ÁMBITO Y LUGAR DE ESTUDIO……………………………………………………35

1
7.2. POBLACIÓN Y MUESTRA…………………………………………………………..35
7.3. DESCRIPCIÓN DEL MÉTODO POR OBJETIVOS ESPECÍFICOS…………….35
7.4. OPERACIONALIZACIÓN DE VARIABLES……………………………………….38
VIII. CRONOGRAMA DE ACTIVIDADES……………………………………………...40
IX. PRESUPUESTO…………………………………………………………………………41
BIBLIOGRAFÍA…………………………………………………………………………….42

2
 RESUMEN

Actualmente todas las empresas y personas almacenan volúmenes grandes y pequeños de información
en Sistemas Gestores de Base de Datos (SGBD), y recuperan la información en función de peticiones.
En la Dirección de Servicios Académicos de la Universidad Nacional Micaela Bastidas de Apurímac se
maneja la información académica, almacenada en un SGBD. La inadecuada declaración de tipos de
datos y tamaño en las tablas de las Base de Datos (BD) genera un incremento en el tamaño, asimismo
para el proceso de recuperación de información se construye consultas que según la cantidad de tablas
utilizadas se requiere de muchas relaciones o utilizar vistas, que muchas veces no se estructura
correctamente generando exceso e tiempos.

EL objetivo de presente trabajo de investigación es determinar en cuanto el uso de agentes inteligentes

reduce el tiempo en el proceso de recuperación de información asimismo reduce el tamaño de las tablas
y elimina los errores de actualización. En la metodología de la investigación se establece, el diseño de
la investigación es prueba de medias de dos grupos dependientes, la información es recabada en un
cuaderno de registro durante el proceso de definición y manipulación de datos.

Se espera como resultado que el efecto del uso de agentes inteligentes sea significativo y por lo tanto
se pueda reducir el tiempo en la recuperación de información y el tamaño de las tablas.

Palabras clave: Agente inteligente, recuperación de información, SGBD, BD, tablas.

3
 I. PLANTEAMIENTO DEL PROBLEMA

1.1 DESCRIPCIÓN DEL PROBLEMA

Desde tiempos remotos ha existido la necesidad de almacenar la información en diferentes tipos de
instrumentos, con la creación de la primera computadora, se crearon también los Sistemas
Gestores de Base de Datos(SGBD) por la necesidad latente de administrar información, teniendo 4
tipos de modelos: Jerárquico, Red, Entidad Relación (E-R) y el Orientado a Objetos(OO). La base
de dato tiene un lenguaje de definición de datos (permite crean y modificar la estructura de una
tabla) y un lenguaje de manipulación de datos (permite recuperar información y realizar
operaciones de inserción, borrado y modificación de la información almacenada en la BD). En la
actualidad el SQL es el estándar de facto de la mayoría de Sistemas Gestores de Bases de
Datos(SGBD), y se encuentra en el SQL:2011, este estándar nos permite administrar la BD con la
creación de tablas, llaves, relaciones, vistas, trigger. EL Modelo E-R utiliza el estándar SQL para
accesar a la base de dato, éste modelo es el más utilizado para el desarrollo de Sistemas de
Información por los desarrolladores y empresas que se encargan del desarrollo de Software.

En la Universidad Nacional Micaela Bastidas de Apurímac, la dirección de Servicios Académicos

utiliza Sistemas Gestores de Base de Datos que se basan en el modelo relacional. Este modelo
requiere crear, modificar y relacionar las tablas, cuando se crea una tabla por lo general no la
definimos con el tipo de dato correcto o tamaño adecuado, lo que genera un incremento en el
tamaño de la tabla y de la BD. Para la recuperación de información se debe estructurar consultas
algunas veces pequeñas o grandes que dependerá de la cantidad de tablas que utilizamos, como
también se utiliza vistas para optimizar los tiempos de respuestas en las consultas, y para mantener
los datos actualizados usamos triggers que permiten actualizar los datos según se utilice las
operaciones de inserción, actualización y eliminación; todas estas operaciones son definidas por el
administrador de la Base de Datos, que a pesar de enmarcarse bajo el estándar SQL, ocurren
siempre omisiones en la implementación de las operaciones; vistas mal construidas o consultas que
utilizan demasiado tiempo para la recuperación de la información, y con ello el incremento
innecesario de tiempo.

Creando un agente inteligente en el Modelo de Base de Datos Relacional, que se encargue de

administrar los campos de las tablas, controlar las actualizaciones de forma automática y de crear
las vistas y generar las consultas; consiguiendo reducir el tamaño de las tablas y optimizar las

4
 consultas de recuperación de información reflejado en la disminución de tiempo de respuesta. Por
lo que se plantea las siguientes interrogantes:

1.2 ENUNCIADO DEL PROBLEMA

1.2.1 PROBLEMA PRINCIPAL
¿En qué medida el modelo relacional usando agentes inteligentes minimizará el tiempo de
recuperación de datos en las consultas, en la BD de la dirección de Servicios académicos de la
UNAMBA?

1.2.2 PROBLEMAS ESPECÍFICOS

 ¿En qué medida un agente inteligente reducirá el tamaño de los campos en la BD de la
dirección de Servicios académicos de la UNAMBA 2013?
 ¿En qué medida un agente inteligente eliminará los errores de actualización de datos en la BD
de la dirección de Servicios académicos de la UNAMBA?

II. JUSTIFICACIÓN
Una base de datos es una biblioteca de información organizada, que nos permite almacenar grandes
volúmenes de información y recuperarla en función de peticiones. La información puede ser
cualquiera, que sea de gran importancia para un individuo o una organización.
Esta propuesta sería un gran aporte a los administradores de Bases de datos, para reducir el tamaño
de la BD, asimismo a los que tienen problemas durante la implementación de operaciones de
recuperación de datos, modificaciones, inserciones e eliminaciones de datos; brindándoles un
Gestor de Base de Datos que les apoyará en la administración de sus Bases de Datos.
La Dirección de Servicios Académicos de la Universidad Nacional Micaela Bastidas de Apurímac,
mejorará su servicio a los alumnos, docentes y público en general, emitiendo reportes y constancias
más rápidamente, o cualquier pedido de información, por contar con una BD inteligente.

III. MARCO TEÓRICO

3.1 SISTEMA DE BASE DE DATOS

Date(2001), Un sistema de base de datos es básicamente un sistema computarizado para

guardar registros; es decir, es un sistema computarizado cuya finalidad general es almacenar
información y permitir a los usuarios recuperar y actualizar esa información con base en

5
 peticiones. La información en cuestión puede ser cualquier cosa que sea de importancia para el
individuo u organización; en otras palabras, todo lo que sea necesario para auxiliarle en el proceso
general de su administración.
La figura 1 es una imagen simplificada de un sistema de base de datos. Pretende mostrar
que un sistema de base de datos comprende cuatro componentes principales: datos, hardware,
software y usuarios.

Figura 1: Imagen simplificada de una base de datos.

3.2 ARQUITECTURA DE LOS SISTEMAS DE BASES DE DATOS

Date(2001), Menciona la propuesta por el Grupo de Estudio en Sistemas de

Administración de Bases de Datos de ANSI/SPARC. La arquitectura ANSI/SPARC se divide en
tres niveles, conocidos como interno, conceptual y externo.
 El nivel interno (también conocido como el nivel físico) es el que está más cerca del
almacenamiento físico; es decir, es el que tiene que ver con la forma en que los datos están
almacenados físicamente.
 El nivel externo (también conocido como el nivel lógico de usuario) es el más próximo a los
usuarios; es decir, el que tiene que ver con la forma en que los usuarios individuales ven los
datos.
 El nivel conceptual (también conocido como el nivel lógico de la comunidad, o en ocasiones
sólo como el nivel lógico, sin calificar) es un nivel de indirección entre los otros dos.

6
 Figura 2: Los tres niveles de la arquitectura

3.3 EL SISTEMA DE ADMINISTRACIÓN DE BASE DE DATOS

Date(2001), El DBMS (sistema de administración de base de datos) es el software que

maneja todo acceso a la base de datos. De manera conceptual, lo que sucede es lo siguiente:
a. Un usuario emite una petición de acceso, utilizando algún sublenguaje de datos específico (por
lo regular SQL).
b. El DBMS intercepta esa petición y la analiza.
c. El DBMS inspecciona, en su momento, el esquema externo para ese usuario, la transformación
externa/conceptual correspondiente, el esquema conceptual, la transformación
conceptual/interna y la definición de la estructura de almacenamiento.
d. El DBMS ejecuta las operaciones necesarias sobre la base de datos almacenada.

3.4 ENFOQUES DE LOS SGBD

Gonzalez (2000).Una clasificación primaria de los SGBD, nos permite establecer los tipos básicos
según el tipo de estructura de datos que soporta:
 Enfoque jerárquico. Parte de una estructura de datos basada en un conjunto de registros
diferentes guardados en un único archivo y jerarquizados entre sí mediante ligas. Su estructura
de árbol, impone que un elemento padre puede tener varios elementos hijo, pero no su inverso.
Precisa de punteros físicos.
 Enfoque de Red (Codasyl). Similar al enfoque jerárquico en tanto al uso de registros y ligas,
pero dentro del esquema jerárquico un elemento de inferior jerarquía puede tener varios

7
 elementos situados a un nivel superior del mismo. Las bases de datos gestionadas bajo este
enfoque implementan registros conectores (estructuras de datos que sirven para asociar a otras
dentro de un fichero). Precisa de punteros físicos
 Enfoque relacional. Se caracteriza por la representación de datos en forma de tablas, en las
que los conjuntos de registros tienen un formato fijo e idéntica estructura. El enfoque
relacional en bases de datos parte del modelo relacional en matemáticas y, por tanto, son
susceptibles de aplicar al mismo todas las formulaciones teóricas que éste presenta; en
objetivos posteriores desarrollamos una descripción exhaustiva de este enfoque, puesto que el
prototipo BDI, de nuestro estudio utiliza un SGBD relacional (Microsoft Jet).
 Orientado a objetos. Basada en el encapsulamiento de código y datos en unidades
denominadas objetos, que interactúan con el sistema a través de mensajes. El agrupamiento de
objetos con métodos y variables comunes se estructura en clases jerárquicas.
 Enfoque Lógico. No es esencialmente distinto al enfoque relacional, pero se sustenta en la
lógica de predicados de primer orden para representar y manipular los datos, con lo que se
obtiene un modelo relaciona1 flexible con capacidades para la deducción automática, a éste
pertenecen los SGBD deductivos.

3.5 HISTORIA DE LOS SISTEMAS DE BASE DE DATOS

Silberschatz, & Korth & Sudarshan. (2002) La historia de las bases de datos inicia a
mediados de los años cincuenta, en el momento en que comenzaron a introducirse los ordenadores
para automatizar la gestión de las empresas, fundamentalmente con desarrollos en COBOL, y se
han caracterizado por el uso de tecnologías orientadas a la estructuración de datos mediante
modelos jerárquicos y Codasyl (p.ej. IMS de IBM; IDMS de Cullinet) de lógica procedimental,
que obligan al programador a desplazarse registro a registro, hecho que implica una escasa
flexibilidad.
En 1970 se propuso el modelo relacional, basado en los trabajos del Dr. Codd, básicamente el
modelo matemático que dio fundamentos a la segunda eneración de SGBD, caracterizada por una
mayor independencia físico-lógica, dado que actúan sobre conjuntos de registros; entre ellas
destacan ORACLE, DB2, INGRES, INFORMIX, SYBASE, etc. Codd propuso un modelo simple
de datos en el que todos ellos se representarían en tablas constituidas por filas y columnas. A
dichas tablas se les dio en nombre matemático de relaciones, denominándose así el sistema como
relacional.
Codd también propuso dos lenguajes para manipular los datos en las tablas: álgebra y cálculo
relacional, que soportan la manipulación de los datos sobre la base de operadores lógicos en lugar
8
 de los punteros físicos utilizados en los modelos jerárquicos y de red. El resultado fue la aparición
de sistemas relacionales durante la última mitad de los setenta que soportaban lenguajes como el
Structured Query Language (SQL), el Query Language (Quel) y el Query-by-Example(QBE): los
trabajos de investigación que se realizaron durante la década de los ochenta se centraron en la
optimización de consultas, lenguajes de alto nivel, teoría de la normalización, organizaciones
físicas para el almacenamiento de las relaciones, algoritmos para la gestión de memorias
intermedias (bufen), técnicas de indexación para un acceso asociativo más rápido (distintas
variaciones de los árboles), sistemas distribuidos, diccionarios de datos, gestión de transacciones,
etc. Estas investigaciones han tenido como consecuencia la elevada tasa de transacciones de
muchos de los productos actuales que permiten asegurar entornos transaccionales en línea (OLTP)
muy eficientes y seguros. También cabe recordar que durante la primera mitad de los ochenta se
estandariza el lenguaje SQL (el SQUANSI se aprueba en 1986), ofreciendo, al cabo de poco
tiempo, prácticamente todos los productos una interfaz SQL, aún los no relacionales (sistemas
“renacidos”).
El enfoque relacional permite a los programadores la manipulación de tuplas procedentes de
distintos ficheros y tablas en una misma base de datos mediante consultas estructuradas,
habilitando acciones múltiples sobre los registros. La aparición y estandarización de SQL, permitió
una mayor integración, multiplicó las tareas asignadas a las bases de datos e implicó el desarrollo
de sistemas de uso transparente, cuya facilidad de manejo derivó en una excepcional productividad
e impresionante impacto económico.
La tercera generación de SGBD, tiene como principal característica la optimización relacional de
los sistemas en entornos multiusuario, la gestión de objetos que permite tipos de datos complejos
(texto, imagen, audio...), el encapsulamiento de la semántica de datos que proporciona un soporte
robusto para la recuperación automática de la información y mantenimiento de las restricciones de
integridad entre datos.

3.6 Clasificación de los SGBD

 Sistemas Orientados al proceso y SGBD clásicos.- Sistemas que operan sobre conjuntos de
registros agrupados en “ficheros”, cuya naturaleza reside en la recuperación y almacenamiento
simple, dado que no almacenan ningún tipo de información para el procesamiento de datos, las
restricciones, procesos y el control se distribuye en los programas que acceden a los ficheros.
Estos sistemas “clásicos” enfrentan graves problemas de redundancia al encontrarse dispersa la
semántica de los datos en los programas. Se distinguen por el acceso secuencial a cadenas de
caracteres, interpretadas por los programas.

9
 SGBD semánticos
En la medida en que evolucionaron los componentes físicos de los ordenadores y se hizo
posible el uso de mayor memoria para operaciones lógicas, los SGBD incorporaron mayor
número de información sobre los datos en el propio catálogo de la base de datos, habilitando
restricciones de diferentes tipos (CHECK), aserciones e incluso dominios, así, en un SGBD
semántico la base de datos incluye información sobre restricciones, información sobre datos y
los datos en sí.
 SGBD activos
En este tipo de sistemas, los desarrolladores incorporan acciones que el sistema ejecuta sin la
intervención del usuario, a través de disparadores, reglas, demonios, etc. Tecnología basada en
procedimientos que se activan de forma automática, y que han sido previamente especificados
en la fase de definición intensión- de la base de datos. De hecho, representan patrones
invocados donde las condiciones para invocar se revisan en cada paso, frente a los SGBD
semánticos, encontramos además, en la base de datos información de control.
 SGBD deductivos
La programación lógica ha ido evolucionando desde mediados de Ia década pasada hasta
nuestros días ampliando sus horizontes en el desarrollo de sistemas gestores de bases de datos,
la programación lógica, en forma similar a los primeros desarrollos de bases de datos. Centra
su acción en el núcleo de los programas que acceden a los datos, de hecho, la programación
lógica se utiliza principalmente como lenguaje de consulta, mientras que la tecnología de base
de datos se emplea para asegurar un almacenamiento eficiente y fiable. Los SGBD deductivos
se puede implementar añadiendo al SGBD facilidades para almacenar y gestionar reglas,
extendiendo el procesador de consultas del SGBD o acoplando un SGBD con un sistema
Prolog. Aunque, normalmente, en lugar de utilizar un lenguaje como Prolog (que procesa una
tupla a la vez) se suele emplear un lenguaje relaciona1 declarativo denominado DATALOG,
que es poco procedimental y orientado a conjuntos, lo que lo hace más adecuado para bases de
datos. Sintácticamente el DATALOG es muy parecido al Prolog, existiendo en la actualidad
diferentes versiones. Este tipo de lenguajes resulta muy útil para hacer consultas de tipo
recursivo, siendo clásica la de los ancestros de una persona (conociendo que los padres de una
persona son sus ancestros, así como los padres de los ancestros). Sin embargo, todavía no
existen productos comerciales que puedan incluirse en esta categoría, aunque algunas de sus
nociones se van incorporando en la nueva generación de SGBD relacionales-activos”

10
  SGBD orientadas al objeto
Conocidos también como SGBO, aunque podríamos considerarlos como la tendencia a
extender los SGBD relacionales mediante la incorporación de la programación orientada a
objetos, en esta tendencia destacan: interfaces de POO sobre motores relacionales (Visual
Basic, VC++, J++, etc.), herramientas de conversión de esquemas relacionales a esquemas OO
y viceversa, herramientas de migración de esquemas, interoperabilidad de BDR y BDO, etc.
 SGBD multidimensionales
Los sistemas de base relacional han sido diseñado específicamente para soportar el
procesamiento analítico de los datos: On Line Analytical Processing (OLAP), representan los
datos mediante matrices de n dimensiones d.enominadas “hipercubos” asignando a cada
dimensión un dominio específico jerarquizado, cada casilla del hipercubo contiene datos
agregados (infor-kación de...) que relacionan los elementos entre las distintas dimensiones, de
hecho, éstas actúan como apuntadores para identificar los valores dentro de la matriz.
Es importante destacar que el modelo de matriz de datos que aplica la lógica multidimensional
no está asociado a una representación física de los datos, ni utiliza LDD particulares, sus
principales diferencias frente al modelo de tablas relacionadas, reside en que todos los
dominios pueden encontrase relacionados, en contraparte dentro del esquema de tablas, las
relaciones afectan sólo campos clave o campos con naturaleza idéntica-asociativa.

3.7 LENGUAJES DE BASES DE DATOS

Silberschatz, & Korth & Sudarshan. (2002) Un sistema de base de datos proporciona un lenguaje
de definición de datos para especificar el esquema de la base de datos y un lenguaje de
manipulación de datos para expresar las consultas a las base de datos y las modificaciones.
 Lenguaje de definición de datos.- Un esquema de base de datos se especifica mediante un
conjunto de definiciones expresadas mediante un lenguaje especial llamado Lenguaje de
definición de datos(LDD). Por ejemplo, la siguiente instrucción en el lenguaje SQL define la
tabla cuenta:
Create table cuenta
(numerocuenta char(10),
Saldo integer)

 Lenguaje de manipulación de datos.- La manipulación de datos es:

o La recuperación de información almacenada en la Base de datos.

11
 o La inserción de información nueva en la base de datos.
o El borrado de información de la base de datos.
o La modificación de la información almacenada en la base de datos.
Un lenguaje de manipulación de datos (LMD) es un lenguaje que permite a los usuarios
acceder o manipular los datos organizados mediante el modelo de datos apropiado. Existen dos
tipos:
o LMDs Procedimentales. Requieren que el usuario especifique qué datos se necesitan y
cómo obtener esos datos.
o LMDs Declarativos (también conocidos comos LMDs no procedimentales). Requieren
que el usuario especifique qué datos se necesitan sin especificar cómo obtener esos
datos.

3.8 EL MODELO RELACIONAL

R. Stanek (2001) Es un modelo de datos basado en la teoría de las relaciones, en donde los datos se
estructuran lógicamente en forma de relaciones-tablas, siendo un objetivo fundamental del modelo
mantener la independencia de esta estructura lógica respecto al modo de almacenamiento y a otras
características de tipo físico.

3.8.1 OBJETIVOS

 Independencia física: es decir, el modo en el que se almacenan los datos no influya en

su manipulación lógica y, por tanto, los usuarios que acceden a esos datos no tienen
que modificar sus programas por cambios en el almacenamiento físico.
 Independencia lógica: esto es, que el añadir, eliminar o modificar objetos de la base
de datos no repercuta en los programas y/o usuarios que están accediendo a
subconjuntos parciales de los mismos (vistas).
 Flexibilidad: en el sentido de poder presentar a cada usuario los datos de la forma en
que éste prefiera.
 Uniformidad: las estructuras lógicas de los datos presentan un aspecto uniforme, lo
que facilita la concepción y manipulación de la base de datos por parte de los usuarios.
 Sencillez: las características anteriores, así como unos lenguajes de usuario muy
sencillos, producen como resultado que el modelo de datos relacional sea fácil de
comprender y de utilizar por parte del usuario final.

12
3.8.2 ESTRUCTURA DEL MODELO RELACIONAL

La relación es el elemento básico en el modelo relacional y se puede representar como una

tabla:

Nombre
Atributo 1 Atributo 2 ..................... Atributo n
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX Tupla 1
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX Tupla 2
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX .
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX .
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX Tupla n

El número de filas de una relación se denomina cardinalidad de la relación y el número de

columnas es el grado de la relación. Ejemplo:

AUTOR
Nombre Nacionalidad Institucion
Pepe España O.N.U.
John EE.UU. O.M.S.
Pierre Francia N.A.S.A.

Una relación se puede representar en forma de tabla, pero va a tener una serie de elementos
característicos:
 No puede haber filas duplicadas, es decir, todas las tuplas tienen que ser distintas.
 El orden de las filas es irrelevante.
 La tabla es plana, es decir, en el cruce de una fila y una columna sólo puede haber un
valor.

Dominio y Atributo
Un dominio D es un conjunto finito de valores homogéneos (porque son todos del mismo tipo)
caracterizados por un nombre.

13
 Todo dominio ha de tener un nombre por el cual nos podamos referir a él y un tipo de datos;
así el tipo de datos del dominio "nacionalidades" es una tira de caracteres de longitud 10.
Ejemplos de dominios serían:
Colores: Es el conjunto de los colores D={rojo, verde, azul,}
Números de DNI: Es conjunto de números del DNI válidos, formados por ocho dígitos.
Edad: Edades posibles de los empleados entre 18 y 80 años.

Atributos
Describen propiedades que posee cada miembro de un conjunto de entidades. Cada entidad
puede tener su propio valor para cada atributo.

Claves
Una clave candidata de una relación es un conjunto no vacío de atributos que identifican cada
tupla. Por la propia definición de relación, siempre hay al menos una clave candidata, ya que al
ser la relación un conjunto no existen tuplas repetidas y por tanto, el conjunto de todos los
atributos identificará unívocamente a las tuplas. Una relación puede tener más de una clave
candidata, entre las cuales se debe distinguir:
 Clave primaria: es aquella clave candidata que el usuario escogerá, por
consideraciones ajenas al modelo relacional, para identificar a las tuplas de una
relación.
 Clave alternativa: son aquellas claves candidatas que no han sido elegidas.

Relación
Una relación es una asociación entre diferentes entidades.

3.8.3 BASE DE DATOS RELACIONALES - SQL (STRUCTURED QUERY LANGUAGE –

LENGUAJE ESTRUCTURADO DE CONSULTAS)
Según R. Stanek(2001).
3.8.3.1 ESTRUCTURA BASICA
a. La claúsula SELECT
Corresponde a la operación proyección del álgebra relacional. Se usa para listar los
atributos deseados del resultado de una consulta.

SELECT nacionalidad FROM cliente

14
b. La claúsula FROM
La cláusula from corresponde a la operación producto cartesiano del álgebra relacional.
Lista las relaciones que deben ser analizadas en la evaluación de la expresión.

SELECT cliente.nombre, prestamo.cantidad FROM cliente, prestamo

c. La claúsula WHERE
La cláusula where corresponde al predicado selección del álgebra relacional. Es un
predicado que engloba a los atributos de las relaciones que aparecen en la cláusula from.
SQL usa las conectivas lógicas and, or y not en la cláusula where. Los operandos de las
conectivas lógicas pueden ser expresiones que contengan los operadores de comparación
<, <=, >, >=, = y <>. SQL permite usar los operadores de comparación para comparar
cadenas y expresiones aritméticas, así como tipos especiales, tales como el tipo fecha. SQL
incluye un operador de comparación between para simplificar las cláusulas where que
especifica que un valor sea menor o igual que un valor y mayor o igual que otro valor.

d. La operación renombramiento
SQL proporciona un mecanismo para renombrar tanto relaciones como atributos. Para ello
utiliza la cláusula as. la cláusula as puede aparecer tanto en select como en from.

e. Variables tupla
La cláusula as es particularmente útil en la definición del concepto de variables tupla. Una
variable tupla en SQL se debe asociar con una relación concreta. Las variables tupla se
definen en la cláusula from, se puede utilizar la cláusula as (es opcional).

f. Operaciones sobre cadenas

SQL especifica las cadenas encerrándolas entre comillas simple, como ‘Julio’. La
operación más usada sobre cadenas es el encaje de patrones, para el que se usa el operador
like. Para la descripción de patrones se utilizan los dos caracteres siguientes:
• Tanto por ciento (%): El carácter % encaja con cualquier subcadena.
• Subrayado (_): El carácter _ encaja con cualquier carácter.
Los patrones son muy sensibles, esto es, los caracteres en mayúsculas no encajan con los
caracteres en minúscula, o viceversa.
• ‘Nava%’ encaja con cualquier cadena que empiece con «Nava».

15
 • ‘%cer%’ encaja con cualquier cadena que contenga “uli” como subcadena, por ejemplo
‘julio’.
• ‘_ _ _’ encaja con cualquier cadena de tres caracteres.
• ‘_ _ _%’ encaja con cualquier cadena de al menos tres caracteres.

g. Orden en la presentación de las tuplas

SQL ofrece al usuario cierto control sobre el orden en el cual se presentan las tuplas de una
relación. La cláusula order by hace que las tuplas resultantes de una consulta se presenten
en un cierto orden.
SELECT C.nombre, P.cantidad FROM cliente as C, prestamo P WHERE
C.dni=P.dni AND P.cantidad BETWEEN 100 AND 150 ORDER BY C.nombre
De manera predeterminada la cláusula order by lista los elementos en orden ascendente.
Para especificar el tipo de ordenación se puede incluir la cláusula desc para orden
descendente o asc para orden ascendente. Además, se puede ordenar con respecto a más de
un atributo.
SELECT C.nombre, P.cantidad FROM cliente as C, prestamo P WHERE
C.dni=P.dni AND P.cantidad BETWEEN 100 AND 150 ORDER BY C.nombre ASC,
d.importe DESC

h. FUNCIONES DE AGREGACION
Las funciones de agregación son funciones que toman una colección (un conjunto o
ulticonjunto) de valores como entrada y producen un único valor como salida. SQL
proporciona cinco funciones de agregación primitivas:
• Media: avg
• Mínimo: min
• Máximo: max
• Total: sum
• Cuenta: count
Existen situaciones en las cuales se debe aplicar las funciones de agregación no sólo a un
único conjunto de tuplas sino también a un grupo de conjuntos de tuplas; esto se especifica
en SQL usando la cláusula group by. El atributo o atributos especificados en la cláusula
group by se usan para formar grupos. Las tuplas con el mismo valor en todos los atributos
especificados en la cláusula group by se colocan en un grupo.

16
 También se puede establecer condiciónes a los grupos. Esta condición no es aplicable a
una única tupla; se aplica a cada grupo construido por la cláusula group by. Para expresar
este tipo de consultas se utiliza la cláusula having de SQL.
select nombre-sucursal, avg (saldo)
from cuenta
group by nombre-sucursal
having avg (saldo) > 1200

i. VALORES NULOS
SQL permite el uso de valores nulos para indicar la ausencia de información sobre el valor
de un atributos. Se usa la palabra clave null para comprobar si un valor es nulo. Se usa is
not null para verificar valores no nulos

j. OPERACIONES SOBRE CONJUNTOS

La operación Unión
Select nombre_cliente from cliente UNION
Select nombre_cliente from prestatario
La operación unión elimina los duplicados automáticamente; pero si se desea conservar los
duplicados se debe usar UNION ALL.

La operación intersección
Select nombre_cliente from cliente INTERSECT
Select nombre_cliente from prestatario
La operación interseccion elimina los duplicados automáticamente; pero si se desea conservar
los duplicados se debe usar INTERSECT ALL.

La operación excepto
Select nombre_cliente from cliente EXCEPT
Select nombre_cliente from prestatario
La operación except (resta) elimina los duplicados automáticamente; pero si se desea conservar
los duplicados se debe usar EXCEPT ALL.

17
Pertenencia a conjuntos

SQL utiliza el cálculo relacional para las operaciones que permiten comprobar la pertenencia
de una tupla a una relación. La conectiva in comprueba la pertenencia a un conjunto, donde el
conjunto es la colección de valores resultado de una cláusula select.
select m.idestudiante from matricula m where m.idsemestre='2010-1' and m.
idestudiante='092188' and m.idestudiante in (select idestudiante from estudiante)
También es posible utilizar NOT IN.

Comparación de conjuntos
Compara un valor escalar con un conjunto de valores de una sola columna
Puede ser utilizando la constructora SOME, y realizar las siguientes comparaciones: <some,
<= some, >= some, = some y <> some.

Comprobación de relaciones vacías

SQL permite la posibilidad de comprobar si una subconsulta no produce ninguna tupla como
resultado. La constructora exists devuelve el valor verdadero si la subconsulta no es vacía. Se
utiliza la constructora exists.
Utilizando la constructora not exists se puede comprobar la inexistencia de tuplas en el
resultado de una subconsulta

k. MODIFICACIÓN DE LA BASE DE DATOS

Eliminar

Un borrado se expresa de igual modo que una consulta. Se pueden borrar sólo tuplas
completas, es decir, no se pueden borrar valores de atributos concretos. La estructura de la
operación eliminar es:

delete from r where P

Insertar
Para insertar datos en una relación, o bien se especifica la tupla que se desea insertar o se
formula una consulta cuyo resultado sea el conjunto de tuplas que se desean insertar.
Obviamente, los valores de los atributos de la tuplas que se inserten deben pertenecer al
dominio de los atributos. Se utiliza la instrucción insert.
Ejm:

18
insert into cuenta values (‘C-9732’, ‘Navacerrada’, 1200)
Actualizar
Sql permite cambiar un valor dentro de una tupla, sin cambiar todos los valores de la misma.
Para este tipo de situaciones se utiliza la instrucción update.
update cuenta set saldo = saldo * 1.05

l. VISTAS
Una vista es una tabla derivada de otras tablas (básicas o virtuales). Una vista se caracteriza
porque:
– Se considera que forma parte del esquema externo.
– Una vista es una tabla virtual (no tiene una correspondencia a nivel físico)
– Se puede consultar como cualquier tabla básica.
– Las actualizaciones se transfieren a la/s tabla/s original/es.
Una vista en SQL se define utilizando la orden create view. Para definir una vista se le debe
dar un nombre y se debe construir la consulta que genere dicha vista. La forma de la orden
create view es la siguiente:
create view v as <expresión de consulta>

m. DESENCADENADORES
Un desencadenador (Trigger) es un tipo especial de procedimiento almacenado que se activa
de forma controlada por sucesos antes que por llamadas directas. Los desencadenadores
(Triggers) están asociados a tablas. Son una gran herramienta para controlar las reglas de
negocio más complejas que una simple integridad referencial, los desencadenadores (Triggers)
y las sentencias que desencadenan su ejecución trabajan unidas como una transacción.

Las instrucciones de la definición del Desencadenador deben ser INSERT, UPDATE o

DELETE.

Un Desencadenador para inserción de registros genera automáticamente una tabla en el cache

con la información que intenta añadir, esta tablita se denomina INSERTED y es a través de
esta tabla que se pueden hacer comparaciones en otras tablas.

Un Desencadenador para eliminación de registros genera automáticamente una tabla en el

cache con la información que intenta eliminar, esta tablita se denomina DELETED y es a
través de esta tabla que se pueden hacer comparaciones en otras tablas. Si se trata de un

19
 Desencadenador para actualización se generan ambas tablas INSERTED con los nuevos datos
y DELETED con la información que será reemplazada
La sintaxis para la creación de triggers es la siguiente:
CREATE TRIGGER <trigger name>
FOR <INSERT|DELETE|UPDATE>
ON <relation name>
EXECUTE PROCEDURE <procedure name> (<function args>);

3.9 AGENTE RACIONAL

Russell & Norvig(2004) Un agente racional es aquel que actúa con la intención de alcanzar el
mejor resultado o, cuando hay incertidumbre el mejor resultado esperado. En cada posible
secuencia de percepciones, un agente racional deberá emprender aquella acción que supuestamente
maximice su medida de rendimiento, basándose en las evidencias aportadas por la secuencia de
percepciones y en el conocimiento que el agente mantiene almacenado.

3.10 AGENTES Y SU ENTORNO

Russell & Norvig(2004) Un agente es algo que razona, es cualquier cosa capaz de percibir su
medioambiente con la ayuda de sensores y actuar en ese medio utilizando actuadores. La Figura 1,
muestra esta idea.

Figura 3. Los agentes interactúan con el medio ambiente mediante sensores y efectores.

20
3.11 ESTRUCTURA DE LOS AGENTES

Russell & Norvig(2004) El trabajo de la IA(Inteligencia Artificial) es diseñar el programa del

agente que implemente la función del agente que proyecta las percepciones en las acciones. Se
asume que este programa se ejecutará en algún tipo de computador con sensores físicos y
actuadores, lo cual se conoce como arquitectura:

Agente = arquitectura + programa

El programa que se elija tiene que ser apropiado para la arquitectura. Si el programa tiene que
recomendar acciones como Caminar, la arquitectura tiene que tener piernas. La arquitectura
puede ser un PC común, o puede ser un coche robotizado con varios computadores, cámaras, y
otros sensores a bordo. En general, la arquitectura hace que las percepciones de los sensores
estén disponibles para el programa, ejecuta los programas, y se encarga de que los actuadores
pongan en marcha las acciones generadas.

3.12 AGENTE INTELIGENTE

El concepto de racionalidad se puede aplicar a una amplia variedad de agentes que operan en
cualquier medio imaginable. La idea es utilizar este concepto para desarrollar un pequeño
conjunto de principios de diseño que sirvan para construir agentes útiles, sistemas que se
puedan llamar razonablemente inteligentes. Stuart(2004)

3.13 PROPIEDADES DE LOS AGENTES INTELIGENTES

Según Crovetto (2005).
 Continuidad Temporal: El agente se debe estar ejecutando constantemente y desarrollando
sus funciones.
 Personalidad: Posee una personalidad creíble, bien definida, que hace fácil la interacción
con usuarios humanos.
 Autonomía: Si el agente se halla en un entorno cambiante es capaz de adaptarse y de tomar
decisiones dependiendo de sus experiencias.
 Sociabilidad: El agente interactúa con más agentes e incluso con otras entidades.
 Racionabilidad: El agente siempre hace lo correcto, a partir de los datos que recibe del
entorno.

21
  Adaptatividad: Se adapta con facilidad a las indicaciones de los usuarios y a los cambios
en el entorno en base de su experiencia.

3.14 CLASIFICACIÓN DE LOS AGENTES INTELIGENTES

 Agentes de Reflejo Simple.- Son agentes que funcionan de acuerdo a un conjunto de
reglas condición-acción
 Agentes informados de lo que pasa.- Es un agente capaz de ejecutar diversas acciones en
base de percepciones y acciones ejecutadas antes analizando el entorno no solamente en el
momento actual, sino también en momentos anteriores.
 Agentes basado en metas.- El agente necesita saber las metas que se requieren para
alcanzar, no es suficiente solamente con saber el estado actual del entrono en el que se
encuentre. El agente debe ser capaz de analizar la situación actual del entorno con todas las
posibles acciones que se pueden ejecutar y de este modo seleccionar la acción que más le
convenga para lograr las metas de una manera más sencilla.
 Agentes de monitoreo.- Estos agentes brindan información de modo eficaz y oportuno
para el usuario, en el momento en que ocurre el evento.
 Agentes de recomendación.- Este agente tiene una base de datos con información sobre
un tópico de interés para un grupo, al hacer las recomendaciones se fundamentan en
analogías con otros usuarios de un perfil similar.
 Agentes híbridos.- Son aquellos cuya constitución es una combinación de dos o más
filosofías de agentes para conseguir un agente único. Para el desarrollo de determinadas
aplicaciones el tener una arquitectura de agentes híbridas podrá ser de ayuda si se desea
tener mayores beneficios de la arquitectura, pues se aprovecha lo mejor de cada agente.
 Agentes heterogéneos.- Los sistemas de agentes heterogéneos unen diferentes clases de
agentes y pueden contener uno o más clases de agentes híbridos

3.15 TAXONOMÍA DE LOS AGENTES

Según Crovetto (2005).
Sistemas de agentes individuales Sistemas multi-Agente
Agentes Agentes de Red Agentes Agentes móviles
Locales basados en
DAI
Asistentes Agentes, Resolución Telecomunicaciones,
personales, Recuperadores de distribuida Manejo de redes,

22
 Asistente Información, de Servicios sobre
de Automatización de Problemas. demanda de
Consejo. procesos. Mercado
Electrónico.

 Agentes locales.- Los agentes de esta clase acceden sólo a recursos locales. El objetivo de
dichos agentes es colaborar con el usuario, por eso el énfasis en la investigación es el
campo de interacción usuario/agente. Por otro lado, este tipo de agente se ha llamado
también Agente de Interaz o Interfaz Inteligente.

Los agentes locales podrán asistir al usuario de diferentes formas: ejecutan tares en nombre
del usuario, oculta la complejidad de tareas difíciles, actúa asincrónicamente o aprende y
enseña al usuario. La cantidad de tareas que el usuario podría asistir es virtualmente
ilimitada

 Agentes de Red.-Los agentes de red pueden acceder no sólo a recursos locales sino
también a los remotos, y que tienen un conocimiento de la estructura de la red y también de
los servicios disponibles dentro de la red. La principal diferencia que hay entre esta clase
de agente y los sistemas multiagentes, está en que los agentes de red no asumen la
cooperación con otros agentes.
 Agentes basados en DAI(Inteligencia Artificial Distribuida).- La preocupación
principal en los sistemas multiagente que se basan en DAI es la coordinación entre un
conjunto de agentes autónomos inteligentes, como por ejemplo, como coordinan ellos sus
objetivos, habilidades, conocimiento, como planifican la realización de tareas o como
solucionan problemas. Estos agentes se implementan a través de técnicas de IA, como
sistemas que se basan en reglas, ejemplos que se basan en razonamiento. Las
representaciones aplicadas al conocimiento así como los mecanismos de inferencia son
iguales a los usados en los sistemas basados en conocimiento (no-distribuidos). En los
sistemas multi-agente que se basan en DAI un agente se puede comunicar con el usuario,
los recursos del sistema y con otros agentes y cooperar en la realización de tareas, dicha
cooperación se hace por medio de un protocolo de contratación que garantiza la
negociación entre agentes.
 Agentes móviles.- Los agentes móviles se encuentran orientados a brindar gran número de
servicios sofisticados dentro de grandes redes de computadoras. Los agentes de esta clase
se implementan con lenguajes scripting: TLC, Java, Telescript.

23
3.16 METODOLOGÍA PROMETHEUS

Padgham & Winikoff (2004) La metodología Prometheus define un proceso detallado para la
especificación, diseño, implementación y prueba / depuración de sistemas de software
orientado a agentes. Además define una serie de artefactos que se producen a lo largo del
camino. Algunos de estos artefactos se mantienen, y algunos sólo se utilizan como "puentes".
Algunos de los artefactos son gráfica, mientras que otros son de texto estructurado (por
ejemplo, las formas). La metodología Prometheus consta de tres fases, representadas en la
Figura 4.

Figura 4: Esquema de la Metodología Prometheus

 La fase de especificación del sistema se centra en la identificación de los objetivos y la función

básica- realidades del sistema, junto con las entradas (percepciones) y salidas (acciones).
 La fase de diseño arquitectónico utiliza las salidas de la fase anterior para determinar qué tipo
de agente el sistema contendrá y cómo van a interactuar.
 La fase de diseño detallado, se ve la parte interna de cada agente y la forma en que debe
cumplir su función dentro del sistema general.

24
I. Fase de especificación
a. La identificación de los objetivos del sistema.
Las razones para la construcción del sistema debe ser siempre el centro del
pensamiento cuando especificamos el sistema. El uso de la fase de especificación del
sistema facilita una correspondencia en el diseño detallado más adelante y la ejecución,
así como proporcionar un mecanismo adecuado para los requisitos de especificación.
 Identificar las metas iniciales
La breve descripción inicial del sistema por lo general contiene algunas
indicaciones implícitas del sistema objetivo, qué es lo que se supone que el
sistema debe hacer. Estos proporcionan un punto de partida para la
construcción de una lista inicial de los objetivos del sistema.
 Meta Perfeccionamiento
Ahora refinar estos objetivos con la técnica de preguntar ¿cómo?
Consideramos cada meta y preguntar "¿cómo podría esta meta lograr ";? las
respuestas dan los sub-objetivos de la meta en cuestión. Sería posible utilizar
también las técnicas de extracción de preguntar "¿por qué? ', para construir un
árbol meta mucho más completa. Sin embargo, tenemos optado por limitar el
conjunto de metas a las que se derivan más directamente. A medida que
refinamos los objetivos originales para ser un poco más específico, es a
menudo el caso de que nos encontramos con sub-metas similares que surjan en
diferentes objetivos iniciales.

b. Desarrollar escenarios de casos de uso que ilustran el funcionamiento del sistema.

Los escenarios son complementarios a los objetivos en que se muestran las secuencias
de pasos que se llevará a cabo dentro del sistema. En los objetivos de desarrollo,
estamos construyendo escenarios hasta de cómo estos objetivos serán parte de diversos
procesos en el sistema.
Los escenarios nos permiten especificar parte de esta estructura, que a su vez puede
ayudar a identificar objetivos faltantes.
Los escenarios se utilizan principalmente para ilustrar el funcionamiento normal del
sistema, aunque también puede ser útil para desarrollar algunos escenarios que indican
lo que se espera que suceda cuando algo sale mal. A medida que se desarrollaron
escenarios, se hace evidente cuando hay una necesidad de información del entorno (es
decir, las percepciones) y donde las acciones son obligatorios. También, como se

25
 desarrollan escenarios, es común para identificar objetivos adicionales que son
necesarios.

c. Identificar las funciones básicas del sistema.

Consiste en una agrupación de las metas relacionadas, así como perceptos, las acciones
y los datos relacionados con el comportamiento. La funcionalidad debe ser coherente,
en el que se puede describir adecuadamente en uno o dos frases, y puede ser
identificado de una manera que captura su esencia. Las funcionalidades permiten
una mezcla de diseño top-down y bottom-up. Al mismo tiempo, proporcionan un
mecanismo ascendente para la determinación de los tipos de agentes y sus
responsabilidades. El proceso de refinación y metas agrupación sugiere un conjunto
inicial de funcionalidades. Seguir trabajando con los escenarios y el desarrollo de la
especificación también puede sugerir las especificaciones adicionales del sistema es un
proceso iterativo, a partir de identificación de objetivos.

d. Especificación de la interfaz entre el sistema y su medio ambiente en términos de

acciones y percepciones.
Los sistemas de agentes se encuentran típicamente en un entorno cambiante y
dinámico que puede ser afectada, aunque no totalmente controlada, por el sistema de
agente. Una de las primeras preguntas que deben ser respondidas es, cómo es el
sistema de agente va a interactuar con el medio ambiente?; ¿y qué hará el sistema
agente para interactuar con el medio ambiente?

PERCEPCIONES Y ACCIONES

Las percepciones a menudo requieren algún tipo de procesamiento con el fin de extraer
la información que es de valor para el sistema de agente. Por ejemplo, marcos de visión
de una cámara robot no son en ellos mismos lo que el sistema de agente tiene que
razonar, primero deben ser procesados tanto para extraer los datos simbólicos, tales
como 'bola en 15, 10; robot en 25, 70' y para extraer información relevante a partir de
estos datos simbólicos. Si hay un flujo de datos entrantes, el sistema de agente puede
querer reaccionar sólo cuando hay un evento de cierta importancia, a menudo
determinado por el cambio de la situación anterior. En la planificación y el diseño del
sistema de agentes en torno a las percepciones, el diseñador debe tener en cuenta cómo
se obtienen los datos, no sólo llegar, así como la naturaleza exacta de los datos, y en

26
 qué medida pueden ser procesados para proporcionar información de interés. Es
extremadamente importante para investigar y el experimento desde el principio con la
naturaleza exacta de las percepciones disponibles para el sistema. En sistemas en los
que se originan a partir de las percepciones recibidas de dispositivos de detección
físicas de algún tipo, los datos a menudo contienen cantidades significativas de ruido,
que puede requerir el uso de técnicas para filtrar y limpiar los datos. Esto se puede
hacer fuera del sistema de agente, sin embargo, estas cuestiones deben ser consideradas
cuidadosamente en la fase de diseño y el desarrollador debe establecer exactamente lo
que es posible proporcionar como percepciones en el sistema.
Las acciones también pueden ser complejas, lo que requiere el diseño y un desarrollo
exterior al ámbito del sistema, posiblemente incluyendo el monitoreo de fracaso o
continuo bucle de retroalimentación.

DATOS
A medida que se desarrollaron escenarios y funcionalidades, también es importante
tener en cuenta los datos que son parte de estos. Durante el desarrollo de las funciones
y los escenarios se observa tanto en los datos que se producen y datos que se utiliza. En
la fase de especificación del sistema, tenemos que tener en cuenta sobre todo los datos
externos del sistema de agente, ya que esto forma parte de la interfaz y se debe
especificar en esta etapa. Otra parte de la interfaz de sistema que puede ser necesario es
especificar la interacción con cualquier otro software.

II. Fase de diseño arquitectónico

a. La decisión sobre los tipos de agentes utilizados en la aplicación
La decisión más importante en el diseño de la arquitectura es que tipo de agentes el
sistema incluirá. Se evaluarán diferentes opciones utilizando los criterios de
acoplamiento y cohesión. Cada agente debe ser cohesivo, en la que puede ser descrito
con un título corto. El sistema de agentes debe ir acompañado o libremente como sea
posible. Es preferible tener un sistema en el que cada agente tiene que saber acerca de
sólo un número limitado de otros agentes dentro del sistema.
Las etapas de este proceso son:
1. Grupo de funcionalidades en agentes considerando agrupaciones alternativas.

27
 Dada una colección de funcionalidades, es evidente que hay muchas maneras en
las que pueden estar agrupados los agentes. En un extremo, cada funcionalidad
podría corresponder a un diferente agente. Esto no es deseable, los agentes llegan a
tener funcionalidades estrechamente relacionados, lo que conduciría a un alto
grado de dependencia, o de acoplamiento, entre los agentes. En el otro extremo,
todas las funcionalidades que se podrían agrupar en un solo agente. Esto no es
deseable poque agrupa las funciones no relacionadas.

2. Revisión de acoplamiento
Uno de los criterios de diseño es apuntar a un sistema que se acopla tan libremente
como sea posible. No queremos que todos los agentes tienen que saber sobre todos
los demás agentes.
Con el fin de evaluar una agrupación potencial para el acoplamiento, se utiliza un
conocido agente diagrama. Este diagrama representa cada uno de los tipos de
agente. Información sobre el agente interacción se extrae de los descriptores de la
funcionalidad y cada agente está vinculado con los otros agentes que interactúa.

3. Desarrollar descriptores de agentes.

• ¿Cuántos agentes de cada tipo habrá?
• ¿Cuál es la vida útil de cada agente? Si se crean o se destruyen los agentes
durante el funcionamiento normal funcionamiento del sistema.
Cada tipo de agente debe tener un descriptor agente que contiene el la
información más el nombre del agente, descripción de lo que este agente hace
dentro del sistema y una lista de las funcionalidades de la fase anterior que son
incorporado dentro de este agente.
Además, la siguiente información tambien se convierte en una parte del
descriptor de agente:
• ¿Cuáles son los objetivos de este agente?
• ¿Qué percepciones hará a este agente reaccionar?
• ¿Qué acciones (en su caso) va a tomar?
• ¿Qué datos utiliza este agente?

b. Describir la interacción entre los agentes que utilizan diagramas de interacción y

protocolos de interacción

28
Una vez que se deciden los tipos de agentes, el siguiente aspecto del diseño
arquitectónico es especificar la interacción entre los agentes, la captura de las
dinámicas de los aspectos del sistema. Esto construye en ambos los tipos de agente y
también en los descriptores de escenario de la especificación del sistema.

1. Desarrollar diagramas de interacción de los escenarios

Los diagramas de interacción son tomados directamente de diseño orientado a
objetos, pero muestran interacción entre los agentes y no como objetos. El proceso
de elaboración de diagramas de interacción
es tomar los escenarios desarrollados en la fase de especificación y construir
correspondiente diagramas de interacción.
Esto implica: sustitución de cada funcionalidad con el agente que lo incluye,
comunicación entre los agentes donde se necesita y después, expresar el resultado
como un diagrama de interacción

2. Generalizar diagramas de interacción de los protocolos de interacción

Como con escenarios, esperamos tener sólo un conjunto representativo de
diagramas de interacción, no un sistema completo. Para tener interacciones
completas y precisamente definidas. Dado que los protocolos deben mostrar todas
las variaciones, que son a menudo más grande que el diagrama de interacción
correspondiente y pueden necesitar ser dividido en trozos más pequeños. Con el fin
de dar un ejemplo de desarrollo de un protocolo de interacción completa, se
necesitará una notación para describir protocolos de interacción. Desde protocolos
de interacción incluyen secuenciación, opciones, iteración y otras estructuras de
control, la notación tiene que ser muy expresivo. Existe una serie de anotaciones
para los protocolos que describen como actividad UML diagramas, AUML
(Agente UML) (Odell et al . 2000).

3. Desarrollar protocolos y el mensaje descriptores

Al igual que con cada una de las entidades de diseño final en el sistema, tenemos
descriptores para los protocolos y para los mensajes. Los descriptores permiten
reunir la información existente en otros lugares y también para especificar detalles
adicionales sobre la entidad particular.
La plantilla que se utiliza para el descriptor de protocolo es el siguiente:

29
 • Nombre
• Descripción - breve descripción en lenguaje natural
• Escenarios - Listas de los escenarios que se incluyen en este protocolo
• Agentes - listas de los agentes implicados en el protocolo
• Mensajes - Listas de los mensajes implicados en el protocolo
• Notas - y otros datos diversos
Durante el desarrollo del protocolo, se han identificado una serie de mensajes, que
son los mensajes entre agentes en el sistema. En algunos casos, no son mensajes
entre agentes que no requieren de un protocolo. En el diseño detallado, también
habrá otros mensajes internos añadido al diseño.
Los descriptores para mensajes necesitan claramente contener información sobre el
mensaje. También es útil para indicar el fin del mensaje, que puede ser, por
ejemplo, para transferir el control a otro agente o funcionalidad, para solicitar un
servicio, o para actualizar la información.
Los campos en nuestra plantilla descriptor para los mensajes son los siguientes:
• Nombre - breve identificador
• Descripción - descripción del lenguaje natural que contiene toda la
información relevante
• Desde agente
• Para agente
• Propósito - por ejemplo, actualización de datos, servicio de petición, de
control de transferencia, y así sucesivamente
• Información realizó - lo que los campos de información transmitirán este
mensaje.

III. Diseñar la estructura general del sistema

Después de haber especificado los agentes dentro del sistema y las comunicaciones entre ellos,
ahora reunir esta información en un Diagrama general del sistema, que captura
esquemáticamente la arquitectura general del sistema de agente. Con el fin de hacer esto,
también la necesidad de desarrollar un entendimiento más completo de los datos necesarios, así
como información que se atiendan del medio ambiente y las acciones que el agente puede
tomar dentro del medio ambiente.

30
a. Identificar los límites del sistema de agentes y las interacciones con otros
subsistemas
Los sistemas de agentes siempre están operando dentro de algún medio ambiente, y por
lo tanto la especificación de las interfaces con el medio ambiente son muy importantes.
Los límites del sistema agente puede ser el entorno físico, pero también son muy
propensos a ser los límites software donde el sistema de agente forma parte de una
aplicación más grande.
Una parte de la interfaz es la información acerca del medio ambiente, que hemos
denominado percepciones . Dependiendo de la aplicación, los datos brutos desde el
entorno puede requerir un procesamiento significativo con el fin de ser de cualquier
uso a los agentes del sistema. Puede ser más apropiado para este procesamiento que se
lleve a cabo
en un sub-sistema de no-agente, que se incorporan dentro de un agente.

b. Describir las percepciones y acciones

En este paso, desarrollamos descriptores para la entrada y las entidades de interfaz de
salida, perceptos y las acciones, y vincularlos con los agentes pertinentes.
Las percepciones son la información (posiblemente procesado) que el agente recibe del
medio ambiente, mientras que las acciones representan los efectos que el agente puede
tener en el exterior medio ambiente. Se discuten estos, la identificación de cuestiones a
tener en cuenta y proporcionar una plantilla para el registro de información importante
para entender el diseño

c. Definición de los datos compartidos

Durante la etapa de especificación de sistema, se ha identificado los datos persistentes.
Ahora se debe tomar decisiones sobre qué tipo de almacenes de datos persistente se
utilizarán – una base de datos o un archivo y anteriores ideas sobre qué datos artículos
se agruparán juntos en un almacén de datos solo deben ser confirmadas y
desarrollados. También debe determinarse si habrá algún dato compartido dentro del
sistema, accesibles a más de un agente. Un buen diseño será minimizar esto, pero
puede haber situaciones en las que es razonable tener los objetos de datos compartidos.
Si varios agentes van a escribir a los objetos de datos compartidos, esto requerirá
atención adicional para la sincronización (como agentes operan simultáneamente con

31
 otros). Debe prestarse atención en cuanto si esto puede resultar potencialmente en
estados de datos incoherentes que contiene partes de dos versiones diferentes. Esto
dependerá en parte de detalles del entorno de ejecución. Pueden utilizar formas
simples de bloqueo. No discutimos más bloqueo aquí ya que es un tema estándar de
programación concurrente. Sin embargo, es importante asegurarse de que los bloqueos
son liberados tanto en el éxito y fracaso.

d. Desarrollar el diagrama general del sistema

Hay dos artefactos que recopilan esta información el diagrama general del sistema y el
diccionario de datos.
El diagrama general del sistema es sin duda el único artefacto más importante de todo
el proceso de diseño, aunque, por supuesto, en realidad no puede entenderse
plenamente en aislamiento.
Los diversos descriptores proporcionan la información más detallada que pueda ser
necesaria. Los símbolos utilizados en el diagrama de visión general del sistema se
muestran en la Figura 7.1.

Figura 7.1 Símbolos gráficos utilizados en el diagrama general del sistema

IV. Diseño Detallado

El diseño detallado se centra en el desarrollo de la estructura interna de cada uno de los agentes
y cómo se va a lograr sus tareas dentro del sistema.

32
 En esencia, progresivamente refinar cada agente mediante la definición de las capacidades
(módulos en el agente), eventos internos, planes y estructuras de datos detallados.
• El perfeccionamiento de los agentes en términos de capacidades, dando la visión agente de dia-
gramo y los descriptores de capacidades; y
• El desarrollo de las especificaciones del proceso

IV. ANTENCEDENTES

4.1 A nivel internacional

Sergio Antonio Becerra Zepeda, “Bases de Datos Inteligentes”, Universidad de Colima, Mexico,
1999. El problema observado en esta investigación es la necesidad de incorporar herramientas que
permitan acceder y manipular eficientemente las colecciones de datos que distinguen a las nuevas
tecnologías de información. El objetivo es desarrollar un conjunto de herramientas para la
construcción de aplicaciones de Bases de Datos que operen a un nivel de abstracción superior al de
los manejadores de BDs actuales, este nivel de abstracción combinado son sus posibilidades de
integración con otras herramientas permitirá la creación de ambientes inteligentes orientados a
usuarios finales que combinen las tecnologías de bases de datos, bases de conocimiento,
programación orientada a objetos, e interfaces intuitivas para usuarios finales. La muestra no está
definida, solo indica la implementación de las operaciones realizadas. Los SGBD Inteligentes no
existen como tales, por lo que en la arquitectura de una base de datos inteligente intervienen
múltiples factores, sin embargo en el estudio enfocado al desarrollo de un sistema inteligente de
base de datos, se distingue como objetivo de la interfaz: proporcionar consejo y apoyo a la toma de
decisiones, ofrecer opiniones informadas y explicación de sus razonamientos, además permitir
manipular grandes volúmenes de información, para ello el desarrollo de de una Base de datos
Inteligente sobre un motor relacional consiste en: Una Base de Datos relacional la base principal
en la que se concentra en diversas tablas el total de datos útiles del sistema, una base de
Conocimiento dinámica. Base en intenso, constituida de selección de tuplas involucradas en un
proceso de inferencia particular, módulos de Preproceso Enfocados al tratamiento de los datos
inciertos en la base persistente, una base de reglas. Estructuran los procesos de inferencia en
marcos de operación determinados, módulos de acceso binario. Cuando intervienen procesos de
selección y filtrado para los que no se estructura un campo clave, precisamos de archivos binarios a
los que el sistema accede en forma eficiente y rápida.
La inteligencia en una Base de datos, no está necesariamente relacionada con la estructura de la
Base de Datos, sino en la explotación que el sistema pueda hacer de éstos. Se concluye que las

33
 Base de Datos Inteligentes, permiten una serie de ventajas de gran interés, sobre todo en el proceso
de toma de decisiones, al transformar la información en conocimiento al proveer mecanismos
automáticos para el análisis, organización y síntesis de información.

4.2 A Nivel Nacional

Fernando Agustín Ramírez Icaza, “Agentes Inteligentes de Software o Softbots”, Universidad de
Lima, Perú, 2003. El problema observado en esta investigación es que los softwares de hoy no
actúan con inteligencia, no toman decisiones por iniciativa propia ni aprenden de su interacción
con el usuario. El objetivo es sustentar que los Agentes Inteligentes pueden ser considerados como
una herramienta de abstracción para la resolución de problemas que requieran tomar decisiones de
forma autónoma e inteligente, proponiendo las bases de una futura metodología Basada en agentes
Inteligentes de Software. La muestra está definida en la aplicación de esta metodología en la
aplicación de un escenario basado en transacciones comerciales entre viajeros y agentes que
ofrecen paquetes turísticos. Esta nueva metodología consta de 5 pasos: Identificación de agentes
inteligentes de software, Identificación de ambientes, Análisis y Diseño de la Arquitectura del
Softbot, Clasificación del agente inteligente de Software, Identificación de los axiomas de la Base
del Conocimiento.
El resultado observado en el caso práctico, fue la adaptabilidad de esta nuevo enfoque al problema
presentado demostrando la factibilidad de la aplicabilidad con respecto a los problemas del mundo
real del uso de esta nueva metodología. Se concluye que los agentes inteligentes de Software
aprenden a lo largo de la interacción con el medio ambiente y constar de autonomía e inteligencia
para tomar la mejor decisión en el momento indicado.

V. HIPÓTESIS
5.1 HIPÓTESIS PRINCIPAL
Si aplicamos el modelo Relacional usando un agente inteligente entonces se minimiza el tiempo de
recuperación de datos, en las bases de datos de la UNAMBA.

5.2 HIPÓTESIS ESPECÍFICAS

 SI aplicamos un agente inteligente entonces, se reducirá el tamaño de los campos en la BD de
la dirección de Servicios académicos de la UNAMBA 2013.
 Si aplicamos un agente inteligente entonces, se elimina los errores de actualización de datos en
las bases de datos de la UNAMBA.

34
 VI. OBJETIVOS
6.1 OBJETIVO GENERAL
Reducir el tiempo de recuperación de información en las consultas usando un agente
inteligente en el modelo relacional en la BD de la dirección de Servicios académicos de la
UNAMBA.

6.2 OBJETIVOS ESPECIFICOS

 Reducir el tamaño de los campos usando un agente inteligente en el modelo relacional en la
BD de la dirección de Servicios académicos de la UNAMBA 2013.
 Eliminar los errores de actualización de datos usando un agente inteligente en la BD de la
dirección de Servicios académicos de la UNAMBA.

VII. MATERIALES Y MÉTODOS

7.1 ÁMBITO Y LUGAR DE ESTUDIO
Abancay es la capital del departamento de Apurímac. La Universidad Nacional Micaela Bastidas
de Apurímac se encuentra en el cercado de la ciudad, en la Av. Arenas 121, la Dirección de
Servicios Académicos se encuentra en el 2do nivel.

7.2 POBLACIÓN Y MUESTRA

La población está conformada por la Base de Datos del sistema Académico que se maneja en la
Dirección de Servicios Académicos. Esta Base de Datos está conformada por 210 consultas.
La muestra será igual a la población en este trabajo de investigación.

7.3. DESCRIPCIÓN DEL MÉTODO POR OBJETIVOS ESPECÍFICOS

a. Para reducir el tiempo de recuperación de información en las consultas usando un agente
inteligente en la BD.

Frecuencia temporal requerida para la toma de datos.

 Se implementa el agente inteligente.

 Se utilizará un cuaderno de registro durante el proceso de manipulación de datos para los
dos tipos de base de datos: el que usa un agente inteligente y el que no utiliza un agente
inteligente.
 Se crean las tablas en los dos tipos de BD.
 Se ingresa datos en los dos tipos de BD.

35
  Se recupera mediante consultas la información de los dos tipos de BD.
 Se comparará los resultados registrados en los instrumentos aplicados para verificar la
reducción de tiempo en la recuperación de información.

Materiales y equipos a ser utilizados.

Agente inteligente, Gestor de BD, PC.

Prueba Estadística
Formulación de la Hipótesis
̅𝟐 = 𝑿
𝑯𝟎 : 𝑿 ̅ 𝟏 [La media del tiempo de recuperación de información en las consultas
usando un agente inteligente es igual al gestor de BD que no usa agentes inteligentes]
̅𝟐 < 𝑿
𝑯𝟎 : 𝑿 ̅ 𝟏 [La media del tiempo de recuperación de información en las consultas
usando un agente inteligente es menor al gestor de BD que no usa agentes inteligentes]
Prueba estadística
Prueba de medias de dos grupos dependientes.
̅ − 𝒖𝟎
𝒙
𝒁= 𝝈
√𝒏
Nivel de Significancia
5%=0.05
Región Crítica

Si Z C(0) > Z T(0) entonces se rechaza la hipótesis nula, caso contrario se acepta la hipótesis
nula.

b. Para optimizar la definición de campos usando un Agente Inteligente en el modelo

Relacional en la BD.

Frecuencia temporal requerida para la toma de datos.

 Se implementa el agente inteligente.

36
 Se utilizará un cuaderno de registro durante el proceso de manipulación de datos para los
dos tipos de base de datos: el que usa un agente inteligente y el que no utiliza un agente
inteligente.
 Se crean las tablas en los dos tipos de BD.
 Se ingresa datos en los dos tipos de BD.
 Se comparará los resultados registrados en los instrumentos aplicados para verificar la
reducción del tamaño en kb de la tablas.

Materiales y equipos a ser utilizados.

Agente inteligente, Gestor de BD, PC.

Prueba Estadística

Formulación de la Hipótesis
̅𝟐 = 𝑿
𝑯𝟎 : 𝑿 ̅ 𝟏 [La media del tamaño de las tablas del gestor de BD usando un agente
inteligente es igual al gestor de BD que no usa agentes inteligentes]
̅𝟐 < 𝑿
𝑯𝟎 : 𝑿 ̅ 𝟏 [La media del tamaño de las tablas del gestor de BD usando un agente
inteligente es menor al gestor de BD que no usa agentes inteligentes]
Prueba estadística
Prueba de medias de dos grupos dependientes.
̅ − 𝒖𝟎
𝒙
𝒁= 𝝈
√𝒏
Nivel de Significancia
5%=0.05
Región Crítica

Si Z C(0) > Z T(0) entonces se rechaza la hipótesis nula, caso contrario se acepta la
hipótesis nula.

37
c. Para eliminar los errores de actualización de datos usando un agente inteligente en la BD.

Frecuencia temporal requerida para la toma de datos.

 Se implementa el agente inteligente.

 Se utilizará un cuaderno de registro durante el proceso de manipulación de datos para los
dos tipos de base de datos: el que usa un agente inteligente y el que no utiliza un agente
inteligente.
 Se crean las tablas en los dos tipos de BD.
 Se ingresa o actualiza los datos en los dos tipos de BD.
 Se verifica que la actualización en los datos se realizado correctamente.
 Se comparará los resultados registrados en los instrumentos aplicados para verificar que
se hayan actualizado correctamente los datos.

Materiales y equipos a ser utilizados.

Agente inteligente, Gestor de BD, Método Drag drop, PC.

Prueba Estadística

Formulación de la Hipótesis
̅𝟐 = 𝑿
𝑯𝟎 : 𝑿 ̅ 𝟏 [La media de la cantidad de errores encontrados usando agentes
inteligentes es igual al gestor de BD que no usa agentes inteligentes]
̅𝟐 < 𝑿
𝑯𝟎 : 𝑿 ̅ 𝟏 [La media de la cantidad de errores encontrados usando agentes
inteligentes es menor al gestor de BD que no usa agentes inteligentes]
Prueba estadística
Prueba de medias de dos grupos dependientes.
̅ − 𝒖𝟎
𝒙
𝒁= 𝝈
√𝒏
Nivel de Significancia
5%=0.05
Región Crítica

38
 Si Z C(0) > Z T(0) entonces se rechaza la hipótesis nula, caso contrario se acepta la hipótesis
nula.

7.4 OPERACIONALIZACIÓN DE VARIABLES

VARIABLE DIMENSION INDICADOR ESCALA

Variable Independiente Modelo de SQL:2011 Si/No
Modelo de Base de datos Datos
basado en agente inteligente
Agente Metodología Si/No
Inteligente Prometheus
Variable dependiente definición de Tamaño de Kb
Reducir Tiempo de campo tabla
recuperación de información
en las consultas. Tiempo de Seg
Consulta recuperación

Cantidad de Número de
Errores de errores errores
actualización

39
 VIII. CRONOGRAMA DE ACTIVIDADES
8.1 PROGRAMACIÓN DE ACTIVIDADES

Actividades Meses
Set Oct Nov Dic Ene Feb Mar Ab May
Fase de especificación X X

Fase de diseño X X
arquitectónico

Diseñar la estructura X X
general del sistema

Diseño Detallado X X

Creación de BD, ingreso X

de datos y consultas de
recuperación de
información.

Análisis de resultados X

Desarrollo de Informe X
Final

40
 IX. PRESUPUESTO

Rubro Cantidad Unidad de medida Costo Unitario S/. Costo Total S/.
Material de escritorio

Papel Bond A4 2 Millar 30 60

Fólder Manila 25 Unidad 0,5 12,5

Lapiceros 10 Unidad 0,5 5

Bienes

Computadora 1 Unidad 2000 2000

Personal

Impresora Láser 1 Unidad 450 450

Tóner 1 Unidad 200 200

Memoria USB 4GB 2 Unidad 30 60

CD-DVD Simple 50 Unidad 1 50

Servicios

Imprevistos 200 Servicios 1 200

Uso de Energía 70 Mes 9 630

eléctrica

Uso del Internet 120 Mes 9 1080

TOTAL S/. 4747,5

41
 X. BIBLIOGRAFÍA
 Silberschatz, Abraham. F. Korth, Henry. Sudarshan. 2002. “FUNDAMENTOS DE BASES
DE DATOS”4ta edición. Editorial McGRAW-HILL, Madrid, España
 Elmasri, Ramez. Navathe Shamkant. 1994. “SISTEMAS DE BASE DE DATOS” 2da edición.
Editorial Addison-Wesley, Mexico.
 Date, C.J. 2001. “INTRODUCCIÓN A LOS SISTEMAS DE BASES DE DATOS” 7ma
edición. Editorial Pearson.
 Rob, Peter. Coronel, Carlos. 2006. “SISTEMAS DE BASES DE DATOS” 5ta edición.
Editorial Thomson.
 Wesley Longman, Addiso. 2001. “INTRODUCCIÓN A LOS SISTEMAS DE BASE DE
DATOS”, 7ma edición. Editorial Pearson.
 Delaney, Kalen. (2001) “A FONDO MICROSOFT SQL SERVER” 1era Edición. Editorial
Mc Graw Hill.
 R. Stanek, William (2001) “SQL SERVER 2000 MANUAL DEL ADMINISTRADOR”
Editorial Mc Graw Hill.
 Crovetto Huerta, Chirstian (2005) “INTELIGENCIA ARTIFICIAL E INTRODUCCIÓN A
LA ROBÓTICA” Editorial Megabyte.
 J. Russell, Stuart. Norvig, Peter.(2004) “INTELIGENCIA ARTIFICIAL UN ENFOUE
MODERNO” 2da edición. Editorial Pearson.Editorial Pearson.
 Padgham, Lin. Winikoff, Michael. (2004) “Developing Intelligent Agent Systems” Editorial
John Wiley & Sons.
 Ruiz Gonzalez, Francisco. 2000. “ARQUITECTURA DE SISTEMAS DE BASE DE
DATOS”. UNIVERSIDAD DE CASTILLA LA MANCHA.
 Enriquez, Erica Isabel. 2007. “SQL Server 2000”. Universidad Nacional del Nordeste.

42