This post will cover slides 22 through 30 from the presentation and will describe the first two solutions (one with two variations) outlined in the presentation.

Solution Options

The four different solutions that I included in my presentation were: Universe aliases, Flattened structures (column or snowflake), Ancestor Model, and Depth First Tree Traversal. All of them work fine on a clean recursive hierarchy. Each of them partially works for at least some of the other challenges. Some of them present unique challenges (extra disk space requirements or lack of native drilling functionality) that will also be addressed. I am presenting the solutions in increasing order of complexity. This post will cover aliases and flattened structures (both versions). In the next post I plan to cover the ancestor model, and finally I will cover the depth first tree traversal in its own post.

Universe Aliases

This solution is the only one that can be completely self-contained within the universe. No DBA or ETL work is required. There are any number of ways to create an alias. I can:

• Right-click on a table and select Insert Alias
• Select an existing table in my structure, then select Insert + Alias from the menu
• Open my table browser and insert an existing table. An alias will automatically be created for me.
• Select an existing table in my structure and click the “Insert Alias” toolbar button

… and there are other ways to get aliases in my universe, especially if I have loops to resolve. The bottom line is that the process is quite simple.

Here’s what an alias looks like after it has been created and joined to an existing table in my structure.

The join can be a bit tricky. In this case, the employee row MGR_ID is joined to the manager row EMP_ID in order to make the relationship work. It might help to look at the raw data again from an earlier post.

See how the recursive relationship is going to work after establishing this join? Field works for Ferrerez, and Ferrerez works for Noakes. Who does Noakes work for? His MGR_ID column is empty (NULL) implying that he does not have a manager. He owns the company.

Pros of Alias Solution

The primary advantage of this solution is that it is completely self-contained in the universe. No DBA or ETL work is required. That’s about it.

Cons of Alias Solution

There are several cons to this solution. It does not represent lateral relationships at all. I have to use outer joins in order to preserve those rows with missing keys (Noakes in this example). Both of these are important, but the most substantial drawback to this solution is that the depth is determined by the number of aliases that the universe designer creates. In the image shown above there is only one link: from manager to direct employee. How can I — in one step — determine my indirect reports? With only one level of alias, I can only report one level of my hierarchy. How many can I report with this structure?

With that structure I now have two outer joins, but I can report on three levels instead of just two.

How many alias levels do I create? Generally when I have seen this solution used (or used it myself) we resort to asking how many levels are required and then creating some number above that. If I need five, I will create seven. If I need seven, I will create ten.

That means, of course, if I have created ten levels and all of a sudden we have twelve I have to update my universe. That’s not a problem (as long as I keep up with things) but it’s certainly not desirable.

Alias Scorecard

Here’s the scorecard for the alias solution for each of the four scenarios I outlined earlier.

Aliases are the easiest solution to implement but they don’t score well. Let’s move on to the next solution.

Flattened Structure – Single Table Columns

The next solution involves running either a SQL script or some form of ETL. I need to take the recursive table relationship and flatten it out much like I did with aliases, but this time in the database itself. The net result is that I will take data going down in rows:

and pivot it into columns in a table.

The net result is all of my recursion is done during the script process and I end up with one table that contains everything (or every person in my case) stored at their specific level in the hierarchy. It easily allows me to drill because it creates a very natural hierarchy.

Pros of Flattened Table Solution

It handles unbalanced hierarchies much better than aliases because missing lower nodes are simply NULL in the table. That’s fine. This solution can also handle ragged hierarchies with a proper “plug node” strategy. If I have a lower level value (Divisional Director) that reports directly to the president (top level) then level 2 (Vice President) will be empty. I need to fill something in so I can drill properly. More important, that plug node has to tell me what the path is or else I cannot drill up properly. Suppose I had a director named Smith who reported directly to Noakes. The first column in my table would include Noakes. The third column would include Smith. The second column (the missing value due to the raggedness of my data) would contain Smith VP Not Assigned or something like that.

Flattened tables cannot handle lateral hierarchies at all because I can’t store two values in a single column.

Cons of Flattened Table Solution

As already mentioned, this solution cannot handle lateral hierarchies at all. It also requires DBA or ETL work if the number of hierarchy levels changes. My column names should reflect the position (node type) in the hierarchy. That’s not a problem unless my hierarchy levels change, then I might want to update my structures.

But by far the most critical issue with this solution is the fact that it requires DBA or ETL work if my levels ever change. Much like aliases when I have seen this solution implemented I generally see extra columns at the end of my table just to allow for future expansion.

Flattened Table Scorecard

Here is my scorecard for the Flattened Table solution.

Flattened Structure – Snowflake Tables

One thing that I noticed about the data for the flattened structure is that I repeat a lot of values. For example, Noakes is the “level 1 mgr” for every person in the company. It might seem to be more efficient to use a structure like this:

This would reduce my overall storage requirements because I would end up with a single row for the highest level table.

However, it also reintroduces the need for outer joins, which the initial flattened structure avoided.

Pros of Flattened Snowflake Solution

Because the tables get smaller as I get further up the tree (ultimately to a single-row table in my simple example) my overall storage requirement should be smaller as well. If I only need the top one or two levels, my queries should be very efficient. Finally, I think it would be easier to maintain as well. If a new level appears, I add a new table to my chain with the proper restrictions on the ETL for proper table population.

Cons of Flattened Snowflake Solution

Each of the solutions defined so far suffers from some form of this issue: I have to define a table (or column) for every possible level of my hierarchy. If I do not know what the total number of levels will be, I can try to anticipate and create extra tables to support future expansion. But that is not the best solution. Because these tables are maintained in the database, I have to talk to my DBA or ETL team when changes are required. Because the tables are joined I have to consider whether to use outer join to preserve depth on unbalanced hierarchies. And finally, the “plug node” strategy I outlined earlier becomes a “plug row” strategy in this case, and that’s substantially more complicated.

Flattened Snowflake Scorecard

Here is the scorecard for the flattened snowflake solution. In my opinion, it’s a slightly worse solution than the flattened table solution simply because of the join issue and the plug row concern.

Next Time

