/ 
DBIx-SQLCrosstab-1.17
River stage zero No dependents
/ DBIx::SQLCrosstab

NAME

DBIx::SQLCrosstab - creates a server-side cross tabulation from a database

SYNOPSIS

use DBIx::SQLCrosstab;
my $dbh=DBI->connect("dbi:driver:database"
    "user","password", {RaiseError=>1})
        or die "error in connection $DBI::errstr\n";

my $params = {
    dbh    => $dbh,
    op     => [ ['SUM', 'salary'] ], 
    from   => 'person INNER JOIN departments USING (dept_id)',
    rows   => [
                { col => 'country'},
              ],
    cols   => [
                {
                   id => 'dept',
                   value =>'department',
                   from =>'departments'
                },
                {
                    id => 'gender', from => 'person'
                }
              ]
};
my $xtab = DBIx::SQLCrosstab->new($params)
    or die "error in creation ($DBIx::SQLCrosstab::errstr)\n";

my $query = $xtab->get_query("#")
    or die "error in query building $DBIx::SQLCrosstab::errstr\n";

# use the query or let the module do the dirty job for you
my $recs = $xtab->get_recs
    or die "error in execution $DBIx::SQLCrosstab::errstr\n";

# do something with records, or use the child class 
# DBIx::SQLCrosstab::Format to produce well 
# formatted HTML or XML output
#

my $xtab = DBIx::SQLCrosstab::Format->new($params)
    or die "error in creation ($DBIx::SQLCrosstab::errstr)\n";
if ($xtab->get_query and $xtab->get_recs) { 
    print $xtab->as_html;
    my $xml_data = $xtab->as_xml;
}

DESCRIPTION

DBIx::SQLCrosstab produces a SQL query to interrogate a database and generate a cross-tabulation report. The amount of parameters needed to achieve the result is kept to a minimum. You need to indicate which columns and rows to cross and from which table(s) they should be taken. Acting on your info, DBIx::SQLCrosstab creates an appropriate query to get the desired result. Compared to spreadsheet based cross-tabulations, DBIx::SQLCrosstab has two distinct advantages, i.e. it keeps the query in the database work space, fully exploiting the engine capabilities, and does not limit the data extraction to one table.

See http://gmax.oltrelinux.com/cgi-bin/xtab.cgi for an interactive example.

Cross tabulation basics

Cross tabulations are statistical reports where the values from one or more given columns are used as column headers, and GROUP functions are applied to retrieve totals that apply to such values.

SELECT
   id, name, gender, dept
FROM
   person
   INNER JOIN depts ON (depts.dept_id=perspn.dept_id)

+----+--------+--------+-------+
| id | name   | gender | dept  |
+----+--------+--------+-------+
|  1 | John   | m      | pers  |
|  2 | Mario  | m      | pers  |
|  7 | Mary   | f      | pers  |
|  8 | Bill   | m      | pers  |
|  3 | Frank  | m      | sales |
|  5 | Susan  | f      | sales |
|  6 | Martin | m      | sales |
|  4 | Otto   | m      | dev   |
|  9 | June   | f      | dev   |
+----+--------+--------+-------+

A simple example will clarify the concept. Given the above raw data, a count of employees by dept and gender would look something like this:

+-------+----+----+-------+
| dept  | m  | f  | total |
+-------+----+----+-------+
| dev   |  1 |  1 |     2 |
| pers  |  3 |  1 |     4 |
| sales |  2 |  1 |     3 |
+-------+----+----+-------+

The query to create this result is

SELECT
    dept,
    COUNT(CASE WHEN gender = 'm' THEN id ELSE NULL END) as m,
    COUNT(CASE WHEN gender = 'f' THEN id ELSE NULL END) as f,
    COUNT(*) as total
FROM
    person
    INNER JOIN depts ON (person.dept_id = depts.dept_id)
GROUP BY
    dept

