7. Modelado Físico

El paso de un modelo lógico a uno físico requiere un profundo entendimiento del manejador de bases de datos que se desea emplear, incluyendo características como:

Conocimiento a fondo de los tipos de objetos (elementos) soportados
Detalles acerca del indexamiento, integridad referencial, restricciones, tipos de datos, etc
Detalles y variaciones de las versiones
Parámetros de configuración
Data Definition Language (DDL)

Como se comentó en el modelado lógico el paso de convertir el modelo a tablas hace que las entidades pasen a ser tablas (más las derivadas de las relaciones) y los atributos se convierten en las columnas de dichas tablas.

Físicamente esta metáfora de una tabla se mapea al medio físico, con algunas consideraciones como se menciona en las siguientes secciones.

7.1 Atributos

7.1.1 Tipos de Datos

Revisar los tipos de datos disponibles en el DBMS, en especial

Número de dígitos en números enteros
La precisión de los flotantes
Cadenas de caracteres de longitud fija (char(50)) y variable (varchar(50))
Blobs (Binary large objects) y Clobs (Character large objects)

7.1.2 Llaves primarias

En ocasiones se pueden presentar casos en donde la llave primaria no puede representarse en alguno de los tipos ofrecidos por el dbms, en ese caso se podria definir alguno y bien optar por otra llave primaria.

Importante:

Algunos dbms poseen la capacidad de "autoincrement" o "identity property" con la cual pueden automáticamentemanipular algun atributo para generar llaves incrementales. Pero es importante verificar: como se manejan internamente ?, se pueden reiniciar ?, se permite especificar algun valor inicial ?.

7.1.3 Orden de las atributos (columnas)

Algo importante dependiendo del dbms que se utilice pero por lo general la secuencia es:

Columnas de longitud fija que no se actualizan frecuentemente.
Aquellas que nunca se actualizan que por lo general tendrán longitud variable.
Las que se actualizan frecuentemente.

7.1.4 Integridad Referencial

En la medida de lo posible indicar cuales columnas brindan o sirven de vínculo entre 2 tablas.
El usuario (programador) puede hacerse cargo de esto pero es mejor que el dbms se haga cargo.
No se recomienda en ambientes de desarrollo.

7.2 Indices

"Es una tabla que contiene una lista de elementos (llaves) y números de referencia donde dichos elementos se encuentran (campos de referencia)".

Un índice es un atajo desde un campo llave hacia la localización real de los datos.

Es el punto clave de la optimización de velocidad de toda base de datos.

Si se busca alguna tupla en base a un atributo que no tiene un índice entonces se realiza un escaneo de la tabla completa lo cual es demasiado costoso, por eso es recomendable usar índices en:

Llaves primarias
Llaves foráneas
Indices de acceso
Ordenamiento

No olvidar que el uso de un índice implica:

Overhead debido a la actualización de los mismos
Espacio adicional en disco
Procesos batch de muchos datos pueden volverse demasiado lentos
Manipulación de archivos adicionales por el sistema operativo

Tipos de índices:

Btrees

Reverse Key

Basado en btrees pero usando el campo en orden inverso

Craig --> giarC

Partitioned

Btrees separados en diferentes "chunks" que inclusive pueden ser distintas particiones del disco

Ordered

Especificación del btree para indicar si ordena ascendente o descendentemente

Hashing

Acceso directo a los datos a través de una fórmula de hash. El inconveniente es que requiere de espacio adicional en disco y no es útil al recuperar "rangos" de datos.

Clustering

La idea es mantener las tuplas ordenadas bajo algún criterio. El inconveniente es que requiere de espacio adicional, cuando se acaba entonces se puede seguir insertando pero se pierde el concepto de clustering.

Interleaving Data

Cuando 2 tablas de antemano se sabe que se mezclarán (join) para buscar cierta información entonces es conveniente hacer esa mezcla en el disco. La mayoría de los dbms no lo hacen de manera directa, se prefiere el clustering.

