martes, octubre 30, 2007

1º Propuesta - En los origenes de las decisiones...

Hace ya muchos años, en los orígenes de los modelos OLAP nos podíamos encontrar este tipo de estructuras, las cuales es posible que la mayoría de nosotros no nos hemos encontrado nunca, pues hoy por hoy son innecesarias y están muy superadas. Pero tal vez merezca la pena observar este artilugio y disfrutar con algunas de sus características. Antes de proseguir, indicar que lo que menos me importa en este momento son las métricas, las cuales he puesto al azar. Para mi merece interés los inventos que se pueden apreciar en las dimensiones.

En líneas generales podemos observar en todas la tablas la misma estructura, un código genérico según concepto, su descripción genérica y un atributo denominado Level. Todo un invento por aquellos años.

Creo que para muestra y coger la idea es bastante con la siguiente explicación. Supongamos que tenemos la necesidad de meter los datos desde el 1999 al 2002, con todos sus meses y días, u otros niveles intermedios. Pues el resultado de dicha tabla sería:

Codigo Descripción Level
01 1999 1
02 2000 1
03 2001 1
04 Enero 2
05 01/01/1999 3
06 2002 1
07 Febrero 2
09 Marzo 2
10 27/05/2003 3

En definitiva lo importante es ver como el campo level es el que nos proporciona información sobre el nivel jerárquico dentro de la dimensión, de tal forma que si queremos ver las ventas por meses deberíamos filtrar por el level del tiempo con valor igual a 2. Si deseamos ver las ventas por días, el filtro del tiempo debería ser 3, etc.

Tengamos en cuenta que en aquellos años no teníamos unas herramientas como las actuales y el “interrogatorio” lo hacíamos los informáticos y eran unos buenos intentos para satisfacer las demandas.

Lógicamente tenían ciertas ventajas y ciertos inconvenientes, pues imaginar lo complejo que es preguntas por las ventas de un determinado producto, en un momento en el tiempo y en un centro determinado. La sentencia SQL tiene level por todos los lados y además las condiciones restrictivas. Lo dicho tenían muchos problemas, algunos de los cuales los siguiente teniendo las estrellas de hoy en día… ya llegaremos. Pero el principal problema era que dichos modelos y su explotación eran imposibles dejarlos en manos de los usuarios finales.

Bueno simplemente eran otros tiempos, daremos un próximo paso en nuestra evolución…

Preguntas y comentarios recibidos:

Sergi pregunta: Indicadores contenidos en la Fact Table precio_unidad y coste_unidadSon propios del producto, ¿Por qué no se representan dentro de la dimensión Producto?, ¿Qué motivos de peso hay para romper la 3 forma normal?.

Respuesta: Tal y como adelante, el objetivo del modelo (ejemplo) solamente trata de haceros ver como hace años, finales de los ochenta, muchas personas ya se rompian la cabeza para intentar montar algo para poder analizar la información de forma más agil.

Estos temas los veremos en los siguientes modelos. En cualquier caso, efectivamente el precio unidad y el coste, logicamente deberian ir asociados al producto, pero no dentro de la dimensión producto (o no de forma normal), pues dichos valores varian con el paso del tiempo, basicamente podemos diseñar versionning (algo coñado y dificil de manejar para un simple usuario) o montar una fact especifica, ya veremos que es lo más conveniente.

Bueno en el modelo propuesto, es más que discutible si hemos roto o no la tercera forma. Pues a un simple vistazo tenemos unas tablas con codigo y descripción, siendo esa primary key la clave foranea de la tabla de hechos, el atributo level es un artilugio informatico, al igual que un flag u otra cosa.

Pero te adelanto que en este caso el fin justifica los medios, en DW lo normal es la desnormalización... poco a poco.

Sergi pregunta: Pongamos por caso que un determinado producto no se vende nunca, ¿Cómo podemos saber su precio unitario y el coste por unidad?

Respuesta: Buena observación y buen analisis del modelo. En la mini estructura propuesta, que repito que no tiene nada que ver con lo que haremos, solamente estariamos "procesando" las ventas, por lo tanto sin venta no habría otros datos. Estas en lo cierto.

