Universal Smart Data Access

​

In most significant enterprises, data access and manipulation tend to be complex due to a number of factors:

​

• Quite often, each enterprise application has its own way of accessing/manipulating data.

​

• There are multiple data repositories and repository types within an enterprise, further complicating data access.

​

• There needs to be data consistency across potentially disparate data repositories.

​

• Data repositories may reside off-premise (e.g. the cloud).

​

The Emberly Clark Universal Data Access Layer eliminates those complexities by providing one simple and platform independent  way to access all data repositories, regardless of repository type   or location. Additionally, it ensures consistency across both compatible and disparate data repositories by enabling atomic transactions across them.

​

When configured to return canonical types,  it further shrinks codebase size by reducing the number of data access methods.

 

Leveraging Artificial Intelligence (AI), it can be used with "Adaptive SQL" (click here to learn more) to reduce time to benefit in MDM scenarios.

​

The net effect is a significant reduction in codebase size, reduction in maintenance and development costs, and the promotion of faster times to market.

​

For additional information or a Demo, call us at 800-314-9503 (select option 1, then 2), or send us an email.

 

1-Platform Independent means that the Universal Data Access Layer works with mainframe, mini, and micro computers and also supports communication between them.

2-Repository Types may be structured-relational (SQL Server, Oracle, etc.) , structured-NoSQL (MongoDB, Cassandra, etc..), or Unstructured (Sharepoint, Documentum, etc.)

3-In most mid to large-size enterprises, there may be multiple definitions of a business entity (e.g. customer) at the database level. In those cases, a “Canonical Schema” would provide a single definition for a given business entity that would be used to supply data to and get data from enterprise databases. The benefit is that the amount of data access programming code is reduced to one set per entity, as opposed to multiple sets per entity.