How To Use Peer Tables for HDWF Extensibility
Last updated on MARCH 08, 2017
Applies to:Oracle Healthcare Data Warehouse Foundation - Version 6.0 and later
Information in this document applies to any platform.
Per section "Peer Tables" from HDWF Programmer's Guide,
Oracle recommends to use peer tables when a direct mapping from source data cannot be made to an already defined HDWF table, or all of the UDAs are used for that specific data type.
Q1: The above implies that, say the implementation team has used up all of UDA NUMBER data types and has some more NUMBER data types to map. There are a few UDA VARCHAR2 available.
But based on the recommendation, the NUMBER data type should not be mapped to one of the VARCHAR2? (e.g. no type casting of NUMBER or DATE into VARCHAR2)
Q2: A peer table PEER.PEER_FACILITY is constructed with custom required DATE and NUMBER fields; the PK is same as the PK of HDM.HDM_FACILITY.
2.1 How can versioning be incorporated into this PEER_FACILITY?
2.2 If versioning is not introduced in PEER_FACILITY, HDM.HDM_FACILITY would have versioning resulting in a M:1 (many to one) relationship from HDM.HDM_FACILITY PEER.PEER_FACILITY. Is this a correct assessment?
2.3 If so, what can be done to facilitate versioning and other features that are bolted as part of OHADI?
2.4 What is the mechanism to communicate the extension requirements back to Product Development? Is there a template that needs to be followed?
Q3: All UDA NUMBER columns are used up. There are 1 or 2 named NUMBER type fields available in table that has not been mapped yet.
Could the source field be mapped to this HDM base table’s NUMBER typed named field, though they may be functionally different?
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms