Understanding Tables and Pipes

Overview

In an analysis model, data is held in a table which consists of:

  • Columns - these are the attributes.
  • Rows - these are the data records.

Tables can be connected with pipes, which are used to send data from one table to another. Pipes also connect other types of modelling objects, such as a datasource that connects to a database or file exporter. Usually, a pipe has default settings, this means it passes all attributes and records onto the next object. However, you can use the pipe properties to control which attributes and records from the input object you want to pass through.

For example, here we have data being imported from a database using a datasource and data collector, the data is held in its original form in a table before being passed onto a second table where is it enriched. It is possible to add filters on any of the pipes to remove records, such as a business being found with no name or a transaction being older than a specified date.


To move data between modelling objects we must run an analysis model. PhixFlow then uses the information in each object's properties to process the data. Because with each analysis run the data in a table can change, PhixFlow keeps the dataset for each run. If there is a problem in the analysis run, you can delete a dataset(s) by reverting back to the selected recordset; see Rollback RecordsetsYou can also copy or move data from a dataset; see Copying or Moving Table Data.

Viewing Data in a Table is possible via views, the default view shows data in a grid. You can also create your own views such as graphs and charts. View properties have lots of options to control which attributes are included in the view, which records are shown and how to sort the records.

Running Analysis

Running analysis is where PhixFlow evaluates your configuration and uses this information to processes your data. Analysis is started from a table, and then all modelling objects which procede the table will process the data in order. It should be noted that:

  • Not all modelling objects will appear or need to be in the same analysis model. This means running analysis can run analysis on more modelling objects than appear in your analysis model.
  • Some modelling objects can be set to static, these will not run, unless analysis is run directly on them and PhixFlow will not run any items which precede a static item. This is useful where there is information which you do not need to reprocess every time you run analysis, or want to run it on a different schedule.

Solution

  1. To Run Analysis, hover over the  Table and click  Run Analysis:
  2. To Run Analysis automatically on a timed schedule, see Task Plans.

Static Objects

There are several reasons you may wish to set a modelling object to be static, including:

  • You have information which does not need to be updated using an analysis model, such as country ISO codes or VAT amounts. These can be updated by a user through a screen.
  • You want data to be updated on a separate schedule from the other data.

Solution

  1. Tables
    1. Switch on static: hover over the item on an analysis model and click Static.
    2. Switch off static:
      1. locate the table in the repository and double click it.
      2. In the properties window that opens locate the Analysis Options section and expand it.
      3. Untick Static.
  2. Pipes
    1. Switch on Static: Hover over the pipe and click Static.
    2. Switch off static: Hover over the pipe and click the play button.

Tables and Time Periods

A table can contain any number of datasets, each in turn can contain many records. Depending on how the data will be interacted with, you will need to set the time period which PhixFlow uses to collect the datasets. The period can be:

Transactional

This allows multiple users to run independent analysis tasks at the same time.

Daily

This is a non-transactional table type, and generates or collects data every day.

Monthly

This is a non-transactional table type, and generates or collects data every month.

Variable

This is a non-transactional table type, and generates or collects data since the more recent run of the table to the current date.

For non-transactional periods, PhixFlow checks for incomplete record-sets and reports an error if it finds them. However, pipes from transactional tables allow incomplete recordsets, as data is constantly changing.

Pipes and Data to Read

Pipes have a plethora of uses (see Pipe), one key use is selecting which dataset(s) to read. The two most common options are:

  1. All: This means that the pipe will pull the data from all datasets.
  2. Latest: This means the pipe will only pull information from the very latest dataset.

This option is available in the pipe properties → Data to Read

Publishing Tables

When you make changes to a table's properties or its attributes, PhixFlow publishes the changes to the PhixFlow database. This happens automatically in the background. Publishing many tables or tables with many attributes can take some time.

If the table properties are set incorrectly, PhixFlow will not be able to publish the table to the database. If this happens, the  System Console will report the publishing error. PhixFlow will also display an error message if you try to interact with the table, for example to view its data or to run analysis. You must correct the table properties, so that PhixFlow can retry publishing the table. 

During the publishing process, PhixFlow may create temporary tables in its database. These are kept for a period, then automatically removed when a system task runs. For information about:


To ensure that PhixFlow can publish data changes, its database must have enough space to hold a copy of the largest table. For the different databases, the space needs to be in:

  • Oracle: temporary table space
  • SQL Server: temporary file group
  • MySQL: the file system.

Learn More

Some options may still refer to streams and stream sets.


Terminology changes in progress

As part of the redesign of PhixFlow, we are changing the following terms:

dashboard → screen   
stream → table
stream attributes → attributes
stream item → record
stream set → recordset
stream view → view
stream item action → record-action 
stream action → table-action
driver class → database driver