This documentation page assumes that you already have a SeekTable account. You can create free account by signing up.

Pivot table by SQL database

You can configure 'live' connection to your SQL database and use it as a data source for pivot table (chart, flat table) reports. In this case data is not imported: SeekTable executes aggregate query (GROUP BY) to retrieve the necessary data for the report.

There are no any limitations on the dataset size, but your database should be able to execute aggregate queries fast enough (in seconds); in case of relatively small datasets - up to millions of rows - almost any OLTP database can do that. For large tables dataset size can be limited with database-level filtering by indexed columns (see parameters setup section below), or by using pre-aggregated tables (or materialized views). For real-time reporting by really big data (billions of rows) specialized analytical databases may be used:

How to configure SQL data source

  1. Click on "Connect to Database" item at "Cubes" view, or just open this link (ensure that you're logged in).
  2. Select "SQL-compatible database" in Data Source Type selector: SQL database connection settings
  3. In Cube Name enter short title that describes this data source.
  4. Choose your database in Database Connector and configure its Connection String:
  5. Specify Select Query: this is SQL SELECT command that determines possible columns for dimensions or measures. In simplest case this might be something like:
    SELECT * FROM some_table_or_dataview
    You can specify complex SQL query if needed (with JOINs, WHERE).
  6. Keep Infer dimensions and measures by columns checked to determine dimensions and measures automatically by the first N rows. You can modify suggested configuration later.
  7. Click on "Save" button.

If everything is fine you should see a new cube dashboard with the list of available dimensions and measures.

In case of connection error you'll see an orange box with an error message; you may click on "Edit Configuration" and apply necessary changes.

Dimensions setup

SQL cube dimensions setup
Type
Field: dimension name refers to table column or result of SQL expression (can be provided as first "Parameter").
Expression: dimension is defined as calculated field with custom formula that uses another dimensions as arguments (formula and arguments should be specified in "Parameters").
Name
Unique dimension identifier. For Type=Field this is column name specifier (possibly with table alias prefix).
Label
User-friendly dimension title (optional).
Format
Custom format string (.NET String.Format) for dimension values (optional). Examples:
  • for number values: ${0:0.##} → $10.25
  • for date values: {0:yyyy-MM-dd} → 2017-05-25
Parameters
For Type=Field: you can specify custom SQL expression for this dimension, or dimension ID column for "Conditional JOIN rule".
For Type=Expression: you can specify custom formula (1-st parameter) and dimension names for the arguments (2-nd, 3-rd etc parameter).

Measures setup

SQL cube measures setup
Type
Count: the number of aggregated rows.
Sum: the total sum of a numeric column.
Average: the average value of a numeric column.
Min: the minimal value of a column.
Max: the maximum value of a column.
FirstValue: custom SQL aggregate expression like 'COUNT(DISTINCT some_column)'.
Expression: measure defined as calculated field.
Name
Explicit unique measure identifier. You can leave it blank (for any measure types except "Expression") to generate the name automatically.
Label
User-friendly measure caption (optional).
Format
Custom format string (.NET String.Format) for measure values (optional). Example:
  • ${0:0.##} → $10.25
Parameters
For Type=Count: no parameters needed.
For Type=Sum/Average/Min/Max: column name to aggregate.
For Type=FirstValue: custom database-level SQL aggregate expression.
For Type=Expression: first parameter is an expression, and next parameters are names of measures used as arguments in the expression.

Report parameters setup

Report parameters are used when you need to declare user-defined variable and use it in the SQL template as you want; typical usage is SQL query filtering with WHERE conditions.

SQL cube parameters setup
Name
Unique (for cube) parameter identifier.
Label
User-friendly parameter caption for UI (optional).
Data Type
String: text-based value.
Int32: 32-bit integer (max value is 2,147,483,647).
Int64: 64-bit integer (max value is 9,223,372,036,854,775,807).
Decimal: Fixed-point number with max 28 significant digits. Decimal point is '.' character.
DateTime: date or datetime value (in case of date this will be datetime value with 0:00:00 time). Date value should be specified as string in YYYY-MM-DD format.
Boolean: accepts only 'True' or 'False' value.
Multiple Values
If checked parameter can accept several values (as array, in UI user can enter them as comma-separated string). Multivalue parameter can be used only with SQL IN condition.
Default Value
Defines default value of this parameter. Empty means 'not defined'.

When parameter is defined it can be used in Select Query as following:

SELECT * FROM orders o WHERE 1=1 @orderDate[ and o.orderDate>={0} ]

Parameter syntax notes:

@
identifies that this is a placeholder for the parameter
orderDate
parameter Name
[ ]
expression between square brackets is added to SQL command when parameter is defined.
{0}
placeholder for the parameter value. Value is provided to database as typed command parameter; SQL injections are impossible. This also means that parameter value cannot contain SQL expression or used to provide part of SQL command.

In case of multivalue parameter:

SELECT * FROM orders WHERE 1=1 @countries[ and o.country IN ({0}) ]

Efficient lookups resolution

Data in SQL databases often is organized with star schema: when main facts table contains only numbers and foreign keys, and actual values are stored separately in dimension tables. To resolve these lookups these dimension tables should be joined in the cube's Select Query, for example:

SELECT o.*, c.name as country_name FROM order o
LEFT JOIN countries c ON (c.country_id=o.country_id)

This works fine if you have relatively small number of rows in the 'orders' table and everything works very fast. But what if you have millions of rows?.. Every JOIN adds signficant overhead and excessive database load.

Fortunately, solution exists: JOINs may be applied after facts table aggregation, and only when they are needed for the concrete report. This is possible with Conditional JOINs for lookups setup, for example: