Iinini

Modelos Alternativos de Bases de Datos 1
Profesor:
Prof. Mauricio Arturo Reyes Hernández
Integrantes:
 Juan Pablo Badal Arias
Materia:
Modelos Alternativos de Bases de Datos
Fecha: 11/06/2019
División Académica: Informática y Sistemas
Carrera Profesional: Licenciado en Sistemas Computacionales
Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Índice
Contenido
Introducción ...................................................................................................................................................... 6
2.5. Bases de Datos Geográficas....................................................................................................................... 8
Propósito ...................................................................................................................................................... 10
Aplicaciones en Sistemas de Información Geográfica (SIG) ................................................................... 10
Arquitectura de funcionalidad ................................................................................................................... 13
Ejemplo práctico 1: Sistema Georreferenciada de Información Cafetera – SICA ............................... 14
Ejemplo práctico 2: Sistema de Finanzas Castilla ................................................................................... 18
Ejemplo de PostGis Mapeo ........................................................................................................................ 23
Creación de una Tabla Espacial la manera fácil ............................................................................... 26
Conocer pgAdmin III ................................................................................................................................ 29
Ejecutar una consulta SQL desde pgAdmin III .................................................................................. 31
Creación de una Tabla Espacial ............................................................................................................ 32
2.6. Bases de Datos Temporales ..................................................................................................................... 35
Propósito ...................................................................................................................................................... 38
Aplicación..................................................................................................................................................... 38
Ejemplo práctico 1: Bernardo .................................................................................................................... 40
Ejemplo práctico 2: Interfaz para la Gestión de Bases de Datos Temporales (IGBDT) ...................... 44
CREANDO TABLAS TEMPORALES EN SQL SERVER .................................................................... 48
Indexando Tablas Temporales de SQL Server ........................................................................................ 52
2.7. Bases de Datos Seguras ........................................................................................................................... 57
Propósito ...................................................................................................................................................... 64
Ejemplo práctico 1: Cifrado transparente de datos (TDE) para el espacio de trabajo de revisor en
SQL Server. ................................................................................................................................................. 68
Ejemplo práctico 2: Seguridad de la bases de datos de tipo PostgreSQL .............................................. 71

2.8. Bases de Datos Difusas ............................................................................................................................ 79

Propósito ...................................................................................................................................................... 83
Aplicación..................................................................................................................................................... 83
Ejemplo práctico 1: Sistema de inferencia de control difuso .................................................................. 88
Ejemplo práctico 2: Implementación de una base de datos relacional difusa. Caso práctico: tutoría
académica. .................................................................................................................................................... 91
2.9. Almacenes de Datos ............................................................................................................................... 101
Propósito .................................................................................................................................................... 104
Arquitectura de funcionalidad ................................................................................................................. 105
Aplicación................................................................................................................................................... 108
Ejemplo práctico 1: Herramienta software de ayuda ............................................................................ 109
Ejemplo práctico 2: Desarrollo Aplicación ............................................................................................. 111
Conclusión ..................................................................................................................................................... 113
Bibliografías .................................................................................................................................................. 114

Índice de ilustraciones
Figura 1: Vista de BTN25 y BTN100 de la ciudad de León ............................................................................. 8
Figura 2: Vista del entorno de captura en BTN25............................................................................................. 9
Figura 3: Diseño de la arquitectura y tecnologías del Sistema de Información Geográfica ........................... 13
Figura 4: Modelo entidad relación de la base de datos geográficos de Sistema de Finanzas Castilla ............ 18
Figura 5: Interfaz gráfica de inicio al sistema Web......................................................................................... 19
Figura 6: Interfaz gráfica para el despliegue tabular de datos ......................................................................... 20
Figura 7: Interfaz gráfica de configuración partida ......................................................................................... 20
Figura 8: Interfaz gráfica del histórico de Configuración de Partidos ............................................................ 21
Figura 9: Interfaz del visor Web de mapas...................................................................................................... 22
Figura 10: Representación Entidad Espacio-Temporal ................................................................................... 39
Figura 11: Relaciones entre temas, espacio y tiempo ..................................................................................... 39
Figura 12: Arquitectura de la interfaz IGBDT ................................................................................................ 44
Figura 13: Pantalla principal de IGBDT ......................................................................................................... 46
Figura 14: Pantalla para la ejecución de consultas temporales ....................................................................... 47
Figura 15: Arquitectura distribuida segura de BizTalk Server........................................................................ 64
Figura 16: Esquema general de la arquitectura. .............................................................................................. 85
Figura 17: Tabla con resultados de una consulta FSQL en el programa cliente FQ2 con herramientas Web. 87
Figura 18: Acceso principal a la interfaz......................................................................................................... 88
Figura 19: Agregación de datos a la B.D. ....................................................................................................... 88
Figura 20: Consulta de Promedio. ................................................................................................................... 89
Figura 21: Interfaz para el control de conjuntos difusos de la B.D. ................................................................ 89
Tabla 1: Clasificación de datos clásicos y difusos (parcial) ............................................................................ 91
Figura 22: Inferencia Conjunto Difuso 1 ........................................................................................................ 93
Tabla 2: Cálculo de pendiente y punto de intersección de la recta, Conjunto Difuso 1 .................................. 93
Figura 23: Recta ajustada del Conjunto Difuso 1............................................................................................ 93
Tabla 3: Tablas que intervienen en el modelo relacional difuso ..................................................................... 94
Figura 24: Modelo de base de datos ................................................................................................................ 95
Tabla 4: Tablas de referencia del modelo relacional difuso ............................................................................ 96
Figura 25: Estado inicial-tablas difusas........................................................................................................... 96
Figura 26: Flujo de transformación difusa ...................................................................................................... 97
Figura 27: Comprobación de transformación difusa. ...................................................................................... 97
Figura 28: Diseño interfaz – Menú Principal .................................................................................................. 98
Figura 29: Consulta mediante aplicación antes de transformación difusa ...................................................... 99
Figura 30: Consulta mediante aplicación después de transformación difusa .................................................. 99
Figura 31: Arquitectura de construcción de almacenes de datos. ................................................................. 105
Figura 32: Arquitectura general de un Data Warehouse ............................................................................... 106

Figura 33: Arquitectura genérica de DW (Chaudhuri & Dayal, 1997) ......................................................... 107
Figura 34: Creación del esquema del almacén .............................................................................................. 109
Figura 35: Elección de la granularidad.......................................................................................................... 110
Figura 36: Refresco de los datos ................................................................................................................... 110
Figura 37: Informe Ratio Prima por Dirección con Business Objects. ......................................................... 111
Figura 38: Informe Ratio Prima por Producto con Business Objects. .......................................................... 112

Introducción
Aquí se analizara el concepto de las Bases de Datos Geográficas donde forma parte del Sistemas
de Información Geográfica (SIG) que permiten gestionar y analizar la información espacial, por lo
que han venido a integrarse en la alta tecnología de los geógrafos y otros profesionales que trabajan
sobre el territorio. Se trata de sofisticadas herramientas multipropósito con aplicaciones en campos
como la planificación urbana, la gestión catastral, la ordenación del territorio, el medio ambiente, la
planificación del transporte, el mantenimiento y la gestión de redes públicas, el análisis de mercados,
etc.
Así pues, un SIG es un software específico que permite a los usuarios crear consultas interactivas,
integrar, analizar y representar de una forma eficiente cualquier tipo de información geográfica
referenciada asociada a un territorio, conectando mapas con bases de datos. El uso de este tipo de
sistemas facilita la visualización de los datos obtenidos en un mapa, con el fin de reflejar y relacionar
fenómenos geográficos de cualquier tipo, desde mapas de carreteras hasta sistemas de
identificación de parcelas agrícolas o de densidad de población. Además, permiten realizar las
consultas y representar los resultados en entornos web y dispositivos móviles de un modo ágil e
intuitivo, resolviendo problemas de planificación y gestión geográfica por lo que se plantea en la
investigación.
Como también se explicara las Bases de Datos Temporales que es aquella que contiene datos
históricos en vez de datos actuales. Tales bases de datos han sido investigadas desde mediados
de los años setenta. Algunas de esas investigaciones adoptan la posición extrema de que los datos
de dichas bases de datos solo son insertados y nunca son eliminados ni actualizados. Por lo tanto,
la investigación sobre Bases de Datos Temporales ha involucrado muchos análisis sobre la propia
naturaleza del tiempo.
De igual manera la Base de Datos debe ser segura ya que tiene que ver con la protección de datos
contra accesos no autorizados y para protegerlos de una posible corrupción durante todo su ciclo
de vida. Hoy en día, organizaciones de todo el mundo invierten fuertemente en la tecnología de
información relacionada con la ciberdefensa con el fin de proteger sus activos críticos: su marca,
capital intelectual y la información de sus clientes. La seguridad de bases de datos es un tema de
suma importancia que nos afecta a casi todos nosotros. Cada vez son más los productos
tecnológicos que de una u otra forma debe ser tomada en cuenta para temas de seguridad y que se
están introduciendo en nuestra vida cotidiana.

En Bases de Datos Difusas se relaciona en este concepto con la teoría de los conjuntos difusos
desarrollada por Zadeh, provee una poderosa herramienta para la representación y manejo de la
imprecisión por lo que actualmente está siendo utilizada en varios campos para el diseño de
sistemas basados en reglas difusas. La teoría de conjuntos difusos, extiende la teoría clásica de
conjuntos al permitir que el grado de pertenencia de un objeto a un conjunto sea representada como
un número real entre 0 y 1 en vez del concepto clásico en el que solo se tiene la posibilidad de
pertenecer a un conjunto o no pertenecer al mismo; en otras palabras, el grado de pertenencia a un
conjunto en la teoría clásica tiene solo dos valores posibles: 0 y 1.
En el sentido más amplio, un sistema basado en reglas difusas es un sistema basado en reglas
donde la lógica difusa es utilizada como una herramienta para representar diferentes formas de
conocimiento acerca del problema a resolver, así como para modelar las interacciones y relaciones
que existen entre sus variables. Debido a estas propiedades, los sistemas basados en reglas difusas
han sido aplicados de forma exitosa en varios dominios en los que la información vaga o imprecisa
emerge en diferentes formas.
Por ultimo Almacenes de Datos que bien es conocido como Data Warehouse que es una colección
de datos en la cual se encuentra integrada la información de la Institución y que se usa como soporte
para el proceso de toma de decisión gerenciales. Aunque diversas organizaciones de personas
individuales logran comprender el enfoque de un Warehouse, la experiencia ha demostrado que
existen muchas dificultades potenciales. Se considera al Data Warehouse como algo que provee
dos beneficios empresariales reales: Integración y Acceso de datos. Data Warehouse elimina una
gran cantidad de datos inútiles y no deseados, como también el procesamiento desde el ambiente
operacional clásico.
Una data Warehouse se crea al extraer datos desde una o más bases de datos de aplicaciones
operacionales. La data extraída es transformada para eliminar inconsistencias y resumir si es
necesario y luego, cargadas en la data Warehouse. El proceso de transformar, crear el detalle de
tiempo variante, resumir y combinar los extractos de datos, ayuda a crear ambiente para el acceso
a la información Institucional. Este nuevo enfoque ayuda a las personas individuales, en todos los
niveles de la empresa, a efectuar su toma de decisiones con más responsabilidad.

2.5. Bases de Datos Geográficas

Una Base de Datos Geográfica (BDG) es un conjunto de
datos geográficos organizados de tal manera que permiten
la realización de análisis y la gestión del territorio dentro de
aplicaciones de Sistemas de Información Geográfica (SIG).
Además, una BDG se utiliza de soporte para la implantación
de servicios geográficos relacionados con las
Infraestructuras de Datos Espaciales (IDE), y su contenido
es la base fundamental en los procesos de producción
cartográficos.
La espina dorsal de una BDG es el modelo de datos, que consiste en la formalización conceptual
(descripción) de las entidades geográficas del mundo real con el objeto de realizar una abstracción
que permita satisfacer unas necesidades de información. La implementación del modelo debe de
facilitar la explotación y optimizar el almacenamiento para conseguir el mejor rendimiento en las
consultas.
Todo lo relativo a la descripción de los diferentes productos de una BDG queda reflejado en las
denominadas especificaciones del producto. En ellas se recogen tanto el catálogo de objetos
geográficos asociado como el sistema de referencia, la calidad de los datos y los metadatos, así
como la captura, el mantenimiento y la distribución de los mismos.
Figura 1: Vista de BTN25 y BTN100 de la ciudad de León

La Información Geográfica (IG) se sitúa a la cabeza de los productos más solicitados por los
ciudadanos a las administraciones públicas (AA. PP.). El notable aumento de esta demanda ha
modificado todo lo relativo a la captura, el almacenamiento, el tratamiento, el mantenimiento y la
actualización de la información geográfica y espacial.
El Instituto Geográfico Nacional (IGN) desarrolla en la actualidad diferentes proyectos de I+D+i

aplicados a la producción cartográfica y el control de calidad en entornos de (SIG), creando y
manteniendo BDG continuas que permiten generar cartografía bajo demanda en función de los
cambios acontecidos en el mundo real, y de esta forma romper con el clásico concepto de hoja de
serie cartográfica.
Figura 2: Vista del entorno de captura en BTN25
La captura masiva y selectiva permite clasificar la IG por temas, garantizando la continuidad de los
elementos y concretando las particularidades propias de la temática a la que pertenecen. El
almacenamiento de gran volumen de IG requiere la puesta en marcha de servidores y BDG
específicas para el tratamiento espacial de los datos, el cual se desarrolla en entornos de producción
de SIG, abandonando los sistemas CAD.
El mantenimiento y la actualización son tareas destinadas a mejorar la calidad geométrica,

semántica y topológica de la IG, parámetros demandados por el usuario final del producto. Las BDG
favorecen no solo la “interoperabilidad” entre éstas y otras bases de datos, bien del IGN, bien de
otros organismos de las AA. PP., sino que permiten la multirrepresentación a través de procesos de
generalización conceptual o cartográfica.

La conjunción de los resultados de estos proyectos facilitará la producción cartográfica automatizada

extrayendo IG de diversas fuentes, componiendo la escala y el espacio requerido por el usuario,
aportando un producto de calidad y asegurando la actualidad de los datos.
Las Bases de datos Geográficos que se producen en el IGN son:
 Base Topográfica Nacional 1:25.000 (BTN25)

 Base Topográfica Nacional 1:100.000 (BTN100)
 Base Cartográfica Nacional 1:200.000 (BCN200)
 Base Cartográfica Nacional 1:500.000 (BCN500)
Propósito es que contienen multitud de información alfanumérica de todo tipo (geográfica,

demográfica, económica, geológica, usos de suelo, vegetación, social, urbanística, etc.), mediante
la cual se pueden realizar cualquier estudio estadístico para obtener un resultado concreto igual que
se haría en Microsoft Access o Microsoft Excel, con la ventaja de poder visualizar los resultados en
planos y mapas que ofrecen una mejor comprensión de los mismos.
Aplicaciones en Sistemas de Información Geográfica (SIG)

Es un sistema compuesto por hardware, software y procedimientos para capturar, manejar,
manipular, analizar, modelar y representar datos georreferenciados, con el objetivo de resolver
problemas de gestión y planificación. Los SIG son ante todo herramientas de ayuda a la resolución
de problemas. De forma general podemos decir que están compuestos por un conjunto de
metodologías, procedimientos y programas informáticos especialmente diseñados para manejar
información geográfica y datos temáticos asociados. Un sistema de información geográfica es una
utilidad para entender y presentar hechos que ocurren sobre la superficie terrestre.
Son una herramienta que nos permite trabajar con bases de datos y realizar análisis multicriterio
para la toma de decisiones, tienen aplicación en diversos campos: gestión de patrimonio cultural,
urbanismo, redes de tensión eléctrica, cableado telefónico, topografía, micología, gestión de rutas,
redes de saneamiento y abastecimiento, control de compras, arquitectura, paisajismo…

Entre los SIG computarizados, aquellos basados en una computadora personal (PC) se encuentran
más a la mano y son relativamente más sencillos de operar. Tienen capacidad para generar mapas
a diferentes escalas y tabular información adecuada para análisis repetitivo, diseño de proyectos y
toma de decisiones. Aunque un SIG en una PC puede producir mapas de calidad cartográfica o con
suficiente detalle para diseños de ingeniería, es lo más efectivo para los grupos de planificación
encargados de analizar temas de peligros naturales en los proyectos integrados de desarrollo.
Los datos manejados por un SIG en computadora son ordenados, sea por técnicas de ''raster" o de
vectores. El modelo "raster" utiliza un cuadriculado para referir y almacenar la información. Un área
de estudio es dividida en pequeñas áreas o matriz de células cuadradas (a veces rectangulares)
idénticas en tamaño, y la información -los atributos presentados con códigos numéricos- es
almacenada en cada compartimento para cada estrato o atributo en la base de datos.
Un compartimento puede mostrar bien el rasgo dominante que se encuentra en esa unidad, o la
distribución porcentual de todos los atributos que se encuentran en la misma unidad. Los sistemas
basados en raster definen las relaciones espaciales entre variables más claramente que los basados
en vectores, pero la inferior resolución por causa de la estructura celular reduce la exactitud espacial.
CARACTERISTICAS DE SOBREPOSICION DE UN SIG

Entre las aplicaciones más usuales destacan:
Científicas
o Especialmente en ciencias medioambientales (en sentido amplio) y relacionadas con el espacio.

