RESUMEN TASD

Unidad 2: Modelo relacional

Porque hacemos un diseño de BDD?
● Describir la información que necesita el negocio
● Facilitar la discusión
● Prevenir errores y malos entendidos
● Generar documentación del sistema
● Formar la base para el diseño del modelo físico
● Fortalecer una buena práctica

Ciclo de vida
1) Realidad del negocio
2) Modelo lógico: Se arma el esquema de la base con las relaciones entre tablas.
3) Modelo físico: Se definen los tipos de datos, que dependen del motor de base de
datos con el que se está trabajando (target server).
4) Target Server

Tipos de datos
● Nativos(Built-in): Numéricos (smallint ,int, bigint, float, numeric, decimal), Texto
(char, varchar, nchar, nvarchar, lvarchar), Fecha (date, datetime, timestamp,
time, interval), otros (blob, clob, text, byte).
● Tipos de datos definidos por el usuario (UDTs)
Para elegir un tipo de dato debe tenerse en cuenta su rango de valores, las operaciones
que se realizarán con este y cuanto espacio ocupa.

Tipos de datos numéricos

● Utilizar siempre el tipo de dato numérico que ocupe menor espacio en disco
● Evitar el uso de FLOAT o DOUBLE, a menos que se requiere precisión de varios
decimales
● Utilizar DECIMAL o NUMERIC para valores que requieran una cantidad fija de
decimales
● Considerar adecuadamente la precisión para campos DECIMAL o NUMERIC

Tipos de datos texto

● No Utilizar columnas de texto para identificadores de los objetos
● Para textos menores a 5 caracteres, utilizar tipos de datos CHAR (no usar
VARCHAR)
● No utilizar VARCHAR para cadenas de caracteres de longitud fija y conocida
● Considerar tipos de datos CLOB, TEXT o LVARCHAR para cadenas de caracteres
muy largas

Tipos de datos fecha

● Recordar: ANSI SQL no está debidamente definido para los campos de tipo fecha.
● Elegir el tipo de datos de acuerdo al nivel de precisión mínimo requerido

Modelado dimensional
Es una técnica de diseño que busca presentar los datos en un framework estándar,
intuitivo y escalable, que permite un acceso a los datos altamente performante,
basándose en el modelado relacional pero con algunas restricciones de diseño
importantes

Data Warehouse: es una copia de los datos transaccionales específicamente

estructurada para la consulta y el análisis
Tablas de dimensiones: Las tablas de dimensiones
definen como están los datos organizados lógicamente y
proveen el medio para analizar el contexto del negocio.
Contienen datos cualitativos. Representan los aspectos de
interés, mediante los cuales los usuarios podrán filtrar y
manipular la información almacenada en la tabla de hechos.
Como se puede observar, cada tabla posee un identificador único y al menos un campo o
dato de referencia que describe los criterios de análisis relevantes para la organización.

Tablas de hechos: Las tablas de hechos contienen, precisamente, los hechos que serán
utilizados por los analistas de negocio para apoyar el proceso
de toma de decisiones. Contienen datos cuantitativos.
Los hechos son datos instantáneos en el tiempo, que son
filtrados, agrupados y explorados a través de condiciones
definidas en las tablas de dimensiones.
El registro del hecho posee una clave primaria que está
compuesta por las claves primarias de las tablas de
dimensiones relacionadas a este.

Modelado multidimensional
Almacenamiento a través de tablas de hechos y tablas de dimensiones. Proveen una
estructura que permite, a través de la creación y consulta a una estructura de datos
determinada (cubo multidimensional por ejemplo), tener acceso flexible a los datos, para
explorar y analizar sus relaciones, y consiguientes resultados.
Las bases de datos multidimensionales implican tres variantes posibles de
modelamiento, que permiten realizar consultas de soporte de decisión:

Esquema en Estrella: Consta de una tabla de hechos central y de varias tablas de

dimensiones relacionadas a esta, a través de sus respectivas claves.
Este modelo debe estar totalmente desnormalizado. Las ventajas que trae aparejada la
desnormalización, son las de obviar Joins entre las tablas cuando se realizan consultas,
procurando así un mejor tiempo de respuesta y una mayor sencillez con respecto a su
utilización. El punto en contra, es que se genera un cierto grado de redundancia, pero el
ahorro de espacio no es significativo. El esquema en estrella es el más simple de
interpretar y optimiza los tiempos de respuesta ante las consultas de los usuarios, sin
embargo es el menos robusto para la carga y es el más lento de construir.

