Teradata Magazine Cover Teradata Magazine Online  
Register Help Password
Password:
Quick Links
Current Issue
Archives
Teradata.com
Teradata Magazine Rss Feed
ARCHIVES Search Teradata Magazine Online:  
TECH2TECH
Tech2Tech
Table of contents


Ask the expert
Check out some of the past Ask the expert columns and industry white papers on active data warehousing.

Active data warehousing: from nice to necessary
Operating an intelligent enterprise enabled by an active data warehouse is no longer an option.

Supplying intelligence
Supply chain management software improves operations.

The .NET result
One way to simplify data access for software developers is the .NET Data Provider for Teradata.

Tech support
Understand how to best provision AMP worker tasks.


PrintPrint

Send to colleagueSend to colleague
PDF (185 kb) E-mail us

The .NET result

The .NET Data Provider for Teradata simplifies data access for software developers.

Application development has always been a challenge, particularly in the large-scale distributed computing environments common in enterprises that rely on data warehouse technology. Software developers have to consider how they will effectively deploy and manage applications. They have to determine how different applications will communicate with each other. They must take into account security, how applications will scale over time and ensuring high availability. Finally, programmers have to implement data access methods for those applications. “A lot of things come into play that companies have to consider when they are developing applications,” says Steve Mazingo, Teradata product manager for .NET.

Over the past several years, enterprise developers have embraced the Microsoft .NET framework, which provides a solution to the problem of connecting systems, information and devices within broad corporate computing infrastructures. The Java 2 Platform, Enterprise Edition (J2EE) stack provides an alternative technology, but for the purposes of this article, let’s take a closer look at .NET.

The .NET framework and the products based on that framework are designed to connect systems, information and devices within broad corporate computing infrastructures to enable more efficient collaboration, communication and integration. The technology has been added to a wide array of Microsoft products, including Visual Studio 2005, the company’s integrated development environment. The goal is to give developers the ability to quickly build, deploy, manage and use connected and secure solutions—generally through the use of Web services. For those of you not familiar with Visual Studio, the developer has a “palette” with components that are dragged, dropped and connected to form an application. Then, at runtime, the appropriate access methods or application programming interfaces (APIs) are invoked to run the application.

The framework allows companies to optimize use of their existing IT investment while taking advantage of a powerful tool for developing new programs. Together, .NET and Web services can integrate disparate computing systems and applications. The framework frees organizations from the limitations imposed by proprietary technologies and it helps lower information infrastructure costs by providing developers with tools to quickly build new applications.

Key Features of the .NET Framework
Base Class Library: The Base or Framework Class Library provides classes that encapsulate common functions like file reading and database interaction.

Common Runtime Engine: Programming languages on the .NET framework compile into a common intermediate language. This is compiled into native code. These concepts together are known as the Common Runtime Language.

Interoperability: The .NET framework provides interoperability between new and existing applications.

Language Independence: The .NET framework supports development in multiple languages.

Security: .NET has improved security that is easier to implement.

Simplified Deployment: New deployment mechanisms in .NET eliminate many of the challenges associated with Windows application deployment. —A. M.

Access to data
As a software development tool, .NET represents an evolution of many different Microsoft technologies, notes Cal Arabshahi, technical leader for the .NET Data Provider for Teradata. One key aspect of the evolution is ActiveX Data Objects (ADO or ADO.NET), which provides access to relational data sources like Teradata as well as XML documents. ADO.NET includes .NET Framework Data Providers for connectivity to relational data sources. “One of the things that applications have to do is talk to a database,” says Mazingo. “You need some way to connect.”

In many ways, .NET Data Provider is conceptually the successor to Microsoft’s Open Database Connectivity (ODBC) and Object Linking and Embedding Database (OLE DB) methods for connecting applications to databases. Microsoft developed ODBC in the early 1990s and OLE DB in the mid 1990s.

At that time, Microsoft’s primary focus was on integrating desktop applications through OLE. Over time, the company stepped up its efforts and released the Common Object Model (COM) as the basis for integration, and, in the database arena, OLE DB. A problem soon emerged, however; Visual Basic programmers could not use OLE DB. As a result, Microsoft released yet another database access layer for use with Visual Basic: ADO, designed to provide a consistent approach to accessing data regardless of the data structure.

At this point, within the Microsoft arena, a simple consistent programming model across programming languages simply did not exist. “There were a lot of [software development kits] and other ways of accessing the operating system,” Arabshahi says. “Microsoft needed a consistent and simplified programming model.” Enter the .NET framework, along with the .NET Data Provider for Teradata, as the method to access relational data within the framework.

The key to understanding the .NET Data Provider for Teradata, according to Arabshahi, is understanding ADO.NET. “ADO.NET is a new data access layer for .NET,” he says. “It is not just a port of ADO to the .NET framework.” ADO.NET provides several key pieces of functionality. First is interoperability. ADO.NET can be used to access both XML and relational data, but because data in ADO.NET can be transported in an XML format, it can also be read by any platform; moreover, ADO.NET is programming-language neutral. It can be used by a broad variety of modern programming languages including VB.NET and C#, as well as more established languages like C++, COBOL and FORTRAN. Finally, ADO.NET supports both a disconnected multi-tier model of computing and a connected model.

Designed for Windows and Web-based applications that are connected directly to the database, .NET Data Provider supplies the underpinning for data access in ADO.NET’s connected computing model. It can be used as a data access abstraction layer for packaged applications as well as for custom applications. It provides access to any relational databases.

.NET Data Provider for Teradata

.NET Data Provider
.NET Data Provider for Teradata is designed for Windows and Web-based applications providing direct data access to the Teradata Database.
For some time, Teradata users have been able to take advantage of the .NET framework using generic providers or bridges such as .NET Data Provider for OLE DB and .NET Data Provider for ODBC. But .NET Data Provider can also be customized to expose the unique features of different relational databases.

Earlier this year, after a yearlong development effort, Teradata released .NET Data Provider for Teradata. “We wanted to conform to the specification and expose the full feature set of the Teradata Database,” Arabshahi says.

The .NET Data Provider for Teradata 1.0 contains custom features, such as the ability to expose inline and deferred retrieval of large data objects (LOB). “Inline support is great for small BLOBs and CLOBs,” Arabshahi says. Character large objects (CLOBs) and binary large objects (BLOBs) are two new data types supported in Teradata Warehouse 7.1 and later versions. CLOBs may contain character or text data, such as documents, or XML. BLOBs may contain binary data such as pictures, audio or biometric data. Two new custom classes called TdBlob and TdClob have been added to support the retrieval of deferred LOBs.

Another noteworthy aspect of .NET Data Provider for Teradata is support for batch updates and for a feature called iterated requests. “In a nutshell,” Arabshahi says, “we have been trying to make sure applications have access to the full breadth and functionality of Teradata.”

The interest in the Teradata user community for .NET Data Provider for Teradata is high. “We know that we have a lot of customers who have adopted .NET as their application development platform,” Arabshahi says, “including many large customers who used the bridges available earlier.”

Users in the beta program were drawn from a broad array of customers, says Mazingo. “They come from all over: finance, healthcare, transportation. There’s been widespread acceptance.”

The release of .NET Data Provider for Teradata provides a useful resource for all Teradata customers who are developing applications within a .NET environment. Developers now have a single contact point for support when their applications access the Teradata Warehouse. The integration of Teradata functionality into the .NET environment will be more complete. “.NET Data Provider for Teradata has all of the facilities you need in .NET,” Mazingo says. T

© Teradata Magazine-June 2006

RELATED LINK:

Drivers and Connectivity Software


back to top




Copyright by Teradata Corporation 2001-2007.