o Desarrollo de modelos empíricos, por ejemplo los que relacionan temperatura con altitud,
orientación, etc. a partir de medidas tomadas en el lugar.
o Modelización cartográfica (aplicación de modelos empíricos para hacer mapas de temperatura
a partir de mapas de altitud, orientación, etc.)
o Modelos dinámicos (utilización de las leyes de la termodinámica y la dinámica de fluidos para
hacer un mapa de temperatura utilizando un mapa de elevaciones, entre otros,
como condiciones de contorno.
o Teledetección, las imágenes de satélite son estructuras raster que se manejan de forma óptima
en un SIG.
Gestión
o Cartografía automática
o Información pública, catastro
o Planificación de espacios protegidos
o Ordenación territorial
o Planificación urbana
o Estudios de impacto ambiental
o Evaluación de recursos
o Seguimiento de las consecuencias de determinadas actuaciones (presas, diques, carreteras)
Empresarial
o Marketing (envió de propaganda a los residentes cerca del local que cumplan determinadas
condiciones).
o Estrategias de distribución (optimización de las rutas que una flota de camiones debe realizar
para distribuir mercancía desde varios almacenes a varios clientes).
o Localización óptima de una sucursal en función de los clientes potenciales situados alrededor.

Arquitectura de funcionalidad
Diseño de la arquitectura del Sistema de Información Geográfica
El diseño de la arquitectura del SIG (Figura 3) corresponde a un modelo cliente-servidor de tres

niveles. Esta arquitectura se caracteriza por un modelo de aplicación distribuida que separa las
funciones en capas de procesamiento y se encuentran comunicadas y coordinadas mediante una
red que permite el intercambio de mensajes entre los mismos (Luján, 2002):
Figura 3: Diseño de la arquitectura y tecnologías del Sistema de Información Geográfica

El cliente, es decir el equipo que solicita o demanda los recursos, equipado con las interfaces de
usuario para su presentación, y asume que con cada petición obtendrá una respuesta. Los clientes
del sistema pueden ser de dos tipos: los clientes ligeros que acceden a la interfaces básicas SIG a
través de navegadores Web, y los clientes pesados que conectan a los servicios geográficos y
puedan recuperar las geometrías o mapas georreferenciados con el objeto de procesarlos o
analizarlos, ejemplos de software con estas características son Quantum GIS, ArcGIS, gvSIG, entre
otros.
● El servidor de aplicaciones, también denominado software intermedio (Middleware), cuya tarea

es proporcionar y gestionar los recursos solicitados y atender las peticiones de los investigadores y
usuarios, pero requiere otro servidor para hacerlo. Este conjunto de aplicaciones se comunican con
la base de datos, aislando de este modo las conexiones directas con los clientes. Para el caso del
SIG, se tiene en esta capa los servidores de mapas, el servidor generador de memoria caché de
teselas y el marco de desarrollo Web.
● El servidor de datos, responsable de la gestión y almacenamiento permanente de los datos, útil
para proporcionar al servidor de aplicaciones los datos alfanuméricos y geográficos que solicite el
cliente.
Ejemplo práctico 1: Sistema Georreferenciada de Información Cafetera – SICA

Es un sistema de información, conformado por una base de datos, dinámica y georreferenciada de
cobertura nacional, a la que se accede a través de internet para:
 Actualizar
 Consultar
 Analizar
 Modelar
 Visualizar datos geo-espaciales de la información básica de productores, fincas y lotes cafeteros
del país.
Se convierte en la herramienta de información estratégica para el diseño, formulación, trazado y
seguimiento de políticas de competitividad y sostenibilidad de la caficultura colombiana.
El SICA es permanentemente actualizado por parte del Servicio de Extensión de la FNC.
La administración y operación del sistema es responsabilidad de la FNC apoyada en un reglamento
establecido, donde se encuentran definidos los requisitos, deberes y responsabilidades
relacionadas con el registro, actualización y uso de la información allí consignada. El reglamento
contiene los lineamientos, directrices y acciones pertinentes para una adecuada gestión de la base
de datos, regida por los perfiles de acceso, conceptos básicos y acciones a seguir dada la dinámica
propia de la caficultura.

Los usuarios del SICA pueden generar reportes consolidados y detallados en función de su perfil y
cobertura. Estos reportes pueden ser de tipo geográfico (mapas) y alfanumérico (tablas,
gráficas y estructuras). Los insumos para la generación de reportes son los datos registrados
en el sistema asociados a caficultores, fincas, lotes cafeteros y labores de educación.
La calidad de la información almacenada es permanentemente monitoreada para certificar la

trazabilidad de los cambios y actualizaciones encontradas en campo, para ello se cuenta con
diferentes estrategias y herramientas tecnológicas donde se ejerce control sobre los datos, su
integridad y seguridad que facilita la operatividad, transparencia y veracidad de la información.
Actualmente se realiza la implementación de la aplicación SICA en dispositivos móviles diseñado

bajo el sistema operativo android, para la captura de información en modo desconectado y cuyo
desarrollo especializado incluye el visor geográfico, las herramientas de navegación básicas, el
módulo de caficultores, fincas, lotes y labores educativas, todo enmarcado en un entorno tecnológico
moderno, fácil de usar garantizando una solución efectiva para que el Servicio de Extensión ejecute
sus tareas con mayor eficiencia, ahora no se requiere dependencia de acceso a Internet para el
registro de las novedades encontradas en campo.

Detalles de zona cafetera en el sistema:
El mapa ilustra la distribución espacial de los lotes

cafeteros registrados en el SICA a diciembre 31 de
2015.


Ejemplo práctico 2: Sistema de Finanzas Castilla

Figura 4: Modelo entidad relación de la base de datos geográficos de Sistema de Finanzas Castilla

Desarrollo de un Sistema de Información Geográfica Web para el análisis espacial y

temporal de las finanzas del Reino de Castilla en el siglo XVI.
Diseño de las interfaces gráficas de usuario
Como propuesta de interfaces gráficas de usuario en el cliente Web, se expone a continuación las
principales pantallas y elementos gráficos que permitirán a los investigadores comunicarse con el
servidor de aplicaciones de manera amigable y flexible.
La figura 5 corresponde a la interfaz de inicio una vez que el investigador se haya autenticado en el
Sistema de Información, y es el punto de ingreso y navegación en las aplicaciones del sistema.
Ofrece una barra de menús a la administración y acceso a las aplicaciones. También ofrece la
visualización del histórico de actividades sobre los datos.
Figura 5: Interfaz gráfica de inicio al sistema Web
La interfaz de usuario de la Figura 6, corresponde al despliegue tabular de los datos en las

aplicaciones. En ella se encuentra elementos para la búsqueda o filtro de datos, por ejemplo, el
filtrado por división territorial. Esta interfaz, también ofrece algunas acciones sobre la base de datos,
como agregar nuevos registros, o borrar los existentes.

Figura 6: Interfaz gráfica para el despliegue tabular de datos
Figura 7: Interfaz gráfica de configuración partida

La interfaz de la figura 7, corresponde a una de las principales clases del sistema, la Configuración
Partido. Ofrece todos los elementos para definir de forma única, la renta, el partido y la colección de
geometrías de localidades y nomenclátor. Esta interfaz integra un visor de mapas como herramienta
de ayuda para la georeferenciación y análisis de las localidades agregadas.
En cuanto a las características propias de la zona, se realiza la identificación de las rentas,

administración, así como los montos de cada una de las localidades o nomenclátor que conforma la
geometría de la configuración partido de las rentas del Reino de Castilla.
Figura 8: Interfaz gráfica del histórico de Configuración de Partidos

La segunda interfaz de importancia en la aplicación de finanzas castilla, es la correspondiente con

los históricos de la configuración de partido (Figura 8). Esta interfaz especifica de manera única, la
configuración de partido y la fecha en que recoge la información anual de los montos totales, así
como el total arrendado y encabezado, y las personas (financieros) que participaron como
arrendadores o receptores. Finalmente, se recoge información relativa a las fuentes bibliográficas
donde se obtuvo dicha información.
La figura 9 muestra la propuesta del visor web de mapas para el despliegue y visualización de los
datos espaciales y temporales. El diseño sigue la estructura básica las interfaces SIG, con una barra
de herramientas, una zona de visualización de la información geográfica, un panel del contenido de
las capas, la leyenda y una región para el despliegue de la información y resultados de la búsqueda.
Figura 9: Interfaz del visor Web de mapas

Ejemplo de PostGis Mapeo

Para producir un mapa de datos de PostGIS, necesita a un cliente que puede obtener los datos. La
mayoría de los programas de código abierto GIS pueden hacerlo - gvSIG, QGIS, uDig por ejemplo.
Ahora te mostramos cómo hacer un mapa de QGIS.
Iniciar QGIS desde el menú de escritorio SIG y elija Add PostGIS layers en el menú de capa. Los
parámetros para la conexión a los datos de Natural Earth en PostGIS ya están definidos en el menú
desplegable de Conexiones. Puede definir nuevas conexiones con servidores aquí y almacenar los
ajustes de fácil retiro. Haga click en el menú desplegable de conexiones y escoja la Natural Earth.
Presione editar si usted quiere ver lo que esos parámetros son para Natural Earth, o sólo
presione Connect para continuar:

Ahora obtendrá una lista de las tablas espaciales en la base de datos:

Elegir la tabla ne_10m_lakes y presione Add en la parte inferior (no Load en la parte superior - que
carga los parámetros de conexión de base de datos), y se debe cargar en QGIS:
Ahora debería ver un mapa de los lagos. QGIS no sabe que son los lagos, así que no podría azul les
color para usted - utilizar la documentación de QGIS para trabajar la manera de cambiar esto. Haga
un acercamiento sobre un famoso grupo de lagos en Canadá.

Creación de una Tabla Espacial la manera fácil

La mayoría de las herramientas de escritorio de OSGeo tienen funciones para importar datos
espaciales en los archivos, como shapefiles, en las bases de datos PostGIS. Otra vez vamos a usar
QGIS para mostrar esto.
Importar shapefiles a QGIS puede hacerse mediante el práctico Administrador de Base de Datos de
QGIS. Encuentre el manager en el menú. Vaya a Database -> DB Manager -> DB Manager.
Despliega el ítem de Postgis, luego el ítem de NaturalEarth. Luego se conectará a la base de datos
de Natural Earth. Dejar la contraseña en blanco si le pide. En el ítem público, hay la lista de las capas
de la base de datos. Verás la ventana principal del administrador. A la izquierda puede seleccionar
tablas de la base de datos y usar las pestañas de la derecha para conocerlas. La pestaña Vista previa
le mostrará un pequeño mapa.
Ahora usaremos el administrador de DB para importar un archivo de formas en la base de datos.

Usaremos los datos de síndrome de muerte súbita del lactante (SMSL) de Carolina del norte que se
incluye en uno de los complementos de paquete de estadísticas R.

En el menú Table elija la opción Import layer/file . Pulse el botón ... y busque el shapefile sids.shp en
el paquete de maptools R (ubicado en /usr/lib/R/site-library/spData/shapes):

Deja todo lo demás como está y presione Load
Permitir que el Selector de Sistema de Referencia de Coordenadas sea por defecto (WGS 84
EPSG:4326) y presione OK. El shapefile se debe importar a PostGIS sin errores. Cierre el
administrador de PostGIS y regrese a la ventana principal de QGIS.
Ahora cargue los datos de SIDS en el mapa utilizando la opción Add PostGIS Layer”. Con un poco de
reorganización de las capas y algunos coloreados, usyed debe ser capaz de producir un mapa
coroplético de las cuentas de síndrome de muerte súbita (campos sid74 o sid79) en Carolina del norte:

Conocer pgAdmin III

Puede utilizar al cliente de base de datos gráfica pgAdmin III del menú de Bases de Datos para
consultar y modificar su base de datos no-espacialmente. Este es el cliente oficial de PostgreSQL y
le permite usar SQL para manipular sus tablas de datos. Puede encontrar y ejecutar pgAdmin III desde
la carpeta de Bases de Datos, existente en OSGeo Live Desktop.

Aquí, usted tiene la opción de crear una nueva conexión a un servidor PostgreSQL, o se conecta a un
servidor existente. En este caso, vamos a conectar al servidor local predefinido.
Después de la conexión establecida, puede ver la lista de las bases de datos ya existentes en el
sistema.
La «X» roja en la imagen de la mayoría de las bases de datos, indica que no han sido aún conectado
a cualquiera de ellos (está conectado sólo a la base de datos predeterminada postgres). En este
momento eres capaz sólo de ver las bases de datos existentes en el sistema. Puede conectarse
haciendo doble click en el nombre de una base de datos. Hágalo para la base de datos natural_earth2.
Usted puede ver ahora que desapareció la X roja y un «+» apareció a la izquierda. Presionando un
árbol va a aparecer, mostrando el contenido de la base de datos.
Navegar en el subárbol esquemas, expandirla. Luego ampliar el esquema de public. Navegando y
ampliando Tables puedes ver todas las tablas dentro de este esquema.

Ejecutar una consulta SQL desde pgAdmin III

pgAdmin III, ofrece la capacidad de ejecutar consultas a una base de datos relacional.
Para realizar una consulta en la base de datos, tienes que pulsar el botón SQL de la barra de
herramientas principal (el uno con el amarillo lente de aumento).
Vamos a encontrar la tasa de SIDS sobre los nacimientos del 1974 para cada ciudad. Además, vamos
a ordenar el resultado, en función de la tasa calculada. Para hacer eso, necesitamos realizar la
siguiente consulta (enviarla al editor de texto de la Ventana SQL):
select name, 1000*sid74/bir74 as rate from sids order by rate;

Luego, debe presionar el botón de flecha verde, apuntando a la derecha (ejecutar consulta).
Creación de una Tabla Espacial

Ahora tenemos una base de datos espacial podemos hacer algunas tablas espaciales.
Primero creamos una tabla de base de datos común para almacenar algunos datos de la ciudad. Esta
tabla tiene tres campos - uno para un ID numérico de identificación de la ciudad, una para el nombre
de la ciudad y otra para la columna de geometría:
demo=# CREATE TABLE cities ( id int4 primary key, name varchar(50), geom
geometry(POINT,4326) );
Convencionalmente esta columna de geometría se denomina geom (la más vieja convención de
PostGIS era the_geom). Esto le indica a PostGIS qué tipo de geometría, tiene cada función (puntos,
líneas, polígonos, etcetera), cuántas dimensiones (en este caso, si tiene 3 o 4 dimensiones
utilizaríamos POINTZ, POINTM o POINTZM) y el sistema de referencia espacial. Utilizamos
EPSG:4326 coordenadas para nuestras ciudades.

Ahora si revisas la tabla ciudades usted debería ver la nueva columna y se informó que la tabla no
contiene actualmente ninguna fila.
demo=# SELECT * from cities;

id | name | geom
----+------+----------
(0 rows)
Para agregar filas a la tabla que utilizamos algunas sentencias SQL. Para obtener la geometría en la
columna de geometría usamos la función PostGIS ST_GeomFromText para convertir de un formato
de texto que le da las coordenadas y un id de sistema de referencia espacial:
demo=# INSERT INTO cities (id, geom, name) VALUES (1,ST_GeomFromText('POINT(-

0.1257 51.508)',4326),'London, England');
demo=# INSERT INTO cities (id, geom, name) VALUES (2,ST_GeomFromText('POINT(-
81.233 42.983)',4326),'London, Ontario');
demo=# INSERT INTO cities (id, geom, name) VALUES
(3,ST_GeomFromText('POINT(27.91162491 -33.01529)',4326),'East London,SA');


2.6. Bases de Datos Temporales

Las bases de datos temporales son aquellas que administran los datos considerando la variación
del tiempo en los mismos, partiendo del hecho de que el tiempo es una variable importante en la
información, y que convencionalmente las bases de datos representan el estado de la información
en un solo instante de tiempo, existen sectores dentro de los que se incluyen las finanzas, la
medicina y el entorno gubernamental, que necesitan representar su información en un tiempo
pasado; razón por la cual, durante los últimos veinte años se han presentado modelos de bases de
datos temporales, con el fin de representar la evolución histórica de los datos.
Para el modelamiento de las Bases de Datos Temporales (BDT) se puede hacer una extensión del
modelo relacional, adicionando atributos temporales a cada relación. Así mismo, para lo que refiere
a la consulta de los datos existen lenguajes especializados para estas bases de datos, como lo son
TQUEL y SQL3.
Se pueden ver dos estados importantes de los datos en las BDT, en el tiempo válido, que es el
periodo de tiempo en el que el hecho es real y se permite una serie de operaciones como la
eliminación, la inserción y la modificación en cualquier instante de tiempo; y el tiempo de transacción,
el cual describe el punto en el tiempo en que fue ingresada la información, soportando operaciones
como actualizaciones únicamente en el estado actual (no se puede modificar el pasado), volver a
un estado anterior “Rollback”, y eliminación lógica puesto que no se puede eliminar físicamente la
información para conservar el histórico de los datos.

Especificando más profundamente, los aspectos temporales normalmente incluyen tiempo de

validez y tiempo de transacción. La combinación de estos dos atributos forman un dato bitemporal.
 Tiempo de validez indica el período en el cual un hecho es verdad en el mundo real.

 Tiempo de transacción indica el período en el cual un hecho está guardado en la base de
datos.
 Dato Bitemporal es la combinación del tiempo de validez y el tiempo transaccional.
Estos dos períodos no tienen que ser idénticos para un mismo hecho. Imagine una base de datos
temporal guardando datos sobre el siglo veinte. El tiempo de validez sobre esos hechos estará
comprendido entre el año 1901 y el año 2000, sin embargo el tiempo transaccional empezará
cuando insertemos esos hechos en la base de datos, por ejemplo, 25 de diciembre del 2006.
Característica
Se caracterizan por la incorporación de uno o más atributos temporales, que pueden reflejar el
momento en que un hecho fue actualizado en la base de datos (tiempo de transacción), o el
momento en el que realmente ocurrieron los hechos que se modelan (tiempo valido), o ambos
inclusive.
Tipos:
Tiempo Transaccional
Registran el tiempo de acuerdo al momento en que se

almacena un hecho, es decir, en el orden en que se procesan
las transacciones. Debido a que se mantiene la historia de
todos los estados consistentes de la base de datos, se
pueden realizar un roll-back hacia cualquiera de estos
estados anteriores. Las bases de datos de tiempo
transaccional no permiten modificar el pasado. Un Rollback
es una operación que devuelve a la base de datos a algún
estado previo.
Otro aspecto temporal que se relaciona con los hechos de una base de datos es el tiempo de
transacción. El tiempo de transacción de un hecho en la base de datos es el momento en que el
hecho es actual (es registrado) dentro de la base de datos. A diferencia del tiempo válido, el tiempo
de transacción puede estar asociado con las entidades de la base de datos y no solo con los hechos.
El tiempo de transacción puede estar asociado con valores y objetos que no son necesariamente
hechos; por ejemplo, el valor “63” puede almacenarse en una base de datos, pero no denota una
sentencia lógica.
Esto quiere decir que el tiempo de transacción está asociado con “63”, pero no es un tiempo válido,
de manera que todas las entidades tienen un tiempo de transacción asociado. Este tiene un período

de duración, ya sea durante una inserción, eliminación; o múltiples inserciones o eliminaciones para
una misma entidad.
Tiempo Vigente O Valido
Soportan el tiempo en que el hecho ocurrió en la realidad, que puede no coincidir con el momento
de su registro. El orden de ocurrencia de los eventos puede diferir del orden de su registro. Este
sistema permite realizar correcciones sobre los datos registrados, es decir que los estados
anteriores se pueden modificar. En dicho caso, solo se mantiene la última versión de cada estado.
Una relación con tiempo válido utiliza el concepto de tiempo válido como marca de tiempo, los
hechos son registrados en el momento en que realmente ocurren en el mundo modelado.
La semántica del tiempo válido está fuertemente relacionada con la realidad, por lo tanto es más
compleja que la semántica del tiempo de transacción. Así, las bases de datos de tiempo válido o
bases de datos históricas necesitan de operaciones sofisticadas para manejar adecuadamente la
compleja semántica del tiempo válido.
Bitemporales
Integran la dimensión transaccional y la dimensión vigente, a través del versionado de los estados,
es decir, cada estado se puede modificar para actualizar el conocimiento de la realidad pasada,
presente o futura, pero esas modificaciones se realizan generando nuevas versiones de los mismos
estados. Especificando más profundamente los aspectos temporales normalmente incluyen tiempo
de validez y tiempo de transacción, la combinación de estos dos atributos forman un dato bitemporal.
Tiempo de transacción indica el periodo en el cual un hecho está guardado en la base de datos
bitemporal es la combinación del tiempo de validez y tiempo transaccional, estos dos periodos no
tienen que ser idénticos para un mismo hecho, imagine una base de datos temporal guardando
datos sobre el siglo XX, el tiempo de validez sobre esos hechos estará comprendido entre el
año1901 y 2000, sin embargo el tiempo transaccional empezara cuando insertemos esos hechos
en la base de datos por ejemplo el 25 de diciembre del 2006.
Las relaciones Bitemporales combinan los beneficios de las de tiempo de transacción y las de tiempo
válido en una relación que las soporta a ambas. Una relación bitemporal puede ver tuplas válidas
en un momento, tal como se conocían en algún otro momento, capturando completamente la historia
de los cambios. En una relación bitemporal el usuario puede examinar información histórica desde
el punto de vista de un estado previo de la relación; en una consulta pueden manejarse ambos tipos
de tiempo. Cada transacción causa la creación de un nuevo estado histórico.
Este tipo de relación puede verse como una secuencia de estados Rollback, en donde cada uno de
estos constituye una relación histórica completa. La operación de Rollback en una relación
bitemporal selecciona un estado histórico particular, sobre el cual es posible ejecutar una consulta