The solutions covered in this post are the least complex and therefore offer the least flexibility. They are easy to set up; in the case of aliases the entire solution can be built within the universe designer application. All of the other solutions require some sort of database scripting. In the next post I will talk about the ancestor model and how we used it at a manufacturing client. It has some definite advantages, and it handles just about all of the different challenges I have outlined. I don’t have to worry about plug nodes, and it handles both ragged and unbalanced hierarchies quite well. However it has an impact on disk usage and it can’t be drilled using the native functionality provided by BusinessObjects. Do the pros outweigh the cons? Come back soon and see for yourself.

Related Links

• Universe Models for Recursive Data Part I: Introduction
• Universe Models for Recursive Data Part II: Design Challenges

Supplemental Material
Scripts to create and populate the basic HR table used for this presentation.

• Create table

  create table employee
  (emp_id number(5) not null
  ,emp_lastname varchar(20)
  ,emp_firstname varchar(15)
  ,emp_dob date
  ,emp_address varchar(40)
  ,emp_area_code varchar(7)
  ,emp_town varchar(15)
  ,emp_phone varchar(18)
  ,showroom_id number(4)
  ,emp_start date
  ,emp_mgr_id number(5)
  ,emp_sex varchar(1)
  ,job_id number(4));
  
  alter table employee add constraint emp_pk primary key (emp_id);
  create index emp_dept on employee(dept_id);
  create index emp_showroom on employee(showroom_id);
  create index emp_mgr on employee(emp_mgr_id);
  

