Tarea Post
Negronski
Comparación paradigma Kimball e Inmon.
200230358
deja los datos accesibles de una manera mas directa que en el caso de
Inmon. Tambien me parece que el caso de Inmon existe una mayor
tendencia a que existan desfases entre los datos consultados y los
datos reales, sobre todo si se requiere la replicacion de datos
detallados de los "data marts" en el datawarehouse.
Luis Cano
distintas circunstancias o necesidades en la construcción de un DW, de
lo contrario no habria debate. La aplicacion de cada una depende de la
situacion actual de los datos y en que momento se esta diseñando el
DW.
No puedo hablar por experiencia, pero si departamentos de una
organizacion tuvieran sus datamart en linea, entonces construir un DW
como lo propone Kimball suena razonable. En otro caso, si tenemos el
tiempo de diseñar el DW desde cero podriamos utilizar lo mejor de
ambos mundos, en el caso que los datos se puedan unir naturalmente,
i.e. que no necesiten tranformaciones excesivas, yo me iria por un
esquema estrella como lo plantea Kimball y utilizando la aproximacion
de Inmon haciendo un datawarehouse de donde sacar los datamarts.
Si los datos necesitan mantenimiento frecuente en el DW, o no se
puedan unir naturalmente, entonces utilizar 3NF, esto porque la
mayoria de datos de un OLTP al final estan en 3NF.
Entonces algunos de los aspectos que tomaria en cuenta para decidir
que aproximacion utilizar son:
- La herramienta para ETL, construccion de los cubos et al. Permite
manejar mejor 3NF, estrella. Que tal flexible es para la
transformacion o cuanto tiempo se necesita para programarla.
- Existen Datamarts actualmente? Si existen para que reinventar el
agua azucarada. Claro si los DataMart son consistentes.
- Que tanto mantenimiento necesita el DW? Pasar de un CIF a varios
DataMarts es mas sencillo que de varios DataMarts a un CIF, entonces
el mantenimiento de scripts puede ser mas costoso en el segundo caso.
- Tener un CIF asegura que haya solo una version de los datos para
los DataMart, en cambio tener varios DataMart puede ocasionar haya mas
de una "perspectiva" de la informacion. Esto es mas validero entre mas
compleja sea la organizacion. Y si la alta gerencia ve varias
"perspectivas" ya la hicimos, en la calle.
- Si el tiempo es ajustado y se necesitan resultados pronto, hacer
DataMarts es mas rapido que diseñar el DW, en cambio si se toma el
tiempo para el diseño de un CIF puede ayudarnos a no quebrarnos la
cabeza con la integración de los datos luego (de DM al DW).
- La cantidad de datos que se quieran en el DataWarehouse, si es un
DW pequeño hacer esquema estrella es lo ultimo.
Al final creo que se tomaran cosas de cada uno, segun el caso. Despues
de todo no existe la panacea para este tipo de cosas.
Todo esto se resume en poder vender mejor la idea a la alta gerencia
para que den mas fondos a la construccion de un DW. Es mas eso
justamente voy a hacer ahora mismo, nos vemos en Hawaii.
Carlos Garcia
de vista tecnico (Bill Inmon's) quien considera que los datos deben
estar normalizados en 3FN y el otro poco convencional, dado que no se
consideran dichas normalizaciones y que lo que existe es el producto
de la sinergia de los esfuerzos por unir y aprovechar los datos
existentes en todos los departamentos de una organizacion
Es cuestion al fin y al cabo de que es lo que vamos a utilizar para la
base de datos OLAP, si nos vamos por el enfoque técnico, terminaremos
de seguro con un diagrama copo de nieve si existen muchas fuentes de
datos a considerar y terminaremos casi seguro utilizando productos
Microsoft, dado a que ellos este es el esquema que recomiendan para
SQL 2005, por el otro lado si nos vamos por el lado de Ralph Kimball's
este no dice nada a cerca de las normalizaciones pero es casi seguro
que terminaremos con un esquema estrella y usando oracle dado a que es
el producto mas recomendable para dichos esquemas.
Tambien hay que tener en cuenta que la seleccion de productos dado un
esquema, son solo recomendaciones y que bien se pueden usar ambos
esquemas en cualquiera de los dos productos.
Al fin y al cabo somos nosotros los que elegiremos uno sobre el otro
dadas las circunstancias de donde nos encontremos.
johnskelter_200312931
por Kimball e Inmon no son en realidad demasiado grandes, sin embargo,
estas pequeñas diferencias hacen que estos enfoques sean aptos para
diferentes tipos de organizaciones que deseen implementar un sistema
de data warehouse.
Por ejemplo, en el "enfoque Kimball" un data mart es en sí el data
warehouse, mientras que en el "enfoque Inmon" el data mart es tan solo
una capa del data warehouse. Esta diferencia de concepto no cambia en
sí la funcionalidad que tiene un data mart como tal, aunque sí cambia
la forma en que éste encaja dentro del sistema de inteligencia de
negocios de una organización.
Debido a esto, se podría decir que el "enfoque Inmon" pareciera ser
más apto para sistemas de data warehouse aplicados a grandes empresas
y/o corporaciones, mientras que el "enfoque Kimball" es más apropiado
para sistemas aplicados a departamentos o áreas en una empresa. Sin
embargo esto es bastante relativo y depende mucho de qué tipo de
organización desee implementar el sistema, así que lo mejor es
entender ambos puntos de vista y decidir por nosotros mismos cuál de
los dos se aplica más a nuestras necesidades como dijo Carlos García
en el post anterior.
Luis Espino
da, tambien que resuelven distintas circunstancias o necesidades de
construcion, otro es la consideracion de normalizarla 3FN, sin
embargo hoy el Ing. Vetorazzi menciono que debemos olvidarnos de la
normalizacion, no se si solo se referia al punto de vista de Kimball o
de ambos.
Otro punto que lei es que en 1997 Kimball aseguro que su modelo
multidimensional era la unica manera viable de diseñar bases de datos
destinadas a su uso directo del usuario final, sin embargo en el 2000
Inmon dijo que si diseñas un DWH desde el punto de vista de análisis
de un solo individuo condenas al resto a su mismo punto de vista y que
dificilmente en el modelo dimensional puedes incluir información no
incluida en el foco original del análisis.
Pero el modelo de Inmon coincide con Kimball en un único proceso ETL
que alimenta un DWH corporativo, pero el que lo alimenta no es
dimensional es un DWH basado en el modelo Entidad-Relación. La idea de
Inmon es que el modelo E-E es mucho mas enriquecido y adaptable que el
multidimensional. Una vez tenemos el DWH E-R corporativo generamos los
datamarts dimensionales que queramos, y ademas nos puede servir para
crear cualquier otra extracción para cualquier otro sistema de toma
desiciones, como para sistemas expertos.
Pero si consideramos que el modelo es para usuarios con poca
experiencia es mejor el modelo de Kimball ya que su modelo dimensional
tiene dos ventajas sobre el de Inmon: Usabilidad y Productividad.
Entonces creo que la desicion de usar que modelo se basara en el
enfoque y la opinion del Ingeniero que lo realizara, si queremos una
copia de los datos transaccionales estructurados para la consulta y el
analisis usamos el modelo de Kimball, pero si queremos un conjunto de
datos orientados por temas, integrados, que serviran para el soporte
en la toma de desiciones usamos el modelo de Inmon. Sin olvidarnos de
la experiencia del Ingeniero a realizarlo y el tamaño de la inversion
de la Empresa para el DWH.
Jose Ruiz
Según Inmon (considerado por muchos el padre del Data Warehouse),
un Data Warehouse es un conjunto de datos orientados por temas,
integrados, variantes en el tiempo y no volátiles, que tienen por
objetivo
dar soporte a la toma de decisiones y por otro lado según Ralph
Kimball
(considerado el principal promotor del enfoque dimensional para el
diseño
de almacenes de datos), un Data Warehouse es una copia de los datos
transaccionales específicamente estructurada para la consulta y el
análisis.
mari...@gmail.com
inmon como kimball estan en lo correcto. Debido a que se puede
realizar un DataWarehouse ya sea con datos normalizados y
con datos no normalizados. De lo anterior se obtienen el modelo
Estrella y el Modelo Snowflakes, el primero utiliza datos sin
normalizar y el segundo normalizados. Entonces cuando seguir
cada definicion queda en función en depende, depende de que
es lo que se necesita hacer, pues si se tienen datos normalizados
y se realizan joins de tablas grandes entonces la obtención de los
resultados es un tanto lento. Entonces esto indica que el modelo
de kimball lleva las de ganar pero con alguien experto puede ser
muy conveniente utilizar lo de bill inmon.
Erick Moran
diferente pues por un lado un autor dice podemos representar
escenarios muy complejos pero para ello se necesita involucrar
personal capacitado en el area para su comprension, por el otro lado
la capacidad de representacion se ve reducida pero no se necesitan de
avanzados conocimientos para poderlo comprender, pero vemos que ambos
son muy utiles segun con las personas con las que se va a trabajar la
data.
Negronski
habierto hasta que envie la nueva tarea, la siguiente semana.
Por lo que estaremos discutiendo esto durante varios dias. Pueden
agregar links de referencia o cualquier otra info interesante que
encuentren. O si saben de alguna empresa que este trabajando algo al
respecto en Guatemala, cualquier comentario es bueno.
saludos and happy posting.
Rene Chinchilla Molina
en detalle todo dependera del procedimiento enfoque final aunque
los dos se refieran al mismo tema DWH donde Immon se enfoca
en mas a un base de datos al cumplir las 3era FN basado a una
porcion del sistema inteligencia de negocios, Kimball se enfoca en
cumplir un conglomerado de datos para no realizar una gran
conexion entre tablas y se basa en un modelo dimensional de datos
en lo que pude ampliar, el modelo de Kimball es el mas utilizado
en algunos modelos donde tenemos varios procesos ETL mientras
siendo un modelo mas dado a coorporaciones, mientra que Immon
coincide en ETL lo unico en el que alimenta DWH basado en un
modelo E-R corporativo creado para datamart
On 7 feb, 13:47, "Negronski" <edwin.al...@gmail.com> wrote:
Hugo Pacheco
informacion, puesto que para kimball es un repositorio que guarda todo
en base a sus dimenciones en un solo fact table, lo cual permite que
sea mas facil la informacion como una sola unidad, en cambio Inmon
dice que esto limita el uso del datawarehouse y lo separa o permite
separarlo por departamentos lo cual hace que la informacion tenga o
esta ya separada por puntos de vista diferentes en el negocio, aunque
en esto separamos la informacion
essolares
On 7 feb, 13:47, "Negronski" <edwin.al...@gmail.com> wrote:
> Aqui van todos sus comentarios.
> Comparación paradigma Kimball e Inmon.
A mi criterio los dos modelos tanto el de Kimball como el de Inmon se
adecuan a las necesidades de las empresas, puesto que depende de la
cantidad de información a manejar y la forma más conveniente en que
se desee manejar.
Esto depende ya que en el caso de Kimball el manejo de la informacion
se hace de forma conglomerada, es decir toda la información almacenada
en un solo modelo dimensional.
Por lo contrario lo que plantea el Autor Inmon es que el manejo de la
información se realice de forma distribuida, sin perder la relacion
entre toda la información del negocio.
Ambos autores plantean un punto de vista diferente pero que nos lleva
a la misma idea del mejor manejo de la información de la empresa por
medio del data warehouse.
William
ninguno es mejor que el otro, todo depende del enfoque que
se le de. Por ejemplo Kimball a menudo es utilizado por poseer
su modelo multidimensional, y tambien se tienen varios procesos
ETL que nutre el DWH, y el paradigma Inmon unicamente se
tiene un proceso ETL.
Rafa - 9617129
adecuada
del crecimiento de la data, además al basarse en el paradigma de
Imonn Top-Down se podría considerar al primero una actualización o
mejora
del segundo.
Como mencionanba en un articulo, ambos esta bien, con ventajas y
desventajas
según el medio donde se apliquen.
Raúl Cruz Orellana
Considero que ambos criterios pueden ser aplicados a las empresas
dependiendo las situaciones paras las que las necesiten.
El modelo de Kimball se basa mas en el manejo de toda la información
en un solo lugar, es decir que todo de analiza bajo una sola
dimensión, y es mas es más apropiado para los departamentos o áreas
específicas en una empresa.
El modelo de Inmon es mas utilizado par un manejo mas aplicado para el
uso de empresas mas grandes que llevan un mayor volumen de información
y por lo tanto el uso de sistemas distribuidos es el mas adecuado de
la misma.
Esto nos lleva a decir que el camino que propone cada uno de estos dos
puntos de vista adquiere importancia en base al tipo de negocio que se
tenga.
JuanJo
dos filosofias, tanto la de Kimball y la Inmon difieren
pero al final de cuentas ambas se centran en el almacenamiento de los
datos para su futuro analisis, hay que mencionar
que estas filosofias difieren por la forma en que son aprovechadas, de
hecho no puedo decir que alguna de las dos sean mejor pues debido al
entorno que tenga la empresa y las necesidades de esta, alguna de
ellas podria ser la respuesta a algun problema de analisis de negocio.
200312877
datawarehouse puede
o no puede estar normalizado.
Entonces para decidirnos sobre utilizar el paradigma de Inmon que se
encuentra en 3NF o
Kimball que no se encuentra normalizado, solo tenemos que preguntarnos
cual es que se
ajusta mejor a nuestras necesidades (tiempos de respuestas,
almacenamiento, cantidad de datos, etc).
Carlos Garcia
otro paradigma quienes quieren imponerlo uno como mejor que el otro.
Una comparación real entre ambos paradigmas no es factible dado a que
se aplican segun las circunstancias en que nos encontremos,
al final somos nosotros quienes decidimos uno sobre el otro,
acorde a presupuestos, arquitectura existente, costos, si existe
o no personal calificado, el ambiente, situaciones legales,
licenciamientos, etc.
Huber
La conjeturas paradigmaticas de ambos atienden a la solucion de un
problema especifico, en el caso del paradigma de Kimball el
Datawarehouse depende de un manejo de informacion libre y accesible,
los contenidos del Data WareHouse son entendibles y navegables y
persistente desde un punto de vista historico, ademas posee un enfoque
multidimensional
Inmon nos representa un enfoque parecido. La idea de Inmon es que el
modelo E-E mucho mas efectivo y adaptable que el
multidimensional.ademas mejora la trazabilidad decisional
como conclusion Kimball se encierra en un unico modelo mientras que
Inmon es mucho mas abierto
Ivan Montufar Mayorga
Pues para mi los 2 estan bien, solo depende para quien va destinado,
el Modelo tridimensional de kimbal va enfocado a usuarios finales los
cuales no tienen mucha experiencia y es mucho mas usable y productivo
para ellos. Mientras que el Modelo de Inmon ganamos la capacidad de
representar escenarios complejos pero necesitamos usuarios con mayor
capacidad.
Jose Ruiz
que el modelo de Ralph Kimball no es tridimensional, es n-dimensional
segun tengo entendido
agui...@gmail.com
través de 2 palabars: Estático vs. Dinámico.
Uno de los principales aspectos a comparar es el tiempo de
implementación. La implmentación, si nos basamos en Kimball es de
manera casi inmediata, ya que no espera por nada (un diseño) para
iniciar la implementación, sino que aboga por ir modificando nuestro
proyecto acorde a las circunstancias que se presentan. Mientras que
Inmon propone esperar por tener un diseño definido antes de comenzar
con la implantación.
agui...@gmail.com
cada uno de éstos. El concepto que Kimball propone es mucho mas
adaptativo, aunque puede implicar mayor trabajo durante su desarrollo,
ya que se tendrán que hacer ajustes constantes por cada variante que
aparezca. El modelo de Inmon por el contrario, puede no representar
demasiado trabajo, ya que el mayor esfuerzo reside en el diseño que se
debe elaborar, pero presentaría poca adaptabilidad y su mayor problema
estribaría en que es lo que se tendría que hacer si el modelo de
negocio de una empresa que utilize este concepto cambia. Habría una
ventana de tiempo posiblemente muy larga mientras se vuelve a definir
todo antes de comenzar su desarrollo.
Heber 200313540
interesantes, y creo q me han dado una mejor panorámica de las
similitudes vrs. diferencias entre ambos modelos, uno un tanto rígido,
mientras el otro más flexible.
Dentro de los puntos que más me sobresaltaron, y uno de los que no se
ha tocado a fondo, es que el modelo de Kimbal utiliza una estructura
de bus, donde se agrupan las dimensiones en común a las necesides de
la empresa, por lo que se centralizan los datos, aun que físicamente
se encuentren distribuidos. La Base de Datos se ve como un todo,
evitando asi la repetición de datos que se darían en un modelo como el
de Inmon, ya que realiza réplicas del DW en distintos Data Mart, de
acuerdo con las necesidades de cada departamento dentro de la empresa,
descentralizando los datos en departamento, area, etc.
Por último, en concenso podríamos desir que para desidir entre un
modelo u otro, sería una cuestión mas técnica que filosófica, se debe
de tomar en cuenta algunos aspectos como tiempo que se tardaría el
desarrollo con uno u otro modelo, costos de operación, si se posee
algún conocimiento previo sobre uno u otro modelo.
Gerson Raymundo
La filosofia de Ralph Kimball
Esta filosofia dice que el Datawarehouse de una empresa es la union de
todos los Datamarts, y que la informacion esta guardada en modelos
dimensionales.
Kimball define el modelo dimensional, como un modelo que contiene la
misma informacion que un modelo que se encuentra en tercera forma
normal, con la diferencia que el modelo dimensional contiene
informacion empaquetada para hacer consultas faciles que contienen
gran nivel de detalle.
Mi opinion personal sobre esta filosofia es que, es igual de buena que
la Filosofia de Inmmon, pero todo depende del enfoque que querramos
darle, por ejemplo, si no tenemos limitante de espacio para guardar
informacion, la mejor forma de manejar los datawarehouse es con la
filosifia de Kimball, ya que utiliza la redundancia de datos para
poder consultar de una manera mas sencilla. Creo que este modelo es el
mas utilizado en las empresas por motivos de facilidad de uso, facil
acceso a la informacion, ademas de proveer la facilidad de dividir
todo en datamarts que juntos forman toda la informacion de
Datawarehouse.
Gerson Raymundo
Esta filosofia explica que el Datawarehouse es una seccion muy
importante de la inteligencia de negocios, y que la informacion esta
guardada en tercera forma normal.
El hecho de usar normalizacion en los datos, implica la eliminacion de
redundancia, y esto puede ayudar si nuestra limitante es el espacio
para guardar informacion, una de las desventajas de esto, se centra en
la realizacion de consultas, ya que puede dar lugar a consultas muy
complicadas. Este modelo utiliza replicas de sus datos en Datamarts
para mantener informado a cada sector de la empresa en caso lo
necesite.
En conclusion, las dos filosofias son buenas, ambas tienen enfoques
diferentes, la decision de que filosofia utilizar estara a cargo de
las personas de informatica que deberan de estar conciencientes de las
necesidades del negocio, asi como las capacidades de almacenamiento
para poder emitir una buena decision con respecto a que tecnica de
Datawarehouse deben utilizar.
Ivo
del datawarehouse, las dimensiones, y se tiene un tipo de unión entre
estas, Inmon dice lo mismo, solo que los datos son ingresados an un
datawarehouse relacional, basado en un ER... Kimball =
multidimensional... Inmon= Relacional, no se si estoy mal, pero eso
fue lo que yo entendi.
Jaime Caceres
Ya que el mas usado es el modelo dimensional se puede decir de este
que esta formado de dos tablas una llamada fact table donde se
almacenas las metricas y las dimesion table que es donde se lleva el
control de las metricas
Ivan Montufar Mayorga
Haciendo una conjetura, Kimball trabaja con el Modelo estrella y Inmon
trabaja con el Modelo snowflake, si no es asi me corrigen, en los 2
modelos existen Fact table y dimension table, la diferencia es que el
modelo estrella no esta normalizado y el snowflke si lo esta, por lo
leido el modelo de Kimball es el mas popular pero en si los 2 son
buenos, en el modelo de kimbal existe redundancia y consume mas
espacio pero las consultas son mas rapidas, mientras que las de Inmon
no existe redundancia pero las consultas pueden ser mas tardadas pero
con un mejor detalle.
essolares
Warehouse), un Data Warehouse es un conjunto de datos orientados por
temas, integrados, variantes en el tiempo y no volátiles, que tienen
Según Ralph Kimball (considerado el principal promotor del enfoque
dimensional para el diseño de almacenes de datos), un Data Warehouse
es una copia de los datos transaccionales específicamente estructurada
para la consulta y el análisis.
entre las dos filosofias.
Luis Espino
asi se seleccionara el modelo.
Sin embargo creo que lo mas importante es que podemos sacar provecho
de ambas, les adjunto una direccion de un pdf que se refiere a
Datawarehouse para la gestion por procesos en el sistema productivo,
en este menciona ambos modelos y hace como una sintesis para la
aplicacion de los mismos.
http://www.poms.org/Meeting2004/POMS_CD/Browse%20This%20CD/PAPERS/002-0278.pdf
marjozero
SI SE TIENE ESPACIO PARA DESPERDICIAR QUE SE USE
KIMBALL SI IMPORTA EL ESPACIO QUE SE USE INMON
ALGO ASI QUE SI SE ES MICROSOFT-ORACLE
johnskelter_200312931
exactamente cuál de los dos enfoques es mejor que el otro.... como
casi todo en esta vida depende de las circunstancias y el contexto...
no se pueden ver las cosas blanco y negro.
Buscando un poco de info. en internet, encontre que aparte de los
enfoques Kimball e Inmon que estamos discutiendo, existen otro dos
tipos de enfoque: el Hybrid Approach y el Federated Approach. Sobre el
segundo no tengo el concepto muy claro... así que si alguien lo sabe
sería bueno que lo comentara... y sobre el primero pues como su nombre
lo dice es un enfoque toma elementos de la metodología Inmon y de la
metodología Kimball, lo cual es un punto interesante ya que se puede
obtener lo mejor de dos mundos.
Por cierto... hablando sobre la implementación de estos enfoques...
¿existen herramientas que hagan énfasis en algún enfoque o podemos
utilizar cualquier herramienta para implementar un data warehouse tipo
Kimball o uno tipo Inmon? Si alguien lo sabe sería interesante que lo
respondiera...
JuanJo
debido
al punto de vista un datawarehouse puede ser muy util, pues como el
menciona, para Kimball es un repositorio donde todo esta almacenado en
un
conglomerado para poder tener acceso a la informacion como una sola
unidad
para su analisis, ademas Inmon menciona que separando en pequeños
datamart
la informacion se puede tener puntos de vista diferentes en el negocio
para
analisar el estatus de la informacion. por elllo creo que Hugo Pacheco
ha
expuesto un punto muy importante y comparto lo mismo con el.
Juan Jose
2001-13138
JuanJo
compañeros, es que tanto Inmon como Kimball se metieron un gol cada
uno debido a que por un lado ganamos capacidad para representar
escenarios complejos pero necesitamos usuarios listos y expertos como
decia Erick Moran, mientras que por el otro perdemos capacidad de
representacion pero ganamos que cualquiera pueda usarlo. Bueno si
alguien tiene una idea distinta que me la haga saber para mejorar esta
conclusion.
Juan Jose Baten
2001-13138
Heber 200313540
abstracciòn de todas las necesidades de la empresa para generar un
Data Warehouse, de modo que la informaciòn que se integre dentro de
ella sea lo suficientemente capaz de abarcar todas las espectativas de
cada departamento, y asì todos tomen informaciòn de un repocitorio
centralizado la toma de deciones. Ademàs, agrega una estructura de
bus, donde se comparten caracterìsticas comunes utilizados enter los
datamarts.
Por otra parte, el modelo de Innmon propone que se deben de tener los
datamarts descentralizados, uno para cada departamento, y el conjunto
de todos ellos formarà el datawarehouse en su totalidad.
William
entre Kimball e Inmon son:
Kimball dice: un data mart es construido extrayendo datos
directamente
de sistemas operacionales, mientras que Inmon dice: un data mart es
construido extrayendo datos de una empresa dw.
Kimball dice: los data marts estan relacionados uno con otro, basado
en
dimensiones, por otro lado Inmon dice: los data marts no están
relacionados.
Kimball dice: un data mart mantiene todos los datos disponibles
históricos,
e Inmon dice: un data mart mantiene la historia limitada.
En conclusión ambos tienen características muy completas para BI, por
eso
recalco que depende de para que se quiera utilizar se elige uno.
an@ lui§a
debido al enfoque que le da, de que el objetivo de Data Warehouse es
dar soporte a la toma de decisiones, mientras que Kimball enfoca más
el objetivo de ésta en las consultas y el análsis de los datos
On Feb 7, 11:35 pm, "200230358" <haroldoro...@yahoo.com> wrote:
> En principio me parece mas atractivo el paradigma de Kimball dado que
> deja los datos accesibles de una manera mas directa que en el caso de
> Inmon. Tambien me parece que el caso de Inmon existe una mayor
> tendencia a que existan desfases entre los datos consultados y los
> datos reales, sobre todo si se requiere la replicacion de datos
> detallados de los "data marts" en el datawarehouse.
>
> On 7 feb, 13:47, "Negronski" <edwin.al...@gmail.com> wrote:
>
>
>
> > Aqui van todos sus comentarios.
> > Comparación paradigma Kimball e Inmon.- Hide quoted text -
>
> - Show quoted text -
goge?
paradigmas, tanto de kimbal e Inmon son correctos, o efectivos en su
punto de vista, dependiendo que es lo que tenemos, que es lo que
queremos, y como lo queremos manejar. Por un lado,Inmon hace mencion
que algunas veces las empresas necesitan mas flexibilidad al momento
de almacenar los datos, por lo que el modelo estrella (en el cual
recomienda Kimball) se queda corto. En mi opinion, la idea de Inmon es
mas abierto porque podemos los datamarts que queramos, y ademas, nos
puede servir para otro sistema decisional, como mineria de datos.
goge?
el modelo de kimball es mas popular, utiliza mas espacio ya que existe
redundancia, pero obviamente sera mas rapido.
Con el modelo Inmon podemos optimizar el espacio, pero recordemos
realmente lo que estamos buscando acá, ya dejamos atras las
transacciones en linea, donde necesitabamos optimizar espacio. Lo que
aca nos interesa es un sistema de ANALISIS, para lo cual ya SUPONEMOS
que para hacer esto, tenemos el espacio suficiente, por tal motivo, no
debemos de preocuparnos por ello.
Lo que el usuario (el cual puede ser un gerente) quiere ver son
reportes, datos o tendencias de una manera que le sirva a él, no le
interesa como esta almacenado, o peor aún, cómo lo hizo.
Cambiando un poco... respecto a lo que menciono Heber en unos post
anteriores, que <i>"el modelo de Innmon propone que se deben de tener
los
datamarts descentralizados, uno para cada departamento, y el conjunto
de todos ellos formarà el datawarehouse en su totalidad."</i> Me dejó
en qué pensar, ya que en el articulo "Data Warehousing: Similarities
and Differences of Inmon and Kimball", la autora hace mención a unos
puntos que estos grandes gurus hicieron mención:
"El DataWarehose no es mas que la unión de todos los data marts" Ralph
Kimball Dec. 29, 1997.
pero luego Inmon no se queda atras, y hace un argumento hacia tal
opinión de kimball:
"Usted puede tener todos los pececillos del oceano, y juntarlos y aún
asi, no formar una ballena". Bill Inmon Jan. 8, 1998.
Asi que, al parecer Inmon no comparte tal idea. :-)
Erick Moran
pero la verdad no creo que se este una interpretacion correcta .
No hay mejor o peor entre estas dos filosofias, si estariamos hablando
en sentido futbolistico el marcador seria un 1 a 1 entre Kimball e
Inmon.
rpa...@gmail.com
tener todo junto para que esto tenga todos los aspectos importantes
del negocio en un solo lugar, ya que para el si no lo hacemos de esta
forma se pierda la idea del datawarehouse que es un repositorio de
toda la informacion requerida por el negocio, pero esto es aplicable
para mi solo a. cuando la empresa no estan grande
b. la informacion que se guarda tiene relacion
Por ejemplo si la empresa es una Multinacional como La NBC Universal,
que tiene desde canales de tv hasta compañias que hacen maquinas de
hacer hornos, su dataware house seria enfocado a negocios economicos
de como un anuncio de tv afecta al dia siguiente la venta de un
producto.
Pero tambien tiene el otro salo que un ejecutivo de la compañis de
maquinas de hacernos hornos solo debe ver si negocio como lo menciona
Inmon tener un conjunto de datamarts.
Bueno desde lo puestos mas altos de la compañia es buen tener un
esquema de kimball, pero los gerentes de mediano nivel el recomendable
que solo tengan un enfoque Inmon.
Como dicen cada quien que trabaje su parcela, por lo tanto una union
de los enfoques es lo recomendable
Lisbeth Ricart
página sencilla, pero muy interesante en sus comentarios acerca de
este concepto. Basicamente es un blogger dedicado a los Sistemas
Decisionales. Y su autor Jorge Fernandez Gonzales de Barcelona,
España, dedica sus Post haciendo comentarios de Data Warehouse.
Dentro de algunos de sus post que llaman la atención se encuentran
algunos formas de implementar un Data Warehouse a través de las
metodologías ágiles (DSDM, Scrum) y aunque el autor no llega a muy
buenas conclusiones es interesante su desarrollo.
En algunos otros post, se hacen comparativas entre ambos modelos,
mostrando los diversos enfoques que se muestran en estas
metodologías. Y por último existen unos post donde se encuentras los
pasos o reglas que se deben tomar en cuenta para un Data Warehouse que
se muestran muy interesantes y los requisitos mínimos de un Data
Warehouse.
La direccion de este blogger es http://sistemasdecisionales.blogspot.com/
si tienen un tiempecito leanlo... esta interesante.
an@ lui§a
Bueno como para todo, cada quien tiene diferentes necesidades, los dos
modelos que discutimos tienen enfoques diferentes, es por eso que
siempre va a crear un poco de polémica, pero en sí como han dicho
anteriormente, es importante que cada quien adopte el que más le
convenga según sus necesidades
200312504
Hugo Pacheco
para una empresa se puede usar uno u otro, tambien la experiencia que
tenga el analista y del sistema en usar uno u otro, pues uno prefiere
usar lo que sabe hacer bien, aunque aveces no importa que sea el mejor
o no.
ootonielec
modelo multidimensional y según dice en un blog que encontré, él
aseguró que su modelo multidimensional era la única forma viable de
diseñar bases de datos, pero apareció Inmon 3 años mas tarde y se
atrevió a desafiar a Kimball afirmando que en el modelo dimensional
difícilmente se puede incluir información que no se incluyó en el foco
original del análisis y define el datawarehouse basado en un modelo
entidad relación, la verdad no tengo experiencia en ello pero dicen
que es mas costoso de implementar pero que mejora la trazabilidad
decisional y no se cierra a un solo modelo.
.
ootonielec
El Datawarehouse surgió con el objetivo de hacer consultable la
información que se tiene de tiempo atrás y están en la categoría de
los sistemas para el soporte de decisiones (DSS) que tienen como
objetivos medir y controlar el desarrollo de algunas cuestiones
importantes del negocio, entonces tanto Kimball como Inmon persiguen
el mismo objetivo pero sus puntos de vista difieren al parecer Inmon
cuestionó a Kimball y propuso una mejora a algunas deficiencias del
modelo dimensional de kinmball pero según se dice que en cuestiones de
dinero es mas costosa esta propuesta de Inmon en realidad no se cuánto
pero existiría la posibilidad de que a largo plazo se recupere esa
inversión.
Lisbeth Ricart
Buscando algunos artículos interesantes sobre el tema, encontré un
articulo escrito por W. H. Inmon http://www.dmreview.com/article_sub.cfm?articleId=3165
donde describe la evolución histórica del diseño de las bases de
datos.... Partiendo desde las más elementales hasta lo que hoy conocemos
como Data Warehouse.
Pero para poder contrastar un poco esta visión de Bases de Datos,
Ralph Kimball en un articulo llamado Fact Tables and Dimension Tables
en http://www.intelligententerprise.com/030101/602warehouse1_1.jhtml
describe la estructura que debe contener un Data Warehouse.
Ambas visiones enfocadas a los modelos que ambos han propuesto,
describiendo sus lineamientos de DW; que ya aquí hemos discutido
ampliamente.
José Julio Pineda Chinchilla
José Julio Pineda Chinchilla
Edwin Allen
por un Inmon.
Pero para crear un DW from scratck si no hay DM es mejor tirarte por
un kimball,
ademas es de analizar los factores
Tiempo de Respuesta vs Abstraccion del Modelo (facilidad de uso)
x cierto no tengo tu carnet????????????
Gerson Raymundo
Mi opinion personal sobre esta filosofia es que, es igual de buena que
la Filosofia de Inmmon, pero todo depende del enfoque que querramos
darle, por ejemplo, si no tenemos limitante de espacio para guardar
informacion, la mejor forma de manejar los datawarehouse es con la
filosifia de Kimball, ya que utiliza la redundancia de datos para
poder consultar de una manera mas sencilla. Creo que este modelo es el
mas utilizado en las empresas por motivos de facilidad de uso, facil
acceso a la informacion, ademas de proveer la facilidad de dividir
todo en datamarts que juntos forman toda la informacion de
Datawarehouse.
Gerson Raymundo
Carnet 200313132
Gerson Raymundo
importante de la inteligencia de negocios, y que la informacion esta
guardada en tercera forma normal.
En conclusion, las dos filosofias son buenas, ambas tienen enfoques
diferentes, la decision de que filosofia utilizar estara a cargo de
las personas de informatica que deberan de estar conciencientes de las
necesidades del negocio, asi como las capacidades de almacenamiento
para poder emitir una buena decision con respecto a que tecnica de
Datawarehouse deben utilizar.
Gerson Raymundo
Carnet 200313132
200011246
e Inmon.
A mi opinion creo que Inmon es un diseño de DW elegante y mas ordenado
claro que esto sacrifica tienpo en la creacion de cubos, y es aqui
donde importa la frecuencia y tiempo en que los cubos deben de ser
generados en una organizacion, si la necesidad es de generar los cubos
mas rapidos y muchas veces entonces la alternativa es Kimball.
Claro esto no es una regla pues con un poquito de paciencia y salivita
todo sale jajaja, en conclusion la base de los dos paradigmas es el
mismo una fact table y muchas dimenciones.
Alvos
antes de su implementación, y ambos modelos pueden ser de carácter
estático o dinámico dependiendo de las necesidades de la empresa en
la que sean implementados.
El modelo de kimball no sugiere una modificación de lo realizado, al
contrario,
en base a cubos diseñados con anterioridad, habla de el acoplamiento
de
los mismos para cubrir necesidades organizacionales y de creación de
tablas
que sean utilizadas como recursos externos para información que se
encuentre
en cubos ya diseñados. En todo caso lo que propone Kimball es la
extensión
del modelo inicial definido.
200230358 Harsoon
sobre inteligencia de negocios, me parece que en efecto ambos enfoques
son útiles dependiendo del negocio donde se implementara el
datawarehouse, por ejemplo, en clase se nos ha mencionado un caso en
el que los cubos se generan constantemente, en ese caso se empleará un
enfoque que no tarde en la generación, sin embargo, si los cubos son
de datos historicos casi inmutables puede convenir hacer un amplio
tratamiento de la información para optimizar los tiempos de respuesta
sin importar el consumo de recursos por la generación.
Por otro lado, en mi opinión es solo cuestión de tiempo para que este
tipo de modelos pierdan su relevancia debido al avance tecnológico,
eventualmente, los tiempos de respuesta de sistemas distribuidos
permitirá hacer consultas rápidamente sin necesidad de tratar
demasiado los datos. El "Federated Approach" se aproxima a esto,
básicamente los datos residen en muchos lugares distintos, al requerir
consultas no se acumulan y tratan todos los datos sino únicamente los
que son útiles para el objetivo actual, para el usuario externo las
fuentes de datos son transparentes y se ve únicamente un gran pozo de
datos. Por el momento esto no es eficiente en todos los casos, un
documento interesante a este respecto por DB2 esta en
http://www.wintercorp.com/rwintercolumns/PlayingEveryTune.html, en la
parte de "FEDERATED VS. CENTRALIZED DATA WAREHOUSING"
200212447_Edgar
la informacion se puede recopilar de varios lugares, de varias bases
de
datos, o de varias redes,etc... Pero lo que logre entender en los
conceptos de
Immon y Kimball debaten, es que no importa de donde venga la
informacion
si no la logica de la creacion del DWH.
Puesto que Kimball lo envuelve todos los datos recopilados en un DWH
multidimencional
en la cual las dimensiones se relacionan. Por otro lado Immon divide
la informacion
recopilada en distintos modulos independientes, costando mucho la
relacion entre ellos.
Aunque por parte seria mejor, pero el costo en relacionar estos es
mayor.
Entonces dependiendo de lo que se necesite el negocio, rapides u
organizacion, se
puede elegir entre cualquiera de los dos conceptos.
IvonneAldana_200212438
es decir, el diseño del mismo, en este aspecto creo que Bill Inmon se
baso en la necesidad de centralizar la información para analisis, de
diversos sistemas OLTP, La filosofía de Inmon es que los datos
deberían estar integrados y accesibles de forma detallada, haciendo
uso de datamarts, tratandolos como sub conjuntos del datawarehouse,
asi por ejemplo se tendría un datamart de un departamento y el
datawarehouse integra la información de todos los departamentos
mediante los datamart, es un acercamiento tipo top-down. Es una
estructura bastante organizada. Ahora, Ralph Kimball propone un
acercamiento tipo Bottom-up donde los datamarts son conectados al
datawarehouse como una estructura de bus, que contiene todos los
elementos comunes por los datamarts, ya que la filosofía de kimball
es que usando estos elementos, los usuarios pueden consultar todos los
datamarts juntos.
Vinicio
se mezclen las dos metodologias la de Bill Inmon y la de Ralph
Kimball
encontre una empresa que implementa una mezcla y se llama Abemak
Consultores.
Es interesante porque muchas veces nos decidimos por una o por otra
metodologia
sin saber que talvez nuestra solucion esta en realizar una combinacion
de
las caracteristicas de cada una de las opciones que se ajusten a
nuestras
necesidades.Aunque en la pagina de este grupo consultor
http://www.abemak.com/SeccServicios/BusinessIntelligence-A.htmno
se detalla como implementa esta fucion de metodologias sera
interesante profundizar mas
en esto.
Marco Vinicio Gomez
Carne 2001-12583
Vinicio
competencia sino mas bien como que una es la variante de la original.
Debemos de conocer a profundidad las dos metodologias para
poder saber cual se adecua mas a nuestra organizacion y preveer
los resultados de una implantacion de este tipo.
Es importante que no se vea los paradigmas o la tendencias
como una palabra dicha sino que se tenga el valor de plantear
modificaciones o nuevas ideas en cualquier ambito de la tecnologia
para seguir obteniendo innovacion.
Vinicio Gomez
Carne 2001-12583
Luis Cano
informacion, debemos tener el juicio suficiente para hacer
modificaciones a paradigmas existentes, eso si, siempre que tengamos
la experiencia. De lo que he leido en esta discusion y de otros
articulos, la perspectiva de Kimball es la mas utilizada, la razon
prevalente es que en organizaciones el esfuerzo de implementar un DW
ha sido a nivel departamental, creandose primero los DM's. Sin
embargo, eso muestra una deficiencia en esas organizaciones, y es la
falta de vision de los altos mandos, falta de vision porque no han
previsto la necesidad de organizar de forma centralizada la
informacion. Y esto lleva a los departamentos a hacer esfuerzos por su
cuenta. Al llegar a una organizacion tal vez tengamos que utilizar
ambas perspectivas, o una mezcla o inventar alguna (seria bueno).
sergio cifuentes
para poder tomar una decesion, he leido que el modelo de kimball es
mas agil que el de inmon, tambien es mas costoso de mantener, pero que
tiene ventajas como centralizar la inf. a diferencia del de kimbal.
sergio cifuentes
para poder tomar una decesion, he leido que el modelo de kimball es
mas agil que el de inmon, tambien es mas costoso de mantener, pero que
tiene ventajas como centralizar la inf. a diferencia del de kimbal.
On 23 mayo, 09:35, Luis Cano <shr...@gmail.com> wrote:
sergio cifuentes
On 6 mayo, 10:35, Vinicio <tkvini...@yahoo.com.mx> wrote:
> Ivonne Fijate que he leido un poco acerca de alguna empresa en la que
> se mezclen las dos metodologias la de Bill Inmon y la de Ralph
> Kimball
> encontre una empresa que implementa una mezcla y se llama Abemak
> Consultores.
> Es interesante porque muchas veces nos decidimos por una o por otra
> metodologia
> sin saber que talvez nuestra solucion esta en realizar una combinacion
> de
> las caracteristicas de cada una de las opciones que se ajusten a
> nuestras
> necesidades.Aunque en la pagina de este grupo consultorhttp://www.abemak.com/SeccServicios/BusinessIntelligence-A.htmno
sergio cifuentes
informacion como un todo para la organizacion mientras que kimball
agrupa por secciones esto como todos han escrito genera ventajas y
desventas a la hora de implementar cada modelo
les dejo igual un link de un cuate que siempre ha desarrollado modelos
kimball y opina acerca de inmon
http://sistemasdecisionales.blogspot.com/2006/09/inmon-o-kimball-o-cuanto-apreciamos-la.html
On 3 abr, 11:49, "IvonneAldana_200212438" <ivonnealda...@gmail.com>
wrote:
Aaron
de DW. En este modelo se manejan dos tipos de tablas para llevar el
control de la información. Una de estas es la Fact Table, que se
encarga de almacenar las medidas o métricas de los procesos del
negocio. El otro tipo se le conoce como Dimension Table, y lleva el
control de las características de los procesos.
Además, se habla sobre los atributos, que es una analogía de los
atributos de una entidad en un modelo relacional.
Aaron
Jose Carlos
lastimosamente como en la mayoría de paradigmas en computación solo el
tiempo dirá si esta verdad se mantiene como tal, me parece también
curiosos como los paradigmas creados por los autores han evolucionado
y muchos de ellos ya no son aceptados.
Utilizar Innon o Kimball, parece una solución que radica en la
preferencia del desarrollador y en la visión de la organización, por
lo visto anteriormente, lo que me indica que ambas son soluciones
factibles, que pueden implementarse en una organización.
200216479
essolares
adecuan a las necesidades de las empresas, puesto que depende de la
cantidad de información a manejar y la forma más conveniente en que
se desee manejar.
Esto depende ya que en el caso de Kimball el manejo de la informacion
se hace de forma conglomerada, es decir toda la información
almacenada
en un solo modelo dimensional.
Por lo contrario lo que plantea el Autor Inmon es que el manejo de la
información se realice de forma distribuida, sin perder la relacion
entre toda la información del negocio.
Ambos autores plantean un punto de vista diferente pero que nos lleva
a la misma idea del mejor manejo de la información de la empresa por
medio del data warehouse.
Edgar Salazar
200312699
essolares
Según W. H. Inmon (considerado por muchos el padre del Data
Warehouse), un Data Warehouse es un conjunto de datos orientados por
temas, integrados, variantes en el tiempo y no volátiles, que tienen
por objetivo dar soporte a la toma de decisiones.
Según Ralph Kimball (considerado el principal promotor del enfoque
dimensional para el diseño de almacenes de datos), un Data Warehouse
es una copia de los datos transaccionales específicamente
estructurada
para la consulta y el análisis.
Estas definiciones nos ayudan a entender un poco mas la diferencia
entre las dos filosofias.
Edgar Salazar
200312699
pablo
200312669
Aclarando un poco mas:
"Kimball - Let everybody build what they want when they want it, we'll
integrate it all when and if we need to. (BOTTOM-UP APPROACH)"
"Inmon - Don't do anything until you've designed everything. (TOP-DOWN
APPROACH)"
Pueden leer algunos pros y contras de cada enfoque aqui:
Raúl Cruz Orellana
considero que se debe de entender cada una de las filosofías de ambos
autores, pues Immon se enfoca en una porción del sistema total de
inteligencia de negocios.
Es decir que se tiene un datawarehouse, y los data marts, tienen el
origen de su información en ese datawarehouse, Mientras que Ralph
Kimball, nos dice que es datawarehouse es el conjunto de todos los
data mart, y que la información siempre se encuentra en el modelo
dimensional.
Francisco Raul Cruz Orellana
200312484
-JF-
utilizar su paradigma, por un lado tenemos a un Kimball que desarrolló
su modelo hace 10 años en un mundo donde expone tener un proceso ETL
que alimentará los datamarts finales (facil uso para el usuario con
poca experiencia), ahora bien, me voy un poco más por el lado de
Inmon, y de hecho coincide siempre con Kimball en un solo proceso ETL
pero agrega un paso más alimentando un DWH unico del cual se extrearan
los datamarts de los que harán uso los diferentes departamentos de la
empresa, aunque un poco más costoso pero siento que puede ser más
viable ya que se puede llegar a un nivel más detallado.
Rene Chinchilla Molina
donde día a día del analisis de infomacion, asi como sus
paradigmas cada uno se aplica dependiendo las necesidades,
limitaciones, costos (dinero, tiempo, etc.) y reglas
del negocio que a su esto con lleva a la infinidad de
fuentes de informacion recopiladas y posteriormente, limitar,acotar
depediendo los objetivos del DWH.
aplicar y definir una matriz de información donde sea sencilla la
aquisicion de la información e integrar la meta data (METRICAS/
DIMESIONES).
En los ETL,RDBMS, OLAP, Reporting, siendo asi kimball un paradigma
sencillo
que con lleva a administradores, gerentes y tomadores de decisiones
cambiar o simplemente modificar reglas del negocio siendo una
fuente confiable de informacion y de facil entendimieno
a su vez se puede monitorear.
René Alfonso Chinchilla
200112477
agui...@gmail.com
contras, y esto se traduce en los campos de aplicación en los cuales
cada paradigma logrará el desempeño que deseamos. Por ejemplo, el
modelo de Kimball tiene ciertas orientaciones específicas. Es decir
que puede ser utilizado principalmente para el rastreo de inventario,
procesos de manufactura, ventas, utilización de recursos, etc. Ya que
cada uno de estos aspectos puede ser manejado a través de un data
mart, individual, aunque esto no implica que no se encuentre
totalmente integrado con el data warehouse. Lo que Inmon por su parte
propone a través de su modelo altamente normalizado es la preservación
de la data "tal como es", obviamente despues de haber sido validada y
limpiada. Entonces la data del DW debe de estar en el nivel más bajo
de granularidad posible, pero dicho dataware house debe ser formado
por una transformación y carga directa, no por la colección de los
data mart's.
Pero ¿qué pasa si para nuestro modelo de negocio, un data warehouse
formado por data marts es suficiente?, ¿qué pasa si no lo es? Es ahi
donde las personas de IT deben de saber seleccionar un modelo
apropiado y no dejarse guiar por un absolutismo de paradigmas.
Carlos Aguilar
199516424
Fernando de León
acerca de lo que vayas a aplicar, y tener una muy buena visión a
futuro ya que de lo que hagas ahorita dependerá que en un futuro no
muy lejano puedas escalar en lo que estes implementando, no es de
dejarse llevar por las corrientes o porque en internet hay un 70% de
personas que esten de acuerdo con X o Y paradigma, creo que es bueno
aprender de sus experiencias y ver los pros y contras de ambos
paradigmas pero realmente es cuestion de "tomarlas en cuenta" nada más
y centrarte y poner los pies en lo tangible para tu empresa, ya que a
este nivel podríamos estar hablando de que un gerente puede apoyarse
en lo que un DSS le de... creo que hay que evaluar muy bien ambos
paradigmas y ver bajo que condiciones se implementaran.
J. Fernando de León
1998-11540
melvin m
parte de este comentario fue tomado de:
http://www.dmreview.com/article_sub.cfm?articleId=1400
EVALUANDO AMBOS BANDOS
Ambos expertos están de acuerdo en que el éxito del
warehouse/marts depnde efectivamente en obtener los requerimientos del
negocio primero.
Ambos expertos están tambien de acuerdo con que la intervención del
usuario experto del negocio evalúe que todas las espectativas son
manejadas.
de la misma manera ambos concuerdan en que los datos deben ser
organizados, estandarizados ya que pueden existir muchas fuentes
externas de datos.
concuerdan en que la mas adecuada estructura es el esquema estrella.
Para Inmon ODS (Operation Data Set) es un snapshot actual del negocio.
Kimball sin embargo sugiere que se cree todo un historial de datos
para cubrir cada detalle en el almacén de datos.
El ha creado el concepto de cambios leves en las dimensiones del
reporte - lo que es vs. lo que fue.
"... The data warehouse is nothing more than the union of all the data
marts ..." Ralph Kimball Dec. 29, 1997.
a lo que Inmon respondió:
"You can catch all the minnows in the ocean and stack them together
and they still do not make a whale." Bill Inmon Jan. 8, 1998.
Inmon cree que el esquema de estrella de kimball causa inflexibilidad
y que esto conduce a auna estructura quebradiza pq cree que esto no es
lo optimo. Cree ademas que su esquema, dependiente de datamarts
resuleve el problema del acceso a los mismos datos, el cual cambia en
el tiempo.
la arquitectura BUS de kimball cree que no se necesita un repositorio
centralizado.
Kimball - Let everybody build what they want when they want it, we'll
integrate it all when and if we need to. (BUTTOM - UP)
Inmon - Don't do anything until you've designed everything. (TOP-DOWN
APPROACH)
----
COMENTARIO
Bueno, ambas filosofias tienen puntos a favor y puntos en contra. Al
parecer kimball inclina al desarrollo mediante metodologías ágiles, ya
que
todo ve ( o trata de que asi se perciba ) de una manera simplista.
Difieron cuando dice que data warehouse no es mas que la union de
todos los datamarts, y lo dice por su metodologia BUTTON-UP, que
conforme se vaya necesitando se va creando. Al decir que no se
necesita
un repositorio centralizado, quiere saltarse una parte importante de
lo que es el diseño de una arquitectura.
Inmon es un poco mas sereno en cuanto al desarrollo. espera a que todo
este debidamente diseñado, y ademas de que ve al warehouse mas
que solo como la suma de sus partes datamarts.
Esto me recuerda la clásica lucha: RUP vs Metodologías ágiles.
Yo me inclino mas por la filosofía de Inmon, (tambien considero muy
seriamente utilizar RUP para desarrollar aun así sean aplicaciones
pequeñas)
y critico mas a kimball.
recuerden "Lo único constante en el desarrollo del software, es el
cambio" (HEAD FIRST OOA&D)
saludos,
melvin miculax
2002-12299
andresae...@gmail.com
nosotros lo integraráremos si es necesario, y cuando sea necesario.
(ACERCAMIENTO BOTTOM-UP)
Pros: Rapido para construir, rapido ROI (Return Of Investment), ágil
Contra: más difícil de mantener como recurso de la empresa, a menudo
redundante, a menudo difícil de integrar Data Marts
Inmon - no hacer cualquier cosa hasta que has diseñado todo.
(ACERCAMIENTO DE ARRIBA HACIA ABAJO)
Pros: fácil de mantener, integrado firmemente (tightly integrated)
Contra: toma la manera demasiado larga para entregar los primeros
proyectos, inflexible
Andres Saenz
200219625