Siebel Analytics Server Administration Guide > Setting Up a Siebel Analytics Server Repository >

About Repository Structure in the Administration Tool

The Siebel Analytics Server stores metadata in repositories. The Administration Tool has a graphical user interface (GUI) that allows Siebel Analytics Server administrators to set up these repositories. A Siebel Analytics Server repository consists of three layers. Each layer appears in a separate pane in the Administration Tool user interface and has a tree structure (similar to the Windows Explorer). You can expand each object to see a list of its components. These layers are not visible to the end user.

Most windows and dialog boxes have online help containing information to help you complete a task. To access a help file, click the help button in a window or dialog box.

This section contains an overview of the layers of an Analytics repository and provides instructions for creating a repository file, the first step in setting up a repository.

Physical Layer in the Repository

The Physical layer contains information about the physical data sources. The most common way to populate the Physical layer is by importing metadata from databases and other data sources. If you import metadata, many of the properties are configured automatically based on the information gathered during the import process. You can also define other attributes of the physical data source, such as join relationships, that might not exist in the data source metadata.

There can be one or more data sources in the Physical layer, including databases and XML documents. For information about supported databases, see System Requirements and Supported Platforms on Siebel SupportWeb.

For each data source, there is at least one corresponding Connection Pool. The connection pool contains data source name (DSN) information used to connect to a data source, the number of connections allowed, timeout information, and other connectivity-related administrative details. For details about connection pools, see Setting up Connection Pools. For more information about setting up the Physical layer, see Creating and Administering the Physical Layer in a Repository.

Business Model and Mapping Layer in the Repository

The Business Model and Mapping layer organizes information by business model. Each business model contains logical tables. Logical tables are composed of logical columns. Logical tables have relationships to each other expressed by logical joins. The relationship between logical columns can be hierarchical, as defined in business model hierarchies. Logical tables map to the source data in the Physical layer. The mapping can include complex transformations and formulas.

The Business Model and Mapping layer defines the meaning and content of each physical source in business model terms. The Siebel Analytics Server uses these definitions to pick the appropriate sources for each data request.

You can change the names of physical objects independently from corresponding business model object names and properties, and vice versa. Any changes in the underlying physical databases or the mappings between the business model tables and physical tables might not change the view in the end-user applications that view and query the repository.

The logical schema defined in each business model needs to contain at least two logical tables. Relationships need to be defined between all the logical tables. For information about creating business model schemas, see Data Modeling. For more information about setting up the Business Model and Mapping layer, see Creating and Administering the Business Model and Mapping Layer in a Repository.

Presentation Layer in the Repository

You set up the user view of a business model in the Presentation layer. The names of folders and columns in the Presentation layer appear in localized language translations. The Presentation layer is the appropriate layer in which to set user permissions. In this layer, you can do the following:

• You can show fewer columns than exist in the Business Model and Mapping layer. For example, you can exclude the key columns because they have no business meaning.
• You can organize columns using a different structure from the table structure in the Business Model and Mapping layer.
• You can display column names that are different from the column names in the Business Model and Mapping layer.
• You can set permissions to grant or deny users access to individual catalogs, tables, and columns.
• You can export logical keys to ODBC-based query and reporting tools.

For more information about setting up the Presentation layer, see Creating and Maintaining the Presentation Layer in a Repository.