Download Defining Aliases within your Datastore in Data

Defining Aliases within your Datastore in Data Services
When developing code within SAP’s Data Services enterprise information management tool; generally
requirements dictate having to extract and load data across multiple environments. Data Services
utilizes datastores to allow you to connect to a variety of different data sources such as a web service,
an adapter, or more commonly a database. Those database data sources can include everything from
SQL Server, Oracle, DB2, even Netezza. This blog will describe setting up datastores against a Netezza
database to utilize the alias functionality to simplify the process of migrating code from development to
production.
What is Netezza and how does Data Services connect to it?
Netezza is a powerful Data Warehousing appliance that integrates the database, server, and the storage
components into a single system. Netezza is purpose-built for data warehousing and is specifically
designed for running complex data warehousing workloads. As a result of using proprietary architecture
to deliver fast query performance, minimal tuning and administration, and high scalability; Netezza is an
ideal database system to use for your data warehousing needs. As with any relational database system,
Data Services can easily connect to Netezza using a datastore connection. Data Services can then import
the metadata that describes the data through that connection. If the metadata is identical across
multiple environments you can have multiple data configurations within one datastore:
Having multiple configurations within one datastore eliminates the need to create a datastore for every
single database you need to connect to; which can speed up development time and prevents
unnecessary clutter in your local object library. But are there any differences in how Data Services
connects to Netezza database tables, as opposed to say SQL Server tables?
How Data Services Intereprets Netezza Owner Names
One key difference between how Data Services connects with Netezza as compared to say SQL Server, is
how it interprets owner names. When you create an object in SQL Server, the default owner is usually
“dbo”. When you create an object in Netezza, the default owner is usually “admin”. The difference in
how Data Services reads the owners is that for SQL server, the actual owner name (dbo) will be read
when importing metadata or creating template tables in that environment. For Netezza, Data Services
reads the name of the database as the owner name, not the actual Netezza owner name of that object.
For example, let’s say you have a dataflow that extracts data from a single source table from the STAGE
datastore that points to the STAGINGTEST database with the owner name admin:
As you can see from the images above the EMPLOYEE table is sourced from the STAGINGTEST database
using the owner ‘STAGINGTEST’ which is the database not the owner name. How Data Services reads
owner names of table objects is something to always keep in mind when working with various database
platforms. Now that we have that out of the way, let’s discuss a case scenario for defining aliases.
Case Scenario
We will continue to use the images above as part of our case scenario example. In this example,
STAGINGTEST would be the environment where the development and subsequent testing of your
dataflow would take place. The production repository you are migrating to only contains the production
datastore connections, and the production table owner names which in this case would be named
STAGE not STAGINGTEST:
When you ‘get latest’ on that dataflow into the production repository you would then see two versions
of the table, the table with the production table owner and the table you just migrated with the
development table owner:
When attempting to execute the job, the job will fail against the Netezza database with a “Cross
Database Access” error:
So how do you resolve this? Do you create another datastore configuration that points to the
production database in your local repo and then switch the default configuration before migrating to
PROD? That would cause the same error because the table owner you have already specified for your
source table is still STAGINGTEST. Plus you may not have access to the production environment from
your local repository. Do you create two separate datastores (prod and dev, if you have access) and two
different versions of your dataflow, one to test and one to move to production? You could but that
would mean unnecessary extra development time. This situation is what makes defining aliases in your
datastores so beneficial.
Defining Aliases
Defining aliases in Data Services allows you to substitute your specified datastore configuration alias for
the real owner name when you import metadata for database objects. Therefore, when you are
migrating from development to production, Data Services uses the alias you have defined in your
datastore to automatically change the table owner name with the table owner name of your choice. In
this case, that owner name would be the production owner name: STAGE.
To define an alias in your datastore:
1) Right click the datastore in question and click edit:
2) Then click the Advanced button, then the Edit button again:
3) Scroll down to the bottom of your configuration, click on the Aliases (Click here to create)
section, and a ‘Create New Alias’ icon box will pop up:
4) Type the name of your production table owner, ‘STAGE’ then next to the Alias name under the
Configuration tab; list the name of the actual table owner of the table you are utilizing…..in this
case STAGINGTEST:
5) Now when you import your source table from the STAGINGTEST database…even though you are
using the STAGINGTEST table owner, DATA SERVICES reads the alias of that owner as STAGE:
Data Services allows you to speed up development time and simplify the process of migrating
code from development to production by using the alias functionality in your datastore
configuration to do the work of remapping owner names when moving across various database
environments.
Shaun Scott, Business Intelligence Consultant
Decision First Technologies
[email protected]
Shaun Scott is a business intelligence consultant specializing in data warehousing and ETL development.
Shaun delivers customized SAP BusinessObjects solutions for customers across all industries. With
Decision First Technologies, Shaun utilizes SAP Data Services, Universe Design, Web Intelligence, and a
variety of database technologies, including SQL server, DB2, and Netezza.