Have FTM Public Views That Mirror Control Center's UI Data Model

The FTM Control Center's operational data model consists of:
- Inbound Physical Transmission
- Inbound Transmission
- Inbound Batch
- Processing Batch
- Inbound Segments
- Transactions
- Endpoints
- Outbound Batches
- Outbound Transmissions
- Outbound Physical Transmissions

Have FTM PFS public (aka FTMPUB) database views mirror this structure and allow a person to join data across these views. Some example view names are:
- INBOUND_PHYSICAL_TRANMISSION_DATA_V
- INBOUND_PHYSICAL_TRANMISSION_STATES_V
- INBOUND_TRANSMISSION_DATA_V
- INBOUND_BATCH_DATA_V
- PROCESSING_BATCH_DATA_V
- INBOUND_SEGMENT_DATA_V
- TRANSACTION_DATA_V
- TRANSACTION_STATE_V
- OUTBOUND_BATCH_DATA_V
- OUTBOUND_TRANSMISSION_DATA_V

The views should be consistent with the following guiding principles:
1) Easily map to the Control Centers user interface data model
2) Have a naming convention consistent with FTM-base
3) Allow for linking of data across the related element (e.g. Batches to the containing Transmissions)
4) Allow for the linking of data objects across the FTM-base and FTM PFS components
5) Balance the need for backwards compatibility and API adoption by deprecating the IPD/check name-based views such as: GW_FILE_STAT_V, INBOUND_FILE_DATA
6) When payment type specific transaction data is required then create payment type specific views such as: CHECK_TRANSACTION_DATA_V and ACH_TRANSACTION_DATA_V.
7) When other payment type specific views are required then create views using a naming pattern of PAYMENT_TYPE_XXXX. Ideally the views are based upon the generic views and appends the additional data/columns.