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

What is impedance for AC circuits ?

Impedance of a circuit: It is the total effect of resistance or the measure of opposition to the passage of the current and its unit is the ohm. The term impedance is represented with the use of letter Z.

Impedance for resistors, capacitors and inductors have to be calculated slightly different. Due to current/voltage behavior for each one. As you can see pretty denoted at the image below:

* Resistors remains unaffected the frequency of current/voltage.
* Capacitor leads voltage by 90 degrees ahead.
* Capacitor lags voltage by 90 degrees earlier.

impidance

How to calculate Z for resistors in AC circuit ?
In this specific case there is not much to do. Because the value of R is remained as a constant. (It is perhaps an obvious matter as per the fact that resistors do not affect any frequency).

How to calculate Z for capacitors (AKA capacitive reactance) in AC circuit ?
First of all. To understand how the following calculation works, it is required the concept of radian in wikipedia. Afterward It’ll be comprehend.

Zc = 1/(w*c) = 1/(2pi*f*c)
w = radian frequency in rad/s = 2pi*f*c
where f is the frequency in hertz of the voltage source.
c = capacitance in farads.

How to calculate Z for inductors (AKA inductive reactance) in AC circuit ?

Zl =  2pi*f*l
l = inductance in henries.

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.

Principios de un Datawarehouse

La inclusion de todos los principios de un Datawarehouse, no es algo de caracter obligatorio, pero seguirlos puede llevarnos al exito y valor del mismo.

Un Datawarehouse debera incluir datos que sean aplicables a la empresa, este es el valor y relevancia enraizada de un Datawarehouse.

Asi que despues de leer a varios autores…. He sintetizado los principios de un buen Datawarehouse.

* Orientacion por Temas: Los datos seran agrupados por Temas, esto con la finalidad de absorver cambios, sin necesidad de hacer grandes cambios en la arquitectura del mismo. Un Datawarehouse jamas presentara datos que reflejen la manipulacion de los datos operacionales. En su lugar reflejara datos que representan las mas importantes areas dentro de la empresa.

* Integracion de los Datos: Aun cuando el dato provenga de distintas aplicaciones, departamentos,etc. Las diferencias deberian ser suavizadas para que los datos contengan el mismo look and feel.
a) Por Forma: Si se tiene el formato 123-(34) y 12334, uno de estos dos formatos debera ser impuesto sobre el otro.
b) Por Funcion: Cuando dos o mas datos representan la misma cosa pero con nombres diferentes, estos dos nombres deberan ser remplazados por uno solo.
c) Por Granulacion: Cuando dos o mas elementos aplican diferentes grados gerarquicos (distrito,region) para definir la misma cosa, estos 2 o mas elementos seran resueltos al mismo nivel de Jerarquia o Detalle.

* Jamas Volatil: A diferencia de los datos en operacion de las aplicaciones, los cuales tienen el futuro de ser descartados una vez que la compañia haya terminado de usar estos. En el Datawarehouse siempre deberan permanecer con la intension de poder expresar lo que es la empresa a lo largo del tiempo.

* Variante al Tiempo: Todos los datos tienen un contexto sobre un momento en el tiempo. Un Datawarehouse debera mantener ese concepto para expresar los eventos de la empresa a lo largo del tiempo sobre 3 conceptos:
a) Que era
b) Que es actualmente
c) Como sera si nada llega a cambiar
Este es un principio es una significante diferencia de aplicaciones operacionales, las cuales funcionan en el ahora, mas que en los eventos pasados.

* Ofrecer una unica version de la verdad: Un Datawarehouse debera definir cada elemento de los datos de una manera que… todos los miembros de la empresa asocien una y solo una pregunta con los datos de ese elemento.
Aqui un ejemplo de lo que se debera evitar:
— Cuantos carros fueron ensamblados ?
1.- Total de ensamblados nuevos 32,000
2.- Total de ensamblados reconstruidos 1,000
3.- Total de ensamblados para empresas filiales 19,000

Aqui un ejemplo de lo que debe ser:
— Cuantos carros nuevos fueron ensamblados ?
1.- Total de ensamblados nuevos 32,000

Esto permite que cuando todos los miembros de una empresa miren hacia el dato elemento, lo hagan todos con un solo entendimiento de su significado.

* Inversion a largo plazo: El Datawarehouse debera ser suficientemente flexible, escalable para absorver los cambios ademas de agregar un valor a la compañia a largo plazo. Ofreciendo a su vez un retorno de inversion atraves de su longevidad y estabilidad

Nota Importante: El analista ETL es el responsable de que los principios del Datawarehouse se cumplan.

Asumiendo cambios significativos en las fuentes de datos

La predictible simetria de los modelos dimensionales permiten a estos absorver algunos cambios significativos en la fuente de datos o en el modelado, esto sin invalidar las aplicaciones datawarehouse existentes.
Aqui les describo algunas de las modificaciones no esperadas. Iniciando con la mas simple:

Nuevos atributos en la dimension. Si descubrimos nuevos atributos a un producto, agregariamos esos atributos a la dimension como nuevas columnas. Si nuevos atributos estan disponibles solo despues de un punto especifico en el tiempo, entonces “No Disponible” o su equivalente sera insertado en los registros anteriores a este punto en el tiempo.

Nuevas dimensiones. Podemos agregar dimensiones a una tabla de hechos existente, bastara con agregar una nueva llave foranea y llenar esta correctamente con valores de las llave primarias proveniente de la nueva dimension.

Nuevas medidas en la Tabla de hechos (Caso Sencillo). El Caso sencillo de esto es,

cuando las nuevas medidas estan disponibles para el mismo grado de granularidad en el que se encuentra la tabla de hechos

. En este caso, la tabla de hechos es alterada para agregar las nuevas columnas, y los valores son puestos en su lugar. Si las nuevas medidas para la tabla de hechos, estan solo disponibles desde un punto del tiempo en adelante, entonces los valores nulos necesitaran ser remplazados en las viejas filas de la tabla de hechos.

Nuevas medidas en la Tabla de hechos (Caso Complejo)Cuando nuevas medidas que se desean agregar a la tabla de hechos

ocurren sobre un nivel diferente de granularidad

. Si las nuevas medidas no pueden ser albergadas o asignadas a el original nivel de granularidad de la tabla de hechos, se puede decir entonces que las nuevas medidas pertenecen a su propia tabla de hechos.”Ya que es un error mezclar diferentes medidas con diferente nivel de granularidad sobre una tabla de hechos”.

Dimensiones que se vuelven mas granulares. En algunas ocasiones es deseable aumentar la granularidad de una dimension. En la mayoria de los casos, los atributos originales de la dimension pueden ser incluidos en una nueva, mucho mas granular a causa de que estos pueden acomodarce en una relacion muchos a uno. Las dimensiones mas granulares a menudo implicaran una tabla de hechos mas granular. Pudiece no existir mas alternativa que tirar la tabla de hechos y reconstruir la misma. Ademas, todas las aplicaciones existentes podrian no ser afectadas.

Agregando una completamente nueva fuente de datos envolviendo tambien inesperadas nuevas dimensiones. Casi siempre, una nueva fuente de datos tiene su propia granularidad y dimensionalidad, entonces nosotros creamos unas nueva tabla de hechos . Deberiamos evitar el ajuste a la fuerza de nuevas medidas dentro de una existente tabla de hechos con medidas ya consistentes. Las aplicaciones existentes trabajaran aun a razon de que las tablas de hechos y dimensiones ya hechas no sean modificadas.