US Army Corps of Engineers

BUILDING STRONG®

Local Data Requirements and Definitions

USACE SDSFIE Training

Prerequisites: Creating a Data Dictionary for Your Local Data

BUILDING STRONG®

Video sequence

2 of 24

BUILDING STRONG®

Objectives

Understanding “source” and “target” terminology Understanding what is a valid SDSFIE element Understanding how to validate and refine local

requirements in a Source Data Dictionary Understanding where to obtain the definitions to

populate a Source Data Dictionary Understanding how to develop a geodatabase

consistent with the final Source Data Dictionary

3 of 24

BUILDING STRONG®

TERMINOLOGY: “SOURCE” AND “TARGET

4 of 24

BUILDING STRONG®

“Source” and “Target” “source” = current or “as-is” condition of your

local data, or local geodatabase schema “target” = future or “to-be” condition of your local

data, or local SDSFIE Adaptation schema

5 of 24

from Source to Target

“Source data” “Source data dictionary” “Source geodatabase” “Source schema”

“Target data” “Target data dictionary” “Target geodatabase” “Target schema” or “Adaptation

schema”

BUILDING STRONG®

VALID ELEMENT DEFINITIONS IN THE SDSFIE STANDARD

6 of 24

BUILDING STRONG®

SDSFIE Element Uniqueness: Names and Definitions

Every SDSFIE element has a specific name and one unique definition

Definitions of SDSFIE elements must be unique in meaning; semantic overlap must be minimized

No two SDSFIE elements of same type (e.g., feature type) can have same name, but different definitions

No two SDSFIE elements with different names can have the same definition.

► Generally, no renaming in USACE Adaptations► Implementation exceptions are provided; in USACE adaptations,

the use of an alias is allowable but must be justified

7 of 24

BUILDING STRONG®

Valid SDSFIE Elements: Definitions

Relevant rules relative to SDSFIE elements that already exist, and adaptation extenstions:Rule 4-12: Extended feature types must be logically unique, with non-duplicate namesRule 4-14: Extended attributes may not have duplicative or conflicting definitionsSection 4.2: “No SDSFIE Adaptation can change the definition or data type of an existing element.”

8 of 24

*Guidance for the Adaptation of SDSFIE 3.0, DISDIG, Version 1.0, 11 May 2011

BUILDING STRONG®

Implications of SDSFIE Element Name and Definiton Policy

For the purposes of developing your data dictionary, implement this guidance and these rules as follows: Do not address definitional conflicts with 3.1 model elements at this time. (That will be done later.)Address definitional conflicts among your high-level data elements (i.e., feature classes and object tables)Focus on identifying and resolving any potential conflicts involving your non-standard (custom) high-level data elements

9 of 24

BUILDING STRONG®

VALIDATING LOCAL REQUIREMENTS IN YOUR DRAFT DATA DICTIONARY

10 of 24

BUILDING STRONG®

Validating Local Requirements in your Data Dictionary

Steps for reviewing the local requirements, as expressed in your draft data dictionary:Review all elements to verify they are requiredFlag any element that can be excludedFlag any element that is questionable with respect to inclusion criteriaIdentify additional requirements

11 of 24

BUILDING STRONG®

WHERE TO OBTAIN ELEMENT DEFINITIONS TO POPULATE YOUR DATA DICTIONARY

12 of 24

BUILDING STRONG®

Element Definitions Missing from the Data Dictionary have been Highlighted

13 of 24

BUILDING STRONG®

Definitions Sources for Elements from a “Prior Release” Elements in your local geodatabase may have

originated in a prior release of the standard, e.g., SDSFIE 2.6 or SDSFIE 3.0 Gold

With the exception of domain values (aka enumerants), SDSFIE 2.6 Elements are all lowercase and use underscores, e.g.,► soil_sample_point (a 2.6 feature class)► samp_typ_d (a 2.6 attribute)► d_smpmeth (a 2.6 domain)► VIBRACORE (a 2.6 domain value)

14 of 24

BUILDING STRONG®

Obtaining Definitions for Elements from a “Prior Release” 3.0 element definitions are already in your data

dictionary if you followed steps in Video 4. If there are only a very few 2.6 and/or 3.0

feature classes and/or object tables:► use the website’s Browse interface to obtain

definitions

15 of 24

BUILDING STRONG®

Using the Browse Interface to Obtain Definitions

16 of 24

Log in at sdsfieonline.org

Go to the Models & Workflows page

Select the data model► Click SDSFIE Gold to

expand► Click SDSFIE 2.61 -

Retired to select that data model

Scroll down in the Model Elements view to find and select the feature type or object table for which you need the definition

Highlight and copy the required definition

BUILDING STRONG®

Obtaining Definitions for Elements from a “Prior Release” If you have many 2.6 and/or 3.0 feature classes

and/or object tables:► download the 2.6 or 3.0 Gold workbook model to

obtain definitions; these can be found on USACE page of the sdsfieonline.org website:

http://www.sdsfieonline.org/PublicPages/Branches/Corps.aspx

17 of 24

BUILDING STRONG®

Definition Sources for Elements with non-SDSFIE origin

For those elements of your local data that were not based on a prior release of the SDSFIE, these sources may be helpful in obtaining definitions:Metadata for feature classes and object tables may contain required definitions, including attribute definitions

► If metadata is stored in ArcCatalog metadata model, then access definition through the ArcCatlog’s Description view

► Metadata may be stored in documents outside of the geodatabase and/or ArcCatalog, e.g., text, html, or PDF format

► Other locations (e.g., a domain-specific data dictionary, if you built feature classes from that schema)

18 of 24

BUILDING STRONG®

Communications within Data Owners and Others

For definitions still missing, ask others:►data owner►business process owner►data users

Provide list of elements flagged as “questionable for inclusion in adaptation”

Ask for any additional, known, near-future requirements

19 of 24

BUILDING STRONG®

Finalizing the Source Data Dictionary

Fill in all missing definitions Make any additional exlusions, found in review Make any additions (e.g., new requirements) Resolve any definitional conflicts (e.g., semantic

overlap) (Optional) Send entire data dictioary to local data

owners and local data users for final review; solicit final feedback

Make any final changes to data dictionary

20 of 24

BUILDING STRONG®

DEVELOPING A GEODATABASE ALIGNED TO YOUR FINAL DATA DICTIONARY

21 of 24

BUILDING STRONG®

Creating the Final “Source” Geodatabase

Remember that you are still working on the copy of your local geodatabase that you made earlier

Make deletions based on additional exclusions developed in the review process

Do NOT make additions to your schema (e.g., adding a feature class or attribute) if there are no data records present for the element(s)

Implement any other changes resulting from the review process

22 of 24

BUILDING STRONG®

Review

23 of 24

Understanding “source” and “target” terminology Understanding what is a valid SDSFIE element Understanding how to validate and refine local

requirements in a Source Data Dictionary Understanding where to obtain the definitions to

populate a Source Data Dictionary Understanding how to develop a geodatabase

consistent with the populated Source Data Dictionary

BUILDING STRONG®

Next steps

Videos should be seen next are►Creating the Local Adaptation

Contact sdsfie@usace.army.mil with comments or additional information

24 of 24