Esquema Copo de Nieve: Este esquema representa una extensión del modelo en
estrella cuando las tablas de dimensiones se organizan en jerarquías de dimensiones.
Existe una tabla de hechos central que está relacionada con una o más tablas de
dimensiones, quienes a su vez pueden estar relacionadas o no con una o más tablas de
dimensiones.
Este modelo es más cercano a un modelo de entidad relación, que al modelo en estrella,
debido a que sus tablas de dimensiones están normalizadas.
Uno de los motivos principales de utilizar este tipo de modelo, es la posibilidad de
segregar los datos de las tablas de dimensiones y proveer un esquema que sustente los
requerimientos de diseño. Otra razón es que es muy flexible y puede implementarse
después de que se haya desarrollado un esquema en estrella.
Se pueden definir las siguientes características de este tipo de modelo:
 ● Posee mayor complejidad en su estructura.
● Hace una mejor utilización del espacio.
● Puede desarrollar clases de jerarquías fuera de las tablas de dimensiones, que
permiten realizar análisis de lo general a lo detallado y viceversa.
A pesar de todas las características y ventajas que trae aparejada la implementación del
esquema copo de nieve, existen dos grandes inconvenientes de ello:
● Si se poseen múltiples tablas de dimensiones, cada una de ellas con varias
jerarquías, se creará un número de tablas bastante considerable, que pueden
llegar al punto de ser inmanejables.
● Al existir muchas uniones y relaciones entre tablas, el desempeño puede verse
reducido.
● Las existencia de las diferentes jerarquías de dimensiones debe estar bien
fundamentada, ya que de otro modo las consultas demorarán más tiempo en
devolver los resultados, debido a que se deben realizar las uniones entre las
tablas.

Esquema Constelación o copo de estrellas:

Los mencionados esquemas pueden ser implementados de diversas maneras, que,

independientemente al tipo de arquitectura, requieren que toda la estructura de datos
este desnormalizada o semi desnormalizada, para evitar desarrollar uniones (Join)
complejas para acceder a la información, con el fin de agilizar la ejecución de consultas.
Los diferentes tipos de implementación son los siguientes:

● ROLAP: Relational OLAP, basado en acceso a BD relacionales. Implementación

OLAP que almacena los datos en un motor relacional.
● MOLAP: Multidimensional OLAP, basado en acceso a BD multidimensionales. Esta
implementación OLAP almacena los datos en una base de datos multidimensional.
Para optimizar los tiempos de respuesta, el resumen de la información es
usualmente calculado por adelantado (y es comprimida al almacenarse).
● HOLAP: Hybrid OLAP, permite almacenar una parte de los datos como en un
sistema MOLAP y el resto como en uno ROLAP
Arquitectura Business Intelligence
Una solución de Business Intelligence parte de los sistemas de origen de una
organización (bases de datos, ERPs, ficheros de texto...), sobre los que suele ser
necesario aplicar una transformación estructural para optimizar su proceso analítico.
Para ello se realiza una fase de extracción, transformación y carga (ETL) de datos. Esta
etapa suele apoyarse en un almacén intermedio, llamado ODS, que actúa como pasarela
entre los sistemas fuente y los sistemas destino (generalmente un datawarehouse), y
cuyo principal objetivo consiste en evitar la saturación de los servidores funcionales de la
organización.
La información resultante, ya unificada, depurada y consolidada, se almacena en un
datawarehouse corporativo, que puede servir como base para la construcción de
distintos datamarts departamentales. Estos datamarts se caracterizan por poseer la
estructura óptima para el análisis de los datos de esa área de la empresa, ya sea
mediante bases de datos transaccionales (OLTP) o mediante bases de datos analíticas
(OLAP).

Los datos albergados en el datawarehouse o en cada datamart se explotan utilizando

herramientas comerciales de análisis, reporting, alertas... etc.

Cubos OLAP
Es una base de datos multidimensional, en la cual el almacenamiento físico de los datos
se realiza en un vector multidimensional. Los cubos OLAP se pueden considerar como
una ampliación de las dos dimensiones de una hoja de cálculo.
Optimización de rendimiento (performance tuning)
SQL Tuning: En una aplicación que accede a una base de datos, es muy importante el
tuning de las sentencias SQL, particularmente hay que prestar atención a las consultas
(SELECT, UPDATE y DELETE) y a las cargas masivas de datos (que se pueden optimizar
con cursores for insert y/o herramientas para carga masiva de datos).

Optimizador: Componente del motor de base de datos encargado de identificar el

camino (path) más rápido para resolver una consulta (query).
Funcionamiento en Informix: Una vez que la sentencia SQL enviada por la aplicación
cliente ha pasado el proceso de parsing (o sea que es sintáctica y semánticamente
correcta), el optimizador procede a identificar y analizar todos los query paths posibles
para la resolución de dicha sentencia; para
esto considera tanto el método de acceso,
como el orden y la metodología de join;
amén de otras características particulares
tales como el nivel de optimización y el
objetivo de optimización. A todos los query
paths se les asigna un costo, producto de
una fórmula compleja que considera la
cantidad de filas de las tablas, la cantidad
de páginas que ocupa, el coeficiente de
selectividad de los índices, un factor de
I/O a disco y un factor de consumo de
CPU; para asignar este costo el
optimizador se basa en las estadísticas almacenadas en el catálogo de la base de datos
(tablas sys* en el caso de Informix). Una vez que todos los query paths tienen un costo
asignado, el optimizador simplemente selecciona el de menor costo, y es con este query
path que el motor resuelve la sentencia, entregando el resultado de vuelta a la
aplicación cliente.

