Memory addressing – Segmentation in Hardware (THE CRITIC AND IMPORTANT STUFF)

Physical Page: The basic unit memory management that kernel treats. Each architecture defines its own size in asm/page.h. There is a struct page for each physical page on the system.

MMU: Today microprocessor’s hardware (compound of Segmentation and Paging units) that manages memory and performs virtual to physical address translation. it contains the system’s page table

Logical Address: address of real mode (In this mode is possible the os’s bootstrap but it is just mapping 1MB in “linear addresses”) and protected mode (In this mode is enforced HW I/O and memory protection, it allows to work with a 4GB address space of linear addresses), it is based in a segment architecture where x86 DOS developers were forced to divide their programs into segments (click here for a profound explanation why logical addresses were created). This kind of address is included in machine language instructions to specify the address of an operand for an instruction. This address is conformed by a segment selector(16 bits) + offset(32 bits)

Linear address: address also known as virtual address (Usually represented by an unsigned integer to range from 0x00000000 to 0xFFFFFFFF). Every time a segment selector is loaded in a segmentation register (cs, ds , ss and other extra that may refer to arbitrary data segments. Such registers live upon processor to retrieve segment selectors quickly), the corresponding segment descriptor (8 bytes object describing segment characteristics) is loaded from a memory descriptor table into a non programmable CPU register, so segmentation unit is in charge of performing a segment descriptor base address’s field + Logical address offset to get a Linear one from a Logical one (result will be stored in gdtr or ldtr register).

Physical address: Used to address memory cells in memory chips. They correspond to the electrical signals sent along the address pins of the microprocessor to the memory bus.

DMA knowledge (The critic and important stuff)

DMA: Hardware mechanism that allows peripheral components to transfers their I/O data directly to and from main memory without the need of involving the system processor.

Main issue with DMA buffers: If they are bigger than on page, they must occupy contiguous page in physical memory.


DMA Transfer
: Data transfer than can be triggered in 2 ways:

  • Software asks for data
  • Hardware asynchronously pushes data to the system

DMA Transfer triggered by software (usage synchronously):

  1. Process calls read so.. (a request by the program we could say..)
  2. Driver allocates DMA buffer and instructs hardware to transfer its data into that buffer. The process is put to sleep.
  3. Hardware writes data to the DMA buffer and raises an interrupt when it is done.
  4. The interrupt handler gets input data. processor acknowledges the interrupt and awakens the process, which is now able to read data.

DMA utilized asynchronously:

  1. Hardware raises an interrupt (the first one) to notify new data has arrived
  2. Interrupt handler allocates a DMA buffer and tells the hardware where to transfer its data.
  3. The peripheral device writes data to the DMA buffer and raises an another interrupt (the second one) when it is done.
  4. The interrupt handler dispatches the new data, waking any relevant process, and takes care of any house keeping.

DMA transfer issue: Transfers require a DMA suitable buffer (not all memory zones are suitable) that lies within an address range the device can reach (high memory may not work for some devices)

