Implementation

FAKTS is implemented in the open source MySQL database management system, with HeidiSQL software being used as a front-end tool for managing database editing, data entry and interrogation. In a manner similar to that employed in the sister database for deep marine depositional systems (DWAKB in Baas et al. 2005),

16

each entity type (e.g., a facies unit) is assigned a table containing a set of predefined attributes (fields) having numerical domain (e.g. dimensional parameters), predefined class domain (e.g. facies type) or text domain (e.g. original naming of facies unit).

FAKTS is made of nine tables, each hierarchically related to others by one-to-many relationships in a way that approximately corresponds to a hierarchy of scales. In the following, a concise description of each entity type (table) and of some of their attributes (columns and associated domains) is provided (cf. figure 2.3).

Table DATA SOURCE. This table contains all the basic metadata that refers to whole datasets, describing the original source of the data and information for each case study. Among its attributes, this table includes the type of work from where the data have been derived (e.g. peer-reviewed literature, unpublished academic works, technical reports), the methods of acquisition employed (e.g. outcrop observations, GPR profiles, aerial photos), the chronostratigraphic stages corresponding to lower and upper age limits of the studied interval, the geographic location, the names of the basin and river or lithostratigraphic unit, and a dataset data quality index (DQI, see below). In addition, all the associated literature that has been used to constrain the case study boundary conditions is included in this table in the form of bibliographic references.

Table SUBSETS. This table holds all the data about subsets. Some of its attributes contain metadata: original subset coding (figure, table or entry naming or numbering in the source work), descriptors of subset spatial, vertical and horizontal extension, type of spatial observation and sampling (1D vertical, 1D horizontal, 2D cross-section, 2D planform, pseudo-3D, full-3D), fields about the main scales of observation investigated by the authors (original target scale) and chosen for the database by the operators (subset target scale – whose importance for properly characterizing fluvial architecture is clarified later). The remainder of the attributes store all the constraints on external and internal controls and variables that contribute to define the subsets themselves (e.g. tectonic setting, subsidence rates, basin climate type, sediment load dominance type, river pattern). Some of these fields are only expressed as relative change across subsets in a given variable (e.g.

relative regional base level change, relative distality between subsets showing proximal to distal relationships within the same time-span), and their domain comprises ‘increase’, ‘decrease’ and ‘no change’ classes, that refer to change either over time or space, depending on the relationships between the subsets. This table is made of a total of 61 attributes; new attributes can be added at any time depending on the external and internal controls recognized and being considered for investigation in order to accommodate all the available constraints. A note field

(with a text domain) is assigned to every subset for the inclusion of information that cannot be stored in the existing thematic attributes: this note field is used to store information on attributes that relate to single case studies to limit table size.

Subsets can be reassigned at any time, as new constraints on the categorical or numerical variables used for distinguishing them in a dataset emerge.

Table DEPOSITIONAL ELEMENTS. This table contains attributes about depositional elements including original numbering and naming convention, element type (complex or floodplain), the hierarchical order of the channel-complex lower bounding surface (according to Miall 1996), dimensional parameters (e.g. thickness, width), net-to-gross ratio, and descriptors of the planform morphology of the channels contained within channel-complex elements.

Table ARCHITECTURAL ELEMENTS. This table contains attributes about architectural elements including original numbering and naming convention, element type classifications, dimensional parameters, net-to-gross ratio and descriptors of reach morphology (depth and width) for CH architectural elements.

Table FACIES. This table contains attributes about facies units including original numbering and naming convention, lithofacies classifications, dimensional parameters and percentage proportions of textural classes.

Tables DEPOSITIONAL ELEMENTS-, ARCHITECTURAL ELEMENTS-, and FACIES-TRANSITIONS. These tables store the transitions between objects belonging to the same scale (depositional elements, architectural elements and facies units) in the right-lateral, up-dip and upwards vertical directions, expressed using object identifiers. The two tables for facies units and architectural elements transitions also permit specification of bounding surface order (according to Miall 1996) across which the transition occurs.

Table SUBSET STATISTICS. This table holds all the statistical data arising from statistical summaries that cannot be treated using attributes relating to individual objects. The statistics refer to the entire subset and the table allows for the storage of data about object dimensions and transitions only.

All the metadata attributes storing original coding allow the tracking of data from the original dataset. For example, original depositional element numberings are retained within the database, allowing cross-reference back to the original literature.

In fact, this field is not strictly required since the unique identifiers that are assigned to each object at the time of data entry are also used to track them graphically.

Attributes containing original types are fundamental because they communicate the original object classifications (e.g. original facies type): retaining original classifications ensures that it remains possible to reassign object types at a later

18

time, in the event of a change being made to the domain of the relative attribute (e.g. inclusion of a new class of facies).

A series of data quality indices (DQI’s) have been included as a threefold ranking system (rating datasets and attributes as A, B or C level, in order of decreasing quality). This provides a mechanism for the ranking of perceived data quality and reliability following established criteria (Baas et al. 2005), and to filter it accordingly when querying the database. Although dataset DQI is meant to rate the entire case study quality, other similar DQI’s are used for ranking class domain attribute assignment for each entry (e.g. ranking the reliability of attribution of architectural element type). For every table containing descriptive data, notes fields with text domain are provided for the inclusion of additional information.

Every entry in a table is given a unique numerical identifier; these numerical indices are used to relate the tables (working as primary keys, used to unequivocally identify each record, and foreign keys, used to link the entries in the table to other tables through primary keys), so that not only is it possible to track relationships to a specific case study but also the nature of the containment (nesting) of each object within its higher-scale parent object can be reproduced in the database (depositional elements within subsets, architectural elements within depositional elements, facies units within architectural elements; figures 2.2 and 2.3).

Skipping scales is always possible by leaving object types undefined (e.g. facies belonging to an undefined architectural element, which in turn belongs to an undefined depositional element). The same numerical indices that are used for representing cross-scale containment relationships are also used in the three tables for transitions with the purpose of re-creating neighbouring relationships between objects contained at the same scale (figure 2.4).

Figure 2.3: database structure, with constituent tables and selected attributes; yellow:

primary keys, light blue: foreign keys. The (MV) abbreviation denotes attributes with multi-valued fields (e.g. different lithotypes included in the same entry for contributing basin lithologies attribute).

20

Figure 2.4: hypothetical example illustrating how transitions between neighbouring

architectural elements are stored within the database; the same procedure applies to depositional elements and facies units. Transitions between subsets need not be stored as they are conventionally ordered from bottom to top (ancient systems) and in downstream direction (modern systems). Bounding surface orders follow the

classification proposed by Miall (1996).

In the same way as for subsets, the implemented indexing allows depositional, architectural and facies elements to be deleted, edited or added at any time, making all the stored fluvial architectural data entirely editable, for example as new interpretations emerge after original data entry.

The dimensional parameters of each depositional element, architectural element and facies unit can be stored in their respective tables as representative thicknesses, cross-valley widths, downstream lengths, cross-sectional areas, and planform areas. Widths and lengths are classified according to the completeness of observations into complete, partial or unlimited categories (figure 2.5), as proposed by Geehan & Underwood (1993). Apparent widths are stored whenever only oblique observations with respect to palaeoflow are available. Where derived from borehole correlations, widths and lengths are always stored as ‘unlimited’.

Dimensions are obtained from graphical representations employing ImageJ image analysis software, which is used for measuring manually digitized vector geometries.

Figure 2.5: terminology of length types according to Geehan & Underwood (1993).