Giuseppe Maxia > DBIx-SQLCrosstab-1.17 > DBIx::SQLCrosstab

Download:
DBIx-SQLCrosstab-1.17.tar.gz

Dependencies

Annotate this POD

CPAN RT

New  1
Open  1
View/Report Bugs
Module Version: 1.17   Source  

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.

syntax highlighting: