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 table to another. Pipes also connect other types of modelling object, 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 a 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 the to the selected recordset; see Rollback Recordsets. You 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 proceed 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 your run analysis, or want to run it on a different schedule.
Solution
- To Run Analysis hover over the table and click Run Analysis:
- To Run Analysis automatically on a timed schedule see Task Plans.
Static Objects
There are several reason 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
- Tables
- Switch on static: hover over the item on an analysis model and click Static.
- Switch off static:
- locate the table in the repository and double click it.
- In the properties window that opens locate the Analysis Options section and expand it.
- Untick Static.
- Pipes
- Switch on Static: Hover over the pipe and click Static.
- 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: allows multiple users to run independent analysis tasks at the same time.
- Non-transactional
- Daily: generate or collect data every day.
- Monthly: generate or collect data every month.
- Variable: generate or collect 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:
- All: This means that the pipe will pull the data from all datasets.
- 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 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:
- the system task, see Using Tasks and Task Plans
- configuring the period that temporary tables are kept; see System Configuration → Delete Temp Tables after Days.
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
- Maria DB: the file system.
Learn More
- Managing Recordsets
- Managing Models and Data
- Rollback Recordsets
- Modelling objects and Windows
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