Analisis del query path: Consiste en:

1. Identificar y aislar el query lento
2. Registrar el tiempo de ejecución del query
3. Obtener el “explain” (detalle del query path elegido por el optimizador)
4. Analizar y aplicar cambios
5. Volver a iterar hasta obtener el resultado deseado

(obtencion del query path) (optimizador en informix)

Influenciando al optimizador
1. Estadísticas: Las estadísticas utilizadas por el optimizador para resolver un
query, SOLO se actualizan cuando se corre la sentencia de actualización. (Informix → update
 statistics, DB2 → RUNSTAT, Oracle → DBMS_STAT).

2. Fragmentación o particionamiento: Las tablas o índices

pueden estar particionados, o sea el espacio físico es dividido en
unidades de almacenamiento llamadas particiones. Cada
partición contiene un conjunto de datos. Las tablas o índices
particionados permiten mejorar los tiempos de respuesta
(índices globales o locales). Las particiones pueden o no estar
en dbspaces, tablespaces o espacios de almacenamiento
distintos.
○ Particionamiento (en DB2): Todas las particiones en
distintos tablespaces. Una partición por cada tablespace.
Una combinación de las anteriores.
○ Fragmentación (Informix)
■ Round Robin: Ventajas: distribuye los datos en forma pareja entre
las dbspaces y optimiza el tiempo de carga de los datos.
Desventajas: no permite que el optimizador elimine fragmentos.
■ Basada en expresion: Ventajas:permite al optimizador eliminar uno
o más fragmentos en una búsqueda, lo que reduce el tiempo del
query. En el ejemplo de la slide, si se consultan todos los clientes
del estado de California (“CA”), solo hay que scanear el fragmento
en la dbspace1, los otros dos se eliminan de la consulta.
Desventajas: la evaluación de la expresión hace más lenta la carga
de datos. Por eso conviene mantener la expresión de fragmentaci

3. SELECT FIRST “n”: Permite seleccionar las primeras “n” tuplas del set
resultante de la consulta. No puede usarse en: Subqueries, SELECT INTO TEMP,
Vistas, Uniones, Stored Procedures.

4. Directivas al optimizador: Permiten indicarle al optimizador un query path

específico a seguir en vez de dejarlo que realice el análisis y selección en base a
costo. Los tipos de directivas al optimizador son los siguientes:
○ Access methods - índice versus sequential scans
○ Join order - especifica el orden en que se hará el join de las tablas
○ Join methods - fuerza hash joins o nested loop joins
○ Optimization Goal - para tiempo de respuesta rápido versus throughput
○ EXPLAIN - genera la salida del sqexplain.out
Las directivas pueden ser:
○ Directivas Negativas: Le indican al optimizador que descarte un
conjunto de query paths (círculo interno), dejándole libertad para utilizar
cualquiera de los otros query paths posibles (círculo externo - círculo
interno).
○ Directivas Positivas: Le restringen al optimizador a un conjunto
específico de query paths para la resolución de la consulta (círculo interno
únicamente).

5. Crear índices en las tablas cuyas consultas presenten problemas de

performance. Obviamente, cuantos más índices se agreguen a una tabla, más
rápidos serán los SELECTs, pero más lentas las actualizaciones (INSERTs,
UPDATEs y DELETEs), por lo que se debe buscar un adecuado equilibrio.
(ejemplos en informix)

Unidad 4: Seguridad, Backup y Restore

Las 4 dimensiones de la seguridad en BDD (cada uno puede complementar al anterior):
● Seguridad por fila y columna:
○ Sentencias GRANT (dar privilegios), REVOKE (sacar) estándares en todas
 las BDD
○ Separación de permisos según funcionalidades de las aplicaciones
○ Los DBA cuentan con permisos especiales para administrar, no tanto como
○ Superusuario: aquel que tiene acceso a todo.
○ Las mejores prácticas indican: Otorgar sólo los permisos necesarios,
agrupar los permisos por roles o grupos, los DBA deben estar auditados
para tareas administrativas y acceso a los datos.

● Seguridad basada en etiquetas: Permite filtrar el acceso a los datos según su

sensibilidad. Se le asigna etiquetas tanto a datos como a usuarios, pueden ser
“secreto”, “confidencial” y “público”. Entonces si un usuario tiene acceso a lo
público, sólo verá los datos públicos de una tabla. En este modelo no se puede
leer el nivel superior ni escribir en el nivel inferior.

● Encriptación: Permite el ocultamiento de datos sensibles. Se pasa el dato por

algún algoritmo antes de escribirlo para que sea ilegible. En este caso mayor
seguridad implica menos performance. Hay 3 tipos:
○ Encriptación nativa: Encriptación de toda la base de datos en forma
nativa por el mismo motor. Incluye encriptación de: Datos, Log files,
Tablespaces/DBspaces, Datafiles/Containers, Backups,
Tablas/Índices/BLOBs/etc.
○ Encriptación por columna: Puede ser una funcionalidad del motor o
implementada a través de código de la aplicación con un algoritmo propio
de encriptación.
○ Encriptación por HW: El motor manda las páginas desencriptadas pero
el disco lo encripta antes de escribirlo e inmediatamente después de
leerlo. Es lo mas performante. Tiene clave propia del controlador del disco.

● Auditoría:Permite realizar un seguimiento de Accesos (principalmente DBA y

superusuarios, auditar a todos los usuarios no es viable) e implica un registro de
operaciones (sentencias del tipo DROP TABLE, UPDATE, DELETE, etc.). Existen
herramientas de monitoreo y análisis propias del motor o de terceros. Afecta a la
performance y espacio en disco.

Transacción: Conjunto de operaciones que se realizan atómicamente. O se realizan todas

o ninguna.

Proceso de logging
Permite recuperar una base de datos a partir de una situación de crash y mantener la
consistencia transaccional (ROLLBACK).
Para asegurar la consistencia el motor utiliza una bitácora transaccional (o log) en el
que registra todas las operaciones. Cuando se quiere realizar una operación se pasa la
pagina de disco a memoria, luego el motor registra la operación en un buffer en
memoria (ej.: si fuera un DELETE, guarda el registro a borrar). Luego de esto, la
transacción se escribe en los logs del motor en disco (se commitea).
Siempre las modificaciones se hacen en memoria. Nunca directo en el disco.
En caso de crash, se hará un chequeo de los logs para buscar inconsistencias, y en todo
caso, terminar la transacción.
Funciones:
● En caso de caída permite hacer un crash recovery.
● Permite hacer un ROLLBACK.
● Asegura consistencia.
● No afecta el rendimiento.
La implementación varía de acuerdo al motor:
● En Informix:1 Physical Log (BEFORE IMAGES), 3 o más Logical Logs (Bitácora
transaccional), Ambos residen en dbspaces de la instancia
● En DB2: 3 o más Log Files (Bitácora transaccional), Son archivos en Filesystem,
Corresponden a 1 sola Base de Datos

Backup
Copia de los datos originales se realiza con el fin de disponer un medio para recuperarlos
● Backup Físico: Copia física de los datos. Usualmente a nivel de página.
Portabilidad limitada.
● Backup Lógico: Resguardo de la bitácora transaccional. Varía según cada motor.
Permite recuperarse a un punto en el tiempo muy cercano al momento de la falla.

● Restore Físico: Recuperación del backup físico. Los datos se recuperan a la

fecha y hora de inicio del último backup físico.
● Restore Lógico: Recuperación de la bitácora transaccional. Se rehacen todas las
transacciones registradas en la bitácora (rollforward). Se vuelve para atrás
aquellas que no tengan finalización explícita (rollback). Antes se debe hacer un
restore físico.
Al finalizar el restore la base siempre esta consistente.

Tipos de backup
● Según medio de backup:
○ A disco
○ A cinta (o VTL)
○ Integrados con la solución de backup empresarial
○ A la nube (Cloud Storage / Object Storage)
● Según datos a resguardar:
○ Full: Copia completa de todos los datos
○ Incrementales: Parciales. Se reduce el tamaño, y el tiempo de backup y de
recuperación. Existen 2 tipos (y la combinación de estos):
■ Acumulativo: Acumula los cambios desde el último backup full.
■ Deltas: No va acumulando. Sino que tiene en discos separados los
de cada dia. Entonces se necesitan más discos para hacer el mismo
restore que el acumulativo.

(A partir de la diapo 17 empieza a repetir cosas en ingles y habla de informix, nose si

hay algo de importancia)

Unidad 3: Técnicas avanzadas para la replicación de datos

Replicar es el c. O copiar y mantener una base de datos completa. Se pueden mantener
varias copias. En general las copias se realizan en servidores diferentes, o sitios remotos
diferentes. Las réplicas pueden ser de solo lectura o lectura-escritura.
Ventajas:
● Disponibilidad de Datos (Alta disponibilidad)
● Performance por concurrencia elevada (balanceo de carga)
● Procesamiento distribuido
● Seguridad
 ● Mayor tolerancia a fallas

Replicación homogénea
Replicación entre bases de datos de un mismo motor. Generalmente la replicación es
nativa.
● HADR (DB2): Copia cada BDD completa y la mantiene actualizada con 2
modalidades:
○ ACTIVO/PASIVO: BDD prim = L/E, BDD secu = sin actividad (stand by).
○ ACTIVO/ACTIVO: BDD primaria = L/E, BDD secundaria = L
La actualización del secu siempre se hace leyendo la bitácora transaccional del
primario.
Take over: Si la primaria se cae, la secundaria actúa como primaria. Y viceversa.
Catch-up: Cuando la caída se restablece, se sincronizan.

● HDR (Informix): Mismo concepto que DB2 pero se copia la instancia completa
de Informix (todas las BDD). Permite múltiples instancias secundarias en cluster,
con soporte para lectura y escritura.
○ ACTIVO/ACTIVO: BDD primaria = L/E, BDD secundaria = L o L/E

● Enterprise replication (Informix): Permite replicar un grupo de tablas, una

tabla, parte de una tabla o un select. Hay granularidad para replicar a varios
sitios. Puede haber actualizaciones simultáneas en la misma tabla (necesita
mecanismo de resolución).
○ ACTIVO/ACTIVO
■ Soporta “Primary/Target” y “Update Anywhere”
■ Permite Balanceo de carga a través del Connection Manager
■ Permite administrar la solución como un cluster a través de
Flexible Grid
■ Permite soportar Data Sharding y Query Sharding.

● Data guard (Oracle): Replica la BDD completa. Replicación física.

○ ACTIVO/PASIVO: BDD primaria = L/E, BDD secundaria = stand by.
○ ACTIVO/ACTIVO: BDD primaria = L/E, BDD secundaria = L

● MVR-Vistas materializadas (Oracle): Replicación con Vistas Materializadas. La

vista materializada puede ser una copia completa o parcial de una tabla a un
momento dado. Los cambios primero pasan al log, luego se pasa el log a la
secundaria. Es una replicación lógica.
○ ACTIVO/ACTIVO: BDD primaria = L/E, BDD secundaria = L/E

Replicación heterogénea
Replicación entre bases de datos de diferentes motores. Generalmente se utiliza un
software externo.
Change data capture: Se accede los logs del motor de una base y los “traducen” para
el motor de la otra base.

Federación
No se “copian” los datos, sino que hay una vista unificada de diversas fuentes. Es un
producto que no tiene tablas de por sí, sino que tiene los datos para armarlos en
diferentes BDDs. El acceso a los datos no estructurados es de solo lectura.
Problemáticas que resuelve:
● Inteligencia dentro de la aplicación.
● Una conexión por cada base de datos.
● No puede realizarse join entre tablas de distintas bases de datos.
● Altos tiempos de desarrollo.
 ● Manejo de datos redundantes.
● Modificar o reemplazar sistemas para que trabajen juntos.
Ventajas
● Consolida datos y accesos distribuidos en una única fuente de datos.
● Permite el uso de SQL standard.
● Reduce el tiempo de programación.
● Reduce los costos de migración a otros de productos.
● Permite análisis de negocio con data warehouse.
● Reduce los costos necesarios para manejar redundancia de datos.
● Optimización de las consultas.
● Utilización de Passthru.
Desventajas
● Baja performance para ambientes con tiempo de respuesta rápidos en
actualizaciones (INSERTs/UPDATEs/DELETEs).

Características:
1. Federación: Permite consultas y escrituras a distintas fuentes de datos. Las
consultas se realizan con SQL standard. Permite utilización de OO API.
2. Caching: Provee performance para las consultas. El caching se realiza a través de la
definición de MQT (Materialized Query Table). Si se habilita el uso del cache, se lee y
escribe de este en vez de utilizar la fuente de datos. Se necesita indicar el tipo de
refresco de los datos, si es manual o por replicación. Las MQT se basan en fuentes
relacionales.
3. Replicación: Permite replicación entre bases distintas fuentes relacionales con
algunas limitaciones.
4. Transformación:A través de SQL, XML; Web Services, Data Mining.

EL DB2 Information Integrator o InfoSphere Federation Server

es una integración de datos estructurada y no estructurada en una única base de datos.
● Provee consultas en tiempo real y acceso de escritura
● Permite una transformación de los datos para el análisis de negocio e intercambio
de datos.
● Maneja los datos para obtener performance, concurrencia y disponibilidad.
Arquitectura 3 capas:
1. Data layer: Es la base del integrator. Esta capa provee el almacenamiento,
recuperación, y transformación de los datos desde las fuentes en diferentes
formatos. Esta capa esta basada en la arquitectura de bases federadas. Los datos
se almacenan como tablas relacionales estructuradas, documentos XML semi-
estructurados, o formatos sin estructura. Explota la tecnología de base de datos
federadas con una arquitectura de wrapper para integrar fuentes de datos
externas con un servidor de datos tradicional o con aplicaciones.
2. Services Layer: El information integrator conoce como acceder los datos y
determina como los usa. Esta capa provee una infraestructura transparente y
embebida para los servicios de acceso de datos dentro de las aplicaciones.
Incluye procesamiento de consultas, búsquedas de texto y mining,
transformación y replicación de datos.
3. Application Layer: El information integrator conoce las interfaces de
programación que usan los datos. La capa de aplicación provee modelos
 standards de programación y lenguaje de consulta para las otras capas. Se
pueden usar las interfaces de web services, o las interfaces de programación de
aplicaciones (APIS) tradicionales.
Cada capa es una entidad separada, pero dependen y trabajan juntas para proveer una
mayor integración.

(performance federacion)

Unidad 5: Bases de Datos In-Memory

Los datos pueden guardarse en memoria con diferentes estructuras que permitan una
consulta más veloz de los mismos.

Procesamiento transaccional (OLTP): Aquellas consultas relacionadas con la entrada

y recuperación de registros.

Procesamiento analitico (OLAP): Aquellas consultas relacionadas con la obtención y

procesamiento de grandes cantidades de datos.

Modelo por fila

Se guardan registros completos de forma consecutiva dentro de una página. Si un
registro no entra en la página se pone un puntero y se mueve el registro a otra página.
En general el registro no puede exceder el tamaño de la página.

- Acceder a un registro implica la búsqueda de la página hasta encontrar el registro.

- Realizar un cálculo por atributo implica la lectura de todas las páginas.
⇒ Es mas eficiente para querys transaccionales y no analiticas.

Modelo por columna

Se guardan un conjunto del mismo atributo de diferentes registros agrupados en páginas

- Acceder a un registro implica la búsqueda y lectura de páginas hasta encontrar todos

los atributos de un registro.
- Realizar un cálculo por atributo implica la lectura de las páginas que contengan a este.
⇒ Es mas eficiente para querys analiticas y no transaccionales.

DB2 con BLU Acceleration

Es un motor columnar dentro del motor relacional de DB2. Permite mejorar la
performance de los querys análiticos en varios órdenes de magnitud.
● Classic DMS: Maneja las páginas de forma tradicional.
● BLU DMS: Maneja las páginas de forma columnar.
Ambos utilizan el mismo bufferpool y pueden coexistir tablas columnares con tablas por
fila (optimizador elige cual usar). Dispone de un utilitario para convertir tablas de fila a
columnar y viceversa:
● Shadow table: Es una tabla duplicada que, a diferencia de la original, utiliza el
modelo columnar, agilizando querys analiticas. Esta comprimida para evitar
utilizar el doble de memoria.
Esta tecnología trae aparejada 7 innovaciones:
1. Paralelismo: Si hay varios cores usa todos los que puede para procesar.
2. SIMD (single instruction multiple data): Realizar la misma operación para varios
datos simultáneamente.
3. Compresión: No hace falta descomprimir todo, solo un pedazo (ya que se
comprime en orden). Compresión hasta 10 a 1
4. Manejo optimo de memoria
5. Modelo columnar: Se guarda en disco pero siempre se procesa en memoria.
6. Data skipping: No procesa lo que no necesita.
7. Facil de usar e implementar
Ventaja: Con la misma cantidad de memoria mejoro la performance.
Desventaja:Lo pago con aumento de espacio en disco (10%)

Oracle In-Memory
Formato Dual para la misma tabla: La tabla en disco siempre se organiza por filas pero
en memoria puede tener los 2 formatos. Ambos formatos son consistentes
transaccionalmente. Requiere aprox 20% adicional de memoria. No requiere más espacio
de disco. Se pueden borrar los índices sobre las columnas involucradas.

In-memory area: Es una nueva área de memoria dentro de la SGA (dentro de la

shared memory). Cuando se levantan datos del disco se van a levantar por fila en el
buffer cache, pero pasa a la in-memory area en formato por columnas (si corresponde).

Disponible a nivel tablespace, tabla, partición, subpartición, y columnas específicas. Si la

base tiene un tamaño reducido se la podría subir completa a memoria

Restricciones
● Objetos del Esquema SYS (Catálogo o Diccionario de datos)
● IOT (Index Organized Tables)
● Tipos de datos: LONG o LOBS (objetos binarios)
● Objetos más chicos que 64Kb

Las 7 innovaciones de BLU también se aplican acá aunque no se implementan igual.

SAP HANA
Solo almacena los datos en disco en formato columnar. No hay formato híbrido de
almacenamiento en formato fila y columna. No hay duplicidad de datos.
Cada columna es almacenada como un índice. No hay necesidad de índices primarios. Se
pueden crear índices secundarios con varias columnas para usarse en escenarios OLTP.
Los cálculos son realizados en memoria on-demand, esto quiere decir que para una
query puede necesitar pasar toda la base a memoria (lo que puede demorar), pero una
vez pasado a memoria anda rapido.

In-Memory OLTP (SQL Server/Azure SQL)

La palabra clave T-SQL MEMORY_OPTIMIZED, en la sentencia CREATE TABLE, es cómo
se crea una tabla para que exista en la memoria activa, en lugar de en el disco.
Las tablas optimizadas para la memoria tienen una representación propia en memoria
activa y una copia secundaria en el disco. La copia de disco es para la recuperación de
rutina después de un apagado y luego reinicio del servidor o base de datos. Esta
dualidad de memoria-más-disco está completamente oculta de ti y de tu código.
Cómo funcionan las tablas con optimización de memoria más rápido

● Naturaleza dual: una tabla optimizada para la memoria tiene una

representación en la memoria activa y la otra en el disco duro. Cada transacción
está comprometida con ambas representaciones de la tabla. Las transacciones
operan contra la representación de memoria activa mucho más rápida. Las tablas
 optimizadas para la memoria se benefician de la mayor velocidad de la memoria
activa frente al disco. Además, la mayor agilidad de la memoria activa hace
práctico una estructura de tabla más avanzada que está optimizada para la
velocidad. La estructura avanzada es también sin paginación, por lo que evita la
sobrecarga y la contención de los cierres y spinlocks.
● Sin bloqueos: La tabla optimizada para la memoria se basa en un enfoque
optimista de los objetivos de la competencia de integridad de datos versus
concurrencia y alto rendimiento. Durante la transacción, la tabla no coloca
bloqueos en ninguna versión de las filas actualizadas de datos.Esto puede reducir
considerablemente la contención en algunos sistemas de alto volumen.
● Versiones de fila: En lugar de bloqueos, la tabla optimizada para la memoria
agrega una nueva versión de una fila actualizada en la tabla en sí, no en tempdb.
La fila original se mantiene hasta después de que se compromete la transacción.
Durante la transacción, otros procesos pueden leer la versión original de la fila.
○ Cuando se crean varias versiones de una fila para una tabla basada en
disco, las versiones de fila se almacenan temporalmente en tempdb.
● Menos registro: las versiones anteriores y posteriores de las filas actualizadas
se almacenan en la tabla optimizada para la memoria. El par de filas proporciona
gran parte de la información que tradicionalmente se escribe en el archivo de
registro. Esto permite al sistema escribir menos información, y menos
frecuentemente, en el registro. Sin embargo, la integridad transaccional está
garantizada.

Informix Warehouse Accelerator (IWA)

Procesa las warehouse querys más rápidamente que el servidor de base de datos
Informix. Mejora el rendimiento y al mismo tiempo reduce la administración.
Las demandas de las consultas de data warehouse son sustancialmente diferentes de las
consultas de procesamiento transaccional en línea (OLTP). Una consulta típica de
almacén de datos requiere el procesamiento de un gran conjunto de datos y devuelve un
conjunto de resultados pequeño.

● Informix Warehouse Accelerator utiliza una copia de los datos.

● Para acelerar el procesamiento de consultas, la copia de los datos se mantiene en
la memoria en un formato comprimido especial. Los avances en técnicas de
compresión, el procesamiento de consultas en datos comprimidos y la
organización en columnas híbridas de datos comprimidos, permiten a Informix
Warehouse Accelerator consultar los datos comprimidos.
● Los datos se comprimen y se mantienen en la memoria de Informix Warehouse
Accelerator para maximizar el procesamiento de consultas en paralelo.

Sin embargo, antes de utilizar Informix Warehouse Accelerator debe diseñar e

implementar una base de datos dimensional que utilice un esquema de estrella o copo
de nieve para su almacén de datos.

Sentencias y practica
UNIDAD 2
Obtencion del query path
● Informix: SET EXPLAIN ON
● DB2: db2expln
● Oracle: EXPLAIN PLAN FOR SELECT …
(EXPLAIN PLAN FOR SELECT * FROM schema.table WHERE column_pk = 'value_pk')
● MySQL: EXPLAIN [EXTENDED] SELECT …
EXPLAIN [EXTENDED] SELECT COUNT(*) FROM database.table WHERE column_A = value_A;
● PostgreSQL: EXPLAIN [ANALYZE] SELECT …
EXPLAIN [ANALYZE] SELECT * FROM schema.table where column = 'value';
● SQL Server: SET SHOWPLAN_TEXT ON
SET SHOWPLAN_TEXT ON;
GO
 SELECT *
FROM dbo.table
WHERE column_pk = value;
GO
SET SHOWPLAN_TEXT OFF;
GO
● Sybase: SET SHOWPLAN ON

Analisis del query path