histórica. Se conceptúan como bases de datos Bitemporales aquellas que contienen relaciones
Bitemporales.
Propósito
Que son aquellas que gestionan la historia, pudiendo contemplar dos dimensiones del “Tiempo”;
tiempo válido, en el que un hecho es verdadero en el mundo real (con independencia de su registro
en la base de datos) y tiempo de transacción, durante el cual el hecho estuvo presente en la base
de datos es decir una representación codificada de hechos con marcas de tiempo. De acuerdo a la
interpretación extrema de este término, todos los datos son temporales, lo que significa que cada
hecho registrado tiene una marca de tiempo.
Aplicación
Una aplicación inmediata de este tipo de Bases de Datos es aquella que se ejecuta en un entorno
donde se aplican cambios en Tiempo Real. Por ejemplo, las transacciones bancarias incluyen
tiempo inicial de transacción y tiempo final de transacción.
Muchas de las aplicaciones de tecnología de bases de datos son temporales por naturaleza.
Desarrollar un modelo que potencie la gestión temporal de la información:
Finanzas: Cotizaciones bursátiles, contabilidad, cuentas bancarias etc.
Reservas: Vuelos, trenes, hoteles etc.
Ciencia: Monitorización meteorológica...Recursos humanos – Registros sanitarios.
Sistemas de Gestión de BDT Sistemas de Gestión de BDT Los SGBD comerciales (Oracle, Sybase,
Informix, O2…) NO son capaces de realizar gestión temporal en validez y en transacción
simultáneamente.
Existen varias estrategias desarrolladas: Extensiones temporales a lenguajes existentes –

TSQL2 Auténticos SGBD temporales TimeDB, Tiger y Time Series Cartridge.

(Véase la Figura 10), que inicia en el momento de la toma del geo dato y termina en el momento
que se destruyen el geo dato. Bajo la anterior descripción, los datos espacio- temporales se
representan como una inserción de la dimensión tiempo en entidades geográficas concebidas,
donde el espacio geográfico se organiza en capas temáticas que incluyen la información de captura
en un tiempo determinado.
Figura 10: Representación Entidad Espacio-Temporal
(Véase 11). Los autores proponen un modelo de datos espacio temporal orientado a objetos que
tiene en cuenta los atributos básicos y el comportamiento de los objetos espacio-temporales.
Figura 11: Relaciones entre temas, espacio y tiempo

Ejemplo práctico 1: Bernardo

 Bernardo Sabina nació un soleado 6 de marzo de 1985 en Zaragoza. Su madre registró su
nacimiento al día siguiente.
 Tras acabar sus estudios de Ingeniería el 15 de junio de 2007, Bernardo se mudó ese mismo
día a Torrevieja a vender hamburguesas con queso.
 Sin embargo, no registró su mudanza hasta el 25 de junio, ya que tenía una competición
nacional de tenis de mesa.
 Pese a tener un futuro prometedor, Bernardo murió el 20 de septiembre 2012 de un balazo en

la cabeza en el CPS, cuando iba a ver la presentación del PFC de su hermano. El equipo
forense CpSI registró su muerte el mismo día.
¿Qué transacciones SQL se realizarían con una base de datos convencional?
Fecha Hecho ocurrido Acción de la BD Vista en la BD
6/03/1985 Nace Bernardo. - -
7/03/1985 Se registra su nacimiento. Inserción: (Bernardo, Bernardo vive en

Zaragoza) Zaragoza.
15/06/2007 Bernardo se muda a - Bernardo vive en

Torrevieja. Zaragoza.
25/06/2007 Bernardo registra la Actualización: (Bernardo, Bernardo vive en

mudanza. Torrevieja) Torrevieja.
20/09/2012 Bernardo muere; se registra Borrado: -

el hecho. Bernardo
[…] […] […] […]
 Tiempo de Validez (TV): se define como el periodo en el que un hecho es cierto en el

mundo real.
Por ejemplo, el TV de (Bernardo, Zaragoza) es 06/03/85-15/06/07.

Nombre Ciudad TVI TVF
Bernardo Zaragoza 06/03/1985 ∞
Bernardo Torrevieja 15/06/2007 ∞
Bernardo Zaragoza 06/03/1985 15/06/2007
 Tiempo de Transacción (TT): se define como el tiempo en el que se ha incluido el hecho

en la base de datos.
 Datos Bitemporales: son aquellos que combinan (almacenan) TV y TT

– Tiempo de validez inicial (TVI)

– Tiempo de validez final (TVF)
– Tiempo de transacción inicial (TTI)
– Tiempo de transacción final (TTF)
Registro Nombre Ciudad TVI TVF TTI TTF

1 Bernardo Zaragoza 06/03/85 ∞ 07/03/85 uc
1 Bernardo Zaragoza 06/03/85 ∞ 07/03/85 25/06/07
2 Bernardo Zaragoza 06/03/85 15/06/07 25/06/07 uc
3 Bernardo Torrevieja 15/06/07 ∞ 25/06/07 uc


3 Bernardo Torrevieja 15/06/07 ∞ 25/06/07 uc



3 Bernardo Torrevieja 15/06/07 ∞ 25/06/07 20/09/12
4 Bernardo Torrevieja 15/06/07 20/09/12 20/09/12 uc

Ejemplo práctico 2: Interfaz para la Gestión de Bases de Datos Temporales (IGBDT)

Dentro del mundo académico, son pocos los trabajos publicados que abarcan aspectos relacionados
con la implementación de herramientas que posibiliten la administración y recuperación de
información almacenada en bases de datos temporales. La herramienta que se propone, IGBDT,
para gestionar bases de datos temporales permite a los usuarios manejar los valores de tiempo
válido para una determinada aplicación, por medio de interfaces amigables y de fácil manejo, con la
extensión de la funcionalidad del SGBD existente a través de dicha herramienta.
En el trabajo se adaptan extensiones a un conjunto de operadores del álgebra relacional, sobre la

base de aspectos temporales tales como el tiempo válido, para luego ortogonalmente extenderlo a
tiempo de transacción. Se definen para tiempo válido las versiones de los operadores del álgebra
relacional (unión, diferencia, intersección, producto cartesiano, selección, proyección, encuentro,
encuentro natural y encuentro).
La figura 12 muestra los módulos que conforman la arquitectura de la aplicación realizada.
Figura 12:
Arquitectura de la
interfaz IGBDT
A continuación se explica brevemente las funciones de cada módulo de IGBDT:

Explorador: En este módulo el usuario especifica las sentencias SQL con aspectos temporales que
desea ejecutar. Estas sentencias reciben un análisis lexicográfico, luego se genera una lista de
símbolos (tokens) que serán posteriormente entregados al módulo Parser para su análisis.
Parser: Realiza el análisis sintáctico, por lo que detecta si la sentencia SQL especificada constituye
una sentencia legal del lenguaje. En caso de existir algún error sintáctico, se muestra la
correspondiente notificación y se detiene el proceso de traducción. En caso de no existir error, se
genera un árbol sintáctico que es recibido por el módulo Traductor.
Traductor: Chequea si todas las tablas y atributos referenciados en la sentencia existen

actualmente. En caso de ser una consulta temporal, en este módulo se comprueba además si todas
las tablas tienen incluidos los valores de tiempos válidos o de transacción, o ambos. Chequeador:
Es un módulo auxiliar del Traductor, cuya función principal es la de proveer todas las operaciones
para realizar los distintos chequeos, tales como la existencia o no de una tabla referenciada en la
consulta, que los tipos de los atributos sean válidos, entre otros.
En caso de existir algún error, se notifica por medio del mensaje correspondiente y se detiene el
proceso de traducción.
Evaluador: Ejecuta una expresión basada en el álgebra temporal sobre un SGBD relacional,
posteriormente envía el resultado al módulo Explorador. Los resultados intermedios que se obtienen
son almacenados en tablas auxiliares, que serán creadas y eliminadas de forma automática por el
sistema.
Entre las principales opciones operativas que brinda la herramienta están:
 Creación bases de datos temporales por adición de tablas temporales.
 Visualización de bases de datos temporales.
 Ejecución de consultas temporales, que incluyen las sentencias temporales de inserción

(insert), actualización (update) y eliminación (delete).
Todo ello conlleva al soporte de los valores de tiempo válido y tiempo de transacción. Estos valores
de tiempo son tratados ortogonalmente, lo cual quiere decir que para cada sentencia que involucre
el tiempo válido existirá un correspondiente tiempo de transacción. Se pretende que pueda soportar
más de un SGBD, sobre todo aquellos que sean los de mayor demanda.
La figura 13 muestra la pantalla principal de la aplicación.

Figura 13: Pantalla

principal de IGBDT
La aplicación tiene con una interfaz amigable y de fácil manejo. Es posible contar con varias bases
de datos disponibles en un momento dado. Posee una sección para el procesamiento de las tablas
de una determinada base de datos, también pueden crearse nuevas tablas, así como modificar o
eliminar las ya existentes. La herramienta posibilita, además, la transformación de alguna de estas
tablas en su correspondiente tabla temporal, con la adición de los nuevos campos para el manejo
de la información temporal, ya sea el tiempo válido o el tiempo de transacción, según el usuario
determine.
Para la ejecución de las consultas posee un asistente que agiliza y facilita el trabajo de aquellos
usuarios no familiarizados con el lenguaje de consulta. Estas pueden ejecutarse además en Vista
Diseño (ver Figura 14). La herramienta notifica al usuario sobre la detección de los posibles errores
encontrados a la hora de ejecutar determinada consulta. Las tablas resultantes de la ejecución de
una consulta pueden exportarse, de manera que pueden persistir.

Figura 14: Pantalla para la ejecución de consultas temporales
CONCLUSIONES
En el presente trabajo se han expuesto las principales facilidades de la interfaz para la gestión de
bases de datos temporales, en su primera versión. Con la misma se pretende dotar a varios SGBD
convencionales, de extensiones para el manejo de aspectos temporales. Se definió un álgebra
relacional que tiene en cuenta el tiempo, lo cual sirvió de base para la definición de un lenguaje de
consulta, apto para tratar con bases de datos temporales, dotado de capacidad para evaluar
expresiones temporales en sus cláusulas; en las cuales se han introducido predicados,
constructores y operadores, todos ellos también temporales y que pueden ser combinados con los
elementos lógicos, para tratar con eventos, intervalos y otros conceptos propios de los sistemas
temporales.
Lo anterior facilitó la implementación de la herramienta IGBDT, que permite la administración y

recuperación de información almacenada en bases de datos temporales mediante la ejecución de
consultas temporales, en particular para tiempo válido.
En estos momentos se trabaja para incluir las consideraciones de tiempo de transacción, que son
más sencillas y de tratamiento ortogonal con respecto al tiempo válido.

CREANDO TABLAS TEMPORALES EN SQL SERVER

CREATE TABLE #nombreTabla
Creamos una tabla temporal de la misma forma que una tabla común, con la sentencia CREATE
TABLE la única diferencia es el símbolo # antes del nombre de la tabla:
1 CREATE TABLE #tablaTemporal( productDescriptionID INT , description NVARCHAR(400))
Estas tablas son creadas en la base de datos tempdb, en la carpeta llamada Temporary Tables:
Cabe aclarar que si cerramos la conexión actual, esta tabla se eliminará. Por ello, este tipo de tablas
temporales es conocido como Tablas Temporales Locales.
CTE (Common Table Expressions)
A diferencia de las anteriores, este tipo de tabla temporal solo puede ser utilizado durante la
ejecución del bloque de código y solo en una ocasión después de haber declarado el CTE.
1 USE AdventureWorks2012
2 ;WITH nombreCTE ( idProducto , Descripcion )
3 AS
4(
5 SELECT ProductDescriptionID, Description FROMProduction.ProductDescription
6)
7 SELECT * FROM nombreCTE;

O también de la siguiente forma, solo que así nos tendremos que adaptar a los nombres de
columna que nuestro query arroje:
2 ;WITH nombreCTE
3 AS
4(
6)
7 SELECT * FROM nombreCTE;

Declarando varios CTE:

02 ;WITH nombreCTE
03 AS
04 (
06 )
07 , nombreCTE2
08 AS
09 (
10 select * from HumanResources.Department
11 )
12 SELECT * FROM nombreCTE, nombreCTE2;

VARIABLES TIPO TABLA
Desde hace algunas versiones de SQL SERVER, se agregó la variable tipo TABLA, al igual que
los CTE, solo están vigente durante la ejecución del bloque de código.
1 DECLARE @nombreTabla TABLE( idDescripcion INT, Descripcion NVARCHAR(400) )

2
3 INSERT INTO @nombreTabla
5
6 SELECT * FROM @nombreTabla
En resumen, existen tablas temporales locales y globales que pueden ser creadas a partir de
CREATE TABLE #nombreTabla y CREATE TABLE ##nombreTabla y pueden ser eliminadas con
DROP TABLE y solo están vigentes durante la conexión o conexiones que fueron abiertas.
A diferencia de los CTEs y variables TIPO TABLA estás solo están vigentes durante menor tiempo,
las primeras solo durante el bloque de código y pueden ser llamadas solo una vez, las segundas
solo durante el bloque de código en ejecución.
Otra gran ventaja de los CTEs es que es posible hacer referencia dentro de la misma declaración
del CTE mejor conocido como CTE Recursivo, en otra entrega les mostraré como lograr esto.

Indexando Tablas Temporales de SQL Server

El siguiente script se creará tres tablas; la tabla temporal sin índice, la tabla temporal con un índice
no agrupado y la tabla temporal con el índice agrupado, y las llenará con registros de 100k desde la
tabla de pruebas CountryInfo, luego recuperará estos registros de las tablas:
USE SQLShackDemo
GO
set nocount on
go
DECLARE @StartTime AS DATETIME = GETDATE()

CREATE TABLE #TempWithNoIndex
([CountyCode] NVARCHAR(100),[RowVersion] DateTime)
INSERT INTO #TempWithNoIndex
SELECT TOP 100000 * FROM [dbo].[CountryInfo]
SELECT * FROM #TempWithNoIndex WHERE CountyCode='JFK'
PRINT '#TempWithNoIndex'
PRINT DATEDIFF(ms,@StartTime,GETDATE())
DROP TABLE #TempWithNoIndex
GO

CREATE TABLE #TempWithNonClusterIndex
INSERT INTO #TempWithNonClusterIndex
CREATE NONCLUSTERED INDEX ix_tempNCIndexAft ON #TempWithNonClusterIndex ([CountyCode],[RowVe
rsion]);
SELECT * FROM #TempWithNonClusterIndex WHERE CountyCode='JFK'
PRINT '#TempWithNonClusterIndex'
DROP TABLE #TempWithNonClusterIndex
GO

CREATE TABLE #TempWithClusterIndex
CREATE CLUSTERED INDEX ix_tempCIndexAft ON #TempWithClusterIndex ([CountyCode],[RowVersion]);
INSERT INTO #TempWithClusterIndex
SELECT TOP 100000 CountyCode,RowVersion FROM [dbo].[CountryInfo]
SELECT * FROM #TempWithClusterIndex WHERE CountyCode='JFK'
PRINT '#TempWithClusterIndex'
DROP TABLE #TempWithClusterIndex
GO

Después de ejecutar el script previo, el resultado nos mostrará que, en nuestro caso, añadir un
índice no agrupado es peor que tener la tabla sin índice, 1.2 veces el tiempo en nuestro caso, pero
añadir un índice agrupado mejorará el desempeño general 1 vez en nuestro caso, dado que la
comparación e nuestro caso es en milisegundos:
Revisando el plan de ejecución generado después de la ejecución, veremos que, ya que no tenemos
combinaciones con grandes tablas o consultas complejas, los datos recuperados desde las tres
tablas consumen la misma cantidad de recursos (1%) y difieren en el operador que es usado para
recuperar los datos; Table Scan en el caso de la tabla temporal sin índice, Index Seek en el caso de
la tabla temporal con índice no agrupado y Clustered Index Seek en el caso de la tabla con índice
agrupado.
También, usted puede derivar desde el plan de ejecución que la tabla con índice no agrupado tomó
más tiempo (1063 ms) y recursos (47% de toda la ejecución) durante el proceso de inserción de
tabla, opuesto a la tabla con índice agrupado, la inserción tomó menos tiempo (827 ms) y recursos
(32% de toda la ejecución):


En el script previo creamos un índice no agrupado después de llenar la tabla temporal y el índice
agrupado antes de llenar la tabla temporal. ¿Pero es diferente cuando creamos el índice antes o
después de llenar la tabla temporal? Para contestar esta pregunta, realicemos la siguiente prueba
en la cual revisaremos el tiempo consumido en todos los casos; añadir un índice no agrupado antes
de llenar la tabla temporal, añadir un índice no agrupado después de llenar la tabla temporal, añadir
un índice agrupado antes de llenar la tabla y añadir un índice agrupado después de llenar la tabla
temporal:
USE SQLShackDemo
GO
set nocount on
GO
CREATE TABLE #TempWithNonClusterIndexBefore
CREATE NONCLUSTERED INDEX ix_tempNCIndexBef ON #TempWithNonClusterIndexBefore ([CountyCode],[RowVersion]);
INSERT INTO #TempWithNonClusterIndexBefore
PRINT '#TempWithNonClusterIndexBefore'
DROP TABLE #TempWithNonClusterIndexBefore
GO
CREATE TABLE #TempWithNonClusterIndexAfter
INSERT INTO #TempWithNonClusterIndexAfter
CREATE NONCLUSTERED INDEX ix_tempNCIndexAft ON #TempWithNonClusterIndexAfter ([CountyCode],[RowVersion]);
PRINT '#TempWithNonClusterIndexAfter'
DROP TABLE #TempWithNonClusterIndexAfter
GO
CREATE TABLE #TempWithClusterIndexBefore
CREATE CLUSTERED INDEX ix_tempCIndexBef ON #TempWithClusterIndexBefore ([CountyCode],[RowVersion]);
INSERT INTO #TempWithClusterIndexBefore
PRINT '#TempWithClusterIndexBefore'
DROP TABLE #TempWithClusterIndexBefore
GO
CREATE TABLE #TempWithClusterIndexAfter
INSERT INTO #TempWithClusterIndexAfter
SELECT TOP 100000 CountyCode,RowVersion FROM [dbo].[CountryInfo]
CREATE CLUSTERED INDEX ix_tempCIndexAft ON #TempWithClusterIndexAfter ([CountyCode],[RowVersion]);
PRINT '#TempWithClusterIndexAfter'
DROP TABLE #TempWithClusterIndexAfter
GO

