Transportation Hypercubes 
Author Message
 Transportation Hypercubes

I've noticed that OLAP server vendors list very few transportation
companies on their client lists.  As a transportation industry consultant
I have heretofore seen this as a business opportunity; however, as I have
come to understand the technical limitations of OLAP technology more
clearly I'm beginning to worry that there may be a fundamental reason why
there aren't more implementations of OLAP technology in transportation
industries.  

The dilemna that I see stems from the dichotomy between the service that
customers request, transportation of people or goods from point A to Point
B (a journey), and the means by which transportation companies physically
deliver this service, which may be on a variety of different departure
times and routings (legs or segments).  In order to model all of the
potential permutations of city pairs and routings, the single logical
"product/service"  or "city pair" dimension requires up to 6 separate
physical dimensions in order to deliver all of the required information
content.  Using a passenger airline as an example, the following
dimensions would be required:  

1 Journey Origin.  This is the point where the passenger commenced his or
her journey.  A typical query requiring this dimension might be posed by a
salesman in Minneapolis who wants to know the breakdown of passengers
originating their trips in Mineapolis by travel agency in order to
identify the biggest agencies in town.  

2. Journey Destination.  This is the point where the passenger's journey
ends.  A typical query requiring this dimension might be posed by an
advertising exec who wants to know the breakdown of all passengers
destined for Honolulu by journey origin city so that he can decide where
to advertise Hawaii vacations.  

3. Leg/Segment Origin.  This is the departure point of a nonstop flight.
A typical query requiring this dimension might be posed by an airline
scheduler who wants to know the breakdown of passengers boarding flights
in Duluth by journey destination so that he knows what flight connections
are most important at a hub connecting complex.  

4.  Leg/Segment Destination.  This is the arrival airport of a nonstop
flight.  A typical query requiring this dimension might be posed by an
airline scheduler who wants to know the breakdown of passengers deplaning
flights in Duluth by journey origin so that he knows what flight
connections are most important at a hub connecting complex.  

5.  Flight/Departure Time.  This is the identifier of a particular flight
operation, eg., flight 100 at 0900.  A flight can traverse several
legs/segments and a journey can traverse several flight numbers (and
legs/segments).  A typical query requiring this dimension might be posed
by an airline scheduler who wants to know the breakdown of passengers
deplaning flights in Duluth by journey origin *and flight number* so that
he knows what specific flight connections are most important in each hub
connecting complex.  

6.  Hub/Region/Entity.  An operational region rollup, such as Minneapolis
hub, domestic entity, etc.  Flight numbers and journeys can traverse
multiple hubs/regions.  A typical query requiring this dimension might be
posed by an international marketing manager who wants to track the volume
of passengers on international flights by journey destination over time to
monitor the effects of currency fluctuations and political disturbances.  

To these dimensions add "time" and "measures" and you're at 8 dimensions
right out of the blocks.  Start adding dimensions for "customer",
"distribution channel", and "rate program" and you end up with very large
hypercube very quickly (especially with 40,000 travel agency members in
the distribution channel dimension).  I have one logical hypercube design
for a summarized airline ticket database that would require a total of 15
dimensions.  If it could be built, any airline in the world would give its
eye teeth to have it.  However, in a worst case scenario for a very large
airline, this hypercube's cell count would be 6 x 10 to the 33rd power!  I
don't even know what this number would be called!  Also, this hypercube
would probably be about 99.9% sparse.  

Has anyone else examined this problem, and, if so, have you found a more
elegant or practical solution?  

Steve Elkins



Fri, 30 Jan 1998 03:00:00 GMT
 Transportation Hypercubes

Steve Elkins asks about the use of OLAP intransportation
companies.

I agree that the immense sparsity of these databases blows most
commercial OLAP products apart with the bigger systems.  But, the
big airlines have their famous yield management systems (started
by American Airlines with Sabre, I think) which deals with this
problem.  They sell older versions to smaller airlines and other
transportation industries.  For example, the French railways
(SNCF) has a fairly new system called Socrates based on airline
technology.

These systems generate more net yield than the actual business of
flying planes around.  One case study I did of Emery Worldwide
uses similar ideas on a snaller scale to optimize prices.

--
Nigel Pendse,  OLAP Solutions



Sat, 31 Jan 1998 03:00:00 GMT
 Transportation Hypercubes

Quote:


>Subject: Transportation Hypercubes
>Date: 14 Aug 1995 16:29:21 -0400

Steve,

In the past three years I gained quite some experience on datawarehousing/OLAP
like requirements in a factory for discrete products. Every product was
uniquely identified and the factory wide information system contained data
of the product movements of every indvidual product plus the results of all
sorts of quantitive and qualititive tests on these products (production
database)..

Users had a need for many different overviews, all on aggregated data (e.g.
a pareto of the amount of products of every different type that went from A to
B, today, and many more). We looked into using OLAP tools and chose an
approach in which we use a regular RDBMS, partly because we got too many
dimensions, like you do.

In my opinion there are several things you can do in a case like that:

1-
Use several 'hypercubes'. Divide (or distribute) the data over the hypercubes,
such that you don't need to access 2 cubes for one overview. Of course this
will limit your query-possibilities, but some combinations (of one variable
against the other)  perhaps are not very useful anyway (for specific groups of
users).

