Blog list: Top Social Networking Sites
Source: Laura Gibbons Scorecard Application & Six Sigma Blog [link]
Top Social Networking Sites
-
Claims to be the professional liasion source, ala Plaxo meets LinkedIn. My jury is still out…
-
Ways to aggregate all of your friend's information from their blogs
-
Think global text messaging…
-
Claims to be the 1st in this space on the scene…Think mashup meets community.
-
Folks, I was recruited when I wasn't looking solely off my LinkedIn profile. it works!
Twitter? I guess…
Source: Loosely Coupled Human Code Factory [link]
I’m not sure if I really wanted to do it, but I did. http://twitter.com/adronbh…(read more)
Fedora 9 on Hyper V on Windows 2008 Server x64 - Firefox IPv6 DNS issue
Source: oramoss oracle [link]
I’ve been playing with Hyper V this week and came across an issue with Firefox, whereby I thought that the networking setup for Fedora 9 on a Hyper V virtual machine wasn’t working.
The environment is Windows 2008 Server on x64 with the RTM release of Hyper V. I then created a VM and installed Fedora 9 x64 from a DVD ISO - it took a while as I started with a multiple CPU, standard network adapter approach and it kept crashing during the install; when I changed to single CPU and “Legacy” network adapter it installed cleanly - given that Fedora isn’t a “supported” Hyper V OS I can’t really complain.
The problem I then came to was that it appeared that DNS wasn’t working, i.e. in Firefox, if I stuck in a URL, it came back with an error rather than showing the page. I then proceeded to go off on a wild goose chase checking all the Fedora networking setup and reading about Hyper V and it’s “synthetic” network adapter approach, but still couldn’t solve it. Everything seemed to be installed and configured exactly as everybody who had written about it had said…so it should be working right?
It was…but the problem is that Firefox was trying to resolve the name of the URL using IPv6 rather than IPv4…and my network was configured without an IPv6 DNS - I don’t need IPv6 and I’m perfectly happy with IPv4 so that’s what I use. I only discovered this by chance as I wondered whether it might be a Firefox issue (everything else ruled out kinda thinking), so I used the Konqueror web browser to see if it had the same issue and hey presto it was working fine whilst Firefox wasn’t.
How to fix Firefox? Well, basically as indicated in this post on the OpenSUSE website - essentially, you go to the URL “about:config” in Firefox, filter for “network.disable.IPv6″ and set it to TRUE instead of FALSE (double click it to change the value). Then it all works fine.
UKOUG BIRT SIG Meeting, London 8th October 2008
Source: Rittman Mead Consulting [link]
The next meeting of the UKOUG Business Intelligence & Reporting Tools Special Interest Group is on October 8th, 2008 at the Hilton Hotel Paddington. We’ve got a special line up this meeting with an extended session by Michelle Bird from Oracle on the new features coming in OWB 11gR2, plus we’ve got sessions by myself on the technology behind the Oracle BI Applications, one on Oracle Business Intelligence for PeopleSoft, a session by Inatech on Oracle BI and Oracle Application Express, and a session by IBM on driving green initiatives using Oracle Business Intelligence Enterprise Edition.
This SIG meeting is also a special one for me, as I’m standing down as the BIRT SIG Chair. I’ve chaired the SIG now for around five years and my feeling was that it was time for someone else to have a go, as it’s always good to shake things up once in a while. I’ll still be coming along to the SIG meetings and if I think I’ve got enough time free next year, I’d be interested in standing for the board so that I can get involved in a more directional role. Anyway, here’s the meeting agenda.
09:30 - Registration and Coffee
10:00 - Welcome and Introduction
10:10 - What’s Coming with Oracle Warehouse Builder 11gR2 - Michelle Bird, Oracle
11:40 - Coffee
12:00 - Driving Green Initiatives using OBIEE - Lin Gardner, IBM
12:45 - Oracle Business Intelligence for PeopleSoft - Oracle Open World Preview
13:15 - Lunch
14:10 - SIG Committee Elections
14:20 - An Introduction to the Technology Behind the Oracle BI Applications - Mark Rittman, Rittman Mead
15:05 - Integrating Oracle Business Intelligence with Oracle Application Express - Inatech
15:50 - AOB and Close
Rittman Mead are once again one of the event sponsors, so stop by our booth during one of the breaks if you’re coming along. We can talk to you about the BI Publisher, OBIEE and Oracle BI Applications courses we’ve recently put together, and we’ll be able to answer any of your questions about OBIEE, Discoverer, OWB, Oracle BI Applications and any of the other Oracle BI & DW products.
More details on the meeting can be found here, and if you’re interesting in standing for either the SIG chair or deputy chairs positions, you can fill in your details in this online survey.
Dimension Hierarchy Tables and Slowly Changing Dimensions in the Oracle Business Analytics Warehouse
Source: Rittman Mead Consulting [link]
The blog posts I wrote earlier in the week about ragged hierarchies and bridge tables got me thinking about how these things are represented in the Oracle Business Analytics Warehouse (OBAW), the pre-defined data warehouse that comes with the Oracle BI Applications. The OBAW comes with support for ragged hierarchies in the form of dimension hierarchy tables, I also thought I’d spotted some bridge tables in there, and I’ve been meaning to look at how it supports slowly changing dimensions, and so I fired up my virtual machine and took a look.
The OBAW comes with a number of tables with the _DH suffix, which complement the usual set of tables with _D (dimension), _F (fact), _A (aggregate), _DS (dimension staging) and so on. Listing out the table names in SQL*Plus, the full set in BI Apps 7.9.5 is:
SQL> select table_name 2 from user_tables 3 where table_name like '%_DH' 4 / TABLE_NAME ------------------------------ W_ALIGNVER_DH W_AGREEMENT_DH W_ALIGNMT_DH W_INDUSTRY_DH W_INT_ORG_DH W_PRODUCT_DH W_POSITION_DH W_MED_PLAN_DH W_OPTY_DH W_FUND_DH W_GEO_REGION_DH W_PRODCAT_DH W_PERIOD_DH W_ORG_DH W_REGN_DH
So what are these hierarchy tables for, given that there’s already a bunch of dimensions defined in the business model and mapping layer of the repository, with their own hierarchies, levels and so on?
If we take one example, the W_INT_ORG_DH table, you’ll find that it’s listed in the physical model of the BI Apps repository and is aliased several times, as for example Dim_W_INT_ORG_DH_Employee_Org and Dim_W_INT_ORG_DH_Operating_Unit_Org. Taking a look a the Dim - Operating Unit Org logical table within the Core business model, you can see that this logical table maps to two logical table sources, one of which is called Dim_W_INT_ORG_D_Operating_Unit_Org and maps to a single corresponding physical alias table with the names of operating units in it, and another called Dim_W_INT_ORG_DH_Operating_Unit_Org that maps to the alias above the W_INT_ORG_DH table.
So why does a logical dimension table map to both a dimension table and a dimension hierarchy table? How does this relate to the regular, level-based hierarchies in the business model and mapping layer?
The clue is in the level-based bit. What these _DH dimension hierarchy tables are for is to flatten-out the ragged hierarchies that might be in your source system, in this case Peoplesoft, so that your internal parent-child organizational hierarchy relationships can be represented in the level-based way that OBIEE requires them. These are then used for reports that drill-down through the hierarchy (making use of regular dimension and hierarchy objects in the repository), and other dimension history tables such as W_POSITION_DH are used within the repository to secure fact table information to just staff members and their superiors.
Let’s take a look at the structure of the W_INT_ORG_DH table, and the W_INT_ORG_D table that’s the primary source for the other logical table source that this logical dimension table uses, to see how this works.
Looking at the W_INT_ORG_D table first, you can see that it contains the list of organizational units within the business
SQL> SELECT row_wid
2 , org_num
3 , org_name
4 , effective_from_dt
5 , effective_to_dt
6 , current_flg
7 from w_int_org_d
8 where rownum < 10
9 /
ROW_WID ORG_NUM ORG_NAME EFFECTIVE EFFECTIVE C
---------- ------- ------------------------------ --------- --------- -
0 01-JAN-01 Y
6001 0 Setup Business Group 01-JAN-99 01-JAN-14 Y
6002 202 Vision Corporation 01-JAN-99 01-JAN-14 Y
6003 204 Vision Operations 01-JAN-99 01-JAN-14 Y
6004 205 Manufacturing 01-JAN-99 01-JAN-14 Y
6005 206 Widgets Product Line 01-JAN-99 01-JAN-14 Y
6006 207 Seattle Manufacturing 01-JAN-99 01-JAN-14 Y
6007 208 Chicago Subassembly Plant 01-JAN-99 01-JAN-14 Y
6008 209 Boston Manufacturing 01-JAN-99 01-JAN-14 Y
9 rows selected.
Looking at the names of the organization units, you can probably guess that some are higher in the organizational hierarchy than the others. For many organizations their organization hierarchy is stored in their source systems in a parent-child fashion and can often be unbalanced, and the ETL routine that prepares the internal organization hierarchy in the BI Apps anticipates this, initially storing this parent-child hierarchy in the W_INT_ORG_DH_TMP temporary table, with one row per organization unit per source system hierarchy, like this:
SQL> SELECT org_id 2 , org_num 3 , org_name 4 , par_org_id 5 , par_org_num 6 , par_org_name 7 , hierarchy_name 8 FROM w_int_org_dh_tmp 9 WHERE org_num between 0 and 209 10 ORDER BY org_id 11 / ORG_ID ORG_NUM ORG_NAME PAR_ORG PAR_ORG PAR_ORG_NAME HIERARCHY_NAME ------- ------- ------------------------------ ------- ------- ---------------------- ------------------------------ 0 0 Setup Business Group 202 202 Vision Corporation 204 204 Vision Operations 202 202 Vision Corporation Vision Global Reporting 204 204 Vision Operations 202 202 Vision Corporation US Commercial Sales (DBI) 204 204 Vision Operations 202 202 Vision Corporation Global 204 204 Vision Operations 202 202 Vision Corporation Primary Reporting Hierarchy 204 204 Vision Operations 205 205 Manufacturing Vision Corp EBI Hierarchy 204 204 Vision Operations 202 202 Vision Corporation Assets Hierarchy 204 204 Vision Operations 202 202 Vision Corporation Single Establishment Reporting 204 204 Vision Operations 260 260 Vision Administration PJI 204 204 Vision Operations 202 202 Vision Corporation Vision Corp - Global 204 204 Vision Operations 458 458 Vision Services Burden Schedule Hierarchy 204 204 Vision Operations 202 202 Vision Corporation US DBI Hierarchy 205 205 Manufacturing 202 202 Vision Corporation Vision Global Reporting 205 205 Manufacturing 204 204 Vision Operations Single Establishment Reporting 205 205 Manufacturing 204 204 Vision Operations Primary Reporting Hierarchy 205 205 Manufacturing 202 202 Vision Corporation Vision Corp EBI Hierarchy 205 205 Manufacturing 204 204 Vision Operations US Commercial Sales (DBI) 205 205 Manufacturing 204 204 Vision Operations US DBI Hierarchy 205 205 Manufacturing 202 202 Vision Corporation Vision Corp - Global 206 206 Widgets Product Line 1615 1615 Widget Companies Vision Global Reporting 206 206 Widgets Product Line 1615 1615 Widget Companies Vision Corp - Global 206 206 Widgets Product Line 205 205 Manufacturing Primary Reporting Hierarchy 206 206 Widgets Product Line 205 205 Manufacturing Single Establishment Reporting 207 207 Seattle Manufacturing 204 204 Vision Operations Global 207 207 Seattle Manufacturing 205 205 Manufacturing Vision Corp - Global 207 207 Seattle Manufacturing 205 205 Manufacturing Vision Global Reporting 207 207 Seattle Manufacturing 206 206 Widgets Product Line Primary Reporting Hierarchy 207 207 Seattle Manufacturing 206 206 Widgets Product Line Single Establishment Reporting 207 207 Seattle Manufacturing 204 204 Vision Operations Vision Corp EBI Hierarchy 207 207 Seattle Manufacturing 204 204 Vision Operations US DBI Hierarchy 207 207 Seattle Manufacturing 204 204 Vision Operations US Commercial Sales (DBI) 207 207 Seattle Manufacturing 204 204 Vision Operations DBI - Vision Operations 208 208 Chicago Subassembly Plant 205 205 Manufacturing Vision Corp - Global 208 208 Chicago Subassembly Plant 206 206 Widgets Product Line Single Establishment Reporting 208 208 Chicago Subassembly Plant 206 206 Widgets Product Line Primary Reporting Hierarchy 208 208 Chicago Subassembly Plant 205 205 Manufacturing Vision Global Reporting 209 209 Boston Manufacturing 205 205 Manufacturing Vision Global Reporting 209 209 Boston Manufacturing 205 205 Manufacturing Vision Corp - Global 209 209 Boston Manufacturing 207 207 Seattle Manufacturing SEATTLE ECO HIERARCHY 209 209 Boston Manufacturing 206 206 Widgets Product Line Single Establishment Reporting 209 209 Boston Manufacturing 204 204 Vision Operations DBI - Vision Operations 209 209 Boston Manufacturing 206 206 Widgets Product Line Primary Reporting Hierarchy 43 rows selected.
Now if you read my posting the other day about ragged hierarchies and OBIEE, you’ll know that the semantic model used by OBIEE doesn’t (currently, as of the 10gR3 release) support ragged hierarchies, requiring them instead to be “flattened out” into level-based hierarchies. This is exactly the route that the OBAW load routine takes when processing ragged hierarchies, flattening them out into tables such as W_INT_ORG_DH table, so that you now have a row per organization unit, per hierarchy, that shows their path up the organization chart. There’s a number of SDE (Source-Dependent Mappings) that carry out this task, flattening the hierarchy through joining the temporary table about several times to itself using a Source Qualifier transformation, with the rest of the mapping now working with a set of flattened out level columns.
Once the data is in the W_ORG_INT_DH table, it looks like this:
SQL> SELECT row_wid
2 , org_wid
3 , org_hier1_num
4 , org_hier2_num
5 , org_hier3_num
6 , org_hier8_num
7 , org_top_num
8 , effective_from_dt
9 , effective_to_dt
10 , current_flg
11 FROM w_int_org_dh
12 WHERE org_hier1_num between 0 and 209
13 /
ROW_WID ORG_WID ORG_HIER1_NUM ORG_HIER2_NUM ORG_HIER3_NUM ORG_HIER8_NUM ORG_TOP_NUM EFFECTIVE EFFECTIVE C
---------- ---------- ------------- ------------- ------------- ------------- ------------- --------- --------- -
54 6004 205 205 205 202 01-JAN-99 01-JAN-14 Y
183 6002 202 202 202 202 202 01-JAN-99 01-JAN-14 Y
193 6001 0 0 0 0 0 01-JAN-99 01-JAN-14 Y
91 6008 209 209 209 204 202 01-JAN-99 01-JAN-14 Y
92 6006 207 207 207 204 202 01-JAN-99 01-JAN-14 Y
93 6003 204 204 204 204 202 01-JAN-99 01-JAN-14 Y
102 6007 208 208 208 204 202 01-JAN-99 01-JAN-14 Y
1230 6001 0 0 0 0 0 01-JAN-99 01-JAN-14 Y
1411 6008 209 209 209 204 202 01-JAN-99 01-JAN-14 Y
1412 6006 207 207 207 204 202 01-JAN-99 01-JAN-14 Y
1413 6005 206 206 206 204 202 01-JAN-99 01-JAN-14 Y
1414 6004 205 205 205 204 202 01-JAN-99 01-JAN-14 Y
1415 6003 204 204 204 204 202 01-JAN-99 01-JAN-14 Y
1416 6002 202 202 202 202 202 01-JAN-99 01-JAN-14 Y
1527 6007 208 208 208 204 202 01-JAN-99 01-JAN-14 Y
3045 6004 205 205 205 205 202 01-JAN-99 01-JAN-14 Y
3047 6008 209 209 209 205 202 01-JAN-99 01-JAN-14 Y
2090 6003 204 204 204 204 202 01-JAN-99 01-JAN-14 Y
2618 6007 208 208 208 205 202 01-JAN-99 01-JAN-14 Y
2093 6004 205 205 205 204 202 01-JAN-99 01-JAN-14 Y
2095 6005 206 206 206 204 202 01-JAN-99 01-JAN-14 Y
2096 6006 207 207 207 204 202 01-JAN-99 01-JAN-14 Y
2097 6007 208 208 208 204 202 01-JAN-99 01-JAN-14 Y
2098 6008 209 209 209 204 202 01-JAN-99 01-JAN-14 Y
2902 6003 204 204 204 458 202 01-JAN-99 01-JAN-14 Y
2428 6004 205 205 205 205 202 01-JAN-99 01-JAN-14 Y
2679 6005 206 206 206 1615 202 01-JAN-99 01-JAN-14 Y
2430 6008 209 209 209 205 202 01-JAN-99 01-JAN-14 Y
2436 6006 207 207 207 205 202 01-JAN-99 01-JAN-14 Y
2441 6003 204 204 204 204 202 01-JAN-99 01-JAN-14 Y
2696 6004 205 205 205 205 202 01-JAN-99 01-JAN-14 Y
2701 6003 204 204 204 205 202 01-JAN-99 01-JAN-14 Y
2703 6006 207 207 207 205 202 01-JAN-99 01-JAN-14 Y
2208 6003 204 204 204 204 202 01-JAN-99 01-JAN-14 Y
3490 6003 204 204 204 204 202 01-JAN-99 01-JAN-14 Y
4068 6008 209 209 209 207 202 01-JAN-99 01-JAN-14 Y
3053 6006 207 207 207 205 202 01-JAN-99 01-JAN-14 Y
3058 6003 204 204 204 204 202 01-JAN-99 01-JAN-14 Y
3880 6006 207 207 207 204 202 01-JAN-99 01-JAN-14 Y
3882 6008 209 209 209 204 202 01-JAN-99 01-JAN-14 Y
3651 6003 204 204 204 204 202 01-JAN-99 01-JAN-14 Y
3666 6006 207 207 207 204 202 01-JAN-99 01-JAN-14 Y
3183 6007 208 208 208 205 202 01-JAN-99 01-JAN-14 Y
3979 6003 204 204 204 260 202 01-JAN-99 01-JAN-14 Y
3465 6003 204 204 204 204 202 01-JAN-99 01-JAN-14 Y
3236 6005 206 206 206 1615 202 01-JAN-99 01-JAN-14 Y
3478 6004 205 205 205 204 202 01-JAN-99 01-JAN-14 Y
3479 6006 207 207 207 204 202 01-JAN-99 01-JAN-14 Y
3480 6004 205 205 205 204 202 01-JAN-99 01-JAN-14 Y
3481 6006 207 207 207 204 202 01-JAN-99 01-JAN-14 Y
50 rows selected.
This table is then made available in the OBAW, and added to the Internal Organization logical table as an additional logical table source (not sure why its separate logical table source, I would have thought it’d be more efficient to just add it to the existing logical table source that gets the main dimension member information), so that reports can drill up and down the dimension hierarchy. One slight drawback to this approach that’s common to all hierarchy flattening techniques is that you’ll need to amend the _DH warehouse table, plus all the dependent staging and temporary tables if your source parent-child hierarchy has more than the set number (nine I think) of flattened levels, this will be particularly interesting as you’ll need to amend the tables themselves plus the SDE and SIL (source-independent load) Informatica mapping that load them, quite a big task when you think about it especially as there are SDE mappings for each source and for each hierarchy category.
The eagle-eyed amongst you would also have spotted effective from, and effective to, dates in the above tables, together with a current flag column that you usually see in dimensions configured to store history (known in Kimball terms as a slowly changing dimension). That’s precisely what they are, organization dimension entries having start and end dates and a flag to show whether the row you’re looking at is the current (i.e. active) row, with the same columns also being present in the dimension hierarchy tables and in fact every seeded dimension table within the OBAW.
The fact that every dimension table, and in fact every dimension SIL mapping, is set up in order to support slowly changing dimensions means that you can turn on this feature just by setting the $$TYPE2_FLG mapping parameter to “Y”, though you’ll need to start customizing the mapping if you want to go with anything other than the default set of Type 2 trigger columns. If you compare this to SCD handling in OWB it approaches things from a slightly different way, with OWB setting SCD types at the dimension object level and the BI Apps setting it at the mapping level, for the standard set of BI Apps seeded mappings their arrangement works well but it gets a bit messy when you want to alter the set of trigger columns and of course you have to reproduce all of this mapping logic in your own mappings if you want your own custom dimensions to be handled in the same way.
Anyway, that’s it for dimension history tables and slowly changing dimensions. In terms of what I want to cover next in this series, there’s the integration of the BI Apps with E-Business Suite security (probably the number 1 thing I’m asked) and a low-down on the universal adapter and how it can be used to bring in your own, unsupported data sources. But for now though that’s it, let me know if you’ve got any feedback on the above.
Dataupia Frees Your Data
Source: Blog: Richard Hackathorn [link]
At the Boulder BI Brain Trust, we heard a presentation from Dataupia about their company background, product offering, and future directions. They offer a versatile data warehouse appliance.
See the complete blog item here.
El estado actual del Open Source BI
Source: Todo BI: Business Intelligence, Data Warehouse, CRM y mucho mas... [link]
Interesantísima presentación del especialista en BI Open Source, Mark Madsen de Third Nature.
Mark se plantea las siguientes preguntas. Por qué Open Source? Por qué ahora? Que deben hacer los fabricantes de soluciones y los clientes en un mercado, el del BI, que se ha ‘commodificado’, por usar el palabro. Es decir, que la percepción que se tiene de las diferentes soluciones es muy similar, y no se percibe por el mercado. Se buscan soluciones BI… y punto.. ahí entra en juego el Open Source… por su flexibilidad, disponibilidad y precio.
Mark tambié esta muy interesado en como las empresas pueden sacar valor del uso de las soluciones BI Open Source, pensadas como ‘mejor que gratuitas’. Con este criterior en la mente, muchas organizaciones sacarán todo el partido al BI Open Source.
Tambien hace mucho foco en los beneficios reales que todos (fabricantes, clientes, consultores, etc…) pueden sacar del uso del BI.
La verdad es que estamos muy de acuerdo con lo que indica Mark, si bien es cierto, que muchas de sus apreciaciones suyas llevan cierto tiempo para confirmarse y todavía ‘hay que remover’ muchos pensamientos ‘preestablecidos’. Aún así, los hechos estan dando la razón.
Mark Madsen tiene un blog muy interesante sobre el tema.
SAS 9.2 Papers from SAS Forum Australia and New Zealand 2008
Source: Blogging about all things SAS [link]
SAS ANZ ran a forum in Sydney this month, and had a great turn out with over 1,000 attendies. I didn’t manage to make it but heard it was a great event.
SAS ANZ have put up copies of the papers over on the SAS Forum Australia and New Zealand 2008 conference web site, check them out, there is some good info and highlights on whats comming in 9.2!
It Just Has to Work
Lookup Cache
Source: RDA Corp - Business Intelligence and SQL Server [link]
If you are migrating DTS packages to SQL Server 2005 or 2008…
Source: RDA Corp - Business Intelligence and SQL Server [link]
Top 7 Reasons I Wear a Suit
Source: Tod means Fox [link]
I dislike wearing suits.
It used to be that I could code in my favorite Phish t-shirt wearing sandals. I had a key instead of a badge, and lunch usually meant a few greasy pizzas or clam cakes. In those days, my attire only meant something if there was an off-site or if clients were coming to visit “the shop” (which was a tiny building several miles from the heart of the big city). I could easily bounce back and forth between long and short hair and between full beard and cleaned-shaved. Ahh… those were the days.
Now I work in a major international city for a rather large bank. I code in a suit when I’m not in meetings, wear nice shoes, carry a badge, and eat salads and yogurt for lunch. *sigh*
To be fair, I enjoy the new challenges and the big city. And if wearing a suit on occasion is a consequence, I can live with it. So while a suit is not fully mandatory, I still wear one at times. Here’s why:
- It easily puts me in line with the dress code
- Dressing is simpler in the morning (although sometimes it takes a couple of tries to get the perfect knot in my tie)
- My wife tells me I look great
- Dressing down on Friday never felt so good
- I look more important than I am
- I feel more important than I am
- My jacket flaps behind me in the wind when I ride my bike to the train station, which makes me feel like a super hero with a cape
Other than those fantastic reasons, wearing a suit is a real drag.
(I do admit, there is something rather Monty Pythonish about wearing a suit on a bike. I bet I look pretty silly to the folks driving past me. But riding my bike gives me more than 30 minutes a day of much-needed exercise, and on top of that, the price of gas here in Europe would blow your mind!)
BIDS Helper 1.3.0.8 Release
Source: Darren Gosbell [MVP] - Random Procrastination [link]
We have released a new update for BIDS Helper.
This release adds:
- support for Teradata data sources in the Dimension Health Check
- and fixes an issue where the properties page for the Package Deploy feature was not appearing under some circumstances.
Pre-Sales What I’ve Learned - P-prepare, R-Respond, E-execute - Revisited
Source: Michael Tarallo - Open Source BI Guru [link]
The Pre-Sales Engineer
The Pre-Sales Engineer, A.K.A Systems Engineer or Sales Consultant, is the stage performer of the IT world: immensely capable, confident, an excellent communicator who is equally comfortable in front of large crowds as well as small groups. They are Sales Reps in sheep’s clothing. Able to build and nurture relationships throughout the sales process, while maintaining an already established level of trust. Pre-Sales Engineers not only demonstrate the breadth and depth of their company’s products, but they also work closely with sales Account Managers to aid in the sales process and help close business. From 1st calls to technical support to demonstrations; the Pre-Sales engineer is there to make the prospect feel at ease, to paint a vision on how the products will meet a specific need. Their knowledge of the products and services being positioned to solve the business problem are invaluable. It is exactly this knowledge and skill that should be valued by the sales organization and it’s management team. SE’s should never be treated like tools or just “technical resources” . Anyone who believes otherwise has a huge character flaw, judges people immediately and demoralizes those whom they manage. I am truly happy to express that my Sales Director and EVP of Sales view the Pre-Sales engineering department, which I manage, as a valuable component to the sales process and the sales team. Pentaho has a very talented SE staff and I am very proud they are on my team.
Sharing a recent quote from one of network partners in the midwest:
“The Pentaho SEs are the smartest(breadth of experience and depth of expertise) we have met in several years of doing BI consulting sales. Their ability to quickly understand the client problem and devise several innovative approaches (incl thinking well outside the box) makes them fun to work with on accounts. We feel like our clients get the best possible solution – one that fits them and not one that fits the vendor product functionality. One recent experience involved spending several hours with various vendors (incl. Cognos, Oracle etc) explaining a complex client problem and investigating the different solution approaches. The end of those discussions resulted in no clear solution path. The Pentaho SEs were a pleasant surprise - they understood the problem within a few minutes and developed 3 different methods that could be used to tackle the problem – all in an hour phone conversation!”.
The Prospect’s Expectations
Depending on the selling company’s business model, Pre-Sales activity can take many different forms. Whatever that activity may be, it is important to keep the prospect’s expectations into consideration. During the discovery phase of the sales cycle, a Pre-Sales engineer listens and identifies a fit for its company’s offered solutions. He also sets expectations for the prospect on how the solutions will work for them. With knowledge of failed promises from many software/service companies or poor interactions with sales people, prospects are becoming more guarded and demanding when they engage with sales professionals. Specific “needs” to be addressed, justification of the value of any purchase, reviewing several alternatives before making any decisions to ensure the correct fit. In order to set the correct expectations surrounding those items, the sales/pre-sales process must fully uncover the business issues described along with there causes and effects. The process to identify a fit and understand a customer’s expectations should be no different whether you are positioning a physical product or a software solution. The key is to listen and understand what is being said, as well as identify what is “not” being said. For example, I recently was on a call with a major retailer where they were initially kicking tires and stated that they did not have any “specific” business problems. Further discussion revealed key targeted pain points that Pentaho Open Source Business Intelligence Suite could remedy with its software and services. One won’t be able to show a solution to someone who doesn’t perceive they have a problem. The first step when presenting is to help them understand that they have a problem – and that the problem is both important and can be solved. Also, the sales professionals should speak to the prospect as if “they” were the prospect. “That way the prospect is “not” forced to go through a constant mental exercise of morphing what the sales rep is saying into something that’s meaningful to them.
On sites, events, giveaways are they providing any real value?
As stated earlier, the pre-sales process takes different forms depending on the business model of the selling company. For example, many of the recently consolidated proprietary BI vendors (Oracle, Business Objects, Cognos, SAP) and even some of the independents, (MicroStrategy, Actuate and Information Builders) have no problem wining and dining their prospects in the form of expensive lunch and learns, golf outings or even iPod giveaway promos because they know they will recover those costs from the software licensing fees they charge their customers. Speaking from experience, even sending pre-sales engineers all over the United States (or world for that matter) for simple discovery calls, white boarding sessions and demos can add up to $2500/month per engineer (depending on location and means of travel). I remember numerous times eating out in the finest restaurants and staying in 5 star hotels just to do a demo the next morning that could have easily been done over the web. Please note that I understand the importance of human interaction so don’t get me wrong, there is a time and place to shake a hand, but it has to be managed carefully or you will just continue to waste money and downsize your company, similar to what is happening at my former company. I just heard of more layoffs and more seasoned SE’s leaving to find more fruitful and fulfilling jobs.
With the Open Source Business Model the pre-sales process is very similar in regards to any sales process but not so extravagant when it comes to the travel or promotions. There are more web meetings and conference calls with an even higher quality pre-sales engineer(s) who has the experience to back up their company’s claims. This can result in a solution that compares to the proprietary guys but with a lower TCO and a higher ROI.
Opposition, is it Pre-vent Sales?
There is a little joke in the pre-sales circle that the “pre” in pre-sales stands for “prevent”. This can commonly be heard from the account managers in sales organizations due to the level of push back they may receive by the Pre-Sales department. First off the interpretation is silly because the company’s success rides on qualified engagements. Why would anyone want to hinder their company’s performance for little or no reason. However, there are plenty of reasons for pre-sales to push back. One of them may be, not following the defined pre-sales process. A sales person’s job is not only to represent his company but to “get” as much information as possible so he can accurately position the products and services. It is our recommendation that this “discovery” should be done with the pre-sales engineer in order to achieve the most accuracy and again, set the proper expectations. If this information is not received by pre-sales, pre-sales can’t accurately paint a vision or present a solution if they don’t even know “why” they are being engaged. A requirement such as, “I want to see dashboards and reporting and analysis”, is not really too descriptive of what the “drivers” are for “wanting” to see these things. Doing a demonstration without knowing anything is a “Show Up and Throw Up” with HOPEs that the propsect will find something of interest. I don’t see “Hope” as a phase in the sales cycle. Please refer to this link to get a more in depth view of what I mean. Pete Cohan’s Stunningly Awful Demos has been a great resource. Other oppositions one may encounter are related to the personal styles of the individuals one may be working with. Some may be used to the way things were done previously in another company, where there possibly wasn’t a process or the business model was different. Some may be reactive and used to saying yes without drilling in further. Some may not want to bother with the pre-sales process and think they can do it all on their own. Whatever the reason may be pre-sales needs to identify the styles of these individuals and learn how to work with each and every one so it is productive for the prospect and the selling company. I prefer to think of the “pre” in pre-sales to stand for: P-prepare, R-respond, E-execute. Those actions will make for shorter sales cycles, proper customer expectations and improved sales. Happy selling.
Take a Survey on Data Warehouse Appliances
Source: Blog: Richard Hackathorn [link]
Supported by Teradata, Netezza and Kognitio, an independent research study is looking at the trends in the Data Warehouse Appliance (DWA) market. Much is happening, much of which is counter-intuitive.
If you are an IT professional with opinions on DWA, please take 5 minutes to take a survey. I will analyze the results objectively and report those results to you. The complete report will be posted for free on the B-eye-NETWORK. Thank you, Richard
Click Here
CSO Quotes About the Importance of Sales Analytics
Source: Keep It Simple [link]
Every time I speak with Barry Trailer over at CSO Insights, I end up with a few great quotes about sales performance management and the importance of sales analytics to bottom line results.
Here are a few of my favorites from a conversation we had today:
- “Don’t expect what you don’t inspect.”
- “We’re selling fish not wine – a lead doesn’t get better with age!”
- “We don’t know if it’s better to have bad breath of no breath in a territory!”
- “When it comes to our forecast, we have beer goggles and we need a microscope!”
- “I’m pretty sure we’re going to get better than average results…once we figure out what average is!”
- “We don’t have time to sharpen the saw because we’re too busy cutting wood!”
- ” Comparison is the basis of all unhappiness!”
Can you relate to any of these? Got some more gems worth sharing?
The Mystery of OBIEE Bridge Tables
Source: Rittman Mead Consulting [link]
If you’ve played around with the Oracle BI Administrator tool for a while, you may have noticed a box you can tick in the Logical Table Properties dialog, called “Bridge Table”. If you’re familiar with Ralph Kimball and some of this dimensional modeling ideas, you’ve probably heard of this concept before, but it’s not all that clear how you use bridge tables in OBIEE and a quick search around the internet and the OTN forums doesn’t really come up with an examples on how it’s used.
Bridge tables are a solution to what’s called the “multi-valued dimension” problem. For most dimensional models you generally want to link one sale, for example, to one product, one customer, one time period and so on, and this translates into a simple dimensional model where your fact table contains a single key value per dimension for each row that’s been stored. In some circumstances though, say where you are recording the diagnoses for a patient or the claim elements in a claim, you might need to record more than one key value for a particular dimension in each fact table row. In entity relationship modeling terms, you’ve got a many-to-many relationship between patient admissions and diagnoses, like this:
and the usual way you resolve these many to many relationships is to use an intersection table, with the key from the patient admissions table and the key from the diagnoses table copied across to form the intersection, and usually with a weighting column that adds up to 1, so that you can properly add up all the diagnoses and not over-count them.
As I said, this is not exactly new stuff and bridge tables, of which diagnosis group above is one of them, are a fairly common dimensional modeling construct. The problem you hit though when starting to use this feature is that the documentation on it is pretty minimal, and only really talks about setting this feature on the bridge table itself and doesn’t really mention what to do with the dimension table that hangs off of it. What I’ll do in this posting then is set out how I use it, explain my rationale and thereafter invite some feedback, so if someone else has come up with a better idea then we can work with that instead.
Going in to BI Administrator and looking at the physical model for the data set above, it looks like this:
with the key thing here being that the fact table we’ve got the bridge table joining to both the fact and diagnosis dim tables to form an intersection. If you imported this model into the logical business layer as is, the BI Administrator would think the intersection table is the fact table as the other tables join to it.
So what you do now is go into the properties for the diagnosis table and indicate that it’s a bridge table, like this:
Now when you look at the logical model the fact table is identified correctly.
If you try and validate the model now though, you get a warning because the diagnoses dimension table doesn’t link through to the fact table, as it goes through the bridge table instead.
Now not linking through to the fact table is sometimes allowed, basically in situations where you’ve snowflaked your logical model and the dimension table is actually a higher level in the same dimension, but in this case if we try and use this model and bring in the diagnoses information into a query, we’ll get a metadata consistency error.
To solve this, what I would do is remove the diagnosis dimension from the logical model, and instead add it to the logical table source for the bridge table, like this:
Then I’d add any columns that I needed from the diagnosis dimension physical table into the bridge table, which I can do now as I’ve added the dimension table to the bridge table LTS, so that this bridge table now becomes my diagnosis dimension, like this:
So what I’ve done here is take the dimension table, which before linked to the bridge table and thereafter caused the metadata inconsistency, and instead added it to the bridge table logical table source and added it’s columns to the bridge table logical table.
If I run a report now, the data comes out as you would expect, with multiple diagnoses per patient and the weighting applied correctly.
However I’m conscious that to me, getting rid of the logical dimension table seems a bit wrong, and others have said that they don’t use the bridge table feature at all, and instead just combine the various tables into a single logical table source. If anyone’s got any other way of using bridge tables, add a comment to this post and we’ll see what the consensus is.
Data Integration Trends: Future Shock
Source: Data Doghouse - performance management, business intelligence, and data warehousing [link]
Each year, industry analysts, experts and vendors bombard us with acronyms for the next big trend. There are several ways to examine these trends to determine if you should jump on board.
First, ask yourself if the trend is real or just the next pet rock. Is it being used by early adopters or merely by companies conducting R&D to determine if there is any real value? If it is real, will it have an impact on the industry this year, or will it take several years? And will that impact be incremental or revolutionary?
Second, remember that a solution may be appropriate for the Fortune 500 market or the small to midsized business (SMB) market, but not always both. Although trends are pitched to everyone, the reality is that some are a better fit for large firms while others will be adopted by the SMB market.
>>> Read the rest of my article Data Integration Trends: Future Shock on the DM Review website.
Bitmap Index Examples
Source: Rittman Mead Consulting [link]
Between assignments (mostly, OBIEE and BI Applications work) and a family holiday in the Austrian Alps I have been helping Mark with some of the examples he will be demonstrating as part of his 11g Data Warehousing Seminar. I must confess that I, too, will be using the examples in some of my data warehouse courses.
One of the demonstrations I have worked on for is the use of BITMAP indexes in simple (single table) queries. For this demonstration I used the standard SH schema and a couple of the provided bitmap indexes on the CUSTOMERS table; that is the GENDER (CUSTOMERS_GENDER_BIX) and YEAR OF BIRTH (CUSTOMERS_YOB_BIX) indexes.
Firstly, let’s look at the data distributions:
select cust_gender, count(*) from customers group by cust_gender; C COUNT(*) - ---------- F 18325 M 37175
There are about 66% M customers and 33% F, and no customers of any other (or NULL) gender.
A similar query shows us that there are 75 distinct years of birth (between 1913 and 1990) and for 1917 there are 37 customers
So what happens when we query the customers table on gender = M
SQL> explain plan for select * from customers where cust_gender = 'M';
select * from table(dbms_xplan.display);
Explained.
SQL>
PLAN_TABLE_OUTPUT
-------------------------------Plan hash value: 2008213504
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 27750 | 4877K| 407 (1)
|* 1 | TABLE ACCESS FULL| CUSTOMERS | 27750 | 4877K| 407 (1)
---------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("CUST_GENDER"='M')
We do a full table scan and do not use the index.
But when we choose a more selective query - the people born in 1917 (which hits about 0.07% of the table) we see this:
SQL> explain plan for select * from customers where CUST_YEAR_OF_BIRTH = 1917; select * from table(dbms_xplan.display); Explained. SQL> PLAN_TABLE_OUTPUT --------------------------Plan hash value: 3460183038 --------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU) --------------------------------------------------- | 0 | SELECT STATEMENT | | 740 | 130K| 146 (0) | 1 | TABLE ACCESS BY INDEX ROWID | CUSTOMERS | 740 | 130K| 146 (0) | 2 | BITMAP CONVERSION TO ROWIDS| | | | |* 3 | BITMAP INDEX SINGLE VALUE | CUSTOMERS_YOB_BIX | | | --------------------------------------------------- Predicate Information (identified by operation id): ————————————————— 3 - access(”CUST_YEAR_OF_BIRTH”=1917)
This time we are using the bitmap index.
So, is there any merit to using a bitmap index on a column with just two distinct values? After all, we do less work by table scanning the whole table.
The answer to this is yes. One of the great things about bitmap indexes is that they can be combined with other bitmap indexes on the same table by a bitwise ‘AND’ operation; that is we effectively create a multi-column index on-the-fly
SQL> explain plan for select * from customers where
CUST_YEAR_OF_BIRTH = 1917 and cust_gender = 'M';
select * from table(dbms_xplan.display);
Explained.
SQL>
PLAN_TABLE_OUTPUT
---------------------------------------------------Plan hash value: 4226934075
---------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
---------------------------------------------------
| 0 | SELECT STATEMENT | | 370 | 66600 | 82 (2)
| 1 | TABLE ACCESS BY INDEX ROWID | CUSTOMERS | 370 | 66600 | 82 (2)
| 2 | BITMAP CONVERSION TO ROWIDS| | |
| 3 | BITMAP AND | | |
|* 4 | BITMAP INDEX SINGLE VALUE| CUSTOMERS_YOB_BIX | |
|* 5 | BITMAP INDEX SINGLE VALUE| CUSTOMERS_GENDER_BIX | | | ---------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("CUST_YEAR_OF_BIRTH"=1917)
5 - access("CUST_GENDER"='M')
Here you can see both indexes being combined to access a small subset of the customer table.
Hopefully, this has been a clear example of why a low cardinality column may not be a good bitmap index choice in isolation but when combined with other bitmap indexes can be very beneficial.
Lonely At the Top… Proven
Source: Loosely Coupled Human Code Factory [link]
As the saying goes, so do the numbers. Interesting write up about skills acquisition by experience and how lonely it truly is at the top of the game. Interesting read if you like the thinking behind the industry. …(read more)