*** The DMA API ***

  1. Verification of a DMA transfer to desired address (whether it is possible or not)
    #include 	<linux/dma-mapping.h>
    
    // For instance this is a device
    // that can only handle 24 bits addresses
    if (dma_supported(pdev->dev, 0xffffff)
        pdev->dma_mask = 0xffffff;
    else
    {
        pr_warning("DMA not supported for the device");
        goto device_unsupported;
    }
    
  2. Allocating consistent memory (“Memory that can be read immediately after a write by either device or processor, without having to worry about caching effects. This memory can be expensive, and the minimum allocation length may be as big as page.”)
    #include 	<linux/dma-mapping.h>
    
    /// pending example
    

The utility of derivative

A major feature in calculus is “change”.
We require to know how a thing is changing another one so.. we could say “the relationship between two things is a function“. As we wiggle the input point of a function we can know how the output is changing.
But a question is still open What is the ratio which is changing the output value?
Well such ratio is the derivative.

slope_ecuation

#include <stdio.h>
#include <stdint.h>

#define __MAX_X_VALUE  20

static int f_x(int x)
{
   return 6*x - 9;
}

int main(void)
{
    for(int a = 0; a < __MAX_X_VALUE ;a++)
    {
       printf("f(%d)= 6(%d)-9 = %d\n", a, a, f_x(a));
    }
}
optimus@house:~$ g++ slope_ecuation.cpp ; ./a.out
f(0)= 6(0)-9 = -9
f(1)= 6(1)-9 = -3
f(2)= 6(2)-9 = 3
f(3)= 6(3)-9 = 9
f(4)= 6(4)-9 = 15
f(5)= 6(5)-9 = 21
f(6)= 6(6)-9 = 27
f(7)= 6(7)-9 = 33
f(8)= 6(8)-9 = 39
f(9)= 6(9)-9 = 45
f(10)= 6(10)-9 = 51
f(11)= 6(11)-9 = 57
f(12)= 6(12)-9 = 63
f(13)= 6(13)-9 = 69
f(14)= 6(14)-9 = 75
f(15)= 6(15)-9 = 81
f(16)= 6(16)-9 = 87
f(17)= 6(17)-9 = 93
f(18)= 6(18)-9 = 99
f(19)= 6(19)-9 = 105

Los 12 errores más comunes en la construcción de un datawarehouse

Los doce errores más comunes en la construcción de un datawarehouse son:

Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intención de filtrar o agrupar.
Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir el espacio requerido.
Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones.
Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes.
Error 8: Crear “smart keys” para relacionar una tabla de dimension con una tabla de hechos.
Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad.
Error 6: Crear un modelo dimensional para resolver un informe en particular.
Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.
Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación.
Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento.
Error 2: No unificar los hechos entre distintas tablas de hechos
Error 1: No compartir dimensiones entre diferentes tablas de hechos.

Normalizando las Dimensiones – Usando la estrategia Copo de Nieve (Snowflaking)

Esquema en copo de nieve (bola de nieve) es una variedad más compleja del esquema estrella. El afinamiento está orientado a facilitar mantenimiento de dimensiones.
Lo que distingue a la arquitectura en copo de nieve de la esquema estrella, es que las tablas de dimensiones en este modelo representan relaciones normalizadas (3NF) y forman parte de un modelo relacional de base de datos.

Con varios usos del esquema en bola de nieve, el más común es cuando las tablas de dimensiones están muy grandes o complejos y es muy difícil representar los datos en esquema estrella.
Por ejemplo, si una tabla dimensional de los clientes (CUSTOMERS) contiene un million de filas, seria una idea buena crear una tabla con grupos de clientes (CUSTOMER_GROUPS) y mover los datos comunes para cada grupo de clientes a esta tabla. El tamaño de estas dos tablas será mucho menor que de una tabla no normalizada con todos los datos de clientes.

El problema es que para extraer datos de las tablas en esquema de copo de nieve, a veces hay que vincular muchas tablas en las sentencias SQL que puede llegar a ser muy complejo y difícil para mantener.

dw_snowflake_schema

10 Reglas Esenciales para el Modelado Dimensional

Regla 1: En una estructura dimensional se deben cargar los datos con el mayor nivel de detalle posible.

Llenar los modelos dimensionales con el mayor nivel de datalle posible nos debería ayudar a soportar filtros y agrupaciones inpredecibles requeridas por el usuario. Por lo general los usuarios no necesitan ver la información linea por linea, pero no se puede predecir las diferentes formas en que quedrán navegar y rotar la información. Si sólo hay disponible información sumarizada, uno puede estar asumiendo un modelo que cuando el usuario quiera ir a un nivel de profundidas mayor, no le resultará útil. Por supuesto que el detalle atómico puede y debe ser complementado con modelos sumarizados para ganar eficiencia.

Regla 2: Estructurar los modelos dimensionales en torno a los procesos de negocio.

Los procesos de negocio son las actividades realizadas por la organización; los mismos representan eventos medibles, como tomar un pedido o facturarle a un cliente. Los procesos de negocios usualmente capturan o generan métricas de eficiencia asociadas con cada evento. Las métricas de tranforman en hechos, con cada proceso de negocio representado por una tabla de hechos. Además de las tablas de hechos de procesos únicos, a veces son creadas tablas de hechos consolidadas que combinan metricas de varios procesos en una tabla de hecho con un nivel común de granularidad para todas. Pero recordemos que las tablas de hechos consolidadas son un complemento a las detalladas, pero no las sustituyen.

Regla 3: Asegurse de que toda tabla de hechos tiene una tabla de dimensión tiempo asociada.

Los eventos mencionados en la regla 2 siempre están asociados a una fecha cierta, ya sea que se trate de un balance mensual o una transacción monetaria. Toda tabla de hechos siempre debe tener al menos una foreign key a una tabla de dimensión tiempo, cuya granularidad es la fecha única en que ocurrió el evento.

Regla 4: Asegurarsde que todos los hechos que están en una misma fact tengan el mismo nivel de granularidad.

Todas las medidas de una tabla de hechos deben estar al mismo nivel de detalle. Cuando uno mezcla hechos de diferentes niveles de granularidad en la misma tabla de hechos, se está llevando al usuario a aconfundirse y a hacer que las aplicaciones de BI arrojen resultados erroneos

Regla 5: Resolver las relaciones muchos a muchos en las tablas de hechos.

Partiendo de la base de que una tabla de hechos guarda los resultados de los eventos de un proceso de negocio, es muy probable que haya alguna relación del tipo muchos a muchos (M:M) vinculada entre sus foreign keys, como por ejemplo productos vendidos en múltiples negocios en múltiples días. Estos campos de las foreign key nunca deberían ser nulos. A veces las dimensiones puden asumir múltiples valores para un hecho único, tal como muchos diagnósticos asociados con una consulta médica. En estos casos no es razonable resolver la dimensión de varios valores directamente en la tabla de hechos. Esto violaría la granularidad natural del hecho. Así, usaremos una relación muchos a muchos, con una tabla puente de clave doble en conjunto con la tabla de hechos.

Regla 6: Dimensiones con relaciones muchos a uno

Por lo general este tipo de relaciones se suelen desnormalizar y aplanar en una tabla. Si usted se ha dedicado mucho tiempo a modelar sistemas transaccionales, evite tentarse a normalizar este tipo de dimensiones o modelarlas como copo de nieve (snowflake). Es muy común tener varias relaciones 1:M resueltas en una sola tabla de dimensión. Relaciones del tipo 1:1, como la descripción de un producto relacionada con el código del mismo, son también resueltas de esta forma.

Regla 7: Guarde en tablas de dimensiones aquellos atributos que utilizará como etiquetas o filtros de informes

Todo tipo de atributos que crea que vaya a utilizar como etiquetas de reportes o como filtro de reportes guárdelos un tablas de dimensiones, y no en la tabla de hechos. Es aconsejable evitar valores nulos para los atributos de una tabla de dimensión, para estos casos complete los atributos nulos con el valor “NA” (Not Applicable), o algún otro valor por defecto.

Regla 8: Asegúrese que las dimensiones utilicen claves sustitutas (Surrogate Key)

La utilización de este tipo de claves nos darán una serie de beneficios como claves mas pequeñas, con lo cual las tablas de hechos serán más pequeñas, así como los índices utilizados. generando mejor performance. El uso de surrogate keys será útil si quiere hacer un seguimiento de los cambios de los atributos de la dimensión. También permiten mapear códigos de diferentes fuentes operacionales, y además, nos protegen de cambios inesperados en los sistemas transaccionales, como la recodificación de tablas maestras, reciclado de códigos de productos que ya no existen, entre otros.

Regla 9: Cree dimensiones conformadas para integrar datos a lo largo de la empresa

Las dimensiones conformadas son esenciales para un Data Warehouse corporativo. Administradas una sola vez en el ETL y utilizada en varias tablas de hechos, estas dimensiones proporcionan atributos consistentes a lo largo de diferentes modelos dimensionales y permiten hacer drill-across e integrar información de diferentes procesos de negocios. La reutilización de las dimensiones conformadas reduce el tiempo de salida al mercado mediante la eliminación de diseño redundante, sin embargo, estas dimensiones requerirán invertir en una buena administración de datos y en un modelo de gobernanza para las mismas.

Regla 10: Balancear los requerimientos de los usuarios con los cambios a realizar en los modelos dimensionales.

Los modelos dimensionales se extienden constantemente como consecuencia de los requerimientos que hace el negocio. Como encargado de mantener los diferentes modelos dimensionales, usted deberá balancear entre los requerimientos del negocio y el impacto que este tenga sobre los modelos.