Data modeling involves organizing business data to fit the needs of business processes by designing physical models that house the data. You can use Axional Studio dictionary to define your database physical model and extend it by adding additional metadata that will be used by application.

 

1 Data definition (DDL)

The system uses the data model to generate database tables for storing the business data. The structure of your data model depends on how you define database tables. These tables defined in the dictionary do not exist in the database until they are deployed.

Whenever the structure of the table is modified in the dictionary, these modification have to be registered in the conversion log one by one. This way, when a new compilation is performed, the system can contrasts differences between the table definition in the dictionary and the structure of the table contained in the database.

In addition, each table can have one initial data object that will feed the table with data as soon as it is compiled into the database.

                                
Loading...
 

1.1 Table definition

The first element in DDL definition are tables (wic_table_object). Tables are fundamental objects of a database because it is where all the information or data is preserved.

Menu path:
Dictionary / Physical / Tables

 

1.1.1 Description

Tables are database objects that are structured to contain data in the database. In tables, data is organized according to a row and column format, similar to a spreadsheet. Each row represents a unique record and each column a field within the record. For example, in a table that contains the customer's data of a company there can be a row for each customer and different columns in which appear details, such as the customer's number, name, address and phone number.

Tables are uniquely named within a database.

  • Table name*: unique identifier of the table. This must coincide with the name included in the table syntax.
  • Order*: usually 0, this value shall only be used if there is a conflict for the system to establish indexes hierarchies. This process is usually automatic and doesn't need the value to be modified.
  • Locked: the table has been defined in the dictionary, but it is not going to be deployed into the database. Typically used when table definition it's not yet complete. Only who locked the table can unlock it again.
 

1.1.2 Table syntax

With the table syntax we can define the table structure, indexes and constraints.

  • In the table structure each row represents a unique record and each column a field within the record. When defining a table, we need to specify the type of data associated with each column like numbers, strings, temporal data, etc.
  • In the definition of a table several FOREIGN KEY clauses may appear, as many as external keys have the table. However, there can only be one primary key, although this primary key can consist of several attributes.
  • Constraints are imposed to ensure that the data meets a set of predefined conditions for each table. These restrictions help to achieve reference integrity: all references within a BD are valid and all restrictions have been met.

Table syntax accepts both native SQL and XML syntax. We recommend tables to be created in XML, as this will allow the dictionary to transform the statements to various database engines (Informix, Oracle, Postgres, SQLServer, etc.). Direct SQL statements can be used, but will not be converted to other database formats. For further information on Tables syntax see Languages/Reference/XSQL/DDL/Table.

 

1.1.3 Table compilation

It must be taken into account that once a table has been defined and catalogued in the dictionary, it is mandatory to compile it in order that it exists in the database physical model.

The process is executed by the Deployment object, explained later in this section. This process of table compilation must be executed selecting these option in query screen:

  • Type: table
  • Action: create

 

1.2 Initial data

When a table requieres initial data, they have to be defined in the wic_table_object_data, which has to be accessed by the DATA tab of the desired TABLE.

Menu path:
Dictionary / Physical / Tables
 

1.2.1 Description

The initial data is data that you need on a new system for it to be functional. In many cases, before starting to use a database, it is very useful that it already contains tables with useful data for business logic: for example a table of currencies, since these do not usually change and are essential to define the type of currency in each commercial transaction.

The example bellow shows the initial data form to feed the table customers with intial data:

  • Order execution*: it indicates the order in which one table of the system will be fed with data in relation to others that are also deployed with initial data. Rarely used.
  • Delimiter*: indicates the type of separation between the columns in the table data, normally pipe because it is the less frequently used in the database data.
  • Date format*: indicates which format the dates will have in the database once the table is deployed, regardless of the way they are written on this form.
  • Decimal separator*: indicates whether the decimal separator in the database will be a colon or semicolon, regardless of how they are written on this form.
  • Columns: indicates which columns of the table are going to be fed with data. If the indicated columns are not fed, data feed will not take place. Use a comma to separate column names.
 

1.2.2 Data compilation

Once the initial data has been defined and created in the dictionary, it is mandatory to compile it in order that it exists in the database physical model.

The process is executed by the Deployment object, explained later in this section. Data compilation must be executed selecting these option in query screen:

  • Type: table upload
  • Action: create

After the compilation takes place, the screen shows a report with the process result:

IMPORTANT

To deploy a table with initial data it is compulsory that, if the table already exists in the database, has no data on it. Otherwise the feeding with initial data will not take place.
 

1.3 Conversions