Although this query doesn't look easy, it is actually quite easy to create and the resulting data is straightforward. Creating the query requires advance knowledge of the values for the "gender" column, which can be as easy as m/f or as complex as male/female/unknown/undeclared/ former male/former female/pending (don't blame me. This is a "real" case!). Give the uncertainity, the method to get the column values id to issue a preparatory query

SELECT DISTINCT gender FROM person

Then we can use the resulting values to build the final query

my $query = "SELECT dept \n";
$query .=
        ",COUNT(CASE WHEN gender = '$_' THEN id ELSE NULL END) AS $_ \n"
          for   @$columns;
$query .= ",COUNT(*) as total \n"
          . "FROM person INNER JOIN depts \n"
          . "ON (person.dept_id=depts.dept_id) \n"
          . "GROUP BY dept\n";

If you have to do it once, you can just use the above idiom and you are done. But if you have several cases, and your cross-tab has more than one level, then you could put this module to good use. Notice that, to create this query, you needed also the knowledge of which column to test (gender) and to which column apply the GROUP function (id)

Multi-level cross tabulations

If single-level cross tables haven't worried you, multiple level tables should give you something to think. In addition to everything said before, multiple level crosstabs have:

  - query composition complexity. Each column is the combination
    of several conditions, one for each level;
  - column subtotals, to be inserted after the appropriate section;
  - row subtotals, to be inserted after the relevant rows;
  - explosive increase of column number. For a three-level crosstab
    where each level has three values you get 27 columns. If you
    include sub-totals, your number rises to 36. If you have just a few
    levels with five or six values , you may be counting rows by the 
    hundreds;    
  - visualization problems. While the result set from the DBMS
    is a simple matrix, the conceptual table has a visualization tree
    at the top (for columns) and a visualization tree at the left
    side (for rows).

+----+----+--------------------+--------------------+--+
| A  | B  |        C1          |       C2           |  |  1
|    |    +--------------------+--------------------+  |  
|    |    |   D1   |   D2   |  |   D1   |   D2   |  |  |  2
|    |    +--------+--------|  +--------+--------+  |  |  
|    |    |E1 E2 T |E1 E2 T |T |E1 E2 T |E1 E2 T |T |T |  3
+----+----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| A1 | B1 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  4
|    |----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|    | B2 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  5
|    |----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|    |  T |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  6
+----+----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| A2 | B1 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  7
|    |----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|    | B2 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  8
|    |----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|    |  T |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  9
+----+----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| T  | -- |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | 10
+----+----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 a    b    c  d  e  f  g  h  i  g  k  l  m  n  o  p  q

Some definitions

columns headers               : 1-3
column headers 1st level      : 1
column headers 2nd level      : 2
column headers 3rd level      : 3

row headers                   : a, b
row header 1st level          : a
row header 2nd level          : b

row sub totals                : 6, 9
row total                     : 10
column sub totals             : e, h, i, l, o, p
column total                  : q

Column headers choice strategies

The easiest way of choosing columns is to tell DBIx::SQLCrosstab to get the values from a given column and let it extract them and combine the values from the various levels to make the appropriate conditions. Sometimes this is not desirable. For instance, if your column values come from the main dataset, the one that will be used for the crosstab, you are querying the database twice with two possibly expensive queries. Sometimes you can't help it, but there are a few workarounds.

If uou know the values in advance, you can pass them to the SQLCrosstab object, saving one query. This is when the values come from a constraint, for example. You may have a "grade" column and you know that the values can only be "A" to "F", or a "game result" column with values "1", "2", "x", "suspended", "camncelled". Or you can run the full query once, and when you are satisfied that the column values are the ones you know they should be, you pass the values for the subsequent calls.

The list option is also useful when you only want to make a crosstab for a given set of values, rather than having a mammoth result table with values you don't need.

Hidden JOINs

The normal case, in a well normalized database, should be to get the column values from a lookup table. If such table was created dynamically, so that it only contains values referred from the main table, then there is no problem. If, on the contrary, the lookup table was pre-loaded with all possible values for a given column, you may come out with a huge number of values, of which only a few were used. In this case, you need to run the query with a JOIN to the main table, to exclude the unused values.

When yoo use a lookup table, though, you can optimize the main query, by removing a JOIN that you have already used in the preparatory query. Let's see an example.

You have the table "person", which includes "dept_id", a foreign key referencing the table "depts". If you pass SQLCrosstab a column description including a {value} key, it will get from the lookup table both {id} and {value}, so that, instead of creating a main query with columns like

,COUNT(CASE WHEN dept = 'pers' THEN id ELSE NULL END) AS 'pers'

It will create this:

,COUNT(CASE WHEN dept_id = '1' THEN id ELSE NULL END) AS 'pers'

 or (depending on the parameters you passed) this:

,COUNT(CASE WHEN dept_id = '1' THEN id ELSE NULL END) AS fld001 -- pers

The difference is that in the first case your final query needs a JOIN to depts, while in the second case it won't need it. Therefore the final query, the expensive one, will be much faster. The reasoning is, once you went through a lookup table to get the distinct values, you should not use that table again in the main query.

Class methods

new

Create a new DBIx::SQLCrosstab object.

my $xtab = DBIx::SQLCrosstab->new($params)
    or die "creation error $DBIx::SQLCrosstab::errstr\n"

$params is a hash reference containing at least the following parameters:

dbh     
        either a valid database handler (DBI::db) or a hash reference
        with the appropriate parameters to create one

        dbh =>  {
                    dsn      => "dbi:driver:database",
                    user     => "username",
                    password => "secretpwd",
                    params   => {RaiseError => 1}
                }

op      
        the operation to perform (SUM, COUNT, AVG, MIN, MAX, STD,
        VAR, provided that your DBMS supports them)
        and the column to summarize. It must be an array reference,
        with each item a pair of operation/column.
        E.g.: 
        op => [ [ 'COUNT', 'id'], ['SUM', 'salary'] ],
    
        *** WARNING ***
        Use of this parameter as a scalar is still supported
        but it is DEPRECATED.


op_col  
        The column on which to perform the operation
        *** DEPRECATED ***
        Use {op} as an array reference instead.

from    
        Where to get the data. It could be as short as
        a table name or as long as a comlex FROM statement
        including INNER and OUTER JOINs. The syntax is not 
        checked. It must be accepted by the DBMS you are 
        using underneath.

rows    
        a reference to an array of hashes, each
        defining one header for a crosstab row level.
        The only mandatory key is  
            {col}  identifying the column name
        Optionally, you can add an {alias} key, to be used
        with the AS keyword. 

cols    
        a reference to an array of hashes, each defining
        one header for a cross tab column level.
        Two keys are mandatory
            {id}      the column name
            {from}    where to get it from.
                      If the {group} option is
                      used, the other columns can have
                      a value of "1" instead.

        Optionally, the following keys can be added

            {group}   If this option is set, then all the
                      columns are queried at once, with the
                      {from} statement of the first column
                      definition. 

            {alias}   an alias for the column name. Useful
                      for calculated fields.
            {value}   an additional column, related to {id}
                      whose values you want to use instead of
                      {id} as column headers. See below "The
                      hidden join" for more explanation.
            {col_list}
                     Is a referenece to an array of values
                     that will be used as column headers, instead
                     of querying the database. If you know the
                     values in advance, or if you want to use only
                     a few known ones, then you can specify them
                     in this list. Each element in col_list must be
                     a hash reference with at least an {id} key. A 
                     {value} key is optional.
            {exclude_value}
                     Is a reference to an array of values to exclude
                     from the headers. Unlike the general option
                     "col_exclude", this option will remove all the
                     combinations containing the given values.

            {where}   to limit the column to get
            {orderby} to order the columns in a different
                      way.


The following parameters are optional.

where   
        a WHERE clause that will be added to the resulting query
        to limit the amount of data to fetch.

having  
        Same as WHERE, but applies to the grouped values

add_op  
        either a scalar or an array reference containing one or
        more functions to be used in addition to the main 'op'.
        For example, if 'op' is 'COUNT', you may set add_op to
        ['SUM', 'AVG'] and the crosstab engine will produce 
        a table having the count, sum and average of the 
        value in 'op_col'.
        *** DEPRECATED *** Use {op} as an array reference instead.

title   
        A title for the crosstab. Will be used for HTML and XML
        creation

remove_if_null
remove_if_zero
        Remove from the record set all the columns where all
        values are respectively NULL or zero. Notice that there 
        is a difference between a column with all zeroes and a 
        column with all NULLs.
        All zeroes with a SUM means that all the values were 0,
        while all NULLs means that no records matching the given 
        criteria were met.
        However, it also depends on the DBMS. According to ANSI
        specifications, SUM/AVG(NULL) should return NULL, while
        COUNT(NULL) should return 0. Rather than assuming
        strict compliance, I leave you the choice.

col_exclude
        Is a reference to an array of columns to be excluded from
        the query. The values must be complete column names.
        To know the column names, you can use the "add_real_names"
        option and then the get_query method.        

add_real_names
        Add the real column names as comments to the query text.
        In order to avoid conflicts with the database, the default
        behavior is to create fake column names (fld001, fld002, etc)
        that will  be later replaced. 
        This feature may cause problems with the database engines
        that don't react well to embedded comments.

use_real_names
        use the real column values as column names. This may be a
        problem if the column value contains characters that are not
        allowed in column names. Even though the names are properly
        quoted, it id not 100% safe.

row_total
row_sub_total
        If activated, adds a total row at the end of the result set
        or the total rows at the end of each row level. Your DBMS
        must support the SQL UNION keyword for this option to work.

        ********
        CAVEAT!
        ********

        Be aware that these two options will double the server load
        for each row level beyond 1, plus one additional query for
        the grand total.
        The meaning of this warning is that the query generated
        by DBIx::SQLCrosstab will contain one UNION query with a
        different GROUP BY clause for each row level. The grand
        total is a UNION query without GROUP BY clause. If your
        dataset is several million records large, you may consider
        skipping these options and perform subtotals and grand 
        total in the client.
        For less than one million records, any decent database
        engine should be able to execute the query in an acceptable
        timeframe.

col_total
col_sub_total
        If activated, add a total column at the end of the result set
        or the total columns at the end of each column level. 

RaiseError
        If actviated, makes all errors fatal. Normally, errors are 
        trapped and recorded in $DBIx::SQLCrosstab. RaiseError will 
        raise an exception instead.

PrintError
        If activated, will issue a warning with the message that 
        caused the exception, but won't die.

************************************************
The following options only apply when creating a 
DBIx::SQLCrosstab::Format object.
************************************************

commify
        Used for HTML and XML output. If true, will insert commas
        as thousand separators in all recordset numbers.

complete_html_page
        Returns HTML header and end tags, so that the resulting
        text is a complete HTML page.

only_html_header
        Returns only the header part of the table, without records.
        Useful to create templates.

add_colors
        If true, default colors are applied to the resulting
        table.
        text    => "#009900", # green
        number  => "#FF0000", # red
        header  => "#0000FF", # blue
        footer  => "#000099", # darkblue

text_color
number_color
header_color
footer_color
        Change the default colors to custom ones  

 table_border       
 table_cellspacing 
 table_cellpadding 
        Change the settings for HTML table borders. Defaults are:
        border      => 1
        cellspacing => 0
        cellpadding => 2
set_param

Allows to set one or more parameters that you couldn't pass with the constructor.

$xtab->set_param( cols => [ { id => 'dept', from => 'departments' } ]  )
     or die "error setting parameter: DBIx::SQLCrosstab::errstr\n";

$xtab->set_param( 
                     remove_if_null => 1,
                     remove_if_zero => 1,
                     title          => 'Some nice number crunching'
                 )
     or die "error setting parameter: DBIx::SQLCrosstab::errstr\n";

You can use this method together with a dummy constructor call:

my $xtab = DBIx::SQLCrosstab->new ('STUB')
    or die "can't create ($DBIx::SQLCrosstab::errstr)\n";

$xtab->set_param( 
                  dbh    => $dbh,
                  op     => 'SUM',
                  op_col => 'amount',
                  cols   => $mycolumns,
                  rows   => $myrows,
                  from   => 'mytable'
                  )
    or die "error setting parameter: DBIx::SQLCrosstab::errstr\n";
get_params

Returns a string containing te parameters to replicate the current DBIx::SQLCrosstab object. The data is represented as Perl code, and it can be evaluated as such. The variable's name is 'params'. It does not include the 'dbh' parameter.

my $params = $xtab->get_params
    or warn "can't get params ($DBIx::SQLCrosstab::errstr)";
save_params

Saves the parameters necessary to rebuild the current object to a given file. This function stores what is returned by get_params into a text file. Notice that the 'dbh' option is not saved.

unless ($xtab->save_params('myparams.pl')
    die "can't save current params ($DBIx::SQLCrosstab::errstr)";
load_params

Loads previously saved parameters into the current object. Remember that 'dbh' is not restored, and must be set separately with set_param().

my $xtab = DBIx::SQLCrosstab->new('stub')
    or die "$DBIx::SQLCrosstab::errstr";
$xtab->load_params('myparams.pl')
    or die "$DBIx::SQLCrosstab::errstr";
$xtab->set_param( dbh => $dbh )
    or die "$DBIx::SQLCrosstab::errstr";
get_query

Returns the query to get the final cross-tabulation, or undef in case of errors. Check $DBIx::SQLCrosstab::errstr for the reason. You may optionally pass a parameter for the character to be used as separator between column names. The default is a pound sign ('#'). If the separator character is present in any of the column values (i.e. the values from a candidate column header), the engine will try in sequence '#', '/', '-', '=', doubling them if necessary, and eventually giving up only if all these characters are present in any column values. If this happens, then you need to pass an appropriate character, or group of charecters that you are reasonably sure doesn't recur in column values.

get_recs

Executes the query and returns the recordset as an arrayref of array references, or undef on failure. After this method is called, several attributes become available: - recs the whole recordset - NAME an arrayref with the list of column names - LENGTH an arrayref with the maximum size of each column - NUM_OF_FIELDS an integer with the number of felds in the result set

Class attributes

There are attributes that are available for external consumption. Like the DBI, these attributes become available after a given event.

{NAME}

This attribute returns the raw column names for the recordset as an array reference. Even if {use_real_names} was not defined, this attribute returns the real names rather than fld001, fld002, and so on. It is available after get_recs() was called.

my $fnames = $xtab->{NAMES};
print "$_\n" for @{$fnames};
{recs}

This attribute contains the raw recordset as returned from the database. Available after get_recs().

{NUM_OF_FIELDS}

The number of fields in the recordset. Available after get_recs().

{LENGTH}

Contains an array reference to the maximum lengths of each column. The length is calculated taking into account the length of the column name and the length of all values in that column. Available after get_recs().

DEPENDENCIES

DBI
a DBD driver
Tree::DAG_Node

EXPORT

None by default.

AUTHOR

Giuseppe Maxia (<gmax_at_cpan.org>)

SEE ALSO

DBI

An article at OnLamp, "Generating Database Server-Side Cross Tabulations" (http://www.onlamp.com/pub/a/onlamp/2003/12/04/crosstabs.html) and one at PerlMonks, "SQL Crosstab, a hell of a DBI idiom" (http://www.perlmonks.org/index.pl?node_id=313934).

COPYRIGHT

Copyright 2003 by Giuseppe Maxia (<gmax_at_cpan.org>)

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.