The primary name of an object in the
data catalog is represented in the same way as a UNIX
filename—a forward-slash-separated pathname. Many objects also have shorter
qualified names.
Windows and UNIX file systems use paths to name file:
C:\windows\winnt\pgm.exe or
/home/local/jdoe/myfile.txt
Data catalog names follow the same convention:
/Shares/myShare/myfile.txt
/System/LocalDomain/Services/DatabaseServices/MyDb/Query1
Every object in a data catalog has a single unique
pathname that is its primary name. You can use Data Federation links
to create secondary names for any object. Unlike hard links in a UNIX file
system, however, Data Federation hard links are not reference counted—there is
a primary link which, when unlinked, causes the underlying object to be
deleted.
Qualified Names
There are situations where using full pathname
syntax to call on a particular object in the
data catalog is either not appropriate or inconvenient.
For instance, when you invoke a database operation via a JDBC driver, JDBC
dictates that you use a dot-separated three-part name syntax for the
database operation. In other situations it is more
convenient to use an abbreviated syntax to identify users. These
syntaxes are called
qualified names—an alternative, usually shorter syntax
for the full catalog pathname.
The qualified name for a database operation takes
the form shown below; it includes the names of the Data Federation domain, the
database operation’s
database connector, and the database operation itself:
MyDomain.MyDBconnector.MyDBop
Data Federation expands such three-part names
into data catalog paths of the form:
/System/Domains/MyDomain/Services/DatabaseServices/MyDBconn/MyDBop
If the domain name is omitted from the qualified
name, LocalDomain is assumed.
This often allows you to shorten the three-part qualified name to a two-part name, such as MyDBconnector.MyDBop
or dataservice.MyDataservice.
Examples of Qualified Names
Data Federation recognizes qualified names for
the objects listed here. Use these syntaxes to specify objects for the Web services API, the CLI,
ODBC,
or JDBC.
| Database connectors
|
Unlike most other grid objects, which have three-part qualified names, a database connector has a qualified name with at most two parts:
[domain-name.]database-connector-name
When the domain name is that of the local domain, you can omit it.
|
| Data
services
|
There are two ways to specify a
data service. You can use:
domain-name.DATASERVICE.data-service-name
Note: The DATASERVICE part of the name is literal. Do not change the capitalization.
You can access a data service that has been
mapped to a table in a
metadata model in
WorkSpace Data Federation using the
metadata model and table names:
[domain-name.]metadata-model-name.table-name
For example, suppose there is a data service
called empDS in the Bedrock domain, and empDS has been mapped to a table called
Employee in the HumanResources metadata model. You can access the empDS data
service using either of these names:
- Bedrock.dataservice.empDS
- HumanResources.Employee
|
| Database operations
|
There are also two ways to specify a
database operation. You can use:
[domain-name.]database-connector-name.database-operation-name
As with data services, you can access a
database operation that has been mapped to a table in a metadata model in
WorkSpace Data Federation using the metadata model and table
names:
[domain-name.]metadata-model-name.table-name
|
| Virtual database operations
|
[domain-name.]VirtualDb.virtual-database-operation-name
Note: The VirtualDb part of the name is literal. Do not change the capitalization.
|
| SQL views, provisioned
|
[domain-name.]database-connector-name.SQL-view-or-table-name
|
| SQL views, generated
|
-
For a SQL view generated from a database
operation:
[domain-name.]database-connector-name.SQL-view-name
-
For a SQL view generated from a data service:
[domain-name.]DATASERVICE.SQL-view-name
Note: The DATASERVICE part of the name is literal. Do not change the capitalization.
-
For a SQL view generated from a virtual
database operation:
[domain-name.]VirtualDb.SQL-view-name
Note: The VirtualDb part of the name is literal. Do not change the capitalization.
|
|
Tables in relational databases
|
You can access a database table that has been mapped to a
table in a WorkSpace Data Federation metadata model using the
metadata model and table names:
[domain-name.]metadata-model-name.table-name
|
| View generators
|
View generators do not have qualified names, but in some situations (for example, in grid object archiving commands), you point to the view generator by pointing to the grid path of its generated view:
/GeneratedViews/view-name
|
|
Data Federation servers
|
When you are asked to provide
a server name, you can generally pass in just the name; you need not give the
entire catalog path.
When you connect a new server to a Data Federation domain, however, you must supply the server machine’s fully qualified DNS name (for example, bedrock.sybase.com) or its IP address.
|
|
Users
|
Instead of the full path to a user account,
you can provide a qualified name:
user-name@authservice-name.auth-service-type.domain-name
where
<authservice-name> is the name of the
grid authentication service to which the user belongs and
<authservice-type> is one of Ldap,
Grid, Nis. If you do not provide a domain name, LocalDomain is assumed. Qualified
names for users expand to data catalog paths of this form:
/System/domain-name/Services/AuthServices/auth-service-type/authservice-name/Users/user-name
|