Está claro en el resultado generado de ejecutar el script previo que es mejor crear el índice no
agrupado después de llenar la tabla, ya que es 1.2% más rápido, y crear el índice agrupado después
de llenar la tabla, ya que es 2.5% más rápido, debido al mecanismo que es usado para llenar las
tablas y crear los índices:
Revisando el plan de ejecución, el resultado no mostrará que crear el índice agrupado antes de la
inserción consume 18% de toda la ejecución, cuando crearlo después de la inserción consumirá
26% de toda la ejecución. Por un lado, crear los índices no agrupado después de la inserción
consume 27% de recursos comparado con el 29% que es consumido creándolo antes del proceso
de inserción:

2.7. Bases de Datos Seguras

¿De qué seguridad hablamos?
La situación ideal es aquella en la que se logra gestionar el estado y garantizar un nivel adecuado
de los tres aspectos fundamentales de la seguridad de la información: integridad, confidencialidad
y disponibilidad.
Confidencialidad
En términos de seguridad de la información, la confidencialidad hace referencia a la necesidad de

ocultar o mantener secreto sobre determinada información o recursos.
Objetivo de la confidencialidad
Prevenir la divulgación no autorizada de la información.
En general, cualquier empresa pública o privada y de cualquier ámbito de actuación, requiere que
cierta información no sea accedida por diferentes motivos. Uno de los ejemplos más típicos es el
del ejército de un país. Además, es sabido que los logros más importantes en materia de seguridad
siempre van ligados a temas estratégicos militares.
Un ejemplo típico de mecanismo que garantice la confidencialidad es la Criptografía, cuyo objetivo
es cifrar o encriptar los datos para que resulten incomprensibles a aquellos usuarios que no
disponen de los permisos suficientes.

Pero, incluso en esta circunstancia existe un dato sensible que hay que proteger y es la clave de
encriptación. Esta clave es necesaria para que el usuario adecuado pueda descifrar la información
recibida. En función del tipo de mecanismo de encriptación utilizado, la clave puede/debe viajar por
la red, pudiendo ser capturada mediante herramientas diseñadas para ello. Si se produce esta
situación la confidencialidad de la operación realizada (sea bancaria, administrativa o de cualquier
tipo) queda comprometida.
Integridad
En términos de seguridad de la información, la integridad hace referencia a la fidelidad de la

información o recursos, y normalmente se expresa en lo referente a prevenir el cambio impropio o
desautorizado.
Objetivo de la integridad
Prevenir modificaciones no autorizadas de la información.
La integridad hace referencia a:
 La integridad de los datos (el volumen de la información).

 La integridad del origen (la fuente de los datos, llamada autenticación).
Es importante hacer hincapié en la integridad del origen, ya que puede afectar a su exactitud,
credibilidad y confianza que las personas ponen en la información.
A menudo ocurre que al hablar de integridad de la información no se da en estos dos aspectos.
Por ejemplo, cuando un periódico difunde una información cuya fuente no es correcta, podemos
decir que se mantiene la integridad de la información ya que se difunde por medio impreso, pero sin
embargo, al ser la fuente de esa información errónea no se está manteniendo la integridad del
origen, ya que la fuente no es correcta.
Disponibilidad
En términos de seguridad de la información, la disponibilidad hace referencia a que la información

del sistema debe permanecer accesible a elementos autorizados.
Objetivo de la disponibilidad
Prevenir interrupciones no autorizadas/controladas de los recursos informáticos.
En términos de seguridad informática un sistema está disponible cuando su diseño e

implementación permite deliberadamente negar el acceso a datos o servicios determinados. Es
decir, un sistema es disponible si permite no estar disponible.

Y un sistema 'no disponible' es tan malo como no tener sistema. No sirve.

5 consejos para mantener seguras tus bases de datos
Cuando damos consejos de privacidad y seguridad solemos hablar de contraseñas fuertes,

recomendamos hacer copias de respaldo, contar con soluciones de seguridad, mantener los
sistemas actualizados y evitar las configuraciones por defecto. En general, suelen ser los cuidados
básicos y esenciales que cualquier administrador de infraestructura debe considerar. Sin embargo,
según el sistema que esté queriendo proteger, hay algunas cuestiones adicionales a tener en
cuenta.
Teniendo en cuenta la alarmante frecuencia con la que llegan a los titulares los robos y filtraciones
de información, presentamos cinco consejos clave para mantener bases de datos seguras,
especialmente cuando están alojadas en la nube o en servicios tercer izados.
 1 Limita el acceso a la base de datos
“Muchas manos en un plato hacen mucho garabato”, repetía mi abuela cada vez que todos los nietos
queríamos ayudarla a cocinar.
Resulta que este viejo refrán es ideal para aplicar a la seguridad de la información: cuando muchas
personas tienen injerencia en un tema, el resultado no puede ser positivo.
Algo similar ocurre con los accesos a las bases de datos: cuanto más acotados los permisos y
privilegios, mejor.
Un riguroso control de acceso es el primer paso para mantener a los atacantes lejos de tu
información. Además de los permisos básicos como en cualquier sistema, en este caso también se
debe considerar:
Limitar el acceso a los datos sensibles tanto por parte de los usuarios como de los procedimientos,
es decir, que solo determinados usuarios y procedimientos estén autorizados a realizar consultas
en información sensible.
Limitar el uso de los procedimientos importantes solo a usuarios específicos.
Siempre que sea posible, evitar las concurrencias y acceso fuera del horario laboral o habitual.
Por otro lado, resulta una buena práctica deshabilitar todos los servicios y procedimientos que no
se utilicen, para evitar que sean atacados. Además, siempre que sea posible, la base de datos debe
estar en un servidor que no tenga acceso directamente desde internet, para evitar que la información
quede expuesta a atacantes remotos.

 2 Identifica los datos sensibles y los datos críticos
El primer paso, antes de pensar en las técnicas y herramientas de protección, es analizar e

identificar cuál es la información importante que se debe proteger. Para esto, es importante entender
la lógica y arquitectura de la base de datos, para poder determinar con facilidad dónde y cómo se
almacenan los datos sensibles.
No todos los datos que almacenamos son críticos o deben ser protegidos, por lo que no tiene sentido
gastar tiempo y recursos en esta información.
También es recomendable llevar un inventario de las bases de datos de la compañía, teniendo en

cuenta todas las áreas. La única forma de tener una administración prolija y no perder información
es tener conocimiento y registro de todas las instancias y bases de datos de la compañía.
Además, el inventario resulta especialmente útil al momento de hacer un respaldo de la información,

para evitar que datos críticos queden fuera del esquema.
 3 Cifra la información
Una vez identificados los datos sensibles y la información confidencial, una buena práctica es utilizar
algoritmos robustos para cifrar estos datos.
Cuando un atacante explota una vulnerabilidad y logra tener acceso a un servidor o un sistema, lo
primero que intentará robar son las bases de datos. Son un tesoro codiciado, ya que normalmente
incluyen muchos gigas de valiosa información; la mejor manera de preservarla es volverla
ilegible para cualquier persona que llegue a ella sin autorización.
 4 Anonimiza las bases de datos de que no son productivas
Muchas empresas invierten tiempo y recursos en proteger sus bases de datos productivos, pero al
momento de hacer un desarrollo o crear un entorno de pruebas, simplemente hacen una copia de
la base original y comienzan a utilizarla en ambientes mucho menos controlados, exponiendo de
esta manera toda la información sensible.
El enmascaramiento o anonimización es un proceso mediante el cual se crea una versión similar,

manteniendo la misma estructura que la original, pero alterando los datos sensibles para que
permanezcan protegidos. A partir de esta técnica se cambian los valores respetando el formato.
Los datos se pueden cambiar de diferentes maneras: mezclándolos entre sí, cifrándolos, mezclando
los caracteres o sustituyendo palabras. El método elegido dependerá del administrador, las reglas
y formatos que se deban mantener, pero sea cual sea, debe garantizar que el proceso
sea irreversible; es decir, que no se pueda hacer ingeniería reversa para volver a obtener los datos
originales.

Esta técnica es especialmente utilizada (y recomendada) para las bases de datos que forman parte
de entornos de pruebas y desarrollo, ya que permite mantener la estructura lógica de los datos
mientras garantiza que la información sensible del cliente no está disponible fuera del entorno de
producción.
 5 Monitorea la actividad de tu base de datos
Estar atento, auditar y registrar las acciones y movimientos sobre los datos permite saber quién,
qué, cuándo y cómo ha manipulado la información. Tener un historial completo de las transacciones
permite comprender patrones en el acceso y modificación de los datos y así evitar fugas de
información, controlar cambios fraudulentos y detectar acciones sospechosas en tiempo real.
Recuerda seguir estos consejos y ser muy precavido a la hora de administrar y proteger tus bases
de datos. La información que estas alojan es muy valiosa para la empresa y un botín codiciado para
los atacantes, por lo que sin dudas merece toda tu atención.
Principios básicos de seguridad de bases de datos
En esta sección daremos siete recomendaciones sobre seguridad en bases de datos, instaladas en
servidores propios de la organización.
2.1 Identifique su sensibilidad
No se puede asegurar lo que no se conoce.
Confeccione un buen catálogo de tablas o datos sensibles [2] de sus instancias de base de
datos. Además, automatice el proceso de identificación, ya que estos datos y su correspondiente
ubicación pueden estar en constante cambio debido a nuevas aplicaciones o cambios producto de
fusiones y adquisiciones.
Desarrolle o adquiera herramientas de identificación, asegurando éstas contra el malware [3],

colocado en su base de datos el resultado de los ataques de inyección SQL [4]; pues aparte de
exponer información confidencial debido a vulnerabilidades, como la inyección SQL, también facilita
a los atacantes incorporar otros ataques en el interior de la base de datos.
2.2 Evaluación de la vulnerabilidad y la configuración
Evalúe su configuración de bases de datos, para
asegurarse que no tiene huecos de seguridad.
Esto incluye la verificación de la forma en que se instaló la
base de datos y su sistema operativo (por ejemplo, la
comprobación privilegios de grupos de archivo -lectura,
escritura y ejecución- de base de datos y bitácoras de
transacciones).

Asimismo con archivos con parámetros de configuración y programas ejecutables.

Además, es necesario verificar que no se está ejecutando la base de datos con versiones que
incluyen vulnerabilidades conocidas; así como impedir consultas SQL desde las aplicaciones o
capa de usuarios. Para ello se pueden considerar (como administrador):
 Limitar el acceso a los procedimientos a ciertos usuarios.
 Delimitar el acceso a los datos para ciertos usuarios, procedimientos y/o datos.
 Declinar la coincidencia de horarios entre usuarios que coincidan.

2.3 Endurecimiento
Como resultado de una evaluación de la vulnerabilidad a

menudo se dan una serie de recomendaciones específicas. Este
es el primer paso en el endurecimiento de la base de datos.
Otros elementos de endurecimiento implican la eliminación de
todas las funciones y opciones que se no utilicen. Aplique una
política estricta sobre que se puede y que no se puede hacer,
pero asegúrese de desactivar lo que no necesita.
2.4 Audite
Una vez que haya creado una configuración y controles de

endurecimiento, realice auto evaluaciones y seguimiento a las
recomendaciones de auditoría para asegurar que no se desvíe
de su objetivo (la seguridad).
Automatice el control de la configuración de tal forma que se
registre cualquier cambio en la misma. Implemente alertas sobre
cambios en la configuración. Cada vez que un cambio se realice,
este podría afectar a la seguridad de la base de datos.
2.5 Monitoreo
Monitoreo en tiempo real de la actividad de base de datos es clave para limitar su exposición, aplique
o adquiera agentes inteligentes [5] de monitoreo, detección de intrusiones y uso indebido.
Por ejemplo, alertas sobre patrones inusuales de acceso, que podrían indicar la presencia de un
ataque de inyección SQL, cambios no autorizados a los datos, cambios en privilegios de las cuentas,
y los cambios de configuración que se ejecutan a mediante de comandos de SQL.
Recuerde que el monitoreo usuarios privilegiados, es requisito para la gobernabilidad de datos y
cumplimiento de regulaciones como SOX y regulaciones de privacidad. También, ayuda a detectar

intrusiones, ya que muchos de los ataques más comunes se hacen con privilegios de usuario de
alto nivel.
El monitoreo dinámico es también un elemento esencial de la evaluación de vulnerabilidad, le
permite ir más allá de evaluaciones estáticas o forenses. Un ejemplo clásico lo vemos cuando
múltiples usuarios comparten credenciales con privilegios o un número excesivo de inicios de sesión
de base de datos.
2.6 Pistas de Auditoría
Aplique pistas de auditoría y genere trazabilidad de las actividades
que afectan la integridad de los datos, o la visualización los datos
sensibles.
Recuerde que es un requisito de auditoría, y también es importante
para las investigaciones forenses.
La mayoría de las organizaciones en la actualidad emplean alguna
forma de manual de auditoría de transacciones o aplicaciones
nativas de los sistemas gestores de bases de datos. Sin embargo,
estas aplicaciones son a menudo desactivadas, debido a:
 su complejidad
 altos costos operativos
 problemas de rendimiento
 la falta de segregación de funciones y
 la necesidad mayor capacidad de almacenamiento.
Afortunadamente, se han desarrollado soluciones con un mínimo de impacto en el rendimiento y

poco costo operativo, basado en tecnologías de agente inteligentes.
2.7 Autenticación, control de acceso, y Gestión de derechos
No todos los datos y no todos los usuarios son creados iguales.
Usted debe autenticar a los usuarios, garantizar la rendición de
cuentas por usuario, y administrar los privilegios para de limitar
el acceso a los datos.
Implemente y revise periódicamente los informes sobre de
derechos de usuarios, como parte de un proceso de formal de
auditoría.
Utilice el cifrado [6] para hacer ilegibles los datos confidenciales, complique el trabajo a los
atacantes, esto incluye el cifrado de los datos en tránsito, de modo que un atacante no puede
escuchar en la capa de red y tener acceso a los datos cuando se envía al cliente de base de datos.

Propósito
Proporcionan lo que se denomina control de acceso discrecional (los usuarios son los encargados
de establecer el control a través de privilegios), pero existen “bases de datos seguras” que soportan
control de acceso obligatorio, en las cuales los datos presentan diversos niveles de confidencialidad
y los usuarios diferentes clases de autoridad (por lo que se las denomina también base de datos
multinivel)
En la ilustración siguiente se muestra una arquitectura de BizTalk Server altamente distribuida que
tiene en cuenta la defensa en profundidad.
Figura 15: Arquitectura distribuida segura de BizTalk Server

Esta arquitectura contiene los cinco dominios siguientes:
Red perimetral: La red perimetral (también denominada DMZ, zona desmilitarizada y subred
protegida) contiene servidores que proporcionan servicios relacionados con Internet a una empresa.
Este dominio puede contener servidores en los que se encuentran las ubicaciones físicas en las que
los transportes que se comunican con Internet envían mensajes al servidor BizTalk Server y los
reciben de éste.
En este dominio no hay servidores de BizTalk, ubicaciones de recepción de BizTalk ni servidores

de inicio de sesión único empresarial. Si se usa el adaptador de HTTP o SOAP, se pueden emplear
reglas de proxy inversas (la implementación del servidor Forefront Threat Management Gateway
(TMG) 2010 se denomina Publicación en Web) para retransmitir el mensaje del firewall conectado
a Internet (FW4) al firewall que protege el dominio de interfaces de servicio (FW3).
En la ilustración anterior, los servidores de la red perimetral representan servidores que se

encuentran en un dominio externo al entorno de BizTalk Server. Por consiguiente, es posible que
algunos de estos servidores se encuentren en ubicaciones remotas. Por ejemplo, el servidor de
protocolo de transferencia de archivos (FTP) podría ser en una ubicación remota; el servidor de
Protocolo Simple de transferencia de correo (SMTP) podría ser el servidor de correo electrónico
corporativo, un proveedor de servicios Internet (ISP) server o un servidor SMTP remoto.
Dominio de Interfaces de servicio: Este es el domino en el que se inicia el procesamiento del

mensaje. Este dominio contiene los servidores que tienen los controladores de envío y recepción de
BizTalk. Aquí se encuentran los puertos de BizTalk Server, las ubicaciones de recepción, las
canalizaciones, las asignaciones, los esquemas y los ensamblados para recibir, en rutar y enviar
mensajes. El número de servidores de BizTalk de este dominio depende del número de hosts e
instancias de host que requieren las necesidades de rendimiento de la organización.
Dominio de servicios: Este dominio contiene los servicios en los que confían los servidores del
dominio de procesamiento y que necesitan procesar los mensajes correctamente pero requieren
una capa de defensa adicional para protegerse de los ataques procedentes de la red perimetral,
como por ejemplo los servidores de procesamiento que tienen las orquestaciones de BizTalk, las
canalizaciones, servicios de inicio de sesión único (SSO) empresarial, el motor de reglas de
negocios y otros procesos empresariales.

Este dominio contiene además los servicios a los que debe tener acceso el domino corporativo pero
que siguen necesitando protección contra amenazas externas. Uno de los servidores en este
dominio contiene las herramientas administrativas: consola de administración de BizTalk y la utilidad
de administración de inicio de sesión único (SSO) empresarial. Asimismo, este dominio contiene el
servidor secreto principal de SSO, en el que se encuentra la clave secreta principal (clave de cifrado)
que utiliza el sistema SSO para cifrar y descifrar los datos de la base de datos de SSO. Uno de los
servidores de este dominio tiene una instancia de un host que admite el seguimiento de la
información empresarial y de supervisión de estado.
Dominio de datos: El dominio de datos es el que está más alejado de Internet, ya que contiene las
bases de datos de SQL Server en las que se almacenan los datos empresariales y de los procesos
más importantes, y no confía en ningún otro dominio. Aunque cada una de las bases de datos de
BizTalk Server puede encontrarse en un servidor distinto que ejecute SQL Server, se recomienda
combinar las bases de datos en función del tipo de procesamiento que realizan principalmente (de
lectura, de escritura o ambos).
 Un servidor SQL Server para cada base de datos de cuadro de mensajes. Puede agregar más
bases de datos de cuadro de mensajes para equilibrar la carga. Estas bases de datos son de
lectura o escritura intensiva.
 Un servidor SQL Server para la base de datos de SSO. BizTalk Server realiza principalmente
operaciones de lectura en esta base de datos. Esta base de datos contiene datos confidenciales
y necesita los permisos de acceso más restrictivos.
 Un servidor de SQL Server para la administración de BizTalk y las bases de datos de motor de
reglas de negocios. BizTalk Server principalmente operaciones de lectura en estas bases de
datos. Este servidor contiene también la base de datos de seguimiento, que es de escritura
intensiva.
 Un servidor SQL Server para la base de datos de seguimiento de servidor de análisis.
 Un servidor SQL Server para la base de datos de Microsoft Operations Manager (MOM).
 Un servidor SQL Server para el sistema de destino de trasvase de registros.

En la ilustración anterior, el servidor Forefront Threat Management Gateway (TMG) 2010 actúa
como firewall de software para proteger y contener cada uno de estos dominios. Además, cada
dominio tiene su propio controlador de dominio; la confianza se establece desde el dominio que
contiene los servidores esenciales (el dominio de datos) hacia los servidores que se comunican con
el exterior (dominio corporativo y red perimetral), y los servidores sólo tienen acceso a los servicios
de los demás dominios con los que necesitan conectarse.
Hay un firewall que restringe el tráfico dirigido al dominio de datos procedente de los dominios de
servicios y de interfaces de servicio (FW1). De un modo parecido, hay un firewall (FW2) que
restringe el tráfico dirigido al dominio de servicios procedente de los dominios de interfaces de
servicio y operaciones.
Dominio corporativo: Este es el dominio de intranet y contiene todos los equipos de escritorio de
la compañía o departamento, y todos los servidores que ofrecen servicios a los trabajadores de
información dentro de la organización. Dentro de este dominio, hay dos contenedores lógicos
distintos:
Servicios de la intranet. En este contenedor se encuentran los servidores que reciben y

envían mensajes de socios internos para los adaptadores SQL y de archivo. Aunque esto es
una intranet, se diferencia de una red corporativa en que en ésta la mayoría de los usuarios
tienen cuentas y servicios. De un modo parecido a la red perimetral que aparece en la
ilustración, algunos de los servidores de este contenedor pueden encontrarse en una
ubicación diferente. Por ejemplo, la ubicación (carpeta) de envío y recepción del adaptador
de archivo puede ubicarse en cualquier capa exterior al dominio de interfaces de servicio,
mientras que el servidor que ejecuta SQL Server para el adaptador SQL puede ubicarse en
el domino de interfaces de servicio.
Operaciones. Este contenedor tiene clientes de servicios de Terminal Server que los
profesionales de TI utilizan para supervisar, mantener y administrar de modo remoto el
rendimiento y el estado de todos los servidores del entorno. Con los servicios de Terminal
Server, los profesionales de TI pueden conectarse al servidor de administración del dominio
de servicios y realizar desde éste las tareas administrativas de todos los servidores del
entorno.
 El dominio de datos no confía en ningún otro dominio.

 El dominio de interfaces de servicio confía en el dominio de datos.
 El dominio de servicios confía en el dominio de datos.
 El dominio corporativo confía en los dominios de servicios.

Ejemplo práctico 1: Cifrado transparente de datos (TDE) para el espacio de trabajo

de revisor en SQL Server.
Puede adoptar varias precauciones para ayudar a proteger la base de datos, como diseñar un
sistema de protección, cifrar activos confidenciales y crear un firewall en torno a los servidores de
base de datos. Sin embargo, en un escenario en el que se sustraigan los medios físicos (como
unidades o cintas de copia de seguridad) un intruso malintencionado puede restaurar o adjuntar la
base de datos y examinar los datos. Una solución consiste en cifrar los datos confidenciales de la
base de datos y proteger las claves utilizadas para cifrar los datos con un certificado. Esto evita que
alguien que no tenga las claves pueda utilizar los datos, pero este tipo de protección debe planearse
con antelación.
El cifrado transparente de datos (TDE) permite cifrar datos confidenciales tales como números de
tarjetas de crédito almacenados en tablas y grupos de archivos. Los datos cifrados se descifran de
forma transparente para una aplicación o un usuario de base de datos que tenga acceso a los datos.
TDE ayuda a proteger los datos almacenados en medios en caso de que se sustraigan los medios
de almacenamiento o lo archivos de datos. SQL Server usa mecanismos de autenticación,
autorización y auditoría para proteger los datos de la base de datos pero no los archivos de datos
del sistema operativo donde se almacenan datos. Para proteger estos archivos de datos, SQL
Server proporciona TDE. TDE cifra los datos confidenciales almacenados en los archivos de datos.
Para evitar descifrados no autorizados, TDE almacena las claves de cifrado en un módulo de
seguridad externo a la base de datos.
TDE realiza cifrado y descifrado de E/A en tiempo real de los archivos de registro y datos. El cifrado
usa una clave de cifrado de base de datos (DEK), que se almacena en el registro de arranque de la
base de datos a efectos de disponibilidad durante la recuperación. La DEK es una clave simétrica
protegida mediante el uso de un certificado almacenado en la base de datos maestra del servidor o
una clave asimétrica protegida por un módulo EKM. TDE protege los datos sin actividad, es decir,
los archivos de registro y de datos. Proporciona la posibilidad de cumplir con muchas leyes,
reglamentos y directrices establecidos en diversos sectores. Esto permite a los desarrolladores de
software cifrar datos mediante el uso de algoritmos de cifrado AES y 3DES sin cambiar las
aplicaciones existentes.
El cifrado del archivo de base de datos se realiza en el nivel de página. Las páginas de una base de
datos cifrada se cifran antes de que se escriban en el disco y se descifran cuando se leen en la
memoria. TDE no aumenta el tamaño de la base de datos cifrada.
Ventajas de utilizar TDE:

 Como administrador de seguridad tendrá la tranquilidad de que los datos confidenciales estén
protegidos en caso de sustracción de los medios de almacenamiento o de los archivos de
datos.
 La implementación de TDE ayuda a abordar los aspectos de cumplimiento reglamentario

relacionados con la seguridad.
 No es necesario crear desencadenadores ni vistas para descifrar los datos para una
aplicación o usuario autorizados. Los datos de las tablas se descifran de forma transparente
para la aplicación y el usuario de la base de datos.
 No es necesario que las aplicaciones y usuarios de base de datos sepan que los datos a los
que acceden están almacenados en modo cifrado. Los datos se descifran de forma
transparente para las aplicaciones y usuarios de base de datos.
 No hace falta modificar las aplicaciones para controlar los datos cifrados. La base de datos
administra el cifrado y descifrado de datos.
 Las operaciones de administración de claves están automatizadas. El usuario o la aplicación

no necesitan administrar las claves de cifrado.
Ejemplo de TDE
Puede usar los comandos de SQL siguientes para configurar TDE. Puede elegir la contraseña para
la clave principal, y al realizar la copia de seguridad de la clave principal, puede elegir la carpeta y
el nombre de archivo.
USE master
GO
/* Verify master key */
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%MS_DatabaseMasterKey%'
GO
/* if there are no records found, then it means there was no predefined Master Key.
To create a Master Key, you can execute the below mentioned TSQL code. */
/* Create master key */

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'rev$$@admin';
GO
/* Backup master key */
OPEN MASTER KEY DECRYPTION BY PASSWORD = 'rev$$@admin';
GO

BACKUP MASTER KEY TO FILE = 'D:\mssqlbackup\master\masterkey.mk'

ENCRYPTION BY PASSWORD = 'rev$$@admin';
GO
/* Create Certificate */
CREATE CERTIFICATE rev_cert WITH SUBJECT = 'REV Server Certificate';
GO
/* Verify Certificate */
SELECT * FROM sys.certificates where [name] = 'rev_cert'
GO
/* Backup certificate */
BACKUP CERTIFICATE rev_cert TO FILE = 'D:\mssqlbackup\master\rev.cer'
WITH PRIVATE KEY (
FILE = 'D:\mssqlbackup\master\rev.pvk',
ENCRYPTION BY PASSWORD = 'rev$$@admin');
GO
--use rev database

USE rev
GO
/* Create Encryption key */
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE rev_cert;
GO
/* Encrypt database */
ALTER DATABASE revdb SET ENCRYPTION ON;
GO
/* Verify Encryption */
SELECT
DB_NAME(database_id) AS DatabaseName
,Encryption_State AS EncryptionState
,key_algorithm AS Algorithm
,key_length AS KeyLength
FROM sys.dm_database_encryption_keys
GO
SELECT
NAME AS DatabaseName
,IS_ENCRYPTED AS IsEncrypted
FROM sys.databases where name ='revdb'
GO

Ejemplo práctico 2: Seguridad de la bases de datos de tipo PostgreSQL

La seguridad de las bases de datos es un aspecto prioritario de su manejo. En el pasado se ha
contado con sistemas de bases de datos funcionales, que han dejado de utilizarse después de
comprobar lo vulnerable que eran a ser accedidas por usuarios no autorizados. Por el ejemplo, el
caso de bases de sistemas FoxPro 2.0 que podían accederse y modificarse usando aplicaciones
de Excel 2000.
Para mejorar la seguridad en torno a una base de datos se puede recurrir a varios medios:
a) Restricciones propias del entorno de red para su acceso remoto. Esto puede implicar limitar la
cantidad de servicios en el servidor y los protocolos por los cuales se pueda tener acceso a él.
A pesar de que se puedan restringir el uso de carpetas compartidas en el servidor, cuando la
base es parte de un servicio Web o un servicio sobre una intranet, generalmente se dejan
abiertos los puertos para el servicio FTP. Sin embargo se puede limitar este servicio
únicamente para el uso del Webmaster y hacia directorios no relacionados directamente con
la base de datos.
b) Dentro de una aplicación Web también se pueden imponer ciertas medidas de seguridad. Se
puede omitir el uso de Telnet y en su lugar usar una aplicación como pgAdmin para acceder a
la base de datos. La aplicación Web, puede incluir un sistema de validación que incluya la
identificación del usuario, y manejar una tabla de usuarios con funciones restringidas, lo cual
implicaría limitar la cantidad de páginas Web o aplicaciones basadas en PHP a que cada
usuario puede tener acceso, o sobre qué datos tiene derecho de lectura o escritura.
c) Restricciones de seguridad impuestas por el propio gestor de postgresql: En determinado

momento la base de datos puede ser accesible para varios usuarios, pero cada uno puede tener
un perfil diferente de privilegios que limiten su capacidad de acción. Es justamente en torno a este
tipo de restricciones que se enfocara esta sección del curso.

El manejo de roles
A diferencia de Mysql, PostgreSQL no tiene una tabla específica en que se almacenen datos delos
usuarios. En su lugar usa una categoría diferente de objetos llamados roles. Existen los llamados
Group Roles y los Login roles. Se puede administrar una base de datos de este tipo sin Group Roles
(roles de grupo) pero es necesario contar con al menos un role para logear al sistema.
Al examinar las propiedades del Role root se observa lo siguiente:

Aun para un neófito, es evidente que se pueden configurar privilegios, o hacer cambios de
password sobre el rol, en una situación similar al manejo de usuarios que se hace en otros tipos
de bases de datos.
Para crear un nuevo rol se puede recurrir a dos medios:
a) Usar el menú contextual que aparece al hacer clic derecho sobre el objeto Roles en pgAdmin,
y proceder a llenar los cuadros de diálogos que aparezcan.
b) Usar el comando de SQL CREATE ROLE, de acuerdo a la siguiente sintaxis:
CREATE ROLE name;
Para eliminar un role se puede utilizar el comando DROPE ROLE. También es posible
consultar los roles existentes mediante el uso del comando SELECT.

El manejo de grupos de roles es una forma de conceder o limitar privilegios a todo un grupo de
personas en lugar de manejar privilegios individuales. Al hacer clic derecho sobre el objeto Group
roles, aparece el siguiente cuadro de dialogo.

Puede observarse que las propiedades son las similares que para un role ordinario, con la diferencia
de que una vez establecidas para un grupo, cualquier nuevo rol que se incluya dentro de este grupo
(en la pestaña role membreship) heredara los privilegios y restricciones del grupo.
Ya que las tablas y los roles no se crean simultáneamente, se puede optar por conceder ciertos
privilegios a algunos roles nuevos mucho después de haber creado una tabla, o crear una tabla
específica sobre al cual se conceden privilegios a roles previamente existentes. Si se hace clic
derecho sobre un objeto schema o un objeto table aparecerá el menú contextual que incluye la
opción Grant Wizard, mediante la cual es posible conceder privilegios sobre estos objetos a los
roles.
En la primera pestaña del cuadro de dialogo que aparece al elegir Grant Wizard, se observaran las
tablas sobre las cuales es posible conceder privilegios.

En la pestaña contigua se especifican los privilegios concedidos para cada uno de los roles
disponibles:

Como es de esperarse, si bien esta es una forma bastante simple de conceder o negar privilegios,
para el usuario de PostgreSQL que no cuente con PgAdmin, siempre existe la posibilidad de usar
los comandos GRANT y REVOKE de SQL mediante los cuales es posible llevar a cabo la
administración de privilegios.
La sintaxis de GRANT es:
GRANT privilegio ON objeto TO role.
Por ejemplo:
GRANT UPDATE ON accounts TO joe;
Los privilegios que pueden concederse o revocarse son: SELECT, INSERT, UPDATE,
DELETE, RULE, REFERENCES, TRIGGER, CREATE, TEMPORARY, EXECUTE, y USAGE.

El quitar privilegios a un usuario es una necesidad, ya que existen usuarios que en un momento
dado dejan de trabajar para la empresa, o que sufren cambios de funciones en los cuales es más
conveniente la revocación de ciertos privilegios. La sintaxis de REVOKE es:
REVOKE privilegio ON objeto FROM role.
Por ejemplo, para revocar todos los privilegios de un rol:
REVOKE ALL ON accounts FROM PUBLIC;
GRANT y REVOKE también pueden usarse para incluir o no a un role dentro de un grupo,
de acuerdo a la siguiente sintaxis:
GRANT group_role TO role1, ... ; REVOKE group_role FROM role1, ... ;

2.8. Bases de Datos Difusas

Las bases de datos difusas brindan la posibilidad de trabajar con información difusa es decir
información ambigua, vaga o imprecisa, propiedad que no tienen las bases de datos relacionales, y
que es muy necesaria en diferentes ámbitos en los cuales este tipo de información emerge de
diferentes formas.
Presentan gran flexibilidad para el tratamiento y consulta de datos, además pueden resultar una
herramienta importante para ayudar en la toma de decisiones en algunas organizaciones. Esta
flexibilidad se debe al manejo de la información que realizan, la cual es muy similar al lenguaje
natural que utilizamos los seres humanos a diario, encajando estos sistemas de bases de datos en
el campo de la Inteligencia Artificial.
Las bases de datos difusas tienen su sustento teórico en la lógica difusa y en la teoría de conjuntos
difusos, cuyos primeros trabajos se remontan a la década del sesenta en la Universidad de California
en Berkeley a través del profesor Lotfi A. Zadeh.
En cuanto a su implementación existen dos grandes ramas:
 Trabajar con un motor de bases de datos relacionales (SGBDR) con información precisa, y
desarrollar extensiones SQL para realizar consultas difusas sobre este, (por ejemplo Fuzzy
SQL).
 Construir directamente un gestor de bases de datos relacionales difusas (SGBDRD) que pueda
tanto almacenar como consultar información difusa.
La teoría de los conjuntos difusos desarrollada por Zadeh, provee una poderosa herramienta para
la representación y manejo de la imprecisión por lo que actualmente está siendo utilizada en varios
campos para el diseño de sistemas basados en reglas difusas.
En el sentido más amplio, un sistema basado en reglas difusas es un sistema basado en reglas
donde la lógica difusa es utilizada como una herramienta para representar diferentes formas de
conocimiento acerca del problema a resolver, así como para modelar las interacciones y relaciones
que existen entre sus variables. Debido a estas propiedades, los sistemas basados en reglas difusas
han sido aplicados de forma exitosa en varios dominios en los que la información vaga o imprecisa
emerge en diferentes formas.
Actualmente, el modelo relacional no permiten el procesamiento de consultas del tipo “Encontrar a

todos los gerentes cuyo sueldo no sea muy alto” dado que ni el cálculo ni el álgebra relacional, que
establecen el resultado de cualquier consulta como una nueva relación, tienen la capacidad de
permitir consultas de una manera difusa.

En los últimos años, algunos investigadores han lidiado con el problema de relajar el modelo
relacional para permitirle admitir algunas imprecisiones; esto conduce a sistemas de bases de datos
que encajan en el campo de la Inteligencia Artificial, ya que permiten el manejo de información con
una terminología que es muy similar a la del lenguaje natural. Una solución que aparece
recurrentemente en los trabajos de investigación actuales en esta área es la fusión de los sistemas
manejadores de bases de datos relacionales con la lógica difusa, lo que da lugar a lo que se conoce
como sistemas manejadores de bases de datos difusas o FRDBMS (por sus siglas en inglés, Fuzzy
Relational Database Management System).
Origen Lógica Difusa (Fuzzy)

La lógica difusa nació cuando el Profesor Lotfi A. Zadeh publicó un artículo titulado “Fuzzy Sets”
(Conjuntos Difusos). Donde presentó unos conjuntos sin límites precisos los cuales, según él, juegan
un importante papel en el reconocimiento de formas, interpretación de significados, y especialmente
abstracción, la esencia del proceso de razonamiento del ser humano.
En la lógica clásica sólo es posible tratar información que sea totalmente cierta o totalmente falsa;
no le es posible manipular aquella información imprecisa o incompleta inherente a un problema y
como información que es contiene datos que permitirían una mejor resolución del mismo. Con ello
se podría decir que la lógica difusa es una extensión de los sistemas clásicos. La lógica difusa es la
lógica que soporta modos de razonamiento aproximados en lugar de exactos. Su importancia radica
en que muchos modos de razonamiento humano, en especial el razonamiento según el sentido
común, son aproximados por naturaleza.
¿Qué es la lógica difusa?

La lógica difusa se ha convertido en un tema muy común en control de máquinas como el resultado
de hacerlas más “capaces” y “responsables”. Se podría decir que la lógica difusa permite a los
ordenadores trabajar no sólo con métodos cuantitativos sino también cualitativos, se trata pues de
un intento de aplicar una forma más humana de pensar en la programación de computadoras.

Por tanto diremos que “La lógica difusa” es una metodología que proporciona una manera simple
y elegante de obtener una conclusión a partir de información de entrada vaga, ambigua, imprecisa,
con ruido o incompleta, en general la lógica difusa imita como una persona toma decisiones basada
en información con las características mencionadas. Una de las ventajas de la lógica difusa es la
posibilidad de implementar sistemas basados en ella tanto en hardware como en software o en
combinación de ambos.
Modelos de Implementación
El problema de la implementación de los sistemas gestores de bases de datos difusas ha sido
tratado en dos vertientes principales:
 Iniciar con un sistema gestor de bases de datos relacionales (SGBDR) con información precisa
y desarrollar una sintaxis que permita formular consultas imprecisas, lo cual da origen a
extensiones SQL, como Fuzzy SQL, con capacidades de manejar la imprecisión.
 Construir un gestor de bases de datos relacionales difusas (SGBDRD) prototipo que

implemente un modelo concreto de base de datos relacional difusa en el que la información
imprecisa pueda ser almacenada. Dentro de esta vertiente existen dos grandes ramas: Los
modelos a través de unificación por relaciones de similitud y los modelos relacionales basados
en distribuciones de probabilidades.
Particularmente me enfocaré a los trabajos desarrollados en la Universidad de Granada, España

por un grupo de investigadores que se encuentran trabajando en esta rama actualmente.
Representación de la información
Los elementos relacionados con la manipulación de información difusa pueden tener
representaciones diferentes. Por ejemplo, una distribución normalizada de probabilidades puede ser
representada por diferentes tipos de funciones (trapezoidal, triangular, intervalar, etc.). Lo más
usual, es que se usen funciones de tipo trapezoidal. Lo mismo puede decirse de la forma en la que
se modelan los operadores relacionales difusos así como los demás elementos difusos que
aparezcan en el sistema.
El criterio empleado para seleccionar la forma de representación de los múltiples elementos difusos
del sistema manejador de base de datos, puede afectar de manera determinante la funcionalidad y
desempeño de la base de datos, por lo que debería ser uno de los puntos centrales en los que el
experto ajuste la arquitectura del FRDBMS al problema específico a tratar mediante el mismo. Puede
decirse entonces que este criterio de selección y ajuste constituye un paso entre la formulación de
una base de datos relacional difusa y la implementación de un sistema basado en la misma.
La información que se puede manejar en una base de datos difusa puede dividirse en dos
tipos principales:

 Datos Precisos.
Manejados usualmente mediante la representación provista por la base de datos relacional

huésped.
 Datos Imprecisos.
Los modelos usualmente consideran dos tipos de representación para los datos imprecisos además
de la información desconocida o indeterminada que se maneja mediante los tipos unknown,
undefined y null:
– Datos imprecisos sobre dominios ordenados

Este grupo de datos contiene distribuciones de probabilidad definidas en dominios continuos o
discretos, pero ordenados.
 Datos con analogías sobre dominios discretos

Este grupo de datos se construye sobre dominios discretos en los que existen definidas relaciones
de proximidad entre sus valores.
En este caso se deberá almacenar la representación de los datos además de la representación de

las relaciones de proximidad definidas para los valores en el dominio.
 Tipo de dato Indefinido (undefined)

Cuando un atributo toma el valor undefined, esto refleja el hecho de que ningún valor de su dominio
es permitido.
Por ejemplo: el número de teléfono de alguien que no tiene teléfono.
 Tipo de dato desconocido (unknown)
Los datos de este tipo expresan nuestra ignorancia sobre el valor que el atributo toma, sin embargo
expresa también que puede tomar uno de los valores del dominio.
Por ejemplo la fecha de nacimiento de alguien, la desconocemos pero tiene que tener alguna.
 Tipo de dato nulo (null)
Cuando un atributo toma el valor nulo, esto significa que no tenemos información sobre él, ya sea
porque no conocemos su valor o porque es imposible asignarle un valor del dominio.
Por ejemplo el email de alguien es null si desconocemos su valor o si lo tiene o no.

Propósito
Permite almacenar y procesar información de forma más flexible de lo que una base de datos
relacional convencional lo hace; es por ello que es imprescindible investigar acerca de la
composición teórica de una base de datos relacional difusa, así como de los elementos de la lógica
difusa, que son necesarios para la modelación e implementación de dicha base de datos. Es una
combinación de varios archivos de datos independientes, y al mismo tiempo, partes individuales de
la base de datos pueden compartirse entre varios usuarios distintos, en el sentido de que cada uno
de ellos puede tener acceso a la misma parte de la base de datos y utilizarla con propósitos
diferentes.
Aplicación
 Ejemplo de Aplicación humana de la Lógica Difusa
Pongámonos en situación, estas conduciendo por la típica vía con múltiples carriles, en la cual hay
un límite de velocidad establecido de 70 por hora y no se encuentran semáforos más que cada
kilómetro. Lo más normal y seguro en esta situación es conducir siguiendo el tráfico, es decir
siguiendo el ritmo que se marca de forma conjunta entre todos los vehículos, esto situara la
velocidad media probablemente algo más que el limite (78-80 km/h). Definir lo que se seguir el tráfico
es algo bastante difuso ya que hay muchos aspectos que se han de tener en cuenta.
En la situación antes descrita habrá muchos conductores que viajaran a una velocidad de que ronde
los 80 km/h oscilando por arriba o por abajo (la gran mayoría), pero habrá unos pocos que se
mantengan todo el rato a 70 km/h. Para llevar a cabo la conducción los conductores van a estar
usando la lógica difusa innata que todos los seres humanos poseemos, esto se basa en la
observación de la situación para la posterior evaluación de esta, para ello la información obtenida
del medio deberá ser resumida, ponderada y evaluada en conjunto para la toma de la decisión.
Entre los aspectos a evaluar están el número de vehículos que hay por delante, si hay algún pedazo
de chatarra avanzando lentamente por alguna de las vías, si el asfalto esta mojado o se ve afectado
por alguna otra situación climática adversa, si hay algún camión u otro vehículo largo, si existe la
posibilidad de que haya radares en la zona (sabiendo también el margen entre la velocidad limite y
una posible sanción por exceso de velocidad)...
A pesar de todos estos factores, todos los conductores acabarán llevando a cabo una conducción a
una velocidad similar.
 Aplicación en un sistema de control
En muchos procesos complejos, el control que ejerce un operador humano es más efectivo que el
que proporciona un controlador automático convencional. Para esto el operador se basa en su
experiencia (heurística). Usualmente, el operador expresa sus estrategias de control

Lingüísticamente como un conjunto de reglas de toma de decisiones. Por ejemplo para un sistema
de control de nivel de un tanque se podría tener,
“SI el nivel es muy bajo ENTONCES abra bastante la válvula”

“SI el nivel es bajo ENTONCES abra poco la válvula”
“Si el nivel es medio ENTONCES no abra ni cierre la Válvula”
“SI el nivel es alto ENTONCES cierre un poco la válvula”
“SI el nivel es muy alto ENTONCES cierre bastante la válvula”
“Por tanto, en síntesis y desde una perspectiva amplia, un controlador Difuso proporciona un
algoritmo que puede convertir una estrategia de control lingüística, generalmente basada en la
experiencia de un operador humano, en una estrategia de control automático.”
MODELO CLIENTE-SERVIDOR
Los módulos necesarios para la construcción de la extensión de una base de datos relacional a
relacional difusa, usando la estructura lógica de la FIRST-2, según las especificaciones son, muy
resumidamente:
 Módulo Dinámico del Sistema: Como parte del análisis de los requerimientos funcionales
del sistema que son recogidos por casos de uso, se enmarca el modelo dinámico del sistema.
 Módulo de Conexión: Enlaza por defecto al sistema, luego realiza la llamada al servidor. Si
el usuario solicita una conexión este módulo es quien llama al servidor, o al Módulo de Control
de errores.

Figura 16: Esquema general de la arquitectura.
 Módulo de Ejecución de Consulta Clásica: El proceso de ejecución de una consulta clásica

al igual que cualquier llamado al servidor.
 Módulo de Ejecución de Consulta Difusa: El proceso de ejecución de una consulta difusa

es homólogo, pero con un análisis de la instrucción.
 Módulo de Traducción: Aquí el usuario ingresa la consulta difusa en FSQL, luego el servidor
la analiza léxica, sintáctica y semánticamente. Si no hay errores se efectúa la traducción a
SQL.
Para la implementación del cliente que hace de interfaz entre el usuario y el servidor PostgreSQL,
se optó por un sistema desarrollado en plataforma Web. Se optó por PHP, principalmente por la
compatibilidad con una gama de sistemas operativos incluyendo por supuesto Linux y Windows,
pero también por la facilidad de instalación de los archivos fuentes, sus características son más
conocidas por los usuarios, además de que este lenguaje es de software libre.
El servidor FSQL-PostgreSQL, está construido sobre una arquitectura cliente-servidor, con una
interfaz de usuario Fuzzy Query (FQ GNU) que realiza peticiones al Servidor, así la carga de los
procesos se divide en un par de separaciones lógicas, la de interfaz Cliente, pudiendo ser “n”
usuarios cargando localmente su FQ, y los procesos del servidor que se acumulan en una sola
máquina. En la Figura 2 se presenta un diagrama de la arquitectura, la cual es explicada a
continuación:
SGBD (Sistema Gestor de Base de Datos) relacional: Es PostgreSQL, quien debe recibir todas las
operaciones concebidas como extensión del SQL huésped. El SGBD realiza transacciones en SQL

tradicional, y al momento de efectuar una petición se traduce a la extensión del SQL, para que el
servidor ejecute y despliegue la transacción con componentes difusas.
Base de Datos: Almacena toda la información, ya sea crisp o difusa.
FMB y DIC: Es la Base de Metaconocimiento Difuso ya explicada, y el Diccionario del sistema.

Proporciona el diccionario o catálogo del sistema, en este caso de la FIRST-2.
● Servidor FSQL-PostgreSQL: Su función principal es capturar las sentencias escritas en lenguaje
difuso FSQL, y traducir y enviar las mismas al SGBD. Utiliza todos los módulos que están soportados
sobre PostgreSQL, es decir, base de datos, FMB, DIC y una serie de paquetes de funciones,
procedimientos, triggers, etc., que se encuentran implementados en el lenguaje procedural PgSQL.
Cliente Visual (FQ2 GNU): Se trata de una interfaz que comunica al usuario con el SGBD
PostgreSQL. Aquí el usuario planteará sus operaciones o consultas FSQL y lanzará su ejecución al
sistema.
Fuzzy DB activa: Equivalen a una gama de triggers difusos que apoyan y activan la tarea del
servidor FSQL.
Paquetes de uso del servidor FSQL: Se trata de scripts de instalación y desinstalación, así como
los paquetes de análisis y conversión de las sentencias en FSQL. También se tiene el paquete de
operaciones difusas, que debe dotar al servidor FSQL de las operaciones difusas que generan la
extensión.
Módulo de Conexión: Se requieren tres pasos sencillos, primero invocar la librería (adodb), luego
crear el objeto para finalmente ejecutar la conexión con los parámetros del SGBD.
Módulo de errores: Para que la interfaz implementada sea amigable para el usuario se debe
desplegar la información de los posibles errores de forma visual y clara, dicha interfaz de usuario se
desarrolló en Glade.
Módulo de ejecución de consulta SQL: El sistema deberá desplegar consultas en una pantalla
tipo Query estándar para luego desplegar su ejecución en una tabla.
Módulo de ejecución de Consultas: Al igual que para las consultas clásicas, el sistema deberá
mostrar gráficamente en una tabla el resultado de una consulta difusa. También se incorporará la
información del número de columnas y filas recuperadas. La Figura 3 muestra un ejemplo.

Figura 17: Tabla con resultados de una consulta FSQL en el programa cliente FQ2 con herramientas Web.

Ejemplo práctico 1: Sistema de inferencia de control difuso

Para el proyecto se realizó una interfaz en Java, la cual fue probada con una base de datos
denominada Escuela, donde se trabajó en los promedios de los alumnos, en la Figura No.7, se
muestra una ventana donde podemos realizar una conexión a la base de datos, registrar al alumno,
ver su promedio y registrar la materia.
Figura 18: Acceso principal a la interfaz.
Una vez realizada la conexión podemos acceder en agregar materia y nos muestra la ventana de la
Figura No. 8, registro de materias, con la opción de consulta.
Figura 19: Agregación de datos a la B.D.

La Figura No. 9, permite ver el promedio, por lo que cuenta con una caja de texto para introducir
cualquier número de control de alumnos, y nos arrojará su promedio, si y sólo si el alumno está
dentro de la base de datos.
Figura 20: Consulta de Promedio.
La Figura No. 10, nos muestra cómo podemos hacer el llamado de los predicados para tratar la
base datos deductiva difusa, a través de Prolog y MySQL.
Figura 21: Interfaz para el control de conjuntos difusos de la B.D.

Conclusión y trabajo futuro
La enorme cantidad de información que se maneja hoy en día nos lleva a buscar nuevas opciones
para su manejo, pero sobre todo cuando además de ser grandes bases de datos vienen con
incertidumbre, provoca a los investigadores de esta materia seguir realizando nuevo software que
ayude a modelizar, optimizar esas bases de datos que nos arrojen información con una precisión
más exacta.
Al realizar esta interfaz se cumplen las expectativas de darle al lector herramientas que pueden
ayudar a manejar base de datos deductivas difusas y puedan trabajar con ellas de una manera
confiable y amigable, pues muchas veces el no contar con una implementación de alto nivel,
desalientan a los usuarios a la explotación real de las bases de datos por no contar con una interfaz
que sea de fácil manejo. Esta es una primera parte de la propuesta, considerando que es un primer
acercamiento para trabajar con bases de datos que además de ser deductivas sean difusas, con la
finalidad de tener un mejor manejo de la información de cualquier índole.

Ejemplo práctico 2: Implementación de una base de datos relacional difusa. Caso

práctico: tutoría académica.
Como parte del estudio exploratorio y descriptivo de la tutoría académica se revisó el manual interno
de tutorías académicas (SITUTOR) (G. Bravo, 2012), se determinó que el proceso se inicia con la
planificación de la entrevista de los estudiantes de una carrera, la información se registra en una
hoja de Excel parametrizada, esta se encuentra formada por 21 preguntas referentes a la
información personal del estudiante e información general sobre la carrera y las asignaturas en las
cuales registra segunda y tercera matrícula.
A través de 16 preguntas, se analizan aspectos que afectan el desempeño académico del

estudiante, se toma en cuenta hábitos de estudio, ambiente de estudio, actividades adicionales y la
relación que existe con los docentes, entendiendo por relación al estado de confianza, respeto y
comprensión entre las partes durante el tiempo de clases. El análisis de conocimientos se basa en
4 preguntas fundamentales: conocimientos de informática, desenvolvimiento en internet, manejo de
la plataforma o campus virtual de la UTE y conocimiento del idioma Inglés. El estudiante a través
del dialogo con el tutor proporciona aspectos como nivel de comunicación, grado de responsabilidad,
capacidad de trabajar en equipo y una última pregunta que permite conocer cuáles son las
expectativas del estudiante con respecto a las tutorías académicas.
Del análisis realizado se identificó datos clásicos y difusos de las tutorías académicas, información
parcial de estos se muestran en la Tabla 1.
Tabla 1: Clasificación de datos clásicos y difusos (parcial)
Pregunta Dato Tipo de dato

Apoyo Profesores
¿Qué espera el estudiante de la tutoría? Guía en trámites Clásico
Apoyo en las notas
Apoyo Personal
Apoyo Académico
Excelente
Relaciones Familiares Buena Difuso
Mala
Excelente
Relaciones Compañeros Buena Difuso
Mala
Excelente
Relaciones Pareja Buena Difuso
Mala
No tiene Clásico

El universo de datos de la tutoría académica permite clasificar y englobar los datos difusos en tres
conjuntos:
 Conjunto Difuso 1: Alto, medio, bajo.

 Conjunto Difuso 2: Excelente, buena, mala.
 Conjunto Difuso 3: Nada, poco, bastante, mucho.
Estos tres conjuntos de datos difusos, son procesados para obtener el modelo difuso, como ejemplo
se muestra una parte del proceso en cada etapa.
Etapa de Fusificación: la referencia del grado de pertenencia dentro del universo de datos difusos,
en primera instancia se lo realizó en lenguaje natural ejemplo:
 Niveles de concentración (alto, medio, bajo)

 Relación con el docente (excelente, buena, mala)
 Análisis de conocimientos – informática, internet, plataforma, idioma inglés (nada, poco,
bastante, mucho)
Reglas Base: Cada conjunto de datos difusos fue tratado por separado para la transformación
matemática, debido a que representan una escala diferente de grados de pertenencia, los cuales
están dentro de un rango de [0,1]. En el caso práctico de las tutorías académicas, los conjuntos de
datos difusos se encuentra definidos con un número de 3 a 4 datos por conjunto, para definir con
mayor claridad los grados de pertenencia, se procede a colocar atributos difusos intermedios entre
los atributos, estos datos intermedios son representados básicamente como puntos de referencia
dentro de las gráficas de dispersión y ajuste de recta bajo el criterio de mínimos cuadrados.
Etapa de Inferencia: Dentro de las reglas base se declaró tres reglas fundamentales, que se
aplican a los conjuntos de datos difusos, para tener un mejor entendimiento se utilizan gráficos de
dispersión, ubicando en el eje horizontal (x) los atributos difusos, y en el eje vertical (y) los grados
de pertenencia, las reglas aplicadas son:
 Regla Base 1: Transformación matemática por separado de cada conjunto de atributos

difusos.
 Regla Base 2: Los grados de pertenencia a definirse deben estar dentro del rango [0,1].
 Regla Base 3: Colocar atributos difusos intermedios como puntos de referencia.
Como ejemplo se muestra la aplicación de estas reglas de inferencia al conjunto difuso 1 (Alto,
medio, bajo) en la Figura 1.

Figura 22: Inferencia Conjunto Difuso 1
Etapa de Difusificación: Una vez estimados los grados de pertenencia de cada conjunto de
atributos difusos, se inicia el procesamiento de dichos valores a través de la regresión lineal simple
con el método de mínimos cuadrados. Como ejemplo los valores obtenidos para el Conjunto Difuso
1 (Alto, medio, bajo) se muestran en la Tabla 2.
Tabla 2: Cálculo de pendiente y punto de intersección de la recta, Conjunto Difuso 1
La gráfica de la recta ajustada a los puntos del Conjunto Difuso 1 se muestra en la Figura 2.
Figura 23: Recta ajustada del Conjunto Difuso 1

El modelo relacional difuso consta de 19 tablas que contienen atributos clásicos (Crisp) y atributos
difusos como se indica en la Tabla 3.
Tabla 3: Tablas que intervienen en el modelo relacional difuso
Nombre de Tabla Tipo atributo
Facultad Crisp
Carrera Crisp
Nivel Crisp
Paralelo Crisp
asignatura_problema_estudiante Crisp
docente_asignatura_problema Crisp
relacion_docente Crisp / Difusos
razon_problema_asignatura Crisp
tipo_discapacidad Crisp
discapacidad_estudiante Crisp
Estudiante Crisp
tipo_relaciones_conflicto_estudiante Crisp
nivel_relaciones_conflicto_estudiante Crisp / Difusos
tutor Crisp
nivel_concentracion Crisp / Difusos
tipo_cualidad_especifica Crisp
nivel_cualidades_especificas Crisp / Difusos
tipo_conocimiento_especifico Crisp
nivel_conocimiento_especifico Crisp / Difusos
Las tablas que contienen atributos clásicos (Crisp) son tratados dentro de un modelo Entidad –
Relación común, mientras que las tablas que contienen atributos difusos, son sujetos de
transformación a través de etiquetas lingüísticas almacenadas en lenguaje natural dentro de las
respectivas tablas. El esquema final de la base de datos se presenta en la figura 3, el mismo que
consta de 19 tablas con datos clásicos y difusos.

Figura 24: Modelo de base de datos

El proceso de transformación se realizó mediante la herramienta Fuzzy Lookup que es parte de los
servicios de integración de SQL Server (SQL Server Integration Services – SSIS), este proceso
requiere de una tabla de origen que contiene la información difusa recolectada a través de las
entrevistas y la tabla de referencia que contiene los atributos difusos con sus grados de pertenencia
encontrados en el proceso de transformación matemático.
Las tablas de referencia de aquellas tablas que contienen atributos difusos, se muestran en la
Tabla 4.
Tabla 4: Tablas de referencia del modelo relacional difuso
Nombre de Tabla Tipo de Atributos
referencia_nivel_concentracion Crisp / Difusos
referencia_relacion_docente Crisp / Difusos
referencia_conocimientos_especificos Crisp / Difusos
referencia_cualidades_especificas Crisp / Difusos
referencia_relaciones_conflicto_estudiante Crisp / Difusos
A continuación se muestra un ejemplo SQL para la creación de la tabla nivel de concentración, la

misma que va a contener datos clásicos y difusos:
CREATE TABLE nivel_concentracion (
cod_niv_concentracion INT IDENTITY (1,1) not null PRIMARY KEY,

nom_niv_concentracion VARCHAR (50) not null, val_niv_concentracion
DECIMAL (2,2))
La figura 4 muestra las tablas que alojan datos clásicos y difusos, la diferencia radica en que
aquellas tablas difusas, cuentan con un campo donde se registrará el valor numérico resultante de
la transformación difusa de las etiquetas lingüísticas registradas en lenguaje natural, de manera
provisional, este campo se registra inicialmente con el valor de cero (0.00).
Figura 25: Estado inicial-tablas difusas

Posterior a la creación de las tablas se procedió a ingresar la información. Un ejemplo de

inserción se muestra para la tabla nivel de concentración.
insert into referencia_nivel_concentracion values ('BAJO', 0.05) insert
into referencia_nivel_concentracion values ('MEDIO', 0.47) insert into
referencia_nivel_concentracion values ('ALTO', 0.90)
El flujo de transformación difusa para cada tabla que contiene atributos difusos se refleja en la
Figura 5, las tablas de origen, pasan por una transformación difusa, derivación de columnas y
ejecución de comandos SQL para finalmente desembocar en las tablas de destino que son las
mismas tablas, pero internamente modificadas por la transformación.
Figura 26: Flujo de transformación difusa
Posterior a la ejecución del flujo de transformación se comprueba que, los registros difusos de la
base de datos ya cuentan con los valores numéricos equivalentes a las etiquetas lingüísticas, los
registros que han sido transformados pueden ahora ser consultados y visualizados, con la
sentencia select respectiva del lenguaje SQL como se muestra en la Figura 6.
Figura 27: Comprobación de transformación difusa.

En otros sistemas gestores de bases de datos es necesario contar con un servidor FSQL (A.
Urrutia, 2008) que permita a través de un lenguaje extendido realizar consultas difusas, un ejemplo
de este lenguaje es la siguiente consulta:
SELECT *
FROM nivel_concentracion
WHERE nom_niv_concentracion FEQ $MEDIO THOLD 0.5;
Cada vez que sea necesario ejecutar la transformación difusa, se debe ejecutar un proceso de
limpieza de atributos difusos, que consiste en “encerar” el campo de valores numéricos
equivalentes a las etiquetas lingüísticas de las tablas a ser transformadas, con el objetivo de
preservar la integridad de los datos difusos anteriores al integrar nuevos datos a las tablas difusas
y transformar de manera global todos los datos que contenga las tablas, este proceso de limpieza
consiste en ejecutar un procedimiento almacenado creado en la base de datos el cual se ejecuta
directamente desde el SQL Server o desde SSIS mediante un flujo independiente a los flujos de
transformación difusa, a continuación se muestra el procedimiento almacenado.
CREATE PROCEDURE limpiar_difusos AS
BEGIN
UPDATE dbo.nivel_conocimientos_especificos SET val_niv_con_especifico =0 UPDATE

dbo.nivel_cualidades_especificas SET val_niv_cua_especifica =0
UPDATE dbo.nivel_relaciones_conflicto_estudiante SET val_niv_rel_con_estudiante =0 END
Al aplicar el modelo de espiral para el desarrollo de la aplicación, se inició con el análisis de la

interfaz en seis secciones, luego se procedió a diseñar las interfaces de las secciones, el diseño
incluye un menú principal para guiar al usuario hacia la interfaz de ingreso de nuevas entrevistas
o hacia la interfaz de consultas difusas. La Figura 7 muestra la interfaz principal.
Figura 28: Diseño interfaz – Menú Principal

Para verificar el funcionamiento de la aplicación, se realizó pruebas ingresando varias entrevistas

de estudiantes de diferentes carreras de la Facultad de Ciencias de la Ingeniería, en la Figura 8 se
puede observar una de las consultas difusas ejecutadas antes del proceso de transformación, se
puede constatar que los valores numéricos de equivalencias de las etiquetas lingüísticas son cero
(0.00).
Figura 29: Consulta mediante aplicación antes de transformación difusa
Posterior al proceso de transformación, en la Figura 9 se puede observar que la misma consulta

arroja los valores resultantes de la transformación difusa, con lo cual esta información ya puede
ser procesada para comparaciones numéricas o estadísticos según lo requieran la comunidad de
tutores académicos.
Figura 30: Consulta mediante aplicación después de transformación difusa

Conclusiones y Recomendaciones
Es necesario contar con un proceso matemático para analizar información difusa, debido a que, la
mayoría de datos difusos son expresados en lenguaje natural a través de etiquetas lingüísticas, es
conveniente asumir valores que representen grados de pertenencia en una escala de [0, 1] y en
base a estos valores proceder con cualquier método de regresión lineal a encontrar los valores
reales que sean bases en la transformación difusa
La definición del modelo de base de datos difusa, debe ser en base al DBMS que vaya a ser
utilizado, ya que estos pueden basar sus transformaciones difusas en servidores FSQL o en
herramientas CASE donde los resultados obtenidos tienen como fundamento umbrales de similitud,
grados de confianza, distribuciones de posibilidades o únicamente grados de pertenencia de cada
atributo difuso.
El sistema gestor utilizado permite analizar la información difusa en base a umbrales de similitud y
grados de confianza, lo cual pone a disposición dos opciones para garantizar los resultados de las
transformaciones difusas.
Al implementar el modelo de bases de datos difusos basados en puntuaciones de similitud y al
definir un umbral de similitud del 50%, proveen un nivel de confianza del 0.9875, brindando la
seguridad de que los atributos difusos que cumplan con esta condición puedan asumir los valores
numéricos según la tendencia que tiene los atributos originales con respecto a los atributos de
referencia que son la base de búsqueda en la herramienta Fuzzy Lookup.
SQL Server Integration Services – SSIS, es una herramienta muy útil que facilita el procesamiento
de datos clásicos o difusos y permite integrarlos para ser sujetos de consulta o procesamiento
dentro del mismo ambiente de SQL, en SSIS es posible condensar dentro de un mismo flujo de
procesos, tres actividades, automatizando en su mayoría el proceso de transformación difusa y
delegando como proceso manual únicamente la ejecución de dicho flujo.

2.9. Almacenes de Datos

Un almacén de datos (AD) es una base de datos (BD) que
contiene una copia de los datos de los sistemas
operacionales (fuentes de datos) con una estructura
especialmente adecuada para realizar consultas y análisis
(ofrece una visión histórica de los datos de los sistemas
operacionales). El ámbito es uno de los elementos
característicos de los almacenes de datos: Es toda la
empresa. Se usa el término data mart para designar a los almacenes de datos cuyo ámbito es más
reducido, normalmente un departamento o área específica dentro de la empresa.
Los datos procedentes de las aplicaciones, sistemas operacionales componentes y otras fuentes de
información, se integran en el almacén de datos operacionales (ADO, “Operational Data Store”),
que es una colección que contiene datos detallados para satisfacer las necesidades operacionales
de acceso colectivo e integrado a los datos de la corporación a la que sirve. Generalmente, a partir
del ADO se define el almacén de datos corporativo, aunque también existe la posibilidad de obtener
los datos a cargar en el almacén directamente de los sistemas operacionales componentes. Los
datos marts se definen siempre a partir del almacén de datos.
Es muy frecuente encontrar asociado el concepto de almacén de datos con su implementación sobre
BD relacionales o bien multidimensionales (construidas sobre BD relacionales o bien con estrategias
específicas de almacenamiento multidimensional de los datos). Sin embargo, el uso de las bases
de datos orientadas a objetos (BDOO) puede resultar de gran utilidad para el modelado e
implementación de los almacenes de datos.
El diseño del esquema de un almacén de datos debe ser orientado al almacenamiento en sí, sin
tener en cuenta las posibles consultas que se puedan llegar a realizar sobre él. Las consultas se
realizarán principalmente sobre BD multidimensionales diseñadas con este propósito y cuyos datos
se obtienen a partir del almacén. Llegado a este punto, es muy importante tener en cuenta la
dimensión temporal, vital en cualquier tarea de análisis. El esquema del almacén de datos ha de ser
capaz de reflejar las características temporales de los datos. De la misma manera, será igualmente
importante estudiar los mecanismos de extracción, de este tipo de datos, de los sistemas
operacionales componentes (fuentes de datos).
Por otra parte, también es necesario trasladar los datos de las fuentes al modelo de datos del
almacén, así como comprobar si los datos de las fuentes de datos han cambiado desde el último
acceso para, en su caso, actualizar el almacén de datos. Para realizar este proceso de integración
es adecuado usar un modelo orientado a objetos (O-O) como modelo canónico de datos, tal como
se desprende de los resultados presentados. El estándar ODMG define un conjunto de

especificaciones que establece cómo se deben definir y consultar bases de datos orientadas a
objetos.
Actualmente, dicho estándar no ha sido reconocido como tal por ningún comité de estandarización,
aunque hoy en día es el estándar de hecho. Sin embargo, dicho estándar no incluye elementos
temporales. La inclusión de esta funcionalidad permitiría representar elementos y propiedades
temporales en los esquemas tanto de las fuentes de datos como del propio almacén de datos.
La integración de fuentes de datos para su incorporación al almacén de datos es un campo que ha

sido estudiado desde el punto de vista de resolver diferentes problemas, tales como: Integración de
las propiedades semánticas de los datos, integración de niveles de seguridad, etc. Sin embargo,
hasta ahora no se han tenido en cuenta las propiedades temporales de los datos. Estas propiedades
se pueden deducir tanto de la propia fuente en la que se encuentra el dato, como del método de
extracción utilizado para la obtención del mismo.
La integración de las propiedades temporales de los datos implica disponer de algoritmos que nos
resuelvan que, si datos procedentes de diferentes fuentes y teniendo en cuenta las propiedades
temporales de los mismos, es posible su integración para ser incorporados al almacén.
Software Data Warehouse
 Red Brick Warehouse

 Essbase
 Pilot Decission Support Suite
 Microsoft SQL Server
Data marts
Los Data marts son subconjuntos de datos de un data Warehouse para áreas específicas.
Entre las características de una data mart destacan:
 Usuarios limitados.
 Área específica.
 Tiene un propósito específico.
 Tiene una función de apoyo.

Principales aportaciones de una data Warehouse:
Proporciona una herramienta para la toma de decisiones en cualquier área funcional, basándose en
información integrada y global del negocio.
Facilita la aplicación de técnicas estadísticas de análisis y modelización para encontrar relaciones

ocultas entre los datos del almacén; obteniendo un valor añadido para el negocio de dicha
información.
Proporciona la capacidad de aprender de los datos del pasado y de predecir situaciones futuras en
diversos escenarios.
Simplifica dentro de la empresa la implantación de sistemas de gestión integral de la relación con el

cliente.
Supone una optimización tecnológica y económica en entornos de Centro de Información,

estadística o de generación de informes con retornos de la inversión espectaculares.
Características del Almacén de Datos
Organizado en torno a temas. La información se clasifica en base a los aspectos que son de
interés para la empresa.
Integrado. Es el aspecto más importante. La integración de datos consiste en convenciones de

nombres, codificaciones consistentes, medida uniforme de variables, etc.
Dependiente del tiempo. Esta dependencia aparece de tres formas:
La información representa los datos sobre un horizonte largo de tiempo.
Cada estructura clave contiene (implícita o explícitamente) un elemento de tiempo (día, semana,
mes, etc.).
La información, una vez registrada correctamente, no puede ser actualizada.

Propósito
1).- Hace que la información de la organización sea accesible: los contenidos del Data
Warehouse son entendibles y navegables, y el acceso a ellos son caracterizado por el rápido
desempeño. Estos requerimientos no tienen fronteras y tampoco limites fijos. Cuando hablamos de
entendible significa, que los niveles de la información sean correctos y obvios. Y Navegables
significa el reconocer el destino en la pantalla y llegar a donde queramos con solo un clic.
2).- Hacer que la información de la organización sea consistente: la información de una parte
de la organización puede hacerse coincidir con la información de la otra parte de la organización. Si
dos medidas de la organización tienen el mismo nombre, entonces deben significar la misma cosa.
Y a la inversa, si dos medidas no significan la misma cosa, entonces son etiquetados diferentes.
Información consistente significa, información de alta calidad. Significa que toda la información es
contabilizada y completada. Todo lo demás es un compromiso y por consiguiente algo que
queremos mejorar.
3).- Es información adaptable y elástica: el Data Warehouse está diseñado para cambios
continuos. Cuando se le hacen nuevas preguntas al Data Warehouse, los datos existentes y las
tecnologías no cambian ni se corrompen. Cuando se agregan datos nuevos al Data Warehouse, los
datos existentes y las tecnologías tampoco cambian ni se corrompen.
4).- Es un seguro baluarte que protege los valores de la información: el Data Warehouse no
solamente controla el acceso efectivo a los datos, si no que da a los dueños de la información gran
visibilidad en el uso y abusos de los datos, aún después de haber dejado el Data Warehouse.
5).- Es la fundación de la toma de decisiones: el Data Warehouse tiene los datos correctos para
soportar la toma de decisiones. Solo hay una salida verdadera del Data Warehouse: las decisiones
que son hechas después de que el Data Warehouse haya presentado las evidencias.
Beneficios de una data Warehouse
Los beneficios de una data Warehouse son:
 Mejora en la toma de decisiones

 Consolidación de los datos provenientes de varios orígenes
 Calidad, coherencia y precisión de los datos
 Inteligencia histórica
 Separación del procesamiento de análisis de las bases de datos transaccionales, lo que
mejora el desempeño de ambos sistemas

A parte del enfoque de acceder a la información bajo-demanda, existe el enfoque del Almacén de
Datos (Data Warehouse). Un almacén de datos es una BD que contiene una copia de datos de los
sistemas operacionales (fuentes de datos) con una estructura especialmente adecuada para realizar
consultas y análisis (ofrece una visión histórica de los datos de los sistemas operacionales). El ámbito
es uno de los elementos característicos de los almacenes de datos: su ámbito es toda la empresa,
en este caso lo llamaremos almacén de datos. Se usa el término data mart para designar a los
almacenes de datos cuyo ámbito es más reducido, normalmente un departamento o área específica
dentro de la empresa.
Entre las características que diferencian al almacén de datos de otros enfoques encontramos
las siguientes:
 Los datos se extraen de los sistemas operacionales, se transforman según sea
necesario, se integran con datos provenientes de otros sistemas operacionales y se
almacenan en el almacén de datos.
 Cuando se realiza una consulta, ésta se ejecuta en el almacén de datos, sin que
sea necesario acceder a las fuentes de datos.
 Cuando se produce un cambio de los datos en los sistemas operacionales y éste se
considera de relevancia, se propagan los cambios al almacén de datos y se
actualiza.
En la Figura 16 se presenta un resumen de la arquitectura de construcción de almacenes de datos.
Los datos procedentes de las aplicaciones, BDs componentes y otras fuentes de datos son
integrados directamente en el almacén de datos. Los data marts son definidos a partir del data
Warehouse.
Data Marts
Data Warehouse
Aplicaciones, BD
Componentes,
Fuentes de datos
Figura 31: Arquitectura de construcción de almacenes de datos.
En la Figura 17 podemos ver la implementación de la arquitectura y que muestra los componentes
que interactúan para extraer e integrar los datos. Se han introducido dos nuevos componentes: los
wrappers/monitor y el integrator. Conectado a cada fuente de datos hay un wrapper/monitor. El

wrapper se encarga de trasladar los datos del formato nativo de la fuente al formato y modelo de
datos utilizado por el almacén de datos.
El monitor se encarga de detectar automáticamente cambios en la fuente e informar de éstos al
integrator. Cuando una nueva fuente entra a formar parte del almacén de datos o cuando se
detectan cambios de interés en las fuentes, los nuevos datos o los cambios producidos en los datos
se propagan al integrator. Este componente se encarga de filtrar los datos, resumirlos, y si fuera
necesario integrarlos con los datos procedentes de otras fuentes.
En la Figura 17 se muestra un almacén de datos simple y centralizado, pero éste puede ser
implantado cómo una BD distribuida y se pueden utilizar técnicas de paralización para alcanzar
mayores grados de rendimiento.
Otro tipo de datos son los metadatos que contienen información acerca de los datos. Es un directorio
que contiene información sobre como son los datos almacenados en el almacén de datos y dónde
se pueden encontrar esos datos.
Figura 32: Arquitectura general de un Data Warehouse
La Figura 18 ilustra la arquitectura genérica de un almacén de datos. Las fuentes de datos incluyen
bases de datos operacionales, ficheros flat (por ejemplo, hojas de cálculo o ficheros de textos) y
bases de datos externas. Los datos se extraen de las fuentes y se cargan en el almacén de datos
utilizando herramientas ETL (Extracción, Transformación and Load). El almacén de datos se utiliza
para alimentar data marts temáticos y servidores OLAP.
Los data marts son subconjuntos del almacén de datos categorizados de acuerdo a las áreas
funcionales y dependiendo del dominio del problema. Los servidores OLAP son herramientas
software que ayudan al usuario a preparar datos para el análisis, búsquedas, informes y data mining.
El almacén de datos completo forma un sistema integrado que puede dar soporte a varios
requerimientos de análisis e informes para la ayuda en la toma de decisiones.