• Populate table

  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (101, 'Noakes', 'Nicholas', '12-MAR-48', '2356, Melrose Street', '30190', 'San Jose', '12-00-00-01', '01-JAN-91', NULL, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (102, 'Ferrerez', 'Ferdinand', '10-FEB-64', '25 Arcadia Avenue', '75897', 'Los Angeles', '22-55-56-32', '30-MAR-96', 101, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (103, 'Field', 'Felicity', '15-DEC-60', '12 Brasilia Street', '12014', 'Santa Barabara', '14-46-54-22', '26-MAR-95', 102, 'F');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (104, 'Fraser', 'Frank', '13-MAR-67', '45 Seaside Avenue', '75016', 'Los Angeles', '22-55-18-33', '13-DEC-91', 101, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (105, 'Snow', 'Sara', '03-OCT-65', 'Square Woodstock', '18000', 'San Jose', '14-34-34-30', '01-MAY-93', 101, 'F');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (106, 'Speed', 'Sonya', '03-DEC-70', '5, The Vale', '22000', 'San Jose', '14-32-39-43', '04-JUL-96', 105, 'F');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (107, 'Spencer', 'Steve', '01-NOV-64', 'Square Osaka', '33010', 'Los Angeles', '22-24-25-89', '16-APR-91', 105, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (108, 'Helen', 'Harrison', '01-AUG-66', 'Via Firenze', '38200', 'Los Angeles', '22-34-31-11', '13-MAY-94', 101, 'F');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (109, 'Thomas', 'Tom', '01-DEC-68', '11 Over Way', '24000', 'San Jose', '22-45-67-45', '20-DEC-95', 101, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (110, 'Thatcher', 'Terry', '03-OCT-50', 'Stars Parkway', '21000', 'San Jose', '12-11-11-09', '06-DEC-92', 109, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (111, 'Davis', 'Diana', '12-AUG-64', 'Rue Opera Sauvage', '92100', 'Los Angeles', '14-54-11-10', '22-SEP-92', 101, 'F');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (201, 'Pickworth', 'Paul', '12-FEB-51', '23 Las palmas road', '00316', 'New York', '12-24-26-44', '12-JAN-93', 101, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (202, 'Forest', 'Florence', '10-OCT-32', 'Rue des Lombards', '75100', 'New York', '22-54-11-10', '23-DEC-94', 201, 'F');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (203, 'Brown', 'Bella', '12-APR-59', 'Hollywood Blv', '36020', 'New York', '22-36-25-50', '03-FEB-92', 202, 'F');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (204, 'Porter', 'Pete', '15-NOV-57', 'Avd Torre De Embarra', '34100', 'New York', '14-44-11-66', '13-APR-92', 201, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (205, 'Irving', 'Ira', '12-FEB-64', '44 Beach avenue', '13000', 'New York', '12-56-55-20', '18-JUN-95', 204, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (206, 'Bailey', 'Ben', '12-JUN-57', '4 Palisades Drive', '75090', 'Long Island', '12-33-51-29', '01-DEC-90', 204, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (207, 'Duckworth', 'Dave', '09-SEP-66', 'Rue du grand temps', '75018', 'New York', '12-85-01-61', '04-NOV-93', 201, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (208, 'Ince', 'Ian', '10-AUG-53', 'Sunset Blvd', '31061', 'New York', '22-52-22-00', '04-DEC-95', 207, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (209, 'Hilary', 'Hibbs', '01-FEB-60', 'Sand Hill Road', '92800', 'New York', '12-54-11-10', '08-JUN-95', 202, 'F');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (301, 'Dagmar', 'Davinda', '12-APR-58', '12, The Crescent', 'SL1 1HG', 'Slough', '01628-764234', '24-JUN-95', 101, 'F');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (302, 'Presley', 'Percy', '30-OCT-62', '1 Jubilee Close', 'SL5 23F', 'Maidenhead', '01628-834582', '15-JUL-95', 301, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (303, 'Perry', 'Philippa', '24-FEB-71', '23 Rice Hill', 'SL3 12S', 'Maidenhead', '01628-567231', '28-SEP-96', 302, 'F');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (304, 'Hubert', 'Henri', '13-DEC-69', '5 Grand Lane', 'SL3 12S', 'Maidenhead', '01628-243535', '17-APR-96', 302, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (305, 'Adamson', 'Anita', '12-OCT-69', '24 Loose Lane', 'SL4 23D', 'Cookham', '01628-782364', '15-FEB-96', 301, 'F');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (306, 'Beaver', 'Bertie', '12-MAR-72', '223 Grange Hill', 'SL2 67E', 'Windsor', '01628-187632', '13-JAN-96', 305, 'M');
  
  insert into employee (emp_id, emp_lastname, emp_firstname, emp_dob, emp_address, emp_area_code, emp_town, emp_phone, emp_start, emp_mgr_id, emp_sex)
  values (307, 'Motson', 'Mervin', '22-DEC-74', '67 Blows Down', 'SL5 45G', 'Cookham', '01628-198371', '17-JUN-96', 305, 'M');
  

Scripts to create and populate the flattened version of the HR table, Oracle syntax

• Create flattened table

  create table emp_flat
  (emp_lvl_1 varchar2(20)
  ,emp_lvl_2 varchar2(20)
  ,emp_lvl_3 varchar2(20)
  ,emp_lvl_4 varchar2(20)
  );

• Populate flattened table.
  Only four levels are supported.
  Starting point (Noakes) is hard-coded.

  insert into emp_flag (emp_lvl_1, emp_lvl_2, emp_lvl_3, emp_lvl_4)
  select a.emp_lastname
  ,      b.emp_lastname
  ,      c.emp_lastname
  ,      d.emp_lastname
  from employee a
  ,    employee b
  ,    employee c
  ,    employee d
  where a.emp_id = b.emp_mgr_id(+)
  and b.emp_id = c.emp_mgr_id(+)
  and c.emp_id = d.emp_mgr_id(+)
  and a.emp_id = 101;

• Create Snowflake Tables

  create table emp_level_01
  (emp_id number(5)
  ,emp_lvl_1 varchar2(20));
  
  create table emp_level_02
  (emp_id number(5)
  ,emp_mgr_id number(5)
  ,emp_lvl_2 varchar2(20));
  
  create table emp_level_03
  (emp_id number(5)
  ,emp_mgr_id number(5)
  ,emp_lvl_3 varchar2(20));
  
  create table emp_level_04
  (emp_id number(5)
  ,emp_mgr_id number(5)
  ,emp_lvl_4 varchar2(20));

• Populate snowflake tables
  Only four levels are built, each starting from the prior table.
  Starting point (Noakes) is hard-coded.

  insert into emp_level_01 (emp_id, emp_lvl_1)
  select emp_id, emp_lastname
  from employee
  where emp_id = 101;
  
  insert into emp_level_02 (emp_id, emp_mgr_id, emp_lvl_2)
  select e.emp_id, e.emp_mgr_id, e.emp_lastname
  from employee e, emp_level_01 e1
  where e.emp_mgr_id = e1.emp_id;
  
  insert into emp_level_03 (emp_id, emp_mgr_id, emp_lvl_3)
  select e.emp_id, e.emp_mgr_id, e.emp_lastname
  from employee e, emp_level_02 e2
  where e.emp_mgr_id = e2.emp_id;
  
  insert into emp_level_04 (emp_id, emp_mgr_id, emp_lvl_4)
  select e.emp_id, e.emp_mgr_id, e.emp_lastname
  from employee e, emp_level_03 e3
  where e.emp_mgr_id = e3.emp_id;
  

I decided to identify and cover four different examples of recursive data configurations. These included Clean, Unbalanced, Ragged, and Lateral. As I mentioned in the first post, I am going to use some basic human resources (HR) data for my examples. For this post, in order to show samples of each of the four challenges, I am going to represent my recursive data using a tree. The branches of the tree show the relationships between people. The nodes of the tree contain the information about each person. The data might include their name, hire date, and position (title) within the company. In order to properly interact with my recursive data I have to be able to work with both types of information: relationships and node data as well. If you are not sure what I mean, please continue reading, this will make more sense later on.

This post will cover slides 14 through 21 from the presentation and will describe each of the different recursive challenges that I identified.

Clean Hierarchy

In my first example everything is very clean. Each branch of the tree has the same depth. Each branch follows the same path. There are no real challenges encountered in this hierarchy, pictured below.

Imagine that the top of the tree is the company president. The second level (the “B” nodes) represent vice presidents, and the third level (”C” nodes) represents divisional directors. When a hierarchy definition is very rigorous this is the type of tree I expect. For a very simple example let me suggest a product hierarchy instead of an HR chart for the moment. A product hierarchy for a food company might include a Brand Owner, the Brand, the Size, and finally the Flavor. The brand owner could be Beverages-R-Us, the brand could be Super Sports Drinks, the size is two liter bottle, and finally the flavor is Orange. Every product in the system is guaranteed to have all four of these attributes assigned, and they will all be in that exact order.

On the other hand, a human resources hierarchy is rarely as clean. Let me move on to some more interesting examples.

Unbalanced Hierarchy

An unbalanced hierarchy is one where the nodes are at inconsistent depths. Please review the tree shown below.

In the example shown above, there is one node (B1 in this case) that does not have any children while the rest of the nodes at that level (B2) do. If the A node is the company president, and the B nodes are vice presidents, it is entirely possible to have a position (perhaps “VP of Special Projects”) that does not have any additional people that report up to him or her. In that case the tree stops at the VP level and does not go down to the Divisional Director position.

Why is this a challenge? As will be seen later, one of the possible solutions to a recursive data scenario is to pivot the data (flatten) it into different columns. What happens to the missing nodes in this case?

Ragged Hierarchy

In the last example I suggested that there could be a VP of the company that does not have any direct employees. In the case of a Ragged hierarchy it’s slightly different. In this case I might see a Divisional Director who is reporting straight up to the company president without going through a VP.

Note that in the image above I am showing both an unbalanced node (B1) and a ragged node (C2). Let me focus on C2 for a moment. As I already mentioned, there is a relationship from that director position straight up to the president. It does not go through a vice president position. Why is this a challenge? Remember that earlier I mentioned there are two parts that I need to account for: the relationship and the position or node type. In this case the relationship only goes one step, but descends two levels (from president to director). I need to be able to represent both parts properly in whatever data model I come up with.

Lateral Hierarchy

If you have spent any time reviewing company organization charts you may have seen this type of relationship before: I am calling it a lateral (sideways) relationship.

It’s not uncommon to see a lateral relationship from one director to another director (C2 reporting to C1 in this example). This is one of the biggest challenges to most of the design ideas I will be sharing in my next post, because there are two things (people) occupying the same space (node type) on the tree).

Merge / Diverge

As I mentioned toward the beginning of the post that some scenarios are inherently cleaner than others because the relationships all have to exist. Unfortunately, it is quite likely to see a combination of issues. I have even seen challenges where a hierarchy does a merge / diverge relationship such as this:

SAP and other ERP vendors generally allow this sort of hierarchy to be built in order to provide the maximum flexibility to the client company. I have never tried to implement this in BusinessObjects because it simply does not work. There is no clear drill path. Suppose I drill from node B2 to C3, and then from C3 to D2. Now when I drill up, which path do I take? I can drill from D2 up to C3, and then from C3 I can drill up to either node A1 or B2. It’s ambiguous, and therefore our project team decided that we would not attempt to handle this at all. We instituted a business rule (an exception) that would kick out any hierarchy that included this sort of path.

This particular example was dropped from the presentation in the interest of time but I wanted to mention it here.

Combinations

Even without the merge / diverge issue, there are plenty of still challenges. For our project, a typical tree was both ragged and unbalanced. That meant that the solutions we discussed had to be able to handle both. We also had a number of lateral relationships that we needed to address. Our users wanted to be able to enter the tree by node type and drill by level. They wanted to see the entire tree presented as part of a prompt. And they wanted to be able to multi-select from those prompts… for any node at any level.

Next Time

Which solutions work the best? Do any solutions work for all of these different scenarios? My next post in this series will review each of the four solutions I outlined in my presentation and present a scorecard for each.

Related Links

• Universe Models for Recursive Data Part I: Introduction

This post will cover slides 6 through 13 as a basic introduction of recursive data and challenges presented to universe designers.

Defining Recursive Data

Sometimes there is confusion about the distinction between hierarchical and recursive data. Hierarchical data does not present a big challenge for BusinessObjects. It can be something related to time (Year, Quarter, Month, Day), geography (Country, Region, State, City), or something more specific like an accounting structure (Business Unit, Account, Sub-Account). What makes this hierarchical structure work easily is that each element is stored in a different place. It could be in a different column in the same table (flattened) or even in different tables (snowflake). As long as I can drill from one column to another in the hierarchy everything works fine.

Self-referencing or recursive data may initially look like a hierarchy. The key difference is that all of the elements are stored in the same place. There are keys that relate one row in a table back to a different row in the same table. That’s how recursive data is different from hierarchical data.

Why is recursion is a problem for BusinessObjects? The language used “behind the curtain” is SQL, and SQL does not natively support recursion. Some database vendors offer extensions (for example the CONNECT BY PRIOR structure in Oracle) but these are not used by BusinessObjects.

How common is recursive data? It is certainly not unusual. Consider any of the following:

• Company organizational structure
  Object levels: President – Vice President – Director
  Object type: Person
• Inventory BOM (Bill of Materials)
  Object levels: Product – Assembly – Sub-Assembly – Component
  Object type: Inventory item
• Project Management
  Object levels: Project – Task – Sub-Task
  Object type: Project entry
• Multi-Level Marketing (MLM)
  Object levels: Founder – Recruit – Recruit Level 2
  Object type: Person

In each of the above examples the type of object (or node) type is the same at any level. For example, a company organization chart is made up of people. Some people are at different levels, and there are therefore relationships from one person to another. In order to show all of the relationships from the top of the company to the bottom (or the bottom to the top) I have to keep going back to the same table. That is recursion.

Because it’s easy to think about a company organizational structure I used that example for the rest of the presentation.

Note: The Motors database is used in the standard Universe Designer training course and will not be presented in its entirety in the download package for this presentation for copyright reasons. However, I will be providing the standard HR table and all of the modified versions used in this presentation.

Example of Recursive Data Using Prestige Motors HR

A picture will help at this point. Here is a screen shot from the Prestige Motors HR universe that I built for this presentation. Notice that there are two tables in the picture, but one is an alias of the other. In other words, I am really using the same table twice.

The table on the left is the Employees table. I have aliased the table and called it Manager. The two tables are joined using the link from EMPLOYEE.EMP_MGR_ID to Manager.EMP_ID. Since this is really the same table twice, this join defines the relationship from any particular person to their immediate manager. It’s a recursive relationship from a person to a person.

Notice that in this case I have defined the join as an outer (optional) join? That’s because the top person in the company does not have a manager, and the relationship would fail in that case. I want to ensure that I return every person and their manager… even if that person does not have a manager. Here is a sample of some of the data to help show why this is important.

I can review the relationships manually if I want. I can look at the data (shown above) and determine that Pickworth works for Noakes. Davis and Ferrerez also work for Noakes. How am I making that determination? Each of those three folks has a manager ID of 101, and 101 is the employee id for Noakes.

Who does Noakes work for? The EMP_MGR_ID column is blank (null) for Noakes, which implies that he is at the top of the company organization chart.

Another way to see where people fall in the organization chart is to look at their level. Here is output from a report that I eventually will want to generate from my recursive data. It is shown in the format of a tree, with each person showing up as a node on the tree.

Noakes is at level 1. Davis, Ferrerez, and Pickworth are all at level 2. But the tree does not stop there. I have employees at level 3 and level 4 as well.

Typical Recursion Questions

This brings me to the set of questions that I need to be able to answer with my recursive data. I need to know:

Who do I work for?
Who works for me?
Who works at my same level and shares the same manager?
Who is my manger’s manager? My manager’s manager’s manager?
What is the total salary of my direct reports (people who work directly for me)?
What is the total salary of my indirect reports (people who work for people who work for me)?

I am sure there are many more questions but these should serve as a starting point. Some of the questions only require one level of the hierarchy (who works for me, or who do I work for). Those are simple enough to answer, and in fact can be answered with the simple alias structure already shown in this post. But in order to traverse the tree for multiple levels I need a solution that is a but more robust.

Next Time

In the next post of this series I want to talk about some of the different challenges encountered when working with recursive data. Once I define the challenges I will be in a position to start talking about solutions. As a preview, here are the four types of hierarchies I will be talking about:

• Clean – a hierarchy with clean data, consistent node depths, and consistent node paths
• Unbalanced- a hierarchy with inconsistent node depths
• Ragged- a hierarchy with inconsistent node paths
• Lateral- a hierarchy with sideways node paths

If it is not clear what some of those mean, don’t be too concerned; I will be defining each with examples in the next post.

Finally, here is a preview of the various solutions I will talk about:

• Universe aliases
• Flattened structures (columns or snowflake tables)
• Ancestor / Descendant model
• Depth first tree traversal

And a few that I won’t:

• Oracle CONNECT BY PRIOR
• Stored procedures

Part II of this series will talk in more detail about each of the recursive challenges. After I detail the different challenges the next post will talk about the solutions. My plans for the final post for this series are to review the impact of each solution on the native drilling functionality and then to wrap things up.

Related Links

• Wikipedia on Inventory BOM in case you are unfamiliar with the concept of inventory data

This presentation covers slides 10 through 12 from my 2009 GBN presentation titled “Return of the Variables” which can be downloaded from my conference page.

Constant, Formula, or Variable?

A constant is a value that is never going to change. Constants are probably quite rare, to be honest. I could hard-code a sales tax rate into my report but it is far more likely that the tax rate will come from the database. Same for commission percentage or project deadline dates or any other data along those lines. In any case, they’re not really complex and they’re certainly not calculations so I will move on.

That leaves formulas and variables. How are they different? How are they the same?

Both can use the full range of report engine functions. Both can be used just about anywhere on the report. Is there any reason to select one technique over the other?

Yes, yes there is.

The Four Cs

Years ago when I wrote my first Variables presentation I came up with what I called “The Four Cs” to describe why variables are better than formulas. They are:

• Convenience
  A variable can be used with every report feature. I can’t build an Alerter using a formula, as shown here:

  

  I can’t rank on a formula. In Web Intelligence I get a list of query objects and a list of variables, but not formulas. The list probably goes on from there but that’s probably enough important features to prove the point. Variables can be used in places where formulas cannot be used.

• Clarity
  Simply put, a variable is a formula with a name. A name defines the purpose of the calculation. It is much easier to understand a complex calculation like this:

  =((100-[Discount Rate])/100)*[List Price]*[Qty Sold]

  … when that formula is also named “Sale Value After Discount” and saved as a variable.

• Complexity
  Sometimes it’s hard to figure out the syntax for a complex calculation. I will often break something down into simple steps and store the results as variables. Because variables can be reused (formulas cannot since they don’t have a name and therefore cannot be referenced) I can check my work at various points and make sure I am seeing the expected results. In another post related to this conference presentation I showed an alternative way to calculate the number of business days between two dates. If you review that post you will see that the formulas get quite complex indeed! You can bet that I didn’t come up with the final version without working carefully through each step. Using variables, of course.
• Consistency
  Once a variable is built it appears on the list of report “components” saved as part of the document. I have touched on this aspect of variables already in this post. Because variables appear on this list they are reusable throughout the report. Because I can reuse them throughout the report I can edit them in one place and have the changes propagate everywhere I use that particular calculation. If I spend the time and effort to create and test a complex calculation, it’s nice to know that it is reusable and will therefore provide consistent results throughout my document.

Wish List: Universe (or Universal) Variable Repository

At one point I had started writing a VBA script that would allow me to create report variables and check them into a “variable repository” that I stored in a Microsoft Access database. The idea was that once a variable was created I could then easily reuse it in other documents. This worked fine for desktop documents. Web Intelligence documents were not supported at all since the utility was based on VBA. It would be nice if we could see this feature supported directly in the universe framework.

Building Variables

Building variables in a document is fairly simple. I can click the proper button on the toolbar (shown below).

After clicking this button I am presented with the following screen that allows me to create my local calculation. (Note: this screen is from XI 3.0 and is different from what you will see in prior versions.)

This screen allows me to enter a name for my variable, set the qualification (dimension, detail, or measure), and access the full range of report functions.

There is another way that I can create a calculation; I can use the formula bar much like I can in a spreadsheet. Here I have activated the formula bar using the appropriate button and have clicked inside the edit area and started to create my formula.

Is this a problem?

Formula Challenges

For this demonstration I have created the following simple formula.

=[Revenue] / 100

I can use this formula in a report block. In fact I can copy it to multiple report blocks. The problem is, after I have done this I have three (or more) different copies of the same formula. If I click on the initial cell where I created the formula and edit it (perhaps I meant to type 1000 instead of 100 earlier) then only that instance of the formula is changed. The rest of the formulas are stored elsewhere in the document and are not affected by the edit.

This is a problem.

Converting a Formula to a Variable

If I made this mistake and want to convert my wayward formula into a variable I can do that. There is a button on the formula toolbar here:

When I click that button I am presented with the following dialog box that allows me to assign a name to my formula.

Once a formula has a name it becomes a variable and shows up in the document data tab.

Summary

This part of the presentation was probably considered to be fairly basic by most (if not all) of the folks in the room. However, I always repeat this same information every time I deliver a variables presentation. Why? Because of what happened years ago when I presented “Variables and More… Fourth Edition” at the conference in Las Vegas. I thought that by then everyone knew about the toolbar button that provided a way to convert a formula into a variable but it seems that was not the case. The very last question that I took from the audience was from a woman who wanted to know what to do with a formula she had created by mistake. I quickly created a formula and then showed how to convert it into a variable using the process I outlined here. I then found out just how many folks didn’t know about this technique, as it seemed the entire audience went “oooh, aaaah” and proceeded to give me the highest rated presentation marks that I have ever received.

It just goes to show that anything and everything that you know is probably worth sharing. It is very likely that there is somebody, somewhere that doesn’t know what you consider to be basic information. Share those simple tricks and they are much better off. Plus you earn some good karma.

So go ahead, answer a few questions on BOB. Start a blog. Share what you know.

This post covers slides 6 through 9 from my 2009 GBN presentation titled “Return of the Variables” which can be downloaded from my conference page.

Push it Back, Push it Back, Way Back!

I can’t help but hear some football cheerleaders calling out inspirational words to their team as I write that heading. But the reality is that the concept is quite appropriate for this discussion. There are quite a few advantages to putting calculation logic into your ETL (extract / transform / load) tool. For example…

• Build on core data
  ETL tools or other scripts working on core data have an advantage… they’re working on the core data. (That’s almost a recursive definition, which is another presentation. ) What I mean by that is there isn’t anything getting in the way between the process and the data. My scripts can do whatever they want because everything they need should be available. If it’s not immediately available I can build it in a temporary table and move on from there. ETL tools are very powerful in this regard.
• Procedural languages / scripts
  Even in a simple ETL environment where no formal tool is being used I can still write procedural scripts. I can write procedural SQL (PL/SQL) or even C scripts. The only limits are my imagination and the grammar of the selected tool.
• Consistency across all access paths
  This is a real key advantage of pushing calculations back to the ETL layer. Since this process is generally responsible for filling your data warehouse tables, and the calculations are done during that load, it means that any tool used to access that database inherits the results. It means I can use any query tool and still gain the benefits of the calculation results.
• Calculate and store once, retrieve many times
  This is my primary differentiator between putting a calculation in the universe versus doing it in the ETL. I was recently given a block of code and asked to create a predefined condition in the universe to handle the logic. The problem was it was extremely complex and included a number of case statements and outer join requirements… and it was going to impact the fact table. I pushed back and requested that the logic be placed into the ETL. The end result was I got a simple Boolean flag (zero or one value) on the fact table that was much easier to use. An added benefit? If the logic required to populate that field ever changed it could easily be done in the ETL.

Unfortunately there are other issues to consider before putting a calculation into the ETL.

• Change Management
  Not all of the aspects of doing calculations in the ETL are good. For example, most companies seem to have far stricter controls and change management processes around their ETL than they do for reports. Getting a change pushed through the ETL team can have a far wider impact and therefore can take longer and require more justification. Sometimes it is easier to keep a calculation closer to the report to avoid development delays.
• Complexity
  ETL scripts can already be quite complex. Adding new calculations might slow the scripts down and cause them to run beyond their available load window.
• Impact Analysis
  One of the primary advantages of including calculations in the ETL is that the results are shared by everyone. One of the disadvantages of including calculations in the ETL is that a change in that area will impact everyone as well. That means more teams to talk to in order to get a consensus that the change is appropriate and approval to start the process.

In my opinion, despite the potential for slower turn-around time on development requests and the need for greater impact analysis, complex calculations should be pushed back to the ETL if at all possible. This is especially true if the calculations impact join logic, affects security profiles, or needs to be performed on the fact where it will impact nearly every single query that is executed.

Using Universe Objects

The next possible location for calculations is the universe. There are quite a few advantages to putting something into the universe as opposed to having it done in the report. Such as…

• Build once – use many times
  Universe objects are designed to be reusable. Once an object is built it can be used / reused in any number of reports. This is one of the primary reasons we even build universes (that and providing the abstraction layer so business users don’t need to know technical terms.)
• Use full range of database functions
  There is a wide range of functions available inside each of the different report engines, but you can’t access the power of the database. I can use almost any function available from my database to build an object. And if there isn’t a function available to do what I want, I can build one.
• Ensure consistency from report to report
  For quite a long time Business Objects used the slogan “Single version of the truth” when talking about their products. This was based on the concept of reusable objects that I already covered above. Since every business user will be using the same object for Sales Revenue, they should all get the same result when they ask the same question.
• Updates automatically propagate
  Reports built on a universe will automatically get updates when they are published. This means if I discover a bug in one of my objects and fix it, every report that uses that object will get the updated code the next time the report is refreshed. This was a big advantage of the “classic” Business Objects tools over Crystal reports for many years. Any tool that requires a developer to manually write their own SQL code is subject to the same limitation.

That’s a nice list of advantages for universe objects. What about the disadvantages?

• Limited to information from a single universe
  Universe calculations cannot combine objects from two different universes. In fact it’s worse than that; you can’t combine objects from two different contexts in the same universe! This can be a very limiting factor depending on how complex your universe models are.
• Maintenance required by universe designer
  Getting universe work done should be less traumatic than changing the ETL, but it can still be a roadblock depending on the availability of your developer. Notice I said “developer” as it is very difficult to manage a process where more than one person works on the same universe at the same time.
• Some aggregation issues can be tricky
  Percentages and ratios and average calculations are all difficult to do in a universe. There is a new feature called “smart” or “database delegated” measures that started in XI 3.0 that helps some but it’s still an issue to be considered.
• Some functionality might be missing from the database
  It’s less likely today then when I wrote the very first Variables presentation back in 1997, but it might be that the functionality you want or need just isn’t available in your database. Rather than writing a custom database function it might be easier simply to create report calculations instead.

Report Structure Items

There are three basic options available in the report engines provided by Web Intelligence (and Desktop Intelligence as well if you’re using that tool.) They include constants, formulas, and variables. I will talk more about these three choices in the next post. For now I would like to consider the pros and cons of this option.

• Available on all platforms
  As mentioned both Desktop Intelligence and Web Intelligence offer this feature. Crystal goes even further and provides a language that includes scripting features. A report writer can pick the appropriate tool for the job without worrying about losing a calculation engine.
• Independent of SQL restrictions
  The grammar for local calculations comes from the report engine, not the SQL database. That means if you are using a database with limited functions (Sybase IQ comes to mind) you can still accomplish complex tasks in the report by using the available report functions instead. The first time I worked with Sybase IQ was years ago, and it didn’t even offer a way to retrieve the current system date from the host.
• Calculations based on document data
  When you refresh a query you download a microcube into your report. The calculations are then done on that smaller summarized dataset rather than applied to the entire rowset processed during the query process. It could be a performance benefit to be able to do the calculations locally.

That all sounds great, but there are disadvantages as well.

• Stored in a single document
  In the ETL and Universe section I talked about being able to reuse calculation results. I can do that with report variables too, but only in different reports (tabs) within the same document. If I want to use a complex formula in a new document I have to copy / paste or recreate from scratch.
• Require some level of technical expertise
  Most report writers can build simple calculations, especially operations found on the toolbar buttons like sum and count. However, getting complex calculations correct can be a struggle even for seasoned developers. It took a long time for the concept of calculation context to “click” for me, and even today it can sometimes be a challenge.
• Volume of data could impact performance
  Earlier I said that calculations at the report level might improve performance, and now I am saying that the volume could impact performance. Is this a contradiction? No, not really. What I said earlier was that if the report calculations are done on data already summarized by the database engine they should be fast. If the data is not summarized, meaning if the microcube present in the report has a large number of rows, then having additional calculations can certainly slow things down.

Summary

Wow, that was a lot of text. It’s easier to say all of this stuff than to write it down. Can you all do me a favor and just come to the conference next time so I don’t have to write so much?

In all seriousness, what I tried to do with these few slides in my presentation was to outline some of the general thoughts that go into deciding where to put a calculation. Is there a clear and obvious choice as to which to use? No, not really. I apologize if that’s what you were hoping for at this point. Each of these three areas (ETL, universe, report) has clear advantages. In general I prefer to push complex calculations as far back as possible. But if needed we have quite a few options available.

The next post in this series will focus on the different types of report calculations (specifically formulas and constants) and discuss which of those is better. In this case (unlike this post) there is a very clear choice. You can probably guess what it is… after all the presentation title was Return of the Variables.

How can I calculate the number of business days between two dates?

The easiest answer is to use a calendar table with a flag for business days because that takes care of everything quite easily. You can even mark holidays along with weekend days and make the results more useful.

But suppose you don’t have a calendar table. Suppose you don’t care about holidays, you simply want to count the number of Monday – Friday days between a range of dates. Can you do that?

The answer is coming if you read the rest of the post.

Note: This technique was shown in public on Monday at the GBN conference. I had written this blog post some time ago but waited to release it until after the presentation had been delivered. The presentation has been uploaded to my blog and is available for download from the conference page.

Web Intelligence Functions Required

This formula is going to use the following functions, so I will introduce and describe each of them a bit here.

• DaysBetween()
  Input values: two date values
  Output value: an integer number (no fractions) showing the number of days between the two dates
• DayNumberOfWeek()
  Input value: date
  Output value: Number from 1 to 7 denoting the day of week (1 = Monday, 7 = Sunday)
• Truncate()
  Input value: numeric expression or value, number of desired decimal places
  Output value: numeric value truncated to specified number of decimals, for example Truncate(3.14159, 2) = 3.14
  Truncate does not round, so Truncate(5.9; 0) returns 5 which is what is needed for this solution
• Mod()
  Input value: two numbers
  Output value: the remainder of the first value divided by the second
  Example: Mod(10; 2) = 0 and Mod(11; 2) = 1 and Mod(15; 7) = 1
• Substr()
  Input value: string, starting position, length
  Output value: part of the string
  Example: Substr(’1234′;2;1) = ‘2′
• ToNumber()
  Input value: string representation of a valid number
  Output value: number
  Example: ToNumber(’2′) = 2

Counting Weeks

One of the first steps in solving any sort of calculation is to look for shortcuts. Clearly there will be an infinite number of input values for my calculation so I need some way to avoid too many possible choices. Because of this I am going to start by counting the number of weeks between two days.

Take a look at the calendar on the right-side of my blog and try an experiment. It turns out that no matter which day of the week you start on, if you run for seven days you are guaranteed to get exactly two weekend dates. No more, no less, exactly two. Try it out and see. Start on a Sunday and count forward seven days and what do you get? Exactly one Sunday and one Saturday = two weekend days. Start on Monday and count forward seven days and the same thing happens. Start on Tuesday… on Friday, or even Saturday… and any range of seven days always has exactly two weekend dates included.

I can extend this to any multiple of seven days. If I have 14 days I get 4 weekend days. With 21 days I have 6 weekend days. If I multiply by five instead of two I get the number of weekdays in the range, therefore I am going to start my calculation using this pattern. Here is the start of the formula:

Truncate(DaysBetween([Start Date]; [End Date]) / 7 ; 0)

Let me break that down. First the DaysBetween() function is used to determine the number of days between the starting and ending dates for my range. Next I divide the number of days by seven which will result in a decimal result. For example, 15 / 7 = 2.14. Finally I use the Truncate() function to remove the decimal, which converts 2.14 to 2. That gives me the number of full weeks between my two days. Here’s a table showing results for some sample day ranges.

Based on the conclusion I made earlier, I can use the number of weeks and multiply by five to get the number of week days included in the range. In order to get that number I make one small modification to the formula presented above; I multiply the result by five. The result:

Truncate(DaysBetween([Start Date]; [End Date]) / 7 ; 0) * 5

All I have left to deal with are the leftover of days that don’t make up a full week. The decimal part of 2.14 is 0.14 which represents one extra day in my range. In order to know whether to count that day or not, I have to know the name (or alternatively the number) of the day my range starts on.

How Many Extra Days

There is a function called DayNumberOfWeek(). It numbers Monday as 1 and Sunday as 7 so I’m going to pretend that my calendar looks like this:

M T W T F S S
1 2 3 4 5 6 7

What I need to get next is the number of days that are not a full week. I used the Truncate() command earlier to get the number of full weeks. It removes the decimal part of the division result. What I need now is the decimal part, and the Mod() function can be used to get it. This function does a division and returns the remainder. The first argument will be the total number of days, and the second argument will be seven as there are seven days in a week. The result will be a number that ranges from zero (0) to six (6) because those are the only possible remainder values when dividing by sevent.

For example, Mod(15; 7) = 1. 15 / 7 is 2 with 1 left over, therefore 1 is the return value from the Mod() function. To apply that to my current problem: 15 days is made up of two full weeks and one extra day. Twenty days would be Mod(20; 7) which results in 6 remaining days. Mod(21; 7) is zero because there are exactly three weeks and no extra days.

Can I put these two pieces of information together? I can easily get the number of the day in the week, and I know how many extra days there are. I should be able to do some math…

Return of the Variables

Presentation Abstract

It’s time to pull out some variables again as we revisit a popular topic from past conferences. Report variables can provide a more creative, efficient, and effective means of completing the detailed analysis required for your reports. The focus of this presentation is building documents, using report functions, and reviewing variable tricks that can be used to solve reporting challenges. The presentation this year will focus primarily on the SAP BusinessObjects Web Intelligence product and include some of the newest features that have recently become available, but there will be some goodies for users of prior versions as well.

Universe Models for Recursive Data

Presentation Abstract

Recursive data can present a special challenge to SAP BusinessObjects developers because SQL is not natively able to process the relationships. This presentation will show several different methods for modeling recursive data along with the pros and cons of each. All of the methods shown have been used on real-world projects. Attendees will gain a better understanding of the complexities of dealing with inventory models, organizational hierarchies, and other types of recursive data.

As time allows I will be adding detailed blog posts for each of these presentations. I am cheating a bit this year. I have already written two blog posts that detail most of the “Variables” presentation:

• Using ForceMerge() To Fix Unbalanced Data Providers
  This post covers slides 13 through 18 from “Return of the Variables” and was originally released here on my blog back in September.
• Calculating Business Days Between Two Days Via Report Functions
  This post covers slides 19 through 33 of the same presentation and is already written. I need to make a few tweaks and will likely publish it on Friday. Until then the link above won’t seem to be valid, but it should work after the post is published.

That leaves only the initial portion of the presentation to write up, and I hope to have it done fairly soon. The detailed posts for the Designer presentation will take a bit longer.

Some highlights from my third day at the conference…

Webi 3.x Has Cool Stuff

I attended Sandy Brotje’s presentation called “What’s New for Me?” for my first session. I already knew quite a bit of what was new myself, but different people place emphasis on different features so I decided to see what she had to offer. I thought she did a great job of summarizing but also personalizing the new features that were important to her. I should send her a link to my blog post about losing an old friend because she didn’t know what the new measure icon was.

Explorer… Again?

I went to a presentation by Dallas Marks (check out his blog if you haven’t already) about Explorer. He did a short demo (using eFashion, imagine that! ) but then went into the back-end process showing how to install it. I left a bit early because I ended the day with…

Recursive Data in Universes is Hard

… my final presentation of the conference. I am fairly certain I submitted a far more imaginative title, but what came back was “Universe Models for Recursive Data” instead. It was a bit misleading because only one of the four solutions I showed can be done completely in the universe, and it’s the weakest of the four solutions. I had a good crowd for the last session on the last day of the conference, they laughed at my recursive jokes, and I gave out a bunch of BOB hats.

Good times.

So what’s next? There was a slide being shown as a backdrop during the keynote sessions that asked a question about whether there would be a Business Objects focused conference next year, and the answer provided was apparently a bit confusing. My understanding is that there will be a conference next year like this year (and prior years) but under the ASUG name. Since GBN is merging into ASUG it will no longer be the GBN Annual Conference but something similar with ASUG in front instead. I hope we can get more details out about this soon (like dates and the location) and will post here as soon as I hear anything concrete.

Computers Evolve During Stressful Times

The keynote this morning was delivered by Vicki Farrell, the Manager of Marketing Strategy from Hewlett Packard. She presented a couple of interesting points, one of which was that computer technology seems to get the biggest boost during times of economic stress. It’s at this sort of time that people really start looking to get more out of technology as a way to make up ground. She finished out her presentation with a picture of the garage where HP started. (I am sure there is a rule from HP that requires that )

Text Analytics Are Cool

I attended a presentation on text analytics that was interesting enough. I never seem to get anything that I can use in my job from these presentations, but the concept is one that I am quite interested in so I try to attend them. The presented talked about monitoring sentiment by scanning both internal project documents and external web sites. She did get a bit confused when someone asked about RSS; she thought that was some sort of sound file.

Semantic Layer Usability Testing Was Interesting

Unfortunately it was also covered by a non-disclosure agreement so I can’t talk about it.

Too Many Universe Design Sessions

I say this with my own universe design session coming up tomorrow, but I really think we had too many sessions this year. The technology hasn’t changed that much since last year (other than some improvements in SAP BW support in 3.1) and I saw a lot of the same stuff in the few designer sessions I did attend. My stuff is not the typical Designer material so I hope it will be well received by the folks that manage to stay for the last presentation slot on the last day of the conference.

SAP Mentors Rock!

One of the best sessions I attended was delivered by fellow SAP Mentor Ginger Gatling from the SAP Labs. She did a great job of presenting – in less than an hour – what SAP is, what they do, what they had for BI before they purchased Business Objects, how the product suite fits together now, and ended with tips on how people with different Business Objects skills could leverage them in the new environment. Yes, all in one hour. And she was entertaining and energetic while doing it too.

Catching Up With Old Friends is Fun

I have chatted with quite a few BOB members and other friends I have known for years through our common interest in Business Objects. That is one of the best parts of the conference for me every year.

Data Federator Combined With Semantic Layer

One of the things I heard last week was reiterated in public at the GBN conference today, that being that in XI 4.x (no scheduled release date, but could be 2010) the Data Federator product will be embedded directly into the semantic layer. What does this mean? Among other things, it means we can have multi-source universes.

Explorer (Accelerated) Is Still Hot

The keynote from John Schwarz featured yet another demo of the accelerated version of Explorer.

Xcelsius Is Still Hot

It’s hard to turn around without seeing another presentation for Xcelsius.

Old Stuff Still Works

My presentation had slides in it that I lifted from the very first Variables presentation in 1997. It still works. Steve Krandel updated a presentation from five years ago. It still works.

Text Analytics Should Be Hot

Several years ago Business Objects acquired a company that did really cool stuff in the unstructured data (text analytics) space. They should be getting more press; their systems have been integrated into Data Services now. I am planning on going to a text analytics presentation tomorrow.

I also signed up for a “usability session” on the new semantic layer tomorrow. It should be another good day.