Dimensiones genéricas (Aglutinación de niveles)
Aquí vengo a hacerte una propuesta, pero primero desarrollo el problema.

Sergi pregunta: Al tener una aglutinación de niveles, la Fac. table debe almacenar datos con diferente nivel de granularidad y NO siempre todos los indicadores son agregables, así mismo este hecho hace crecer el volumen de datos de la Fact Table.

Respuesta: Efectivamente este modelo, para bien y para mal, permite este tipo de cosas. Lo cual obliga que en función del nivel del dato guardado en la table fact, existan valores vacios en algunas métricas. Posiblemente este y otras cosas, que supungo que detectarán el resto de lectores, han propiciado que hace años no se usen este tipo de modelos. Además el tema de datos aditivos son conceptos que practicamente han aperecido con el uso de herramientas DSS/EIS actuales (desde principios de los 90).

Sergi pregunta o propone: Por eso yo te propongo lo siguiente, la clave de las dimensiones debe ser explicativa NO subrogada, es decir te estoy pidiendo que rompas la segunda forma normal en pedazos y en algunos casos la primera permitiendo así las Fully Functional Dependencies.

Generar una clave explicativa y única, y que aparte sea numérica es posible ya que para cualquier conjunto finito es posible generar una bijeccion con los naturales.

Pero tal vez quede más claro con el siguiente ejemplo, la dimension de tiempo almacenará como clave el número yyyymmdd es decir el primeo de enero de 2006 se expresará 20060101 y el 31 de diciembre 20061231. únicamente almacenaremos el mínimo nivel de detalle, pero este contendrá ya la información de los niveles superiores.

Por ejemplo para consultar las ventas del año 2006 el where podría ser…

WHERE id_tiempo between 20060000 and 20069999;

Para consultar las ventas de enero...

WHERE id_tiempo between 20060100 and 20060199;

Respuesta: A la primera parte de tu propuesta comentarte que llegaremos a otras formas de hacer las cosas, pues por eso hemos avanzado en estos años. El tema de las claves, que detecto que tanto os gusta a todos, no es un tema tan alegre el cual se pueda definir sin ver un ejemplo real, el tipo de clave, si estan o no codificadas, si las claves pueden ser reutilizadas, etc... Seguro que más adelante sale el tema y podemos debatir a nuestro gusto.

Sobre el ejemplo que propones para del desarrollo de una dimensión temporal, decirte que es completamente necesario disponer de todas las claves y ser muy escrupuloso con ellas, pues imagina unas consultas como las que propones sobre un DW de telco, los cuales tienen tablas fact de muchos millones de registro, el sistema lo dejarias colapsado y veriamos si responde. Las consultas deben salir por claves, excepto con DB2 lo ideal es que sean numericas, pues de lo contrario adios al tiempo de respuesta, tambien muy importante el uso de indices (otro mundo), pero consultas por cadenas o "between 20060100 and 20060199" se me antojan muy pesadas.

En cualquier caso, la curiosidad me puede. La proxima vez que este en uno de mis clientes gordos, intentare lanzar una query de ese tipo...

Saludos y muchas gracias por compartir tus ideas y comentarios... esperamos a los demas y sus aportaciones.



viernes, octubre 26, 2007

El modelo propuesto por Álvaro Galan

Empezamos nuestras propuestas de soluciones con nuestro colega Álvaro Galan. Álvaro no necesita motivación ninuna pues poco a poco se mete en su papel y se autopropone mejoras continuas, lo cual me deja casi sin trabajo...


Os pongo copia tal cual, pues no tiene desperdicio.



En realidad, podemos montar varios modelos dependiendo de ciertas cosas.

Parece claro que tendríamos 4 conceptos susceptibles de ser dimensiones:

Articulo
Sección
Centro
Tiempo (Fecha) (me tomo la libertad de cambiar la fecha de venta, mediante un etl, y hacer un split de sus campos, y cargarlo en una dimensión, generando una surrogate key)

De estos yo mantendría Articulo, y fecha como dimensiones independientes, mientras que sección y centro podrían formar parte de una jerarquía (un centro tiene secciones o una sección tiene centros…), lo lógico es una sección (perfumería) depende de un centro (Centro de Sol)

Mientras que el resto de elementos del fichero, podrían ser hechos o propiedades.

Veamos

Para mi hay 2 hechos que son muy claros para una tabla de hechos central:

Unidades vendidas
Total venta

Mientras que un tercero, importe_descuento, dependerá si el descuento se aplica a una venta o a un articulo.

Si se aplica a una venta, tendríamos pues una tabla con 3 hechos, los dos anteriores y éste. Si se aplica a un artículo, se uniría a coste y precio, como 3 elementos de los que ahora hablaremos.

Estos 3 elementos (coste, precio, descuento), pueden ser perfectamente propiedades de la dimensión artículo, si no nos interesase trazar los mismos a lo largo del tiempo, o hacer algún tipo de operación con ellos (medias, sumas, etc.)

Si en cambio, los precios, costes y descuentos cambiasen a lo largo del tiempo, o simplemente nos interesase tenerlos como medibles, compondrían una segunda tabla de hechos. Cuyas dimensiones podrían ser cualquiera de las mencionadas. En función a lo que quisiésemos medir.

Como digo me surgen varios modelos, (no se si esto es trampa, jejejeje).

Por orden de “sencillez”


Este es el mas sencillo, solo “medimos” dos cosas para ventas. Y el coste, precio e importe descuento van como propiedades del artículo





Una ligera evolución de este anterior es considerar el descuento por venta. Su modelo:



Manteniéndonos con el anterior, pero considerando medible el precio (el coste probablemente no cambiase ya que mi razonamiento es que un articulo en un centro podrá costar mas que en otro centro al cliente (precio) (por ejemplo un perfume en la moraleja mas que en vallecas), pero su coste asociado para la empresa es el mismo, aunque a efectos de coherencia del modelo habría que ver si conviene incluirlo, es decir si conviene “hacer cuentas” (sumas, medias, etc..) con el coste, yo lo voy a incluir). Además en este asocio las secciones a centros con una jerarquía, de forma que podamos controlar en un modelo OLAP, el comportamiento de una sección en diferentes centros….)



Este ultimo es mi modelo candidato, aunque aun cabría una vuelta de de tuerca mas que sería pensar si el importe descuento se hace por articulo (propiedad de dimensión, como en el primer modelo), por venta (hecho, como esta ahora), o por articulo/centro (sería un hecho más en la tabla hechos artículo).





jueves, octubre 18, 2007

¿Qué modelo propones tú? (1ª Parte)

Hola amigos, hoy os propongo leer menos y participar más !!!!!!!.

A continuación os voy a poner un supuesto fichero de entrada, supongamos que procede del sistema operacional, y desde él vamos a ir generando diversas estructuras de datos, las cuales debeis explicar...


¿Qué crees que contiene el fichero? ¿Podrías obtener más información que la incluida "a primera vista"?

No os preocupeis, por el momento no existe mucha trampa o truco, solamente pretendo que todos seamos capaces de comprender el contenido del fichero.

Supongamos que deseamos montar un pequeñito modelo OLAP tomando como punto de partida ese fichero.

¿Qué diseño propones? Espero tus comentarios y la descripción o explicación de tu modelo.

Para todos aquellos que quieran participar en este ejercicio público e ir avanzado en las diversas técnicas de modelización entre lo dos... espero vuestros correos en jmarce@movistar.net

Todos los modelos propuestos serán incluidos, valorados, analizados y explicados.

Os espero.

24/10/2007

Hola a todos y gracias por vuestros correos y modelos propuestos. Os pediria que para ser exactos y no dar lugar a esquemas erroneos, me paseis el modelo ya representado a través de cualquier herramienta, solamente necesito el dibujo del modelo y con sus campos y claves identificados. Algunos ya me los habeis enviado, vale perfectamente en formato .jpg, simplemente es para incluir todos y ver la diversidad de vuestros planteamientos.

A continuacion os pongo los nombres o nick de los participantes, tampoco estaria mal tener vuestros e-mails para montar nuestro mini foro, pues algunos habeis contestado exclusivamente por la opcion de comentarios. Lista de participantes:

* Toad

* Juan Vidal

* Diego Arenas

* Alvaro Galan

* Jordi Isidro Llobet

Quedan dos personas de confirmar... pero podemos ir empezando. Según reciba los jpg de cada uno, lo pondremos en el blog y discutiremos las ventajas e inconvenientes. Tal y como os adelante, ire introduciendo nuevas necesiadades y conceptos para ir subiendo la dificultad.

Nota, ojo a los puristas de Kimball pues al final espero que podamos demostrar las limitaciones de las estrellas puras y otros trucos para hacer versionning y controlar los cambios sobre datos de dimensión, sin "putear" al usuario final con mil criterios temporales... ya veremos que conseguimos entre todos.

Una cosa más, habeis conseguido que cambie cierta percepción sobre el nivel en técnicas de diseño, pues algunos teneis un nivel muy bueno.



lunes, octubre 08, 2007

SAP To Acquire Business Objects For Euro 4.8 Bln - Update

SAP To Acquire Business Objects For Euro 4.8 Bln - Update

(RTTNews) - Signaling a shift in its strategy of growing organically, SAP AG (SAP) announced late Sunday an agreement to acquire French business intelligence software maker Business Objects (BOBJ) in a 4.8 billion euro deal. The acquisition is to be made through an open tender offer for all of Business Objects' outstanding shares, valuing each at 42 euros per share. The board of directors of Business Objects has approved the tender offer agreement and committed to recommend the offer to its shareholders subject to fulfillment of regulatory conditions. Following the transaction, Business Objects will operate as a stand-alone entity, while both companies will share executives and resources.

Neither company intends to undertake significant restructuring on account of the transaction. SAP has more than 41,000 customers in 120 countries running SAP applications. Business Objects is a business intelligence or BI software company with solutions ranging from information discovery and delivery, information management, analysis and performance management categories for more than 44,000 customers around the globe. Business Objects ranks ahead of Cognos Inc. (COGN) and Hyperion Corp. in the business intelligence software market, which is worth more than $2 billion.

The transaction is to take the form of a tender offer under French law and a parallel tender offer under U.S.law for all shares of Business Objects as well as American Depositary shares representing that company's ordinary shares, in addition to all convertible bonds and warrants issued by Business Objects. SAP said that the price to be offered per convertible bond would be Euro 50.65 and added that the offers will be only opened for acceptance on clearances from the French stock exchange authority- the Autorite des marches financiers or "AMF- and the French Finance Ministry.

The offer will be subject to certain conditions, namely, that the Business Objects' securities tendered in the offer represent at least 50.01% of all voting rights on a diluted basis, and receipt of EU and U.S.antitrust approval, SAP said.

The transaction is expected to close in the first quarter of 2008 and be accretive to SAP's earnings per share on a U.S. GAAP basis in 2009 and beyond. However, on account of acquisition-related one time effects in 2008, SAP expects the transaction to be dilutive by mid-single digits Euro cents to its earnings per share on a U.S. GAAP basis in fiscal year 2008.

Business Objects has been the subject of repeated takeover speculation for several months. Earlier, Oracle (ORCL) and IBM (IBM) also been mentioned as possible bidders. Business Objects shares advanced in February and in September last year amid speculation that Oracle might bid for the company.

SAP said that through the acquisition of Business Objects, it intends to offer high-value solutions for process- and business-oriented professionals, which will be designed to enable companies to strengthen decision processes, increase customer value and create sustainable competitive advantage through real-time, multi dimensional business intelligence. The company also said that its growth strategy is to significantly increase its revenues from new products, which would address the growing demands of Business Users.

Commenting on the deal, Henning Kagermann, CEO of SAP said, "We are highly committed to the next generation of applications serving Business Users. The combination of SAP and Business Objects in their respective domains will benefit customers, prospects, partners, employees and shareholders. At SAP, we are excited about the prospect of having Business Objects join the SAP Group."

Kagermann added, "With the delivery of the first business process platform; the rapid adoption of our enterprise SOA platform, SAP NetWeaver; and the successful launch of the first complete on-demand business solution for mid-sized companies, SAP Business ByDesign, SAP can now take the opportunity to focus on the industry's next high-growth opportunity, by accelerating and enhancing our efforts for the Business User category."

