Data Compatibility

Data Compatibility is an IT innovation that provides integrated data throughout an organization, among organizations and across industries. Data compatibility is so superior to traditional data integration methods that data compatibility is the inevitable replacement for data integration methods. Compatible data is integrated data. Data is automatically integrated from the time it’s initially stored and it will remain integrated until it's deleted. Any data from a compatible data system is integrated with data from any other compatible data system. Unlike traditional data integration methods, there is no need to spend exorbitant amounts of money, time and effort moving and transforming data. Data compatibility creates untold opportunities for collaboration, both within and outside your organization.

All data arise within a particular context and often as a result of a specific question being asked. That is all well and good until we attempt to use that same data to answer a different question within a different context. When you match an existing dataset with a new question, you have to ask if the original context in which the data were collected is compatible with the new question and the new context. If there is context compatibility, then it is often reasonable to move forward. If not, then you either have to stop or come up with some statistical principle or assumption that makes the two contexts compatible. Good data analysts will often do this in their heads quickly and may not even realize they are doing it. Understanding context compatibility is increasingly important as data science and the analysis of existing datasets continues to take off. Existing datasets all come from somewhere and it’s important to the analyst to know where that is and whether it’s compatible with where they’re going. If there is an imcompatibility between the two contexts, which in my experience is almost always the case, then any assumption or statistical principle invoked will likely introduce uncertainty into the final results. That uncertainty should at least be communicated to the audience, if not formally considered in the analysis. In some cases, the original context of the data and the context of the new analysis will be so incompatible that it’s not worth using the data to answer the new question. Explicit recognition of this problem can save a lot of wasted time analyzing a dataset that is ultimately a poor fit for answering a given question.

Compatible Data Types
The compatibility of two data types (except reference types) is based on their technical type attributes. It is the basis for type checking in assignments to field symbols or when assigning actual parameters to formal parameters. In the case of value assignments and comparisons between data objects (except reference variables), compatibility also determines whether a conversion has to be performed or not. In the case of reference types with data objects (reference variables) that have a dynamic type as well as the static type, then compatibility, which is based entirely on technical type attributes, is not sufficient.

• Non-Generic Data Types (Except Reference Types): Two non-generic data types (not reference types) and data types that contain reference types as components are compatible if all their technical type attributes match.
  • In the case of elementary data type all technical type attributes match. The technical type attributes are as follows:
    • The predefined ABAP type
    • The length (in the case of the types c, n, p, and x)
    • The number of decimal places (in the case of the type p)
  • In the case of structured types, the technical type attribute is as follows:
  • The layout of components: The layout of structured types does not only refer to the sequence of elementary components in memory, but also to the combination of components with substructures and whether a substructure is a boxed component. The names of the components and of the semantic attributes defined in ABAP Dictionary, such as conversion routines or documentation, however, are not important. In the case of compatible structures, all components are compatible in pairs. This applies recursively down to the level of elementary data types.

If two structures are both constructed identically but different substructures are declared as boxed components, the structures are not compatible.

• • In the case of table types, the technical type attributes are as follows: (In the case of compatible internal tables, the row types are compatible and the table category and table key match. Other attributes, such as the initial memory requirement, are not important.)
    • The row type
    • Table category
    • Table key
  • In the case of mesh types, the technical type attributes are as follows:
    • The layout of nodes (including the node names)
    • The associations (defined by ON conditions) of every component, including names and the table key used
  • In the case of enumerated types, the technical type attributes are as follows:
    • All properties of the enumerated type: Every enumerated type is unique and only compatible with itself.

Note: The types specified here are not compatible with one another. For example, an elementary data type is never compatible with a structure, even if the structure has only one component. Statement TYPES cannot be used to define different enumerated types with the same technical type properties. Even data types constructed with RTTC methods exactly like an existing enumerated type are not compatible with it. An enumerated type defined by direct or indirect reference (including RTTI) to an existing enumerated type, is compatible with it however.

• Generic Data Types: A non-generic data type (not a reference type) is compatible with a generic data type if its technical attributes are covered by the generic data type.
• Reference Types: A reference type is the static type of reference variables and determines to which objects they can point. At runtime, reference variables also have a dynamic type determined by the type of the object pointed to by a reference variable. The dynamic type may be more specialized than the static type. For this reason, the rules for typing checks, assignments, and comparisons cannot be covered by a compatibility concept based entirely on the technical attributes of the static type. Instead, the following three points show how reference types can be used together:
  • When typings are checked, the following is possible:
    • A reference variable can be passed to a formal parameter typed as a reference variable, provided that the type of the formal parameter is more general or equal to the type of the reference variable (known as an up cast) and the formal parameter cannot be changed within the procedure.
    • A reference variable can be assigned to a field symbol typed as a reference variable, provided that the reference types are identical.
  • Assignments between reference variables can be carried out by using an up cast or a down cast.
  • Data reference variables can be compared with all data reference variables and object reference variables can be compared with all object reference variables.

As a rule, data reference variables can only be used with data reference variables and object reference variables can be used only with object reference variables. No conversions take place between reference variables. They are either passed as unconverted reference variables, assigned to each other, compared with each other, or no action at all takes place.

See Also

Data Access
Data Analysis
Data Analytics
Data Architecture
Data Asset Framework (DAF)
Data Buffer
Data Center
Data Center Infrastructure
Data Center Infrastructure Management (DCIM)
Data Cleansing
Data Collection
Data Compatibility
Data Consolidation
Data Deduplication
Data Delivery Platform (DDP)
Data Description (Definition) Language (DDL)
Data Dictionary
Data Discovery
Data Driven Organization
Data Element
Data Enrichment
Data Entry
Data Federation
Data Flow Diagram
Data Governance
Data Health Check
Data Hierarchy
Data Independence
Data Integration
Data Integration Framework (DIF)
Data Integrity
Data Island
Data Item
Data Lake
Data Life Cycle
Data Lineage
Data Loss Prevention (DLP)
Data Management
Data Migration
Data Minimization
Data Mining
Data Model
Data Modeling
Data Monitoring
Data Munging
Data Portability
Data Preparation
Data Presentation Architecture
Data Processing
Data Profiling
Data Proliferation
Data Propagation
Data Protection Act
Data Prototyping
Data Quality
Data Quality Assessment (DQA)
Data Quality Dimension
Data Quality Standard
Data Reconciliation
Data Reference Model (DRM)
Data Science
Data Security
Data Stewardship
Data Structure
Data Structure Diagram
Data Suppression
Data Transformation
Data Validation
Data Value Chain
Data Vault Modeling
Data Virtualization
Data Visualization
Data Warehouse
Data Wrangling
Data and Information Reference Model (DRM)
Data as a Service (DaaS)
Database (DB)
Database Design
Database Design Methodology
Database Management System (DBMS)
Database Marketing
Database Schema
Database System