Design the process model

A process model is a plan for the flow of the user interface - how the user gets from screen to screen, what shows on each one, and what other things happen. While the data model describes what is persistent, the process model describes change.

For small projects, you may want to skip the formal documentation of the process model, but you should still read this section to organize your thoughts about what is possible and convenient in Axisbase. This section explains the building blocks in Axisbase.

Kinds of processes

Maintenance: Data maintenance refers to the kind of process when a user looks up a specific record and changes it, or adds new records. As part of this process, users need to be able to search for records, and browse records displayed in tables. Just about any database needs a full set of maintenance screens, at least for the database administrator. Maintenance should be considered the basic interface, and everything else should be added on top of that for special purposes. Axisbase supports standard maintenance without code.
Wizards: Wizards are special cases of data entry, written to provide a more convenient alternative to basic maintenance screens. For example, order entry is often a good candidate for a wizard. Without a wizard, to take a new order, the user would look up a customer, view the orders for that customer, add one, add the line items to the order, save the changes, and then close one or more windows. Every possible option would be available through the maintenance interface. With a wizard, it could be designed to allow the user to enter the line items first, before choosing the customer. Or, it could be designed to assume that the customer is a new customer, and make a check during data entry to see if the name matches any existing customer. To create wizards in Axisbase, you have to write external code.
Web applications: Web applications are usually a special case of wizards, because they are a controlled system meant for the general public, and you only want the user to be able to do specific things, such as create a new order.
Reports: Designing reports is similar to designing search screens for maintenance, except that reports may be formatted for a certain paper size, and are not designed to allow making changes. Also, reports may show summaries instead of or in addition to detail, such as the total sales volume by month.
Background processes: Some systems require background processes, but if you can design an alternate way to do this, it can simplify deployment. An example background process would be to control external equipment, send reminder emails, or change the status of a library book to "overdue" on the day that it becomes overdue. (However, the last example can easily be designed a better way: Don't store the status at all, but just calculate it each time the book record is displayed.)

Data loading fundamentals

Axisbase loads and saves data in whole chunks, not one record at a time. For example, if you request to load all sales in the last week, the database server will load them all into server memory, transfer them all to the workstation, and then they will be displayed. The user can make any number of changes, which are held in the memory of the workstation. When the user chooses to commit the changes, the changed records are sent back to the server for saving. This method is generally replacing the older method of data access in which records are fed to the workstation only as requested and each change is saved when the change is made.

The advantage of the new method is that it works well across the internet, because there are no delays in the user interface during editing. To maintain good performance with Axisbase, you can keep the datasets as small as possible by filtering any data, and never requesting all of a record type that has a large number of records. For example, always request sales in a user-entered date range rather than all sales from all time.

The portion of the database that is loaded into workstation memory is called a data set. A data set can contain records of one main record type, and optionally records of related types. For example, a data set could be all the sales made in the last week, and all the line items of those sales. The collection of records of one record type is called a table; the columns of the table correspond to properties of the record type, and the rows correspond to the records. In Axisbase, the table/row/column terminology is only used for data sets that are loaded into workstation memory; however, in many other systems, that terminology is used more generally and includes records stored in the permanant database.

Axisbase building blocks

In Axisbase, you organize your user interface with building blocks. The kinds of blocks are as follows.

Data subsets: Data subsets are instructions for loading any subset of records from the database into a memory data set. (If you know SQL, they are equivalent to queries or select statements.) A complete list of what subsets can do is given below.
Data outsource: A data outsource is another kind of data source (like a data subset), but it gets data from some outside source, like a text file or another database system.
List: A list is a a way of presenting a data set in a vertically repeating format, which is often a table format.
User-defined: A user-defined block is a way to extend Axisbase by writing external code.
Report: A report is one or more layouts formatted for printing on paper.
Label printer: A label printer prints labels, like a report, but intended for printing on labels.
Window: A window is one or more layouts formatted for on-screen use.

The arrows in the graphic above are important. The arrows connecting data sources to layouts signify that layouts draw their data from data sources. The layouts are then placed inside the final presentation blocks (reports and windows). Important points to remember about this are:

Lists and graphs can be used by themselves, and don't have to be placed in anything.
Lists can also be used inside other lists to create master/detail lists.
When a list is placed in a report or window (or when it is referenced from a hyperlink in a list or window), the linkage can specify that the list use a different data source than the one it was designed with.

Re-use of building blocks

A design goal for the process model is to re-use as many building blocks as possible for as many purposes as possible. Generalize.

For example, suppose you have created a data subset that includes packages needing to be shipped, and a list which formats that data set in a certain way, and a report that contains the list. This sequence of data subset -> list -> report is useful to the shipping department to get a printed list of packages to ship. Now suppose a different department needs a report of packages that were shipped to a certain customer, and that report can be in the same format but with different data. In this case, you only need to create a new data subset and feed it into the same list. You can create a new report that includes the list with the new subset attached.

A second example would be when you need to alter the format but not the data set. In this case, build a new list, but make the new list use the same data subset.

A useful set of building blocks gives the end-user a choice of how to load data (which data subset to use), and how to format it (which list to use). You can use hyperlinks placed on windows to specify the possible connections, or you can create a series of windows (or reports) containing lists, whose purpose is just to connect the contained list to different data subsets.

Parameters

Parameters are data values entered by the user, which are not stored in any record. For example, if you load sales by a date range, the beginning and ending dates would be two parameters. The parameters are named, such as "fromdate" and "todate". Parameter entry fields can be placed on windows; parameter values can be included in lists and reports; and paramteter values can be used by data subsets to control data loading.

Through the extensive use of parameters, you can avoid any programming while still giving the end user a lot of flexibility in searching for and displaying data.

Capabilities of data subsets

You can do a lot with data subsets. This information is meant to let you know what can be done, for the purpose of the design phase. (The instructions to create data subsets is in a different section of the documentation.)

Data subsets are procedural; by creating one, you are telling Axisbase, "first do this, then do this, ..." and so on. You usually start with all records of one type, and then apply various steps to that, the end result of which is an in-memory data set containing one or more tables, with a row for each record and a column for each property of the record type.

A simple example is:

1. Start with all customers

2. Filter by state=NY

3. Sort by customer name

4. Only include the columns name and city

Axisbase performs some optimizations, so it does not always do the steps in the order listed. In this case, it would only load customers in NY into memory (so it basically skips step 1). Also, it only loads the name and city in the first place, instead of loading all columns and then throwing them out.

If a data subset has more than one table in it, each table has its own list of steps.

Here is a list of all the steps that can be used:

Choose columns: Use choose columns to throw out unneeded columns (in order to boost network speed and reduce memory use). If there is no choose-columns step, all possible columns are included.
Sort: Determines a sort order for display. (Note: the sort step doesn't do anything during the loading of data; it only affects the display.)
Fast filter: Restrict the rows to records that match a range of values or a single value. Fast filters are restricted in such a way that they are guaranteed to speed up loading. If a record type has a large number of records, you should generally use at least one fast filter when loading records of that type.
Complex filter: Restrict the rows based on an arbitrarily complex logical expression. Complex filters never improve performance.
Multi-valued parameter filter: Restrict rows to one or more rows that exactly match a set of user-entered values.
Summary: Create a new table in the data set that contains one summary row for one or more detail rows in the current table. For example, you could find the number of sales by state, or the total sales volume per week by sales rep. (The SQL equivalent is the GROUP BY clause.)
Calculated column: Create a new column in the table, and specify a formula that will be used to calculate its value.
Link tables: Link two tables in the data set in a master/detail relationship, such as sales linked to sale line items, or customers linked to sales.
Join tables: Combine two tables in the data set into one table. The final columns will include the columns of both original tables, and the rows will match up based on a common data value. Think of this as placing tables side by side. (The SQL equivalent is selecting from more than one table, or using the JOIN syntax.)
Union of tables: Combine two tables in the data set into one table. The columns of the two original tables must be identical, and the rows of both tables are included in the final. Think of this as placing tables one under the other.

There are four possible sources of rows for a table:

Start with all records of a type: This was explained in the examples above, and is the most common source.
Define a numeric/date sequence: This creates a simple table based on a seqence of numbers or dates, which you can then use to link to another table or base calculations on.
Use the results of a different data subset: If you have a data subset defined and you want to extend its functionality, you can create a new subset that is based on the old one. This is a good idea for cutting down on duplication of effort.
Start with the results of a Data Outsource: This is used when the source of the table is not in the database itself, but is in some external database or file. For example, you can read an external file, and use the data values in the file to join with a table loaded from the database.

At this point, if you haven't actually worked with data subsets, it will be hard to remember the above information. The main point to take from this is that you can do almost anything you can think of.

Bulk operations

The bulk operation building block can be used to do a variety of things to and with whole data sets.

The basic idea of a bulk operation is to load a data set into memory from any data source (a data subset or data outsource), then perform a sequence of operations on it.

The kinds of operations that can be performed are:

User review/edit: When Axisbase reaches this step, it displays the loaded data set and allows the user to make changes.
Mailmerge: Performs a mailmerge - see section below.
Email: Email an external file to all of the recipients identified by a column of a data table.
Massage: Changes every row in the same way, often used when loading external data, to "massage" it to fit into your database structure. The kinds of massage are:

- Trim spaces
- Truncate text (make sure it doesn't exceed a certain maximum length)
Export: Writes the data set to a file.
Modify, Create, and Delete: Modifies, creates, or deletes records in the database based on the intermediate data set.

If you know SQL, you will recognize that bulk operations are similar to SQL UPDATE, INSERT, and DELETE statements. Bulk operations can be a lot easier to work with, and are more flexible when the logic gets complex. You don't have to modify or delete the records that were loaded; for example, you could load in the line items of sales made in the last month, and then mark the products referenced by those line items as active.