Indices Multidimensionales

Bitmaps

Cuando se tienen atributos con pocos valores distintos y se pretenden hacer combinaciones con otros atributos en una misma consulta es conveniente usar un bitmap

Registros originales (edad,salario)

1. (25,60)	2. (45,60)	3. (50,75)	4. (50,100)
5. (50,120)	6. (70,110)	7. (85,140)	8. (30,260)
9. (25,400)	10. (45,350)	11. (50,275)	12. (60,260)

bitmap index de la edad

25: 100000001000	30: 000000010000	45: 010000000100
50: 001110000010	60: 000000000001	70: 000001000000
85: 000000100000

bitmap index del salario

60: 110000000000	75: 001000000000	100: 000100000000
110: 000001000000	120: 000010000000	140: 000000100000
260: 000000010001	275: 000000000010	350: 000000000100
400: 000000001000

Qué empleados tienen entre 45-55 años de edad y un salario entre 100-200 ?

Edad
45: 010000000100
50: 001110000010

con la operación OR: 011110000110

Salario
100: 000100000000
110: 000001000000
120: 000010000000
140: 000000100000

con la operación OR: 000111100000

finalmente la consulta se resuelve mediante el AND

011110000110 AND 000111100000 = 000110000000

Los registros que cumplen con el criterio de la consulta son: el 4 y 5

R-Tree

Region-tree es una estructura que captura la idea de un B-Tree pero para datos multidimensionales. Cada nodo del árbol es un rectángulo mínimo que encierra una región en la cual existen 1 o más elementos.
Una gran diferencia con respecto a los B-Trees es que una búsqueda puede "seguir" varios caminos, si es que un elemento pertenece a varias regiones.

7.3 Denormalización

Se puede definir como el proceso de poner la misma información en varios lugares.

Una normalización reduce problemas de integridad y optimiza las actualizaciones, quizás con el costo del tiempo de recuperación. Cuando se pretende evitar esta demora resultado de la combinación de muchas tablas entonces se puede utilizar la denormalización.

Antes de denormalizar es importante considerar:

El sistema puede tener un desempeño aceptable sin la denormalización ?
Aún con la denormalización el desempeño será siendo malo ?
El sistema será menos confiable debido a la denormalización ?

Candidatos a denormalización:

Numerosas consultas críticas o reportes incluyen datos que incluyen más de una tabla.
Grupos repetidos de elementos necesitan ser procesados en un grupo en lugar de individualmente.
Muchos cálculos necesitan realizarse a una o más columnas antes de procesar las consultas.
Las tablas necesitan ser accesadas de diferentes maneras por diferentes usuarios durante el mismo lapso de tiempo.
Llaves primarias mal diseñadas que requieren tiempo al usarlas en relaciones.
Algunas columnas son interrogadas un gran porcentaje del tiempo.

Importante: nunca se realiza un denormalización en un modelo lógico.

7.3.1 Prejoined Tables

Cuando 2 tablas se mezclan (join) frecuentemente, considerar tener una tabla premezclada (prejoined) la cual deberá:

Contener columnas que no sean redundantes
Contener sólo aquellas columnas absolutamente necesarias para las necesidades de la aplicación
Ser creada periodicamente utilizando las tablas normalizadas (que forman el join)

Ventaja: consultas rápidas y eficientes

Desventaja: la tabla puede quedar inconsistente rapidamente, se recomienda para datos más estáticos que dinámicos.

7.3.2 Report Tables

Mantener reportes en línea puede ser muy costoso, es mejor considerar tener una tabla que incluya los datos de dicho reporte.

Dicha tabla deberá contener:

Una columna por cada columna del reporte
Tener sus tuplas ordenadas secuencialmente en el mismo orden que deben aparecer en el reporte (evitando ordenamientos)
Elementos atómicos (1NF)