The conversion log table (wic_change_log object) is the repository of evolutionary changes made to database structures. Use this option to perform modifications on existing structures.

Menu path:
Dictionary / Physical / Conversions / Conversions
 

1.3.1 Description

The physical data dictionary, in addition to containing the physical definitions of the tables of the operating database and a history of changes to these definitions, can also store the different SQL statements of modification. These statements, when executed, will update the tables to the most recent versions available.

Modifying the physical database involves risks and should not be done without sufficient experience. For this reason, and to protect the integrity of the conversion logs, the application does not allow deletion.

  • Table*: reference table to which evolutionary conversions will be applied. This name will be also used within the SQL statetements.
  • Action*: the value of this drop-down explains the system what to do if an error occurs during the execution of the SQL script. You can opt for two actions:
    • Stop: indicates if an error occurs in any of the sentences in the block. The next time that the update procedure is executed, it will continue with the same update block.
    • Continue: indicates that an error occurs in a block statement continue with the next block statement. This option should only be selected when all SQL statements perform tasks that do not compromise the structure or content of the tables, that is, they carry out modifications of referential integrity restrictions (primary keys, foreign keys and alternative keys) or control restrictions (default values, null values, validations).
  • Locked: lock/unlock conversion log. Only the user who has locked the record has permission to edit it. Until the user who has locked the record does not unlock it, no other user can make changes or delete the selected record
  • Always: indicator that forces the auto-upgrade process to unconditionally execute the block of SQL statements contained in the register. By default, this indicator should not be activated. It should always be activated in the following cases:
    1. Renaming a table.
    2. When no SQL statement makes structure or content changes, that is, they only make changes to restriction rules: indexes, controls, primary keys or foreign keys.
  • Message*: brief explanatory comment about the purpose of the conversion. This message will be displayed in the ws-dbschema utility when the system is processing the change block.
  • SQL Statement*: in this text field the conversion is introduced, that is, a set of SQL statements that implies a table update.
  • Project and notes: the project option allows linking this conversion log to one of the open projects from the wic_dev_projects table on dictionary.
  • Documentation of the conversion: information regarding the reason for the conversion. The combination of this documentation associated with each table over time will give us the total evolution of each structure throughout its useful life.
 

1.3.2 Conversion compilation

Although this process is executed by the Deployment object, it is highly recommended to always complete the following procedure to prevent and detect errors:

  1. Edit the table model. Access the table schema through the physical dictionary and make the relevant modifications. Remember to add the appropriate comments and save modifications.
  2. Create the conversion register. Access the physical dictionary conversion form and create a record that matches the modification made in the table. IMPORTANT: remember to correctly select the Always indicator according to the modification content.
  3. Check object status. Access the compile model (dll) query of the deployment menu. Status must be executed selecting this option in query screen:
    • Database: database name.
    • Action: status.
    • Type: all/table/index/check.
    • Pattern: table name or pattern.
    Press execute button: as a result, the system reports the differences by comparing database table with the new table model. This report includes a recommended solution.
  4. Execute the conversion register through the compilation option. Conversion compilation must be executed selecting this option in query screen:
    • Database: current database or all.
    • Action: upgrade.

      IMPORTANT

      When the upgrade action is selected, all fields except Database in the query are invalidated and all non blocked conversions will be executed.

      If the procedure was successful, a report should confirm the success of the compilation process.

  5. Check object status. As the procedure run correctly, the report should confirm that there are no differences between the model and the database.
 

Conversion Compilation Example

The video below shows as an example of conversion the addition of a new column called 'nickname' to the existing table 'customer' of the database, following the recommended procedure.

 

1.4 Status and maintenance

TO DO

This section is incomplete and will be concluded as soon as possible.

This process allows the management of the physical model of the chosen database. The databases shown are those whose dictionary is the current connection database and to which you have access.

   

1.4.1 Deployment object

It is very important to keep in mind that once a table has been defined and created in the dictionary, it is mandatory to compile it so that it exists in the database.

Menu path:
Deployment / Compile model (ddl)
  • Data base*: allows you to select a database where to compile or all databases of which it is the dictionary
  • Type*: determines the type of element to be compiled:
    • All: all objects
    • Table: the entire table/s
    • Index: only the indexes of selected tables
    • Table load: initial data of selected tables
    • Check: only the checks of selected tables
  • Action*:
    • Create: creation of the physical model.
    • Drop: removes elements from the physical model.
    • Status: information on the current state of the physical model by comparison with the cataloged model.
    • Upgrade: updates of the physical model with the structure changes cataloged in the conversion.
  • Pattern*: use this option to easily select desired elements by name. The percent symbol (%) involves all names.
 

2 Attributes

Based on the attribute definition you can configure the data entry in the system.

For example, you can use an attribute to make sure that the phone numbers written in a phone number field are going to have the proper format. The attribute configuration does not alter the way data is stored, which is controlled by the type of data in the field and other properties.

 

2.1 Attributes

TO DO

This section is incomplete and will be concluded as soon as possible.

Menu path: Dictionary / Physical / Attributes / Attributes

Attributes determine how columns behave in a form or a report, with a variety of options determining display, input, etc. Attributes allow us to describe properties for a given catalog column. These may be composed of default values, formats, user-defined functions, validation lists, etc.

 

2.2 Column options

Management of the fields behavior inside the form. This behavior is handled by three conditions:

  • Enable or disable an input field: to activate or deactivate the input functionality of the field, two types of conditions could be defined.
    1. The first one is executed once at server level when the form is loaded.
    2. The second type is defined at client level and is evaluated dynamicaly according to any change in the form values.
  • Mark the field as non required: it is possible to define criteria to set the field as optional or required, overriding the physical definition of the column on the table.
  • Show or hide the field: the condition allows to show or hide the field. It is executed at the server level.

TO DO

This section is incomplete and will be concluded as soon as possible.
 

2.3 Autocomplete and data verification

Menu path: Dictionary / Physical / Attributes / Data validations

TO DO

This section is incomplete and will be concluded as soon as possible.
 

2.4 Data validation

TO DO

This section is incomplete and will be concluded as soon as possible.
 

2.5 Data colorize

TO DO

This section is incomplete and will be concluded as soon as possible.
 

2.6 Binaries definition

TO DO

This section is incomplete and will be concluded as soon as possible.
 

3 Descriptions and Internazionalization (i18n)

After the physical database model is defined, you can extend it to enrich database model with localized labels, field descriptions, default values, check constraints and so on.

 

3.1 Table information

Through this option we access to the description of the catalog of tables of a database model. From it, if the user has the required authorizations, it is possible to create, delete or modify such descriptions.

The dictionary of tables allows us to define the descriptions of each of the database model tables described, as well as a general description of their functional meaning.

Likewise, it is also possible to access to consult attached information to each of the registered tables:
  • To the dictionary of columns for reference on the columns or fields that form the table structure.
  • To the register of attributes of the columns or fields belonging to the table.
  • To the register of references or integrity relations that the table may have been defined.

As an additional functionality, it is possible to search for tables that in their general information contain a certain string of characters.

 

3.2 Column information

Through this option we access to the catalog description of database model columns. From it, if the user has the required authorizations, it is possible to create, delete or modify such descriptions.

Column dictionary allows us to define descriptions and information related to columns associated to a database catalog as well as a description of features and properties of each of them.

Likewise, it is possible to access to consult information attached to the table to which columns belong:
  • To the table dictionary for reference on its definition.
  • To the register of attributes of table columns.
  • To the register of references or integrity relations of table columns.

 

3.3 Selection Controls (Includes)

Menu path: Diccionary / Logical / Includes

Through this option you can access the definition of includes or lists. These can be assigned as possible values to the columns, through the parameterization of their attributes, or to the object query variables. From this option, if the user has the necessary permissions, they can create, delete or modify these definitions.

TO DO

This section is incomplete and will be concluded as soon as possible.
 

3.4 Check constraints description

Menu path: Dictionary / Logical / Check constraints / Checks descriptions

Through this option you can access the checks dictionary to enter the descriptions associated with the check constrains of a database catalog. From the dictionary, if users have the necessary permissions, they can create, delete or modify these descriptions.

These descriptions will be those shown to users when they insert or modify records in a table, in case any of the records to be inserted or modified does not meet the conditions of any of the existing checks.


Menu path: Dictionary / Logical / Check constraints / Checks inactive

Through this option you can access the check constraints register, of which it is desired that the system does not display or warn of possible problems when evaluating the syntax of these checks. The mere fact of registering a check is already sufficient condition so that it is not displayed.

However, registering it does not mean that it cancels its operability and functionality, since it will be its own database the one that denounces the cases in which the conditions of the same are not fulfilled.

TO DO

This section is incomplete and will be concluded as soon as possible.
 

3.5 Syntax description

TO DO

This section is incomplete and will be concluded as soon as possible.
 

3.6 Status and maintenance

To improve the consistency of the database, the location options allow you to find and/or modify the incomplete elements of the logical dictionary. It mostly refers to translation tables.

Review pending

TO DO

This section is incomplete and will be concluded as soon as possible.