● Informix:
SET EXPLAIN ON;
SELECT lname, fname, call_dtime
FROM customer cu, cust_calls cc
WHERE cu.customer_num = cc.customer_num
AND cu.customer_num = 116;
SET EXPLAIN OFF;
La sentencia SET EXPLAIN ON; genera una salida a un archivo ASCII
Dónde encontrar la salida del SET EXPLAIN ON ?
1. UNIX:
Usuario local: archivo sqexplain.out en el directorio corriente.
Usuario remoto: archivo $INFORMIXDIR/sqexplain.out
2. NT/Windows:
Existe un share que contiene las salidas discriminadas por nombre de usuario:
\\SEVERNAME\sqexpln\username.out

Estadisticas (informix)
update statistics [low] [for table tabname (col)];
update statistics high [for table tabname (col)];
update statistics medium [for table tabname (col)];
update statistics for procedure [procname];

Particionamiento (DB2)
● Por Rangos
CREATE TABLE orders(id INT, shipdate DATE, …)
PARTITION BY RANGE(shipdate)
(
PARTITION q4_2005 STARTING MINVALUE,
PARTITION q1_2004 STARTING '1/1/2004',
PARTITION q2_2004 STARTING '4/1/2004',
PARTITION q3_2004 STARTING '7/1/2004',
PARTITION q4_2004 STARTING '10/1/2004' ENDING ‘12/31/2006'
)

CREATE TABLE departments

(dept_no INT
desc CHAR(3))
IN tbsp0, tbsp1, tbsp2, tbsp3
PARTITION BY (dept_no NULLS FIRST)
(STARTING FROM(0) ENDING(39) EVERY(10))

Fragmentación (Informix)
● Round Robin
CREATE TABLE orders (.....)
FRAGMENT BY ROUND ROBIN IN dbspace1, dbspace2, dbspace3;
● Expression-based
CREATE TABLE customer (.....)
FRAGMENT BY EXPRESSION
state = “CA” IN dbspace1,
state = “DE” IN dbspace2,
REMAINDER IN dbspace3;
Directivas (Informix)
SELECT --+ORDERED, AVOID FULL(e)
name, salary, deptname
FROM emp e, dept d
WHERE loc = “Palo Alto”
AND e.dno = d.dno ;

Directiva Positiva: INDEX (table [index … ])

Indica que utilice un índice determinado para acceder a una tabla en particular. Se debe
indicar el nombre del índice tal como figura en el catálogo de la base de datos
Directiva Negativa: AVOID_INDEX (table [index …])
Indica que no utilice el índice mencionado en el acceso a esa tabla.

SELECT --+ INDEX (e salary_indx)

name, salary
FROM emp e
WHERE e.dno = 1
AND e.salary > 50000 ;

FIRST_ROWS: optimiza para recuperar más rápidamente las primeras 100 tuplas de la
consulta
ALL_ROWS: optimizar para recuperar más rápidamente todas las tuplas de las
consulta.

SELECT --+FIRST_ROWS
name, age
FROM emp e, dept d
WHERE e.dno = d.dno ;

SET EXPLAIN ON; también es una directiva positiva

SELECT --+EXPLAIN, AVOID_FULL(e)

name, jobname
FROM emp e, jobs j
WHERE j.title =”Clerk” AND j.job = e.job ;

UNIDAD 4
Comandos de backup y restore

• A nivel de Base de Datos

– dbexport / dbimport (ascii)

– onunload / onload (binario)

• A nivel de tabla

– onunload / onload (binario)

– Sentencias UNLOAD/LOAD (SQL, ascii)

• Miscelaneos

– dbschema (permite obtener el DDL de un objeto)

 – HPL (utilitario para carga másiva de datos)

Backup de la base
Dbexport: dbexport stores_demo -o /directorio

Restore de la base
Dbimport: dbimport stores_demo -d sabd_dbs -l -i /directorio

UNIDAD 5
DB2 BLU
Crear o convertir tablas a modo columnar:
1. Convertir con utilitario db2convert
2. Convertir con stored procedure admin_move_table()
3. CREATE TABLE … ORGANIZE BY COLUMN … ;

Cargar datos en la tabla columnar:

1. INSERT
2. IMPORT
3. LOAD

Ejecutar queries contra las tablas columnares:

SELECT ACCT_GRP, SUM(BALANCE)
FROM test.ACCT
WHERE ACCT_GRP BETWEEN 100 AND 150
GROUP BY ACCT_GRP

Oracle In-Memory
ALTER SYSTEM SET inmemory_size = 5G scope=spfile;
ALTER TABLE <nombre_tabla> INMEMORY; (sube a memoria)
ALTER TABLE <nombre_tabla> NO INMEMORY; (baja de memoria)
ALTER TABLE <nombre_tabla> INMEMORY PRIORITY CRITICAL (llena el objeto después de abrir la base)