The team has agreed o deviate from the original proposal and store the 'Anchor' in a separate table in the DB persistence layer

See https://wiki.onap.org/display/DW/Decouple+Anchor+from+Fragment+proposal

Some points of clarification:

1. The anchor can be seen as a reference point/data identifier for an data instance tree
2. The 'name' of the anchor will NOT be part of any xPath expressions of the fragment associated with it
3. It might be possible that more then 1 data-instance tree (using other modules in the same schema set) will be associated with 1 anchor but this will be handle by separate user stories.
4. leaf-elements defined on a module-level, not in any container (as seems possible according to Spec but not common practice) will NOT be stored in the anchor
5. The anchor might in the future store other identifiers stored as key value pairs but also this is outside the scope of this user story
6. In persistence implementation we can use 'AnchorEntity' as name to avoid confusion with SPI/API data object of same name

Acceptance Criteria

1. This is a refactoring user story, no functional/behavior changes are expected
   1. the SPI interface is NOT affected
2. A separate table will be used to store anchors and associated properties as currently required by the system (as demonstrable using a DB client)
3. Many data fragments can be associated with one anchor (as is)
4. Data integration test wil be updated to use the new table