Difference between revisions of "IMSMA Staging Area"
Line 37: | Line 37: | ||
| align="left" | '''CDF multi-selects''' | | align="left" | '''CDF multi-selects''' | ||
| align="left" | Stored directly in the main object table as '''comma-separated list of values''' '''AND''' in a normalized way in the <OBJECT>_CDF_MULTISELECT table (in {{IMSMANG}} the values for a multi select have to be looked up in the <OBJECT>_HAS_CDFVALUE, CDFVALUE and CUSTOMDEFINEDFIELD tables) | | align="left" | Stored directly in the main object table as '''comma-separated list of values''' '''AND''' in a normalized way in the <OBJECT>_CDF_MULTISELECT table (in {{IMSMANG}} the values for a multi select have to be looked up in the <OBJECT>_HAS_CDFVALUE, CDFVALUE and CUSTOMDEFINEDFIELD tables) | ||
− | | align="left" | Let's assume that the Land object has a multi-select CDF attribute called ''My Land Multi-Select''. In the staging area, this will result in a column in the HAZARD table called my_land_multi_select with a comma-separated list of values, for example 'Value1, Value2'. Additionally, the table HAZARD_CDF_MULTISELECT can be joined with the HAZARD table in order to get to the same values as rows. Reusing the above example, there will be two rows, one with 'Value1' and one with 'Value2' as values | + | | align="left" | Let's assume that the Land object has a multi-select CDF attribute called ''My Land Multi-Select''. In the staging area, this will result in a column in the HAZARD table called my_land_multi_select with a comma-separated list of values, for example 'Value1, Value2'. Additionally, the table HAZARD_CDF_MULTISELECT can be joined with the HAZARD table in order to get to the same values as rows. Reusing the above example, there will be two rows, one with 'Value1' and one with 'Value2' as values. |
|- | |- | ||
Revision as of 14:39, 19 June 2014
What is the IMSMA Staging Area?
The IMSMA staging area is a flattened version of the IMSMA operational database. In terms of content, the data is an exact copy of the IMSMA database, but the structure is much less complex and therefore easier to query. While in the operational IMSMA database the core object data (e.g. the ID and name of a Land) is stored in one table (e.g. in the HAZARD table) and descriptive attributes (such as single- and multi-select standard and custom defined fields) are stored in separate tables, in the staging area all this information is available in one single table. Therefore, there is no need to write complex queries to get to all the attributes of an object. Ultimately, reporting and data analysis tools can easily be connected to the staging area.
A staging area can be created out of an IMSMANG v.6 database.
Structure of the IMSMA Staging Area
Database model
Flattening principles
This section requires basic knowledge of the IMSMANG structure |
Where to find which data in the staging area | ||||||||||||||
Type of attribute | Where? | Example | ||||||||||||
Standard text, numeric, date and time attributes | Stored directly in the main object table, similar to IMSMANG | The HAZARD (Land) attribute hazard_localid is stored in a column also called hazard_localid in the HAZARD table of the staging area. | ||||||||||||
Standard single-selects | Stored directly in the main object table (whereas in IMSMANG the main object table only contains a GUID reference to the IMSMAENUM table) | The Land attribute status is stored in a column called status_enum in the HAZARD table of the staging area. It contains the translated value of the status base value, e.g. Open or Closed in English or the equivalent values in another language that has been specified at staging area generation. | ||||||||||||
Standard multi-selects | Stored directly in the main object table as comma-separated list of values AND in a normalized way in the <OBJECT>_STD_MULTISELECT table (in IMSMANG the values for a multi select have to be looked up in the <OBJECT>_HAS_IMSMAENUM and IMSMAENUM tables) | The Land object has a multi-select attribute called Marking (Marking Method). In the staging area, the HAZARD table has an attribute marking_method with a comma-separated list of values, for example 'Official Signs, Local Signs'. Additionally, the table HAZARD_STD_MULTISELECT can be joined with the HAZARD table in order to get to the same values as rows. Reusing the above example, there will be two rows, one with 'Official Signs' and one with 'Local Signs' as values (or the translated values if any translations are available). | ||||||||||||
CDF text, numeric, date and time attributes and CDF single-selects | Stored directly in the main object table (as opposed to IMSMANG where a lookup has to be made through the <OBJECT>_HAS_CDFVALUE, CDFVALUE and CUSTOMDEFINEDFIELD tables) | Each CDF will be turned into a column in the staging area. For example, a CDF called My Hazard CDF defined on Land will result in a column named my_hazard_cdf in the HAZARD table of the staging area.
| ||||||||||||
CDF multi-selects | Stored directly in the main object table as comma-separated list of values AND in a normalized way in the <OBJECT>_CDF_MULTISELECT table (in IMSMANG the values for a multi select have to be looked up in the <OBJECT>_HAS_CDFVALUE, CDFVALUE and CUSTOMDEFINEDFIELD tables) | Let's assume that the Land object has a multi-select CDF attribute called My Land Multi-Select. In the staging area, this will result in a column in the HAZARD table called my_land_multi_select with a comma-separated list of values, for example 'Value1, Value2'. Additionally, the table HAZARD_CDF_MULTISELECT can be joined with the HAZARD table in order to get to the same values as rows. Reusing the above example, there will be two rows, one with 'Value1' and one with 'Value2' as values. |
|