Bernard Liautaud, Chairman and Founder of Business Objects said, "Business Objects helps companies transform the way they work through the use of intelligent information. The combination of Business Objects and SAP means that we can truly amplify the reach of Business Intelligence - from the C-suite to Main Street."
SAP noted that the acquisition of Business Objects is in line with its strategy to double its addressable market by 2010 as announced in 2005, and added that it would accelerate its growth in the Business User segment while complementing its organic growth strategy. .
Following the transaction, Business Objects will operate as a stand-alone business as part of the SAP group. SAP noted that customers of Business Objects would continue to benefit from open, broad and integrated business intelligence solutions, which are independent of databases and applications, even while gaining the advantage of application alignment for business analytics. Further, the company said that Business Objects would enhance its BI portfolio scope and capacity with SAP people, know-how and networks.
SAP noted that the solutions from Business Objects would complement the offerings the company already provides for Business Users. On completion of the transaction, John Schwarz will continue as the CEO of the Business Objects entity and is expected to be added as a member to the SAP Executive Board. Doug Merritt, Corporate Officer of Business User, SAP will join the Business Objects entity and report to Schwarz.
Subject to the closing of the transaction, SAP's Supervisory Board intends to propose to elect the founder of Business Object, Bernard Liautaud, to the Supervisory Board at the company's next shareholder meeting. Liautaud will have an advisory role to Kagermann on aspects of strategy and integration until that time.
Goldman Sachs (GS) is acting as financial advisor to Business Objects, while Deutsche Bank Securities Inc. (DB) is acting as financial advisor to SAP.
Separately, on Sunday, Business Objects provided preliminary results for the third quarter. The company said that it expects U.S. GAAP earnings per share for the quarter in a range of $0.04-$0.06, while non-GAAP earnings per share is expected in a range of $0.36-$0.39. On average, twenty-three analysts polled by First Call/Thomson Financial expect the company to earn $0.46 per share for the quarter.
Business Objects forecast revenue for the third quarter in a range of $366-$370 million. Analysts expect the company to report revenues of $385.16 million for the quarter.
The company said that of the total revenues, it expects license revenue in a range of approximately $137-$139 million and services revenue of approximately $229-$231 million. Business Objects expects to announce its financial results for the third quarter on October 24, 2007.
Last month, SAP said it purchased the software license and maintenance business of SAP Arabia, which is its exclusive long-term partner in the region. Financial terms of the all-cash deal were not disclosed. The company noted that the transaction is subject to customary closing conditions and expects the acquisition to complete in fourth quarter of 2007.
Among SAP's peers, Oracle said in March that it would buy Hyperion Solutions Corp. for $3.3 billion in cash, in a bid to surpass SAP in the business intelligence software market. Oracle said that it will pay $52 a share for Hyperion. To boost its growth in applications as its traditional database has slowed, Oracle has spent more than $20 billion on companies including PeopleSoft and Siebel Systems.
In July, SAP reported an 8% growth in its profit for the second quarter to EUR 449 million from EUR 415 million in the prior-year period, aided by a 16% upside in revenues from software and software related services divisions, together with a positive impact from effective tax rate. Total quarterly revenues increased 10% to EUR 2.42 billion from EUR 2.20 billion in the prior-year period, driven by double-digit growth in all regions, despite a flat result from professional services division.
Business Objects reported a net income for the second quarter of $21.60 million or $0.22 per ADS in July, up from $7.95 million or $0.08 per ADS a year ago, helped by strong demand in Europe and an acquisition in France. On a non-GAAP basis, the company's earnings per share soared 55% to $0.48. The company's second-quarter revenues rose 23% to $363.23 million from $294.48 million in the similar period of last year.
SAP closed Friday's regular trading session at $59.23, up $1.34 or 2.31% on a volume of 2.77 million shares. In the 52-week period, the stock has been trading in a range of $44.17-$59.86.
BOBJ closed Friday's regular trading session at $50.27, up $2.71 or 5.70% on a volume of 4.34 million shares. In the 52-week period, the stock has been trading in a range of $33.45-$50.46.
For comments and feedback: contact editorial@rttnews.com

Seguidores