Por tanto, un almacén de datos junto con OLAP, capacita a los decisores para analizar y entender
los problemas. OLAP analiza los datos utilizando esquemas especiales, y permite al usuario
visualizar los datos usando cualquier combinación de variables. Los sistemas de almacén de datos
transforman los datos operacionales en información estratégica para la toma de decisiones.
Almacenan información sumarizada variante en el tiempo en lugar de datos operacionales,
proporcionando respuestas a preguntas en el ámbito decisional. Para extraer esta información de
un entorno distribuido, necesitamos consultar múltiples fuentes de datos e integrar la información
antes de presentar las respuestas al usuario.
En el entorno de los almacenes de datos, esas consultas encuentran sus respuestas en un lugar
central, de tal forma que se reduce el coste de procesamiento y manejo. Después de la carga inicial
el almacén debe ser regularmente refrescado y las modificaciones de los datos operacionales
producidos desde el último refresco se deben propagar al almacén, de tal forma que éste refleje de
la forma más fiable posible el estado de los sistemas operacionales.
Figura 33: Arquitectura genérica de DW (Chaudhuri & Dayal, 1997)
Aunque se reconocen importantes elementos en común entre los almacenes de datos y otras áreas
previamente estudiadas, no se aprovechan en su totalidad los avances conseguidos en estas áreas
para su aplicación a la construcción de almacenes de datos (data Warehouse y data marts), en
concreto, nos referimos especialmente a las BD federadas, BD temporales, así como a la definición
de esquemas externos. Situando a los almacenes de datos en el contexto adecuado se puede
subsanar esta situación, éste es el objetivo de nuestro trabajo.

Aplicación
Integrado: los datos almacenados en la data Warehouse deben integrarse en una estructura
consistente, por lo que las inconsistencias existentes entre los diversos sistemas operacionales
deben ser eliminadas. La información suele estructurarse también en distintos niveles de detalle
para adecuarse a las distintas necesidades de los usuarios.
Temático: sólo los datos necesarios para el proceso de generación del conocimiento del negocio
se integran desde el entorno operacional. Los datos se organizan por temas para facilitar su acceso
y entendimiento por parte de los usuarios finales. Por ejemplo, todos los datos sobre clientes pueden
ser consolidados en una única tabla de la data Warehouse. De esta forma, las peticiones de
información sobre clientes serán más fáciles de responder dado que toda la información reside en
el mismo lugar.
Histórico: el tiempo es parte implícita de la información contenida en una data Warehouse. En los
sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el
momento presente. Por el contrario, la información almacenada en la data Warehouse sirve, entre
otras cosas, para realizar análisis de tendencias. Por lo tanto, la data Warehouse se carga con los
distintos valores que toma una variable en el tiempo para permitir comparaciones.
No volátil: el almacén de información de una data Warehouse existe para ser leído, pero no
modificado. La información es por tanto permanente, significando la actualización del data
Warehouse la incorporación de los últimos valores que tomaron las distintas variables contenidas
en él sin ningún tipo de acción sobre lo que ya existía.

Ejemplo práctico 1: Herramienta software de ayuda

A continuación se describe una herramienta que permite tener cuenta todos los aspectos temporales
que intervienen en la integración de diferentes fuentes de datos.
En la Figura 19 se puede ver una captura de pantalla de la aplicación. En la parte izquierda del área
de trabajo se encuentra el esquema del almacén de datos en forma de árbol. En principio, el
esquema del almacén es generado de forma automática por el sistema a partir de las diferentes
fuentes de datos, pero se le da al diseñador del almacén de datos la posibilidad de realizar
modificaciones.
Figura 34: Creación del esquema del almacén
Las posibles modificaciones incluyen añadir o eliminar nuevas clases y atributos, además de
identificar los elementos de las fuentes que deben ser integrados para obtener el valor de los
diferentes atributos del almacén. En la parte derecha del área de trabajo hay dos listas de elementos
que representan los atributos de la fuente seleccionada (a la izquierda) y los elementos de las
fuentes de datos que se deben integrar para obtener un valor del atributo seleccionado del almacén
(a la derecha). Para añadir un nuevo atributo de la fuente seleccionada a la lista de elementos que
se deben integrar basta con seleccionarlo y pulsar sobre el botón “>>”.
Una vez determinado el esquema del almacén, también es posible modificar algunos de los
parámetros temporales de la integración. En la Figura 20 se muestra el formulario que permite
seleccionar el nivel de detalle temporal con el que se desean almacenar los valores de los diferentes
atributos del esquema del almacén. Se muestra una lista de todas las fuentes de datos que
intervienen a la hora de integrar el parámetro seleccionado en el esquema del almacén y se le da al

diseñador del mismo la posibilidad de seleccionar el nivel de detalle dentro de unos los valores
adecuados para ese dato.
Figura 35: Elección de la granularidad
Por último, en la Figura 21 se muestra la forma en que el diseñador del almacén determina cuando
se debe realizar el refresco de los datos. En la parte superior se muestra la ventana de disponibilidad
de todas las fuentes de datos que intervienen en la integración del atributo del almacén seleccionado
en el esquema. En el centro se muestra la intersección de todas las ventanas de disponibilidad de
las fuentes implicadas en la integración. Justo debajo hay una serie de marcas que indican la
posibilidad de realizar un refresco de los datos del almacén en ese preciso instante, determinadas
automáticamente por el sistema. El diseñador del almacén puede entonces habilitar o deshabilitar
cada uno de estos refrescos de datos mediante la lista de casillas de verificación que aparece en la
parte inferior de la ventana.
Figura 36: Refresco de los datos

Ejemplo práctico 2: Desarrollo Aplicación

En este caso práctico no se ha desarrollado una aplicación completa, sino que se han creado
informes a partir del D. A continuación se describen los informes creados. La finalidad de la creación
del Almacén de Datos era tener un modelo datos que permitiera generar dos informes anuales
sobre la cuantía de las primas de las pólizas. Así pues mediante la herramienta Business Objects
se han generado los informes requeridos, que se muestran en el Anexo C. Este informe muestra la
cuantía de las primas de cada año en cada dirección regional, así como el ratio de la prima y del
número de pólizas, que se calculan de la siguiente manera:
Ratio prima = prima pólizas vigentes/prima pólizas anuladas
Ratio pólizas = número pólizas vigentes/número pólizas anuladas
Este informe muestra el ratio por dirección de forma anual, muy útil para tener una visión global al
cierre del año. La ventaja de realizar estos informes con herramientas OLAP es que son dinámicos
y permiten navegar por las jerarquías. En este caso se tienen dos jerarquías por las que se podría
navegar si se quisiera consultar la información relativa a otros niveles de la jerarquía. La primera es
por fecha, se podrían visualizar los datos por mes o incluso por día si se requiere, y eso se haría de
una forma muy sencilla usando este tipo de herramientas. La segunda jerarquía es la dirección,
coordinación regional y el agente.
En este caso particular el interés para el negocio es poder consultar esta información a nivel de
dirección y a nivel de producto, que es el siguiente informe que se ha generado. En este también se
podría navegar por la jerarquía fecha, y pasar del año al mes o incluso al día. Estos informes se
puedes ven en detalle en el Anexo C, y en las Figuras 29 y 30 se muestran los informes con la
herramienta Business Objects.
Figura 37: Informe Ratio Prima por Dirección con Business Objects.

Figura 38: Informe Ratio Prima por Producto con Business Objects.

Conclusión
Esta investigación de los tipos de bases de datos es actualmente utilizada por medianas y grandes
empresas que se dedican a administrar sus bases de datos, el conocimiento aprendido es extenso
ya que en lo particular no conocía muy bien la funcionalidad de cada base datos. Por lo que quiero
concluir que estas bases de datos están relacionadas con los sistemas que hoy en día se
implementa para hacer miles de cosas como son las bases de datos geográficas que nos permite
obtener datos importantes sobre cada ubicación de la gasolina que se reparte por cada estado,
municipio etc...Por lo que deben de tener un servidor para que se pueda extraer los datos
correctamente.
Ya que tiene la eficiencia de obtenerlos de manera inmediata, por lo que se debe administrar cada
dato en tablas separadas por categorías es lo que comprendí en los ejemplos. De igual manera
están las bases de datos deben ser seguras que es más que nada la seguridad en que debe estar
protegida para que los hacker o personas no autorizadas no puedan ver dicha información como así
dar privilegios que permita el acceso a las personas ver los datos.
También se debe tener en cuenta los almacenes de datos son la parte fundamental para los
sistemas operacionales, ya que tienen una estructura que ayuda a guardar datos de forma precisa
con la visión de realizar consultas y análisis de los datos. Ya que guardados en la base de datos
contiene una copia para que sean visualizados por el usuario que desee ver dicha información.
Por eso es bueno conocer de las bases temporales porque administran los datos considerando la
variación del tiempo en el mismo, ya que actualmente es utilizado por finanzas, la medicina y
entornos gubernamentales es decir bases temporales quiere decir que se basa en el tiempo pasado
por esa razón durante los últimos veinte años se han presentado modelos de bases de datos
temporales, con el fin de representar la evolución histórica de los datos.
Las bases de datos difusas son eficientes ya que brindan la posibilidad de trabajar con información
difusa es decir información ambigua, vaga o imprecisa, propiedad que no tienen las bases de datos
relacionales, y que es muy necesaria en diferentes ámbitos en los cuales este tipo de información
emerge de diferentes formas. Este primer trabajo fue desarrollado por Lotfi A. Zadeh que remonta
la década del 70.

Bibliografías
Jimdo. (2018). Análisis con bases de datos geográficas. Obtenido de: https://sig-
soluciones.jimdo.com/an%C3%A1lisis-con-bases-de-datos-geogr%C3%A1ficas/
Alonso. (2006). 4 Aplicaciones de los SIG. Obtenido de:

https://www.um.es/geograf/sigmur/temariohtml/node18.html
Imasgal. (11 de junio del 2018). APLICACIONES DE LOS SISTEMAS DE INFORMACIÓN

GEOGRÁFICA. Obtenido de: https://imasgal.com/aplicaciones-sistemas-informacion-geografica/
(2019). Capítulo 5. Sistemas de información geográfica en el manejo de peligros naturales. Obtenido de:
https://www.oas.org/dsd/publications/Unit/oea65s/ch10.htm
(2019). METODOLOGÍA E IMPLEMENTACIÓN DEL SIAPS (SISTEMA DE INFORMACION

GEOGRAFICA: GOBERNANZA DEL AGUA). Obtenido de:
httpssiaps.colmex.mxdocumentosArquitectura%20de%20SIAPS.pdf
Instituto Geográfico Nacional. (2019). Las Bases de Datos Geográficas del IGN. Obtenido de:
https://www.ign.es/web/resources/docs/IGNCnig/CBG-BD.pdf. Pág. 3. Madrid – España.
Federación Nacional de Cafeteros de Colombia. (28 de marzo del 2019). Sistema de información Cafetera -
SICA. Obtenido de:
https://www.federaciondecafeteros.org/particulares/es/servicios_para_el_cafetero/sistema_de_informacion_si
ca-1/
Unknown. (18 de septiembre de 2012). Base de datos temporales. Obtenido de:

http://dbtemporaleswili.blogspot.com/
Ortiz. H, (28 de noviembre de 2013). Base de Datos Temporales. Obtenido de:

https://es.scribd.com/document/187699837/Base-de-Datos-Temporales
Bravo. J y Ortega. M, (28 de noviembre de 2013). Base de Datos Temporales. Líneas de investigación en
informática. Obtenido de:
https://books.google.com/books?id=45aIw2vHOgkC&pg=PA44&dq=Bases+de+Datos+Temporales&hl=es&
sa=X&ved=0ahUKEwiI_Yi70IniAhVLMt8KHTimARwQ6AEILTAB#v=onepage&q=Bases%20de%20Dat
os%20Temporales&f=false
Pérez. M, J, (6 de diciembre de 2012). Base de Datos Temporales. Obtenido de:

https://prezi.com/wny5l92hpej7/bases-de-datos-temporales/
Aragón. P, (27 de enero de 2011). Base de datos temporales. Obtenido de:

https://es.slideshare.net/elaragon/bases-de-datos-temporales

Google sites. (2019). Bases de datos difusas. Obtenido de:

https://sites.google.com/site/basededatosiiucb2/tipos-de-bases-de-datos/bases-de-datos-difusas
Artaza. G, (19 de mayo de 2017). Conceptos preliminares sobre Bases de Datos Difusas. Obtenido de:
http://buitrehga.blogspot.com/2017/05/conceptos-preliminares-sobre-bases-de_19.html
Arguello. A, I, (2019). 5.3.1 Almacenes de datos (Data Warehouse). Obtenido de:

https://sites.google.com/site/isaelpractica/5-3-1-almacenes-de-datos-data-warehouse
pnfiiutep836sa. (2 de marzo de 2012). Almacenes de Datos. Obtenido de:

https://modelosbd2012t1.wordpress.com/2012/03/02/almacenes-de-datos/
Business Intelligence. (219). Datawarehouse. Obtenido de:

https://www.sinnexus.com/business_intelligence/datawarehouse.aspx
Unknown. (26 de noviembre de 2014). 5.2.1 ALMACENES DE DATOS (data Warehouse). Obtenido de:
http://mercadotecnia-electronica14.blogspot.com/2014/11/521-almacenes-de-datos-data-warehouse.html
Pastorino. C, (5 de septiembre de 2017). 5 consejos para mantener seguras tus bases de datos. Obtenido de:
https://www.welivesecurity.com/la-es/2017/09/05/consejos-bases-de-datos-seguras/
Ohlinger. M, (7 de junio de 2017). Arquitectura distribuida grande. Obtenido de:

https://docs.microsoft.com/es-es/biztalk/core/large-distributed-architecture
Aula Mentor. (2019). Bases de la seguridad informática. Obtenido de:
http://descargas.pntic.mec.es/mentor/visitas/demoSeguridadInformatica/bases_de_la_seguridad_informtica.ht
ml
Villalobos. J, (2018). PRINCIPIOS BÁSICOS DE SEGURIDAD EN BASES DE DATOS. Obtenido de:

https://revista.seguridad.unam.mx/numero-12/principios-basicos-de-seguridad-en-bases-de-datos
Duque. J. L, (Medellín 2009). DISEÑO DE UN MODELO DE DATOS GEOGRÁFICO QUE SOPORTE LA

GESTIÓN EN ORGANIZACIONES AMBIENTALES. Pág. 105.
Mesa. S. F, (20 de junio de 2012). Desarrollo de un Sistema de Información Geográfica Web para el análisis
espacial y temporal de las finanzas del Reino de Castilla en el siglo XVI. Pág. 55.
Díaz. J. E, Bellon. D. F y González. J, S (enero-junio 2015). Estudio comparativo entre bases de datos
temporales y bases de datos relacionales aplicado a historias clínicas electrónicas. Pág. 8.
Silva. M y Díaz. J, (2010). INTERFAZ PARA LA GESTIÓN DE BASES DE DATOS TEMPORALES

(IGBDT) V 1.0. Centro de Información y Gestión Tecnológica de Santiago de Cuba. Pág. 11. ISSN: 1027-
2887.
Mata. T, Murillo. J, M, Téllez. J, L, (2009). BASES DE DATOS DEDUCTIVAS Y BASES DE DATOS

DIFUSAS. Modelos Avanzados de Bases de Datos. Pág. 18.

Urrutia. A, Galindo. J, Sepúlveda. A, (5 de febrero de 2010). IMPLEMENTACIÓN DE UNA BASE DE

DATOS DIFUSA CON FIRST-2 Y PostgreSQL. Pág. 8.
Innovación y Transferencia Tecnológica (2009). Lógica Difusa. Pág. 19.
Almenares. F y Almenares. A, (febrero - Mayo, 2016). Representación de las interacciones humanas en una
red social de aprendizaje, utilizando bases de datos difusas. Revista Dilemas Contemporáneos: Educación,
Política y Valores. Pág. 14. ISSN: 2007 – 7890.
Saguay. C, Proaño. R, Jácome. B, Aguirre. D, (febrero de 2017). Implementación de una base de datos
relacional difusa. Caso práctico: tutoría académica. Pág. 15. ISSN: 1390-9363.
Ramírez. N, V, (octubre 2015). Interfaz gráfica para el manejo base de datos deductivas difusas. Instituto
Tecnológico de Celaya. Pág. 16. ISSN 1405-1249.
Rodríguez. S, (diciembre de 2009). GESTIÓN DE PÓLIZAS DE SEGUROS: UN CASO PRÁCTICO DE

BUSINESS INTELLIGENCE. UNIVERSIDAD CARLOS III DE MADRID ESCUELA POLITÉCNICA
SUPERIOR. Pág. 151.
Araque. F, (Noviembre de 2005). Definición del modelo y esquema del Almacén de Datos en función de las
características temporales de los sistemas operacionales componentes. Pág. 258. ISBN: 84-338-3732-x.

Iinini

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Iinini

Cargado por

Copyright:

Formatos disponibles

Modelos Alternativos de Bases de Datos 1

Prof. Mauricio Arturo Reyes Hernández

 Juan Pablo Badal Arias

Modelos Alternativos de Bases de Datos

División Académica: Informática y Sistemas

Carrera Profesional: Licenciado en Sistemas Computacionales

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

2.8. Bases de Datos Difusas ............................................................................................................................ 79

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

2.5. Bases de Datos Geográficas

Figura 1: Vista de BTN25 y BTN100 de la ciudad de León

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

El Instituto Geográfico Nacional (IGN) desarrolla en la actualidad diferentes proyectos de I+D+i

Figura 2: Vista del entorno de captura en BTN25

El mantenimiento y la actualización son tareas destinadas a mejorar la calidad geométrica,

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

La conjunción de los resultados de estos proyectos facilitará la producción cartográfica automatizada

 Base Topográfica Nacional 1:25.000 (BTN25)

Propósito es que contienen multitud de información alfanumérica de todo tipo (geográfica,

Aplicaciones en Sistemas de Información Geográfica (SIG)

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

CARACTERISTICAS DE SOBREPOSICION DE UN SIG

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Entre las aplicaciones más usuales destacan:

o Especialmente en ciencias medioambientales (en sentido amplio) y relacionadas con el espacio.

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

El diseño de la arquitectura del SIG (Figura 3) corresponde a un modelo cliente-servidor de tres

Figura 3: Diseño de la arquitectura y tecnologías del Sistema de Información Geográfica

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

● El servidor de aplicaciones, también denominado software intermedio (Middleware), cuya tarea

Ejemplo práctico 1: Sistema Georreferenciada de Información Cafetera – SICA

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

La calidad de la información almacenada es permanentemente monitoreada para certificar la

Actualmente se realiza la implementación de la aplicación SICA en dispositivos móviles diseñado

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Detalles de zona cafetera en el sistema:

El mapa ilustra la distribución espacial de los lotes

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Ejemplo práctico 2: Sistema de Finanzas Castilla

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Desarrollo de un Sistema de Información Geográfica Web para el análisis espacial y

La interfaz de usuario de la Figura 6, corresponde al despliegue tabular de los datos en las

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Figura 6: Interfaz gráfica para el despliegue tabular de datos

Figura 7: Interfaz gráfica de configuración partida

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

En cuanto a las características propias de la zona, se realiza la identificación de las rentas,

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

La segunda interfaz de importancia en la aplicación de finanzas castilla, es la correspondiente con

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Ejemplo de PostGis Mapeo

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Ahora obtendrá una lista de las tablas espaciales en la base de datos:

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Actividad 2 - Modelos de Bases de Datos Orientados a la Funcionalidad

Creación de una Tabla Espacial la manera fácil

Ahora usaremos el administrador de DB para importar un archivo de formas en la base de datos.