2-
more or less simular to -1-. We chose a solution in which we use
regular RDBMS tables filled with data from the 'production' database. The
tables are designed such that a single table can answer many requests for
overviews. Using client software that allows easy implementation of new
requests, in fact we just built many standard overviews. Of course users are
allowed to input selection profiles and overview characteristics.

I think we were able to use the 2nd approach because our users in fact didn't
need the full flexibility of an OLAP tool, plus, using the right client
software overviews can be made quite easy if you have defined the right
tables in the database (Adding new tables to the database and filling them
should therefore not be a very elaborative job.)  An advantage of this
approach that we are able to select from many products for our client or
server software. We might have some more programming effort.  

Sometimes I am wondering if this might be the case in many other business
environments as well. Is it really necessary to offer the full flexibility
(cutting planes in the hypercube) of OLAP tools? Or are they very happy if
they just have a lot of different overviews, and a possibility to order more?

Lucas



Mon, 02 Feb 1998 03:00:00 GMT
 Transportation Hypercubes
Steve,

This posting is not written on my own pc under my own account.

Here are some thoughts on your transportation case you
described. I do not have a clearcut solution (there never
is in modelling), but maybe some clues that might be helpful.

The case you describe is very similar to personnel management
information. One could easily want to analyze maybe twenty
attributes (in relation foreign keys) of an employee. Each
of the foreign keys forms a dimension. The difference with
transportation is the personnel information usually have
lots and lots of dimensions, but all of them are probably
shorter in length than your dimensions (f.i. 40.000 travel
agencies).

First of all, multidimensional modelling is more than
"denormalizing" relational multi-key data. For instance,
on higher levels of aggregation "Journey origin" and
"Journey" destination might show a relatively dense populated
many-to-many relationship, on lower level sparsity grows
and the relationships gradually transforms into a one-to-one
relationship.

In multicube environments you could create a level split,
where the cube "stops" at an aggregate level and another
cube starts, but the two dimensions will be replaced by
a single one, f.i. called "route".

In general, analyze relationships from level to level with
every other level in every other dimension to establish
reasonable many-to-many relationships.

Furthermore, why make it one big cube? In a multicube
environment you could create one or more 3d or 4d cubes
where you combine the coherent dimensions. This is how we
have dealt with the personnel information module in our
EIS application.

You could also try to create any combination of two dimensions
on the spot, filling it with one large relational table.
You would have to roll up the data on the spot as well
or create aggregate tables. This is probably a solution needing
a lot of fast hardware.

Please let me know what you think...

Frank A. Buytendijk


WWW :   http://www.xs4all.nl/~fab/olapkeep.html

Views expressed in this mail are my own and not necessarily of
my employer's.



Tue, 03 Feb 1998 03:00:00 GMT
 Transportation Hypercubes
Arbor has announced a couple of partnerships this year in which third
party vendor tools such as Cognos Powerplay and Andyne Pablo can access
Essbase.

I am looking for anyone with actual experience using one of these tools
to access Essbase.  I am expecially interested in real life
success/failure examples of working with this configuration.

Thanks
Keith Couch



Tue, 03 Feb 1998 03:00:00 GMT
 Transportation Hypercubes

Quote:

> Arbor has announced a couple of partnerships this year in which third
> party vendor tools such as Cognos Powerplay and Andyne Pablo can access
> Essbase.

> I am looking for anyone with actual experience using one of these tools
> to access Essbase.  I am expecially interested in real life
> success/failure examples of working with this configuration.

> Thanks
> Keith Couch


If you would be so kind as to give me a call, or send me a note with your
telephone and company information, I would be happy to put you in touch
with some reference sites that are using both products working with
Essbase.  

Regards,

- Dan

Home:                                           Office:
Daniel Druker                                   Daniel Druker
14190 Wild Plum Lane                            Strategic Alliances
Los Altos Hills, CA, 94022                      Arbor Software Corporation

                                                Sunnyvale, CA, 94089
                                                (408) 727-5800 x4027



Wed, 04 Feb 1998 03:00:00 GMT
 Transportation Hypercubes
: Arbor has announced a couple of partnerships this year in which third
: party vendor tools such as Cognos Powerplay and Andyne Pablo can access
: Essbase.

If you call either the local Cognos office or Arbor I'm sure they can
help. Drop me a note if you need more info. regards.
--
Nigel Campbell            Voice: (613) 738-1338 ext 3016   P.O. Box 9707,Stn.T
Business Intelligence       FAX: (613) 738-0002            3755 Riverside Dr.

                      URL: http://www.cognos.com           CANADA  



Thu, 05 Feb 1998 03:00:00 GMT
 
 [ 7 post ] 

 Relevant Pages 

1. IQship-transportation management system

2. Data Transportation

3. +++US-TN-Nashville-database-ORACLE-transportation-OAO

4. Transportation Control Measure Database-Proposals Solicited

5. recordset as means of transportation possible?

6. Transportation Control Measure Database-Proposals Solicited (Correction)

7. JSSST ISOTAS '93 --- Transportation and Accommodation Guide

8. build hypercubes with more than 7 dimensions?

9. EXCEL add-in for managing hypercubes

10. XML standard format for hypercube exchange

11. 3-way TANGRAM - hypercube management tool.

12. 3-way TANGRAM - hypercube management tool.


 
Powered by phpBB® Forum Software