7.3.3 Mirror Tables

En ocasiones algún departamento de la organización necesita consultar mientras otro hace modificaciones, se pueden usar dos tablas para balancear la carga y obtener buen tiempo de acceso y modificación.

Se debe tener un esquema de duplicación que permita actualizar el espejo de manera eficiente, esto puede hacerse:

A través de un proceso batch, que es bastante rápido
Directamente con herramientas de replicación y propagación del dbms

7.3.4 Split Tables

Si la cantidad de información es considerable se puede pensar en partir una tabla ya sea vertical u horizontalmente

Vertical: implica conservar en ambas la llave primaria para tener una integridad referencial

Horizontal: consiste en separar las tuplas por rangos, los cuales se basan en algun criterio particular.

También se puede considerar el separar columnas:

create table item

(itemnum integer not null,itemsize char(1), itemcolor char(10),
itemdescr char(100))

se dividiría en:

create table item
(itemnum integer not null,itemsize char(1),
itemcolor char(10),itemdescr char(10))

create table item_desc
(itemnum integer not null, itemdescr char(90))

o bien

create table item_desc(itemnum integer not null,itemctr integer not null,
itemdescr char(100))

7.3.5 Combined Tables

Dada una relacion 1-1, combinar las 2 tablas en una sola

Se complica si hay otras relaciones involucradas, una relación 1-m implicaría demasiada redundancia y un aumento considerable del tiempo para actualizaciones.

7.3.6 Redundant Data

Cuando alguna columna de una tabla (A) es solicitada frecuentemente en una consulta de alguna otra tabla (B) entonces vale la pena agregar dicha columna de (A) en (B).

Dichas columnas serán redundantes y deberán cumplir con:

Sólo ser pocas las columnas involucradas
No deben necesitan actualizaciones frecuentes
Deben usarse por un gran número de usuarios y por pocos pero importantes

7.3.7 Repeating Groups

Muchas veces la repetición de tuplas puede transformase en varias columnas de la misma tupla

create table cust_balance

( custnum integer not null,

balanceperiod integer not null,

balance float)

create table cust_balance

( custnum integer not null,

period1_balance float,

period2_balance float,

period3_balance float,

period4_balance float,

period5_balance float,

period6_balance float)

Criterio:

Datos son raramente o nunca agregados, promediados o comparados dentro de una tupla
Los datos aparecen en un comportamiento estático y bajo un patrón
Se puede calcular el número de ocurrencias
Los datos se accesan colectivamente (grupos)

7.3.8 Derivable Data

Similar al de reportes para minimizar muchas fórmulas, se usa cuando:

La fuente de los datos involucrados son relativamente estáticos.
El costo de aplicar el cálculo es demasiado alto.
Es factible realizar el recálculo si es que los datos son modificados.

7.3.9 Hierarchies (speed tables)

create table dept

( DeptNum integer not null,

DeptName char(25),

SupervisorNum integer,

ReportsToDeptNum integer,

PKDN Primary Key (DeptNum),

FKCB Foreign Key (ReportsToDeptNum) references dept )

create table dept

( DeptNum integer not null,

ChildDeptNum integer not null,

Level integer,

Detail char(1),

DeptName char(25),

SupervisorNum integer,

PKDN Primary Key (DeptNum, ChildDeptNum) )

La nueva tabla contendrá una tupla para todo hijo dependiente, no únicamente los inmediatamente dependientes.

Dos columnas adicionales se incorporaron:

Level, contiene un valor numérico indicando el nivel dentro de la jerarquía del ChildDeptNum; si el hijo reside 2 niveles abajo en la jerarquía del padre entonces el Level será 2.

Detail, contiene una "Y" si el ChildDeptNum está hasta abajo de la jerarquía, "N" de otra manera.

7.3.10 Implementación física especial

Partir una tabla de manera que su tamaño se aproxime al de la página que maneja el dbms.