td schema workbench

Teradata Schema WorkbenchUser Guide

Release 13.01B035-4106-060A

June 2010

The product or products described in this book are licensed products of Teradata Corporation or its affiliates.

Teradata, BYNET, DBC/1012, DecisionCast, DecisionFlow, DecisionPoint, Eye logo design, InfoWise, Meta Warehouse, MyCommerce, SeeChain, SeeCommerce, SeeRisk, Teradata Decision Experts, Teradata Source Experts, WebAnalyst, and You’ve Never Seen Your Business Like This Before are trademarks or registered trademarks of Teradata Corporation or its affiliates.

Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc.

AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc.

BakBone and NetVault are trademarks or registered trademarks of BakBone Software, Inc.

EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation.

GoldenGate is a trademark of GoldenGate Software, Inc.

Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company.

Intel, Pentium, and XEON are registered trademarks of Intel Corporation.

IBM, CICS, DB2, MVS, RACF, Tivoli, and VM are registered trademarks of International Business Machines Corporation.

Linux is a registered trademark of Linus Torvalds.

LSI and Engenio are registered trademarks of LSI Corporation.

Microsoft, Active Directory, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation in the United States and other countries.

Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries.

QLogic and SANbox trademarks or registered trademarks of QLogic Corporation.

SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc.

SPARC is a registered trademarks of SPARC International, Inc.

Sun Microsystems, Solaris, Sun, and Sun Java are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries.

Symantec, NetBackup, and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates in the United States and other countries.

Unicode is a collective membership mark and a service mark of Unicode, Inc.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Other product and company names mentioned herein may be the trademarks of their respective owners.

THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN “AS-IS” BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. IN NO EVENT WILL TERADATA CORPORATION BE LIABLE FOR ANY INDIRECT, DIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS OR LOST SAVINGS, EVEN IF EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The information contained in this document may contain references or cross-references to features, functions, products, or services that are not announced or available in your country. Such references do not imply that Teradata Corporation intends to announce such features, functions, products, or services in your country. Please consult your local Teradata Corporation representative for those features, functions, products, or services available in your country.

Information contained in this document may contain technical inaccuracies or typographical errors. Information may be changed or updated without notice. Teradata Corporation may also make improvements or changes in the products or services described in this information at any time without notice.

To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please e-mail: [email protected]

Any comments or materials (collectively referred to as “Feedback”) sent to Teradata Corporation will be deemed non-confidential. Teradata Corporation will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display, transform, create derivative works of, and distribute the Feedback and derivative works thereof without limitation on a royalty-free basis. Further, Teradata Corporation will be free to use any ideas, concepts, know-how, or techniques contained in such Feedback for any purpose whatsoever, including developing, manufacturing, or marketing products or services incorporating Feedback.

Copyright © 2010 by Teradata Corporation. All Rights Reserved.

mailto:[email protected]

Preface

Purpose

This book provides information about Teradata Schema Workbench, a tool used to manage relational-based multidimensional models for Business Intelligence (BI) clients. Teradata Schema Workbench is used to define OLAP metadata, for example cubes, dimensions, hierarchies, measures, and calculations, and define role-based security for these objects in order to control access when running multidimensional queries.

Teradata Schema Workbench is not directly sold with or bundled with Teradata Database or tied to Teradata Tools and Utilities releases.

Audience

This book is intended for use by:

• Data Warehouse and Teradata Database administrators

• Business Intelligence (BI) administrators

• OLAP database administrators

Supported Releases

This book supports the following releases:

• Teradata Database 12.00 and 13.00

• Teradata Schema Workbench 13.01

Use the same version of Teradata Schema Workbench as Teradata OLAP Connector unless the Teradata Business Intelligence Optimizer Release Definition states otherwise.

To locate detailed supported-release information:

1 Go to http://www.info.teradata.com/

2 Under Online Publications, click General Search3 Click Search

Teradata Schema Workbench User Guide 3

http://www.info.teradata.com/

PrefacePrerequisites

Prerequisites

The following prerequisite knowledge is required for this product:

• Relational database management systems including Teradata Database

• Structured Query Language (SQL) including Teradata SQL

• Multidimensional data modeling concepts and Multidimension Expressions (MDX) language

• Online analytic processing (OLAP) concepts including traditional OLAP tools and operations

• Connectivity software including the ODBC driver for Teradata

Changes to This Book

The following changes were made to this book in support of the current release. Changes are marked with change bars. For a complete list of changes to the product, see the Teradata Business Intelligence Optimizer Release Definition associated with this release.

Additional Information

Additional information that supports Teradata Business Intelligence Optimizer is available at the web sites listed in the table that follows. In the table, mmyx represents the publication date of a manual, where mm is the month, y is the last digit of the year, and x is an internal publication code. Match the mmy of a related publication to the date on the cover of this book. This ensures that the publication selected supports the same release.

Date and Release Description

June 201013.01

Initial release

4 Teradata Schema Workbench User Guide

PrefaceAdditional Information

Type of Information Description Access to Information

Release overview

Late information

Use the Release Definition for the following information:

• Overview of all of the products in the release

• Information received too late to be included in the manuals

• Operating systems and Teradata Database versions that are certified to work with each product

• Version numbers of each product and the documentation for each product

• Information about available training and the support center

1 Go to http://www.info.teradata.com/.

2 Click General Search under Online Publications.

3 Type 4104 in the Publication Product ID box.

4 Click Search.

5 Select the appropriate Release Definition from the search results.

Additional product information

Use the Teradata Information Products web site to view or download specific manuals that supply related or additional information to this manual.


2 Click Data Warehousing under Online Publications, Browse by Category.

3 Do one of the following:

• For a list of Teradata Tools and Utilities documents, click Teradata Tools and Utilities, and then select an item under Releases or Products.

• Select a link to any of the data warehousing publications categories listed.

Specific books related to Teradata Schema Workbench are as follows:

• ODBC Driver for Teradata User GuideB035-2509-mmyx

• Teradata Aggregate Designer User GuideB035-4103-mmyx

• Teradata Archive/Recovery Utility ReferenceB035-4103-mmyx

• Teradata OLAP Connector User GuideB035-4105-mmyx

CD-ROM images Access a link to a downloadable CD-ROM image of all customer documentation for this release. Customers are authorized to create CD-ROMs for their use from this image.


2 Click Data Warehousing under the Online Publications, Browse by Category.

3 Click CD-ROM List and Images.

Ordering information for manuals

Use the Teradata Information Products web site to order printed versions of manuals.


2 Click How to Order under Print & CD Publications.

3 Follow the ordering instructions.






PrefaceAdditional Information

General information about Teradata

The Teradata home page provides links to numerous sources of information about Teradata. Links include:

• Executive reports, case studies of customer experiences with Teradata, and thought leadership

• Technical information, solutions, and expert advice

• Press releases, mentions, and media resources

1 Go to Teradata.com.

2 Select a link.

Type of Information Description Access to Information


http://www.teradata.com/t/resources/

Table of Contents

Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Supported Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Changes to This Book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Chapter 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Solution Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Teradata Business Intelligence Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

What is Teradata Schema Workbench? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

What is Teradata OLAP Connector? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

What is MDX? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Chapter 2: Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Cube Schema Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Manually Creating the Cube Schema Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Creating and Using the Sample Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Listing Schemas in the Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Listing Schemas and Cubes in the Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

TBI Repository Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Mandatory Security Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26


Table of Contents

Chapter 3: Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Setting Up a Teradata ODBC Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Setting Up an EDW Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

Setting Up an MDX Service Account and OLAP Connection . . . . . . . . . . . . . . . . . . . . . . . . . .30

Opening a Cube Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Chapter 4: Introduction to the User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Main Window and Schema Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Main Menu and Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Schema Status Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

EDW Connection Status Bar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

Schema Editor Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

Schema Editor Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Schema Tree View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Schema Element Properties View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Schema Validation Error Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

Chapter 5: Cube Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Cube Schema Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Recommended Strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Schema Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

New Schema and Blank Cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

Creating a New Schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

Creating a New Cube. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

Cube Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

Creating a Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

Selecting a Format String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

Chapter 6: Dimensions, Hierarchies, Levels and Properties . . . . . . . . . . . . . . . .47

Dimensions and Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47


Table of Contents

Modeling Dimensions and Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Creating a Private Cube Dimension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Creating a Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Editing a Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Adding Tables to a Hierarchy Source Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Adding a Join Key to the Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Editing a Join Key in a Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Deleting a Join Key from a Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Levels and Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Adding a Dimension Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Inserting and Reordering Dimension Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Creating a Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Shared Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Creating a Shared Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Shared Dimension Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Creating a Cube Dimension Using a Shared Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Chapter 7: Save, Validate, Publish and Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Schema Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Save a Schema to the File System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Publish a Schema to the EDW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Copy a Schema to a Different EDW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Delete a Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Chapter 8: Cube Schema Localization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Add a Localization Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Localized Format Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Chapter 9: Security Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Map a Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Defining Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75


Table of Contents

Defining Cube Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75

Defining Dimension Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77

Defining Hierarchy Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78

Defining Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Aggregate Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81

Defining Member Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

Chapter 10: Calculated Measures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

Create a Calculated Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

MDX Expressions in Calculations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

Chapter 11: Advanced Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91

Create a Named Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91

Creating a Named Set for a Specific Cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91

Creating a Schema Scope Named Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91

Create Calculated Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93

Chapter 12: Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

High Performance Cube Development Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

MDX Validation Using MDX Sample. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96

Validating MDX Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96

Level Member Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97

Has Unique Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97

Column Cannot be Compound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98

AJI-Related Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98

Modeling Parent-Child Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98

Query Banding Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100


Table of Contents

Appendix A: Troubleshooting and Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

MDX Validation Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Format Strings and Currency Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Calculated Members Not Showing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

#VALUE or Nothing in Excel Spreadsheet Cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

“The query did not run...” Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

MDX Issues, Functions and Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

“Unable to Connect to Selected EDW” Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

“Unable to Establish Repository Connection” Message. . . . . . . . . . . . . . . . . . . . . . . . . . 106

Teradata Schema Workbench Event Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Known Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Microsoft Excel Spreadsheet Does Not Refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Multiple PivotTables Using the Same Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Ragged and Skip-Level Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

MDX Aggregate Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Use of Ampersand (&) Member Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Appendix B: Supported MDX Functions and Operators . . . . . . . . . . . . . . . . . . . . . . 109

MDX Function and Methods Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

MDX Operators Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Appendix C: Schema Workbench Toolbox. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Schema Workbench Repository Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Sample Database Loader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Appendix D: TBI Repository Grants Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

SQL Grants Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119


Table of Contents

Appendix E: Teradata OLAP Connector Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121

Metadata Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121

Permanent Entities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121

Transient Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122

Metadata Pre-fetching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122

Cell Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122

Appendix F: Teradata OLAP Connector Registry Settings . . . . . . . . . . . . . . . . . . .125

Registry Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125

Specialized Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126

Appendix G: Teradata OLAP Connector Logging Setup . . . . . . . . . . . . . . . . . . . . . . .129

Log Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129

Logger Registry Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129

Logger Registry Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137


List of Figures

Figure 1: Teradata Business Intelligence Optimizer Architecture . . . . . . . . . . . . . . . . . . . . . . 18

Figure 2: TBI Repository Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figure 3: Schema Tree Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Figure 4: Teradata OLAP Connector Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 5: Teradata Schema Workbench User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Figure 6: Teradata Schema Workbench Main Window and Schema Editor. . . . . . . . . . . . . . 35

Figure 7: Schema Status Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Figure 8: EDW Connection Status Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Figure 9: Schema Editor Toolbar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Figure 10: Schema Tree View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Figure 11: Example Fact Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Figure 12: Example Main Hierarchy Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Figure 13: Example of Creating a Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Figure 14: Adding a Table to a Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Figure 15: Adding a Dimension Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Figure 16: Main Hierarchy Table in a Shared Dimension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Figure 17: Using a Shared Dimension to Create a Cube Dimension . . . . . . . . . . . . . . . . . . . . 61

Figure 18: Modifying the Join Key(s) List of a Shared Dimension. . . . . . . . . . . . . . . . . . . . . . 62

Figure 19: Switching to Other Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Figure 20: Affected Cube Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Figure 21: Schema Validation Warnings and Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Figure 22: Adding Languages to the Localization Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Figure 23: Format String for Localization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Figure 24: Example of Withdrawing Access to a Cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Figure 25: Example of Withdrawing Access to a Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Figure 26: Example of Withdrawing Access to a Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Figure 27: Aggregate Policy Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82



Figure 30: Creating a Named Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Figure 31: Creating a Display Folder for a Named Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Figure 32: Validating MDX Formulas Using MDX Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . 97


List of Figures

Figure 33: MDX Validation Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102

Figure 34: Introduction to the Repository Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

Figure 35: Example of the Server and User Information for Repository Setup. . . . . . . . . . . .114

Figure 36: Example of a successful repository set up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116

Figure 37: Introduction to the Sample Database Loader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117


List of Tables

Table 1: File Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Table 2: View Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Table 3: Repository Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Table 4: Windows Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Table 5: Help Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Table 6: Schema Editor Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Table 7: Supported MDX Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Table 8: Teradata OLAP Connector Registry Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Table 9: Teradata OLAP Connector Specialized Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126


List of Tables


CHAPTER 1

Introduction

The following topics provide an introduction to Teradata Business Intelligence Optimizer (Teradata BIO):

• Solution Architecture

• Teradata Business Intelligence Repository

• What is Teradata Schema Workbench?

• What is Teradata OLAP Connector?

• What is MDX?

Solution Architecture

Teradata BIO is an enterprise-class, general purpose MDX-based solution for Relational Online Analytical Processing (ROLAP). The solution leverages Teradata Aggregate Join Indexes (AJIs) for optimal performance.

The Teradata BIO suite is a set of software components that work together to specify the multidimensional model for your ROLAP system, and provides run-time handling of MDX queries from various BI client applications.

The three major components in the Teradata BIO suite, shown in Figure 1 on page 18, are:

• Teradata Schema Workbench

• Teradata Aggregate Designer

• Teradata OLAP Connector


Chapter 1: IntroductionSolution Architecture

Figure 1: Teradata Business Intelligence Optimizer Architecture

The OLAP DBA, also known as the cube administrator, starts by using Teradata Schema Workbench to indicate how a star or snowflake schema and fact table in your relational database should be mapped to OLAP cubes, dimensions, hierarchies, levels, and measures. The resulting cube schema is published by Teradata Schema Workbench directly to your Teradata Enterprise Data Warehouse (EDW) for later use by run-time BI client applications.

The cube schema is also exported as XML in a .biml file to Teradata Aggregate Designer which generates optimal AJIs to support high performance MDX queries running on the defined cubes.

The client-side component is called Teradata OLAP Connector. It handles the standard MDX query language that is emitted by Excel, and other BI client applications, through the standard OLE DB for OLAP (ODBO) interface. This allows business analysts to perform real-time OLAP queries such as slice and dice, cross-tab reports, and dashboards direct to your Teradata EDW.


Chapter 1: IntroductionTeradata Business Intelligence Repository

Teradata Business Intelligence Repository

Teradata BIO works within the confines of your existing Teradata installation. Teradata BIO relies on star or snowflake schemas hosted in your database, accelerated by AJIs, and administered by native Teradata users and security roles. A star schema normally has a primary or fact table and one or more dimensional tables. A snowflake schema builds on the concept of a star schema and scales that technique to handle an entire data warehouse.

The Teradata Business Intelligence Repository (TBI Repository), shown in Figure 2, is a key component of the Teradata BIO solution. A TBI Repository stores the OLAP cube definition schemas and must be installed on each Teradata server. Cube schemas define the multidimensional model on top of your star or snowflake schema. AJIs, managed by Teradata Aggregate Designer, accelerate the aggregation required by MDX. Teradata users and roles are leveraged by Teradata BIO to control access to all data.

Figure 2: TBI Repository Architecture

What is Teradata Schema Workbench?

Teradata Schema Workbench is a user-friendly GUI used by an OLAP DBA to specify and manage the multidimensional model for your BI client applications. The OLAP DBA can easily and quickly select aspects of the EDW star or snowflake schema for use as dimensions, levels, hierarchies, measures, and calculated measures. You simply build the schema one element at a time. See Figure 3 on page 20 for an example.


Chapter 1: IntroductionWhat is Teradata Schema Workbench?

Figure 3: Schema Tree Example

Teradata Schema Workbench is often used with a design-time connection to the EDW. The DBA conveniently selects actual columns to use for ROLAP. All schemas are validated against the EDW before they are published and made available to business analysts. You can specify cube and dimensional security in terms of existing Teradata roles and can grant or deny access by database schema, cube, dimension, hierarchy, level, or member. For example, you can grant access to western sales information only to the Western Sales Manager role. Cube schemas can be published to an EDW for use with Excel and other MDX and ODBO tools. Excel works through Teradata OLAP Connector to generate optimal SQL.

With Teradata Schema Workbench, an OLAP DBA can use MDX expressions to specify business-oriented calculated measures and named sets such as Top 10 Products by Sales.

Teradata Schema Workbench works in either connected mode or disconnected mode. Connected mode requires a live connection to the EDW and simplifies schema definition by fetching appropriate metadata, such as table and column names, to enable fast pick-and-choose cube model definition. Disconnected mode requires no connection to the EDW, but requires you to specify all metadata.

You can save cube schemas as XML to a BI schema .biml file to work offline or as input to Teradata Aggregate Designer to create optimized AJIs.


Chapter 1: IntroductionWhat is Teradata OLAP Connector?

What is Teradata OLAP Connector?

Teradata OLAP Connector provides MDX query language services. It is an MDX provider, similar to a database driver for OLAP cubes.

Teradata OLAP Connector supports the ODBO standard interface that Excel and many other OLAP clients use to interact with an OLAP cube.

Figure 4 shows how the OLAP Connector sits between BI client applications, such as Microsoft Excel, and Teradata Database. Its job is to interpret any MDX language (with reference to the cube metadata in the TBI Repository) and send ROLAP-oriented, AJI-friendly SQL to Teradata Database.

Figure 4: Teradata OLAP Connector Architecture


Chapter 1: IntroductionWhat is MDX?

What is MDX?

MDX is a language that expresses selections, calculations, and metadata definitions against an OLAP database, and provides capabilities for specifying how query results are to be represented. It is a query language for multidimensional databases, analogous to SQL as a query language for relational databases. Teradata Schema Workbench uses MDX for defining calculations.

We assume that you are familiar with OLAP and the multidimensional data model. However you might not be familiar with MDX. Therefore, we suggest that you familiarize yourself with MDX before you proceed. If you have never seen MDX before, the book Fast Track to MDX provides an excellent introduction to the language.

Find useful references by searching for MDX Expressions and Multidimensional Expressions (OLE DB) in the Microsoft Developers Network Library at http://msdn.microsoft.com/en-us/library/default.aspx.


http://msdn.microsoft.com/en-us/library/default.aspx


CHAPTER 2

Configuration

The following topics provide configuration information:

• Cube Schema Repository

• TBI Repository Limitations

• Mandatory Security Roles

Cube Schema Repository

The cube schema repository, known as the TBI Repository, is a solution-maintained database used to manage the OLAP metadata of the Teradata BIO solution. It can be installed and configured on your database using the Workbench Toolbox described in Appendix C.

The Teradata BIO solution stores cube schema data and associated metadata in a database named TBI_REPOSITORY. The TBI Repository:

• Is self-managed by Teradata Schema Workbench. Do not add or subtract records manually.

• Does not take a lot of space because it does not store cube aggregation data. It only stores cube schema information you have entered using Teradata Schema Workbench.

• Does not need tuning or other optimizations. Do not adjust, compress, or add an index to the TBI Repository.

The TBI Repository contains two dozen tables, with views and macros, that do not relate to other tables on your server outside of the TBI_REPOSITORY database. The Teradata OLAP Connector, used by BI client applications, only reads from this information, with the exception of creating a few small volatile tables of coalesced metadata for the duration of an Excel session.

Repository creation involves the creation of three mandatory roles:

• TBI_USER

• TBI_WORKBENCH

• TBI_SERVICE

For more information on these roles, see “Mandatory Security Roles” on page 26.

The TBI_USER is used to grant individual user access rights to the TBI Repository. Any user intending to use Teradata OLAP Connector must be granted this role.


Chapter 2: ConfigurationCube Schema Repository

The TBI_WORKBENCH is used for granting DBAs and other users intending to have schema publishing rights to the TBI Repository. Without this right, a user will not have the privileges to load or publish from the TBI Repository.

The TBI_SERVICE is used for granting access to datasets, which are fact and dimension tables in your data warehouse, for the MDX Service Account. For more information, see “Setting Up an MDX Service Account and OLAP Connection” on page 30.

In addition to the three mandatory roles, additional roles need to be created for BI Excel users in order to specify their access to certain cube schema definition elements different from other groups of users. For more information, see Chapter 9: “Security Settings.”

Manually Creating the Cube Schema Repository

Before creating the cube schema repository, you should install Teradata Schema Workbench. For more information, see the Teradata Business Intelligence Optimizer Release Definition.

To create a cube schema repository using the Workbench Toolbox, see “Schema Workbench Repository Setup” on page 113. To manually create a cube schema repository, use the following procedure.

To manually create the repository

1 Using Windows Explorer, find the Repository directory.

The default directory specified during installation is c:\Program Files\Teradata\Teradata Business Intelligence Optimizer\13.01\Teradata Schema Workbench\Scripts\repository.

2 Execute TBI Repository DDL.sql.

3 Execute TBI Repository Grants.sql to set up access using Teradata roles for basic solution operation.

If the scripts run without errors, the TBI Repository is installed correctly.

Creating and Using the Sample Database

To create and use the sample database

1 Load the sample database by doing one of the following:

• Use the Sample Database Loader, which is a tool in the Schema WorkbenchToolbox, to load a sample database named TAADemo. See “Sample Database Loader” on page 116 for instructions.

• Manually load the supplied database archive, named ARCTAA, using the ARCMAIN utility. This archive file is located at c:\Program Files\Teradata\Teradata Business Intelligence Optimizer\13.01\Teradata Schema Workbench\Samples\database. Be sure to create the database before running ARCMAIN. Also, you need to create a simple script to do the load. ARCMAIN is a Teradata Tools and Utilities product. For more information, see Teradata Archive/Recovery Utility Reference


Chapter 2: ConfigurationTBI Repository Limitations

2 Load the TAADemoSchema.biml file using the procedure, “To open a cube schema stored in an .biml or .xml file” on page 31.

The TAADemoSchema.biml file is located at c:\Program Files\Teradata\Teradata Business Intelligence Optimizer\13.01\Teradata Schema Workbench\Samples\schema.

3 Publish the TAADemoSchema using the procedure, “To publish a schema” on page 67".

4 Configure your BI client application to use this new cube data source.

Refer to the Teradata OLAP Connector User Guide.

Listing Schemas in the Repository

To list all cube schemas in the repository

✔ SELECT ID, Name, MeasuresCaption, DefaultLanguage, BIWCreator, LastUpdateFROM tbi_repository.BIW_Schema

Listing Schemas and Cubes in the Repository

To list all schemas and cubes in the repository

✔ SELECT b.Name, a.name, Caption, IsEnabled, DatabaseName, TableName, Cache, DefaultMeasureFROM tbi_repository.BIW_Cube aJOIN tbi_repository.biw_schema b on a.schemaid=b.idORDER BY 1, 2

For information on the SQL grants script that create the three mandatory security roles and assigns them to the tables in the TBI Repository, see Appendix D: “TBI Repository Grants Script.”

TBI Repository Limitations

The TBI Repository has the following size limitations:

• Schemas in a repository: 231 -1

• Cubes in a schema: 128

• Dimensions in a cube: 1024

• Hierarchies in a dimension: 1024

• Levels in a cube: 1024

• No limit for the number of levels in a hierarchy or dimension

• Measures in a cube: 1024

• Calculated measures in a cube: 1024


Chapter 2: ConfigurationMandatory Security Roles

• Length of OLAP object names and identifiers (such as schemas, cubes, dimensions, etc.) and their captions: 100 characters

Mandatory Security Roles

At a minimum, three mandatory security roles must be set up for the Teradata BIO solution. Your solution installation documentation explains how these are created.

• TBI_SERVICE

This role should be granted access to all fact and dimension tables on the server that are to be used by the Teradata BIO solution. This broad access will be carefully restricted by the cube administrator for each cube and cube dimension using Teradata Schema Workbench.

The DBA must create one user associated with the TBI_SERVICE role, such as tbiservice, and keep the password confidential. This is called the TBI Service Account. The username and password are entered one time into the Teradata Schema Workbench, which puts them in the TBI Repository. The username and password are transmitted to and from the repository in encrypted form and are kept in the repository in encrypted form.

• TBI_WORKBENCH

This role is used by cube administrators to define cube schemas and set security on cubes and cube dimensions in Teradata Schema Workbench. All cube administrators should be assigned this Teradata Database security role.

• TBI_USER

All BI Excel client users that connect to Teradata BIO must have this role.

A user of a BI client application uses their normal database account and password to make the initial Excel connection. Teradata OLAP Connector ensures the user has the TBI_USER role before connecting to the Teradata BIO suite.

For more information, see “Setting Up an MDX Service Account and OLAP Connection” on page 30 and Chapter 9: “Security Settings.”


CHAPTER 3

Getting Started

The following topics provide basic information to get started using Teradata Schema Workbench:

• Setting Up a Teradata ODBC Data Source

• Setting Up an EDW Connection

• Setting Up an MDX Service Account and OLAP Connection

• Opening a Cube Schema

Setting Up a Teradata ODBC Data Source

Define a data source for each Teradata Database prior to connecting with ODBC. Use the Microsoft ODBC Data Source Administrator to create ODBC data sources and to configure the drivers.

To avoid being prompted for credentials, you can enter your password in one of the following:

• Teradata DSN

• Excel connection (.odc file)

• Excel spreadsheet

If you do not type an authentication username and password in the ODBC Driver Setup for Teradata Database dialog box while creating a DSN, you will be prompted each time you attempt to access a data source in Teradata Schema Workbench. If you do not define credentials in the DSN, Excel connection, or Excel spreadsheet, you will be prompted each time you attempt to connect to an OLAP data source from Excel.

Due to a known issue in all versions of Excel prior to Excel 2007 SP2, you will see a “Initialization of the data source failed” message before being prompted for credentials. You can safely dismiss it and enter your credentials.

Although you will receive a warning about entering a password for a Teradata DSN, it is stored and transmitted in encrypted form. However, your password is not encrypted if you store it in a Microsoft .odc or spreadsheet file.

If you save usernames and passwords in your Teradata DSN, the user must be in either the TBI_WORKBENCH or TBI_USER role. If you plan to use a Teradata DSN with Teradata Schema Workbench, the user must be in the TBI_WORKBENCH role. For Excel, the user must be in the TBI_USER role. If you save usernames and passwords, a separate DSN is required for each role.


Chapter 3: Getting StartedSetting Up an EDW Connection

To set up an ODBC data source

For 64-bit versions of Windows XP and Vista, you must use the 32-bit ODBC Data Source Administrator which is not available from the Control Panel.

1 Open Microsoft 32-bit ODBC Data Source Administrator.

For 32-bit versions of Windows Vista or XP, do one of the following:

• From the Windows desktop, click Start>All Programs>ODBC>32-bit ODBC Administrator.

• From the Windows desktop, click Start>Control Panel>Administrative Tools>Data Sources (ODBC).

For 64-bit versions of Windows Vista or XP, do the following:

a Using Windows Explorer, browse to c:\<Windows installation directory>\ SysWOW64\.

b Run odbcad32.exe.

Note: If you frequently create DSNs, you can create a shortcut to odbcad32.exe in an accessible location such as your Desktop. Double-click the shortcut to view, edit, and add new 32-bit DSNs.

The ODBC Data Source Administrator dialog box appears.

2 Click the System DSN tab.

3 Click Add.

The Create New Data Source dialog box appears.

4 Select Teradata.

5 Click Finish.

The ODBC Driver Setup for Teradata Database dialog box appears. Refer to the ODBC Driver for Teradata User Guide for assistance. See “Additional Information” on page 4.

6 Type the Data Source Name and the Teradata Server Name(s) or IP address(es).7 [Optional] Type an Authentication Username and Password.

8 Click OK.

Setting Up an EDW Connection

To set up an EDW connection

1 Open Teradata Schema Workbench.

The EDW connection status, located in the lower left corner of the main window, displays Not Connected.

2 Click Repository>Connect to EDW.

The Connect to EDW window appears.


Chapter 3: Getting StartedSetting Up an EDW Connection

3 From the Selection connection pane, select an EDW.

If you do not see anything on the Selection connection pane, be sure you have created a DSN. See “Setting Up a Teradata ODBC Data Source” on page 27.

4 If Teradata Database credentials are not in your DSN, a Database credentials required dialog box appears.

To enter your credentials:

a Select an option from the Authentication Method dropdown menu.

b Enter your username and password.

OR

Enter a credential string in the Authentication Parameter box.

c Click OK.

The source database pane is populated:

Note: The list of databases that displays excludes standard system databases.

By default, all source databases check boxes are selected so tables from different databases can be used for your cube dimensions and those tables can be located during validation.

If your password is not in your DSN and entering your password causes an error, recheck your username and password. Also check the Windows application event log for issues. To access the application log, see “Teradata Schema Workbench Event Logging” on page 106.

If you are connecting to a TBI Repository that has never been accessed, you will be prompted to set up an MDX Service Account. See “Setting Up an MDX Service Account and OLAP Connection” on page 30.

5 Click OK.

The EDW connection status, located in the lower left corner of the main window, displays Connected to EDW: <Teradata Database name>.

Now you are connected to the EDW. The next topic explains how to initially set up your service account and password. If your service account has already been set up, proceed to Chapter 4: “Introduction to the User Interface.”


Chapter 3: Getting StartedSetting Up an MDX Service Account and OLAP Connection

Setting Up an MDX Service Account and OLAP Connection

The MDX Service Account is an account that is needed to implement Teradata BIO security. It is an account that is created within the Teradata Database server and must have the TBI_SERVICE role. For information on roles, see “Mandatory Security Roles” on page 26. Every Teradata BIO-enabled Teradata Database must have an MDX Service Account with the TBI_SERVICE role assigned.

• This account is set up in the database by the Workbench Toolbox or the repository installation scripts.

• The username and password are additionally specified in the Service Account Settings of Teradata Schema Workbench as described below, which securely stores them in the TBI Repository.

• Teradata OLAP Connector accesses this information to satisfy OLAP queries emitted by BI client applications.

A user connection from the BI client application to the repository takes place in phases. The following explains the connection process:

1 Initially, when the BI client user connects to Teradata OLAP Connector using their Teradata user ID and password, the connection temporarily uses the user’s TBI_USER role to obtain the encrypted MDX Service Account credentials from the TBI Repository.

2 The initial connection is discarded. However, the user’s initial credentials are saved throughout the lifetime of the session for role mapping purposes.

3 Teradata OLAP Connector creates a new connection using the MDX Service Account with the TBI_SERVICE role assigned.

4 Teradata OLAP Connector invokes stored procedures which build restricted dimensional views for the session based on the user’s other roles.

5 Any queries sent by the BI client application are executed against these views.

Teradata OLAP Connector restricts access to cube schemas and their elements by using cube security and existing roles defined by the cube administrator using Teradata Schema Workbench. For information on how roles are used to implement cube security, see Chapter 9: “Security Settings.”

To change the MDX Service Account settings

Teradata OLAP Connector logs onto Teradata Database using an MDX Service Account. You can change the authentication method for the Teradata BIO solution.


2 Click Repository>Service Account Settings.

3 From the Authentication Method menu, select TD2, KRB5, or LDAP.


Chapter 3: Getting StartedOpening a Cube Schema

4 [Optional] If the authentication method is either KRB5 or LDAP, a parameter might be required. See your administrator or the ODBC Driver for Teradata User Guide.

Opening a Cube Schema

Now that you have completed the connection setup, you have access to the TBI Repository. If someone has already published a cube schema to the TBI Repository, you can open it at this point.

To open a cube schema from a BI repository


2 Click File>Open>From BI Repository.

3 Select one or more schemas.

To select adjacent schemas, click a schema and then drag the mouse to select all desired schemas.

To select nonadjacent schemas, click a schema, and then press Ctrl while clicking each additional schema.

To open a cube schema stored in an .biml or .xml file


2 Click File>Open>From BI Schema File.

3 Browse the schema directory under your installation directory.

The default directory is c:\Program Files\Teradata\Teradata Business Intelligence Optimizer\13.01\Teradata Schema Workbench\Samples\schema.

4 Select a schema.

5 Click Open.

The Teradata Schema Workbench installer maps the .biml extension to Teradata Schema Workbench so a user can double-click on a .biml from Windows Explorer to launch Teradata Schema Workbench. Teradata Schema Workbench also supports drag-and-drop of .biml and .xml files.

To open a cube schema from Windows Explorer

✔ From Windows Explorer, double-click a .biml file.

Teradata Schema Workbench launches and the schema opens.


Chapter 3: Getting StartedOpening a Cube Schema


CHAPTER 4

Introduction to the User Interface

Teradata Schema Workbench is a multiple document interface (MDI) application so each instance of a cube schema opens in a separate Schema Editor window inside the Teradata Schema Workbench main window. The Teradata Schema Workbench main window is used to create and maintain cube schema definitions and allows you to easily navigate a cube schema. Figure 5 shows the main window with three open cube schemas.

Figure 5: Teradata Schema Workbench User Interface

The following topics provide an introduction to the Teradata Schema Workbench main window and Schema Editor window:

• Main Window and Schema Editor

• Schema Editor Window


Chapter 4: Introduction to the User InterfaceMain Window and Schema Editor

Main Window and Schema Editor

The Teradata Schema Workbench displays a main window and a Schema Editor window and provides the following features:

• Schema Editor Titlebar - View the open schema name and location.

• Teradata Schema Workbench Menu and Toolbar - Use the menus to create, open, save, delete, validate, and publish schemas, and connect to or disconnect from an EDW. Use the toolbar to create, open, and save schemas.

• Schema Editor Toolbar - Use the toolbar to create or delete a cube, dimension, hierarchy, level, property, measure, calculated measure, or named set. Also create role mapping for cubes.

• Schema Elements - View the elements within your schema.

• Localization Element - Access the localization element.

Note: This element does not display until you add it.

• Schema Tree View - View the schema elements that you build and define.

• Schema Element Properties View - View the properties of a schema element chosen from the Schema Tree View.

• Schema Status Bar - Displays the status of the current schema.

• EDW Connection Status Bar - Displays the status of the EDW connection.

• Validation Error Log - View error logs after schemas have completed validation.

Note: This view only displays if errors occur during schema validation.

Figure 6 on page 35 shows the main window with one open schema.



Figure 6: Teradata Schema Workbench Main Window and Schema Editor

Main Menu and Toolbar

The main menu bar and toolbar are located at the top of the Teradata Schema Workbench main window. Table 1 describes the File menu.

Table 1: File Menu

Command Button Description

New BI Schema Creates a new schema.

Open>From BI Schema File

Opens existing schema from a BI Schema (.biml) file in the file system.

Open>From BI Repository

Opens existing schema from the EDW’s TBI Repository.

Save Saves the current schema to a file it was opened from.

Save As None Saves the current schema to a different file location.

Validate None Validates a schema.

Publish None Publishes a schema to the repository.



Table 2 describes the View menu.

Table 4 describes the Repository menu.

Table 4 describes the Windows menu.

Table 5 describes the Help menu.

Table 2: View Menu

Command Description

Toolbar Toggles on or off the main window toolbar.

Table 3: Repository Menu

Command Description

Connect to EDW Sets up a connection to the EDW.

Disconnect from EDW Closes the connection to the EDW.

Delete a BI Schema Deletes a BI schema in the EDW.

Service Account Settings

Modifies settings for MDX Service Account.

Table 4: Windows Menu

Command Description

New Window Opens a New Schema window.

Cascade Stacks all open windows so each window title bar is visible.

Tile Vertical Displays all open windows vertically so you can view two or more windows at the same time.

Tile Horizontal Displays all open windows horizontally so you can view two or more windows at the same time.

Close All Closes all open windows.

Arrange Icons Arranges all icons in a row across the bottom of the Teradata Schema Workbench main window.

Table 5: Help Menu


Contents Displays this user guide.


Chapter 4: Introduction to the User InterfaceSchema Editor Window

Schema Status Bar

The schema status bar, located in the lower left of the Teradata Schema Workbench main window, displays the location where the schema was opened from or saved to, including the day, date, and time it was opened or saved.

When a schema is modified, the word Modified displays to the right of the time.

Figure 7 shows an example of the schema status bar.

Figure 7: Schema Status Bar

EDW Connection Status Bar

The EDW connection status bar, located in the lower left of the Teradata Schema Workbench main window, displays the EDW connection status. It includes the DSN when connected to an EDW. Knowing which DSN you are connected to is helpful when opening, transferring, and publishing a schema from one EDW to another.

Figure 8 shows an example of the EDW connection status bar when connected.

Figure 8: EDW Connection Status Bar

Schema Editor Window

The Schema Editor is used to set the elements of the cube schema. You can open multiple schema editor windows to use different schemas as shown in Figure 5 on page 33.

Shown in Figure 6 on page 35, the Schema Editor titlebar contains the schema name with the schema file name in parentheses. If the file is opened from the menu with File>Open>From BI Schema File, the system file path displays in the schema status bar.

About Teradata Schema Workbench

None Displays the Teradata Schema Workbench version information.

Table 5: Help Menu (continued)




Schema Editor Toolbar

The Schema Editor toolbar contains buttons that work on certain elements within the schema. Some of these buttons might not be activated depending on which element you have selected in the Schema Tree View.

Figure 9: Schema Editor Toolbar

Table 6 describes the Schema Editor toolbar.

Table 6: Schema Editor Toolbar

Button Description

Creates a new cube in the schema.

Creates a new dimension to be shared across multiple cubes.

Dimension: Creates a new dimension for a cube.

Use a Shared Dimension: Creates a new dimension for a cube using a shared dimension.

Creates a new hierarchy for a dimension.

Creates a new level within a hierarchy.

Creates a new property for a level.

Creates a new measure for a cube.

Creates a calculated measure for a cube.

Creates a calculated member for a cube.

Creates a named set within a cube.

Creates a role mapping for the cubes.

Deletes any element created from the Schema Editor toolbar.



Schema Tree View

The Schema Tree View displays a tree of elements of the schema that can be built and defined. Vertically expand the tree to display more information for the elements.

As you make changes, the Schema Tree View automatically updates to reflect modifications made to the tree elements and properties.

You can use the shortcut menu to add new OLAP objects to the Schema Tree View. Add new objects by using the shortcut menu at any level of the tree.

To add new OLAP objects from the Schema Tree View

1 Click to highlight the parent of where you want the new object to be located.

2 Right-click to display the shortcut menu.

3 Select the object you want to create.

Figure 10 shows the shortcut menu when you right-click the Measures folder.

Figure 10: Schema Tree View

Schema Element Properties View

The Schema Element Properties View displays the properties for the element selected from the Schema Tree View. Each element has many settings that are important to their specification as well as data structures in the underlying Teradata Database that are required for the schema to be valid.

Property changes are immediately applied. Modified displays in the schema status bar after your change has been applied to the schema.



Schema Validation Error Log

The validation error log displays errors detected during schema validation. Each error in the schema validation is logged with its schema tree location and a message that describes the error.

To validate the schema and view a problematic schema element

1 Select File>Validate to validate the schema.

2 From the Validation Error Log, double-click the element listed under the Location column.

The Schema Element Properties View appears with the element highlighted with either a red error icon or yellow warning icon.


CHAPTER 5

Cube Schemas

The following topics provide information on creating new schemas and cubes:

• Cube Schema Development Process

• New Schema and Blank Cube

• Cube Measures

Cube Schema Development Process

Cube administrators must install Teradata OLAP Connector to test ROLAP cubes. Refer to the Teradata OLAP Connector User Guide for assistance. See “Additional Information” on page 4 to locate this resource. If errors occur while testing cubes, refer to the Troubleshooting chapter of the Teradata OLAP Connector User Guide.

Recommended Strategy

Following is the basic strategy to develop a high performing cube schema and cubes:

• Define a simple cube, dimension, hierarchy, level, and measure.

• Validate and publish the cube schema to the TBI Repository.

• Use Teradata OLAP Connector to test the cube schema to ensure it works with Microsoft Excel.

• Use your chosen Teradata Database tool to run the SQL Explain feature to verify you are hitting the AJIs.

• Gradually add more features and MDX calculations, verifying at each step that you are not missing AJIs.

For more information on developing, testing, and confirming AJI-accelerated performance of simple and complex MDX calculation-containing cubes, see Chapter 12: “Best Practices.”

Schema Validation

As you create the schema elements, Teradata Schema Workbench automatically validates the information you enter. When errors occur, they display to the left of the appropriate field as either a red error icon or yellow warning icon in the Schema Element Properties View. Although you can publish a schema to the TBI Repository if it contains validation warnings, you cannot publish a schema if it contains validation errors.


Chapter 5: Cube SchemasNew Schema and Blank Cube

While you are creating a cube schema, you can perform a more extensive validation by selecting File>Validate from the menu.

If you encounter errors, verify you have created:

• a cube

• a dimension for the cube

• a hierarchy for the dimension

• a level for the hierarchy

• a measure

After you create a cube and validate and publish the cube schema, use Teradata OLAP Connector to test the cube schema to ensure it works with Microsoft Excel or another BI tool. You will get a validation warning if you do not set a default measure.

New Schema and Blank Cube

Creating a New Schema

The schema name should be unique within the TBI Repository and can be up to 100 characters in length. Spaces, underscores (_), or dashes (-) are allowed in schema names. The following punctuation and special characters are not allowed in schema names:

. , ; ' ` : / \ * | ? " & % $ ! + = ( ) [ ] { } < >

Although you cannot publish an empty or partially-completed schema to the TBI Repository, you can save the schema in XML to a .biml file on your hard drive.

To create a new schema

1 From the Teradata Schema Workbench main window, click File>New BI Schema.

2 In the Name box, type a name for the new schema.

3 Select a default language from the menu.

4 Click File>Save.

The schema status displays Saved To with the file location and the date and time saved.

The next topic explains how to create a new cube.


Chapter 5: Cube SchemasNew Schema and Blank Cube

Creating a New Cube

After you create a schema, you can create a new cube and cube definition within a schema.

The cube name can be up to 100 characters in length. Spaces and dashes (-) are allowed in cube names. The following punctuation and special characters are not allowed in cube names:

. , ; ' ` : / \ * | ? " & % $ ! + = ( ) [ ] { } < >

When you create a new cube, leave the Default Measure blank and ignore the validation warning for now. It cannot be selected until measure have been defined for the cube. The default measure defines what cell measure displays when you drag dimensions to axes in Excel.

By default, the Enabled and Cache cell values check boxes are selected. We recommend leaving these check boxes selected. The Enabled check box indicates whether or not this cube is enabled (when published) for clients such as Excel. This allows you to publish a schema that has new aspects that are usable, but hide some defined and validated cubes from the Excel client user.

To create a new cube

1 From the Schema Tree View, right-click on the schema, and click New Cube, or click from the toolbar.

The Schema Element Properties View appears in the right pane.

2 In the Name box, type a name for the new cube.

3 Click in the Caption box.

The caption is automatically filled with the same name as the cube.

4 [Optional] Change the caption name.

The caption is a name that is displayed and can be localized to different languages in the BI client application. For more information, see Chapter 8: “Cube Schema Localization.”

Leave the Default Measure blank for now and ignore the validation warning.


Chapter 5: Cube SchemasCube Measures

5 [Optional] Clear the Enabled check box. By default, the check box is selected.

6 [Optional] Clear the Cache cell values check box. By default, the check box is selected.

7 Select a database from the menu containing a fact table of this cube.

8 Select a fact table to use for this cube within the selected database.

After you add measures to this cube, return to this cube definition to select a default measure. If you do not select a default measure, you will get a validation warning.

Cube Measures

Measures are fact data, typically numeric, that the user wants to explore aggregated along any dimension. Creating a measure involves designating a column in a fact table that you want to become a measure cell in the cube that can be aggregated.

For information on calculated measures, see Chapter 10: “Calculated Measures.”

Creating a Measure

To create a measure for a cube

1 From the Schema Tree View, right-click on the cube, and click New Measure, or click from the toolbar.


2 In the Name box, type a name for the new measure.


The caption is automatically filled with the same name as the measure.





5 Select the column of your fact table that you want to be designated as this new measure from the Measure Column menu.

The menu automatically populates with column names of the fact table specified for this cube if you are connected to the EDW.

6 Select an aggregator function from the Aggregator menu to aggregate the measure.

7 [Optional] Clear the Visible check box if you do not want the measure to be initially visible to BI client applications.

8 Type a format string or select a format string from the Format String menu.

For more information, see “Selecting a Format String” on page 45.

If the measure being created should be the default measure, return to the cube definition and set the default measure. The measure you just created is available from the Default Measure menu.

Selecting a Format String

When you are create a measure, the format string setting allows you to choose how the BI client application renders the measure selected in the Schema Tree View.

To select a format string

✔ Type a format string in the Format String box or select from the Format String menu.



Caution: A format string that begins with a dollar sign is a placeholder for the locale-specific currency for the operating system. In other words, the visual currency character changes as the operating system’s locale changes. For example, currency is formatted with the dollar sign character in the United States, but same currency is formatted with the Euro character in France. If you do not want the operating system’s locale to override the intended currency character, prefix the character with a backslash such as \$#,##0.00 or \$#,##0.

Allowing the locale to change your format does not do any mathematical currency conversion. Manually changing your format string from $#,##0 to €#.##0 also does not cause mathematical currency conversion.

Find useful information on format strings by reading Appendix D in MDX Solutions, 2nd ed. by George Spofford and by searching for format string contents (MDX) in the Microsoft Developers Network Library at http://msdn.microsoft.com/en-us/library/default.aspx.




CHAPTER 6

Dimensions, Hierarchies, Levels andProperties

The following topics provide information on creating dimensions, hierarchies, levels, and properties:

• Dimensions and Hierarchies

• Levels and Properties

• Shared Dimensions

Dimensions and Hierarchies

You can create a dimension with multiple hierarchies and levels. When you create a dimension, you can either create a private cube dimension in a specific cube that is usable only within that cube or create a shared dimension that can be used within multiple cubes. You can derive a specific cube dimension from a shared dimension.

Modeling Dimensions and Hierarchies

In a star schema, foreign keys in the fact table refer to dimensional table keys. When first defining a dimension in Teradata Schema Workbench, you specify the column(s) in the fact table that define the hierarchy or hierarchies of that dimension.

Figure 11 on page 48 shows a schema diagram with a product_id as the foreign key in the Sales Fact table for the Product1 dimension.


Chapter 6: Dimensions, Hierarchies, Levels and PropertiesDimensions and Hierarchies

Figure 11: Example Fact Table

Each hierarchy created using Teradata Schema Workbench must specify a Main Hierarchy Table. A hierarchy uses the Main Hierarchy Table to create join key mappings to the fact table. Every Main Hierarchy Table must map to the fact table. Other tables for the hierarchies (such as arms of a normalized “snowflake” schema) then map directly or indirectly to the Main Hierarchy Table.

Figure 12 on page 49 shows a Product table, Promotion table and Store table being used as Main Hierarchy Tables for the Product, Promotion and Store dimensions. Product Class is an example of an additional hierarchy table being mapped to the Main Hierarchy Table as part of a snowflake arm.

Teradata Schema Workbench also supports multiple column joins. For example, Promotion Schedule table in Figure 12 on page 49 is an example of a snowflake dimension table using a composite primary key; therefore, you must specify two columns for the join to the Promotion table.



Figure 12: Example Main Hierarchy Table

Teradata BIO does not handle ragged hierarchies where leaves are not all at the lowest level, nor skip-level hierarchies where some low level leaves do not descend from an immediately above parent level. For more information, see “Creating a Hierarchy” on page 51.

Creating a Private Cube Dimension

You can create dimensions that are only visible to a cube when they will not be useful in the definition of dimensions in other cubes.

When you validate or publish a schema, a warning displays if you do not have a Time dimension type. Although most cubes need a Time dimension type, it is not required and you can still publish the schema.

Also, a warning displays if the cube has more than one Time dimension type. We recommend having two hierarchies, each with levels consisting of time types.

For more information on foreign keys in fact tables, see “Modeling Dimensions and Hierarchies” on page 47.



To create a private cube dimension

1 From the Schema Tree View, right-click on the cube, and click New Dimension>Dimension,

or click from the toolbar.


Note: The Source Dimension menu is disabled because a shared dimension is not being derived.

2 In the Name box, type a name for the new dimension.


The caption is automatically filled with the same name as the dimension.


4 Select a dimension type from the Dimension Type menu.

Read more about dimension types by searching for available dimension types in the Microsoft Developers Network Library at http://msdn.microsoft.com/en-us/library/default.aspx.

5 Do one of the following to add foreign keys that exist in the fact table that apply to your dimension:

• If you are connected to a repository, select a foreign key from the Foreign Keys in Fact Table menu, and click Add. The menu automatically populates with column names from the fact table specified for this cube.

• If you are not connected to a repository, type a foreign key in the Foreign Keys in Fact Table box, and click Add.





Creating a Hierarchy

You can create a hierarchy for dimensions that are private to a cube. All hierarchies that belong to the same dimension share the same set of foreign keys.

Currently, the Teradata BIO solution only handles level-based dimension hierarchies. This means all hierarchies are balanced, with leaf members only at the bottom level. Parent-Child (that is value-based) hierarchies are not supported unless they have been transformed into a level-based star schema in the underlying database. For more information, see “Modeling Parent-Child Hierarchies” on page 98.

Most hierarchies in OLAP have a top level with one member and it is typically named All. This top level might be explicitly visible in some BI client applications, such as Excel 2003, or it might only show as grand total rows and columns in Excel 2007. When creating a hierarchy, you can select the Use All Member check box to automatically create the All top level.

To create a hierarchy for a shared dimension, see “Shared Dimension Hierarchy” on page 61.

To create a hierarchy for a dimension

1 From the Schema Tree View, right-click on a dimension, and click New Hierarchy, or click

from the toolbar.

The Hierarchy Wizard appears.

2 In the Name box, type a name for the new hierarchy.


The caption is automatically filled with the same name as the hierarchy.


4 Select the Use All Member check box to have Teradata Schema Workbench automatically create an All top level.

5 Click Next. 6 Select a database from the Database menu.

Note: If your fact table is in one database and a dimension table is in another, you should open more than one database when connecting to an EDW.

7 Select a table from the Main Hierarchy Table menu.

A Main Hierarchy Table is the first dimensional table off the fact table in a snowflake schema.



8 Select the join keys from the Hierarchy Table Keys menu.

The join keys for the Main Hierarchy Table must match the columns for the foreign keys in the fact table for the dimension that this hierarchy belongs to. The dialog box states how many keys it is expecting to join the fact table with the main hierarchy table, potentially a compound key. For more information, see “Modeling Dimensions and Hierarchies” on page 47.

9 Click Finish.

Figure 13 shows the settings for a Promotion hierarchy. Teradata Schema Workbench automatically created the All member and All level.

Figure 13: Example of Creating a Hierarchy



10 [Optional] Click Set Default Member to ALL to set the MDX default member to the All member.

If you have chosen to include an ALL level, the default member will already be set to the ALL member.

11 To override the ALL member, or if the All Level Name is blank, use MDX syntax in the Default Member box to specify the unique member name of the default member.

If there is no ALL level and you do not enter MDX syntax to specify a default member, the default member becomes the first member, based on the sort column of the highest level, furthest from the fact table.

Editing a Hierarchy

You can modify hierarchy properties such as name, caption, and default member, and the All member and All level settings using the Properties tab.

In snowflake schemas, if your Main Hierarchy Table for the Dimension hierarchy does not have columns for details of the higher levels, you must reference additional normalized tables. You can modify the underlying source data mappings for the hierarchy including adding secondary tables for the hierarchy and specifying the join keys using the Source Data tab.

To edit a hierarchy

1 From the Schema Tree View, vertically expand the Dimensions folder and select the hierarchy you want to edit.

2 From the Schema Element Properties View, edit the Name, Caption, Default Member, or All Member or All Level settings.

3 From the Schema Element Properties View, select the Source Data tab.

4 Select the join(s) or join key(s) you want to edit, and click Edit.5 From the Database menu, select the database where you want to add the table.

6 From the Table menu, select the secondary table for the hierarchy.

7 Select Update table references if you want to update the table reference in the underlying target database.

Adding Tables to a Hierarchy Source Data

In snowflake schemas, dimension tables are normalized meaning the dimension might consist of one or more tables in the underlying target database. The process of denormalization involves reducing redundant entries by grouping them to separate tables.

To add a table to a hierarchy

You can add a new hierarchy table, along with a join key mapping to the Main Hierarchy Table.





3 Click Add from the top pane.

4 Type or select from the menus for the JOIN to select an existing hierarchy table to map from.

5 Type or select from the menu for the TO to add a hierarchy table to which your snowflake is joining outward to.

6 Click OK.

Figure 14 shows an example of mapping promotion_district table to the promotion table that is the Main Hierarchy Table for the Promotion dimension.

Figure 14: Adding a Table to a Hierarchy

Adding a Join Key to the Hierarchy

Teradata Schema Workbench supports multi-column joins. You can add join keys to the hierarchy table.

Adding a join key to the hierarchy



3 Select the join table from the top pane.

4 Click Add from the bottom pane.

5 Type or select a key from the JOIN Key menu.

6 Type or select a key from the TO Key menu.



7 Click OK.

Editing a Join Key in a Hierarchy

You can edit the join key mappings in a hierarchy table.

Editing a join key in a hierarchy



3 Select the join from the top pane you want to edit.

4 Select the join key from the bottom pane you want to edit, and click Edit.5 Edit the key from the TO Key menu to modify the join key mapping in the hierarchy table.

6 Click OK

Deleting a Join Key from a Hierarchy

You can delete join keys from a hierarchy table.

Deleting a join key from a hierarchy

1 From the Schema Tree View, vertically expand the Dimensions folder and select the hierarchy you want to delete.


3 Select the join from the top pane.

4 Select the join key from the bottom pane you want to delete

5 Click Remove.


Chapter 6: Dimensions, Hierarchies, Levels and PropertiesLevels and Properties

Levels and Properties

Each level within a dimension typically represents a grouping of data sharing some logical attribute within a dimension. For example, cities within a geography dimension or quarters within a time dimension are considered levels. A level must belong to a hierarchy. Member properties are extra attributes (columns) associated with each member of a level.

All dimension members must be members of a level within a hierarchy.

Adding a Dimension Level

You can add a dimension level to a hierarchy.

To add a dimension level

1 From the Schema Tree View, vertically expand the Dimensions folder and right-click the hierarchy to which you want to add a new level.


2 In the Name box, type a name for the new level.


The caption is automatically filled with the same name as the level.



5 Type or select a level type from the Level Type menu.

Note: Currently, not all Microsoft level types are used by Microsoft BI tools.

Set the level type to hint at the type of data that the level represents. Be sure to properly set the level type for time levels. Some dimension type and level type values are used by MDX functions and by other tools and third party applications, for example PeriodsToDate, Account Intelligence, Currency Conversion Wizard.

Find a list of Microsoft 2008 BI tool level types by searching for LevelTypeEnum Enumeration in the Microsoft Developers Network Library at http://msdn.microsoft.com/en-us/library/default.aspx.

6 If the member column data for the level has members that are unique for that level, then check Has Unique Members to improve performance.





For more information, see “Level Member Columns” on page 97.

7 Select the level database where the level table resides from the Level Database menu.

8 Select the level table from the Level Table menu.

This table is from the level database that will be used as the source data for hierarchy members at this level.

9 Select a member column from the Member Column menu.

This member column exists in the level table and is used to represent member data for this level.

The values from the selected Member Column are used to construct cube schema member names; therefore, Teradata Schema Workbench does not support NULL or empty values for member columns. See “Level Member Columns” on page 97.

10 Select a name column from the Name Column menu.

If the name column selected contains abstract IDs, you can select another more descriptive column, if available. For example, if you have a product_id column associated with a product_name column, choosing the product_name column would be more descriptive.

11 Select a sort column from the Sort Column menu.

Note: Choose a Sort Column that represents an attribute of members of that level. For example, when selecting a custom sort order for a store location level called region, choose a column representing a region attribute.

If the sort column is not selected, the Member Column is used for sorting the level. If the Member Column contains abstract IDs and you want to sort on more meaningful data, use the Name Column as the Sort Column.

Figure 15 shows the properties for a newly-added Product level.

Figure 15: Adding a Dimension Level



Inserting and Reordering Dimension Levels

Reordering or inserting levels in the middle of a hierarchy has significant consequences.

First, changing the unique names for members of the hierarchy might invalidate MDX calculations that reference members of this hierarchy. For example, named sets created using the hierarchy’s levels or members might be invalid. Also, the default member of the hierarchy, which is specified by a unique name, might become invalid.

Secondly, any security policy defined for the hierarchy might be affected. If there are conflicting security policy changes for a hierarchy, a warning appears indicating that the conflicting policies must be removed and gives you an option to reconsider the level changes.

To insert a new level

1 From the Schema Tree View, vertically expand the Dimensions folder and select the hierarchy to which you want to add a new level.

2 Right-click and select New Level Here to create a new level above the selected level.

To reorder a dimension level

1 From the Schema Tree View, vertically expand the Dimensions folder and select the dimension you want to reorder.

2 Right-click and select Move Level Up or Move Level Down.



Creating a Property

Properties are attributes (columns) associated with dimension hierarchy members. For example, a Location dimension might have levels for country, state, city, and store. Each store might have a floor area property that might be used to calculate sales per unit floor area.

Member properties are specified as Property elements under a level.

Properties are optional and not required to validate and publish a cube schema.

To create a new property

1 From the Schema Tree View, vertically expand the Dimensions folder and select the level to which you want to add a new property.

2 Right-click and select New Property.


3 In the Name box, type a name for the new property.


The caption is automatically filled with the same name as the property.



6 Type or select a property database from the Property Database menu where the table for this property resides.

7 Type or select the property table from the Property Table menu.

8 Type or select a property column from the property table from the Property Column menu.

9 Select a property format style from the level table from the Property Format Style menu.

The Property Format Style formats how the property appears. For date columns, select Date. For time columns, select Time. For timestamp columns, select Date, Time, or Timestamp. For values containing fixed numbers such as an employee or account ID, select General to disable formatting. Selecting Numeric for an account number such as 1244883 results in the account number displaying as 1,244,883.


Chapter 6: Dimensions, Hierarchies, Levels and PropertiesShared Dimensions

Shared Dimensions

You can create dimensions that can be shared across multiple cubes in the schema. Shared dimensions belong to the schema, although they can be used by one or more cubes.

Create a shared dimension by specifying a main hierarchy table spec that is not attached in Teradata Schema Workbench to a fact table. You can build an entire snowflake schema arm in a shared dimension by specifying additional dimension tables. This arm is rooted in the main hierarchy table of the shared dimension. Graft this arm onto as many cubes (fact tables) as you want by creating a specific cube dimension based on a source shared dimension.

Creating a Shared Dimension

Unlike a cube-scoped dimension, after you create a shared cube dimension, the Foreign Keys in Fact Table box and menu are not available. Foreign keys are defined later when we create a cube dimension which is linked to a shared dimension.

To create a shared dimension

1 From the Schema Tree View, right-click on the Shared Dimensions folder and select New Shared Dimension.


2 In the Name box, type a name for the new shared dimension.


The caption is automatically filled with the same name as the shared dimension.



5 Type or select a dimension type from the Dimension Type menu.

Find a list of dimension types by searching for available dimension types in the Microsoft Developers Network Library at http://msdn.microsoft.com/en-us/library/default.aspx.





Shared Dimension Hierarchy

You can create a hierarchy/arm for a shared dimension using the same procedure in “Creating a Hierarchy” on page 51; however, there is a significant difference between hierarchies that are private to a cube and shared dimension hierarchies.

The mappings for dimensional table keys in the fact table for shared dimensions are maintained on the Main Hierarchy Table Join Key(s) settings in the Source Data tab. Figure 16 shows the Main Hierarchy Table for the Store Manager hierarchy in the Store shared dimension from a sample schema.

Figure 16: Main Hierarchy Table in a Shared Dimension

Note: In Figure 16, <FACT TABLE>, KEY1, and KEY2 (if needed) are template parameters for this shared dimension. The main hierarchy table will be the Store table in the sampledb. An actual cube dimension will join to this main hierarchy table using the main hierarchy table’s store_id key.

When you use the shared dimension to create a cube dimension, specify actual fact table column(s), as shown in Figure 17.

The store_id in Figure 16 is in the dimension table that you are joining to the store_id column in Figure 17 in the actual fact table for this actual cube dimension.

Figure 17: Using a Shared Dimension to Create a Cube Dimension



When a Join Key(s) list for the Main Hierarchy Table is added or removed, the change is reflected across all Main Hierarchy Tables for different hierarchies of the same dimension. The changes are also reflected in any cube dimension that derives from the shared dimension.

In this fact table, a store is identified by its number and the city that it operates in. Figure 18 shows the modification to the Join Key(s) list for the Main Hierarchy Table of a shared dimension.

Figure 18: Modifying the Join Key(s) List of a Shared Dimension

If you switch to other hierarchies that belong to the Store shared dimension, notice the Join Key(s) list for their Main Hierarchy Table has been modified. Figure 19 shows the change in Store Manager hierarchy by adding another join key to map to the fact table.

Figure 19: Switching to Other Hierarchies



Figure 20 shows the Store cube dimension is also affected.

Figure 20: Affected Cube Dimension

The order of the keys of a shared dimension is significant. The order of the keys of the shared dimension’s Main Hierarchy Table Join Key(s) must match the dimension key order when the shared dimension is used within a cube.

As shown in the previous example, store_number and store_city must appear in the exact same order when they are used in a cube dimension.

Creating a Cube Dimension Using a Shared Dimension

To create a cube dimension using a shared dimension

1 From the Schema Tree View, right-click on the cube where you want to create the new cube dimension.

2 Select New Dimension>Use a Shared Dimension.




3 Select a source dimension from the Source Dimension menu.

The Name, Caption, Dimension Type, and Fact Table Keys for the new dimension are automatically filled using the settings of the shared dimension.

4 For each key, use the Fact Table Column menu to select the column names from the fact table.

The order of the keys must match the order that they appear on the Main Hierarchy Table Join Key(s) settings of the shared dimension.


CHAPTER 7

Save, Validate, Publish and Transfer

The following topics provide information on saving, validating, publishing, transferring and deleting cube schemas:

• Schema Validation

• Save a Schema to the File System

• Publish a Schema to the EDW

• Copy a Schema to a Different EDW

• Delete a Schema

The three options that are available to save changes are:

• Save (only enabled if schema was opened from a schema .biml file).

• Save As (to a differently named or located .biml or .xml file).

• Publish to the TBI Repository in an EDW.

Note: Schemas in a repository are uniquely identified by their name.

Schema Validation

Before schemas can be published, they must be validated. Many schema element property values are validated on an ongoing basis as you type, select from menus, or make changes in the Schema Editor. The validation on a schema property element occurs as soon as you have changed a value of an element property in the Schema Element Properties View and focus is changed to another field.

When the schema validation fails, the Schema Element Properties View displays an icon next to the invalid property setting.

Figure 21 on page 66 shows a schema with a warning and an error. The elements that make this schema invalid are an empty caption and an unspecified default measure. The error and warning appear in the Schema Element Properties View, prompting you to enter the values for the caption and default measure.


Chapter 7: Save, Validate, Publish and TransferSchema Validation

Figure 21: Schema Validation Warnings and Errors

A schema fails to validate not only because there are some elements in error, but also if the schema does not meet minimum requirements to be useful. At least one of each of the following must be defined in your cube schema:

• cube

• dimension for cube

• hierarchy for the dimension

• level for the hierarchy

• a measure

If a schema fails to validate, it can still be saved to a .biml file. See “Save a Schema to the File System” on page 67.

MDX query language expressions and calculations in calculated measures, named sets, and calculated members are checked for syntax only. Validation can succeed even if the expression semantics are incorrect. See Chapter 10: “Calculated Measures.”

To validate a schema

For a schema to be validated against the database metadata, Teradata Schema Workbench must be connected to a repository.

✔ From the main window, click File>Validate On to start a full validation.

This validates against the repository information, such as existing database, column and role names, in the database to which you are connected.


Chapter 7: Save, Validate, Publish and TransferSave a Schema to the File System

Save a Schema to the File System

Cube schemas can be saved as a .biml file to your local hard drive. Save a cube schema to a file when:

• you want a file copy

• there is no database connection

• the schema is partially created

• the schema is partially modified

• the schema is invalid and does not validate

Schemas that contain duplicate names cannot be saved to file.

You can use the saved schema to export to Teradata Aggregate Designer to help generate appropriate AJIs to accelerate your Teradata BIO solution.

To save a schema to its original location

The Save option is only enabled if the schema is opened from a schema .biml file.

✔ From the main window, click File>Save.

To save a schema with a different name or to a different location

The Save As option saves the schema (.biml or .xml file) with a different name or to a different location.

✔ From the main window, click File>Save As.

Publish a Schema to the EDW

A schema is validated before it is published. A schema that fails validation cannot be published to the TBI Repository, but it can be saved. See “Save a Schema to the File System” on page 67.

If the schema fails to validate, no changes are made to the TBI Repository.

To publish a schema

For a schema to be published, Teradata Schema Workbench must be connected to a repository.

✔ Click File>Publish.

The Schema Publication progress window displays “Schema publication was successful” if the schema is published.


Chapter 7: Save, Validate, Publish and TransferCopy a Schema to a Different EDW

Copy a Schema to a Different EDW

Schemas can be copied to a repository on a different server.

To copy a schema from one repository to another

For a schema to be copied, Teradata Schema Workbench must be connected to a repository.

1 From the main window, click File>Open>From BI Repository.

The Select Cube Schemas dialog box appears with a list of the schemas in the TBI Repository.

2 Select a schema, and click Open.

3 Click Repository>Disconnect from EDW.

4 View the EDW connection status bar to ensure it states Not Connected.

5 [Optional] If there is risk of overwriting a similarly-named schema in the target TBI Repository that you want to keep, rename your schema.

6 Click Repository>Connect to EDW to connect to the EDW where you want to copy the schema.

7 Publish the schema to this newly-connected EDW.

See “Publish a Schema to the EDW” on page 67.

Delete a Schema

A BI schema can also be deleted from the repository.

To delete a schema

1 [Optional] From the main menu, click File>Save As to back up the schema to be deleted to the local hard drive.

2 Click on Repository>Delete a BI Schema.

The Delete a BI Schema dialog box appears with a list of the schemas in the TBI Repository.

3 Select the schema to be deleted

4 Click Delete.

If there is no error message, you have successfully deleted the schema.


CHAPTER 8

Cube Schema Localization

A cube schema can be localized in Teradata Schema Workbench by specifying localized captions for schema elements. When a cube schema needs to make its various captions available in another language, you can use the Localization elements in the schema to specify the translation for the captions. You can also specify localized format strings.

The following topics provide information to guide you through the creation of Localization elements for your cube schema:

• Add a Localization Element

• Localized Format Strings

Add a Localization Element

When you create a cube schema in Teradata Schema Workbench, you must specify a name for the schema elements that you create. If the names are abstract or difficult to work with, you can specify captions for the elements. The cube schema localization feature enables you to provide multiple translations for these captions.

Teradata OLAP Connector substitutes translations for the appropriate captions based on the locale of the BI client application. When no translation is specified for the locale, the default caption is used.


Chapter 8: Cube Schema LocalizationAdd a Localization Element

To create a localization element

1 From the Schema Tree View, vertically expand the hierarchy to display the Localization element.

Figure 22: Adding Languages to the Localization Element

2 Click the Localization element in the Schema Tree View.

All captions and format strings that are used for the schema are visible in the Schema Element Properties View.

3 Select a locale from the Add Language menu to specify translations for captions in the selected language.

4 Click Add.

A column is created for the new language.

Figure 22 shows the result of adding a French (Canada) translation to the SampleSchema. You can see how the format string will appear by scrolling down.

5 In the column for the new language, type the captions for the new locale.


Chapter 8: Cube Schema LocalizationLocalized Format Strings

Localized Format Strings

In addition to captions, format strings can also be localized. When you select a format string for a measure from the Schema Element Properties View, a format string row appears under the Type column for Localization in the Schema Element Properties View. When you add a language, you can add a localized version for the format string. See Figure 23.

Figure 23: Format String for Localization

Caution: A format string that begins with a dollar sign is a placeholder for the operating system locale-specific currency character. In other words, the visual currency character changes as the operating system’s locale changes. For example, a USA English locale operating system uses a dollar sign ($) currency character, and a French locale operating system uses the Euro (€) currency character. If you do not want the operating system’s locale to override the intended currency character, prefix the character with a backslash such as \$#,##0.00 or \$#,##0.

Allowing the locale to change your currency character does not do any mathematical currency conversion. Manually changing your format string from $#,##0 to €#.##0 also does not cause mathematical currency conversion.

Find useful information on format strings by reading Appendix D in MDX Solutions, 2nd ed. by George Spofford and by searching for format string contents (MDX) in the Microsoft Developers Network Library at http://msdn.microsoft.com/en-us/library/default.aspx.




Chapter 8: Cube Schema LocalizationLocalized Format Strings


CHAPTER 9

Security Settings

The following topics describe how to map roles and define security:

• Overview

• Map a Role

• Defining Security

Overview

Teradata BIO implements security using standard Teradata Database security roles.

Teradata BIO requires the TBI_SERVICE, TBI_WORKBENCH, and TBI_USER roles to be defined by the DBA using normal database tools and assigned to users. For more information on these roles, see “Mandatory Security Roles” on page 26.

All BI client users and Teradata OLAP Connector users require access to the TBI_USER role. However, this role only allows the user to start up Teradata OLAP Connector. Access to individual cube schemas and cubes requires additional configuration.

Additionally, you will need to create more roles for each cube to implement the required level and granularity of security. For example, if you desire to allow universal access to your cube, you will need to create a role for this, such as TBI_<yourcube>_ALL, and map it into Teradata BIO by adding it to the list of Database Roles in the Schema Tree View.

Alternately, to provide restricted access by a subset of dimension, hierarchy, level, or level members, you need to create a role for that, such as TBI_<yourcube>_HIER_<HierRestriction1>, and map it into Teradata BIO. For example, you might create the roles TBI_SALES_HIER_REGIONWEST and TBI_SALES_HIER_REGIONEAST to control access to the Region hierarchy, the former with only access to the western region and the latter to the eastern region.

Teradata BIO implements security by mapping a Teradata security role into a given cube schema and allowing you to grant or deny access associated with this role. The list of usernames associated with a role is managed outside of Teradata BIO using normal database administration methods.

The DBA does not need to define restrictions on a cube's source table for a mapped role. Continuing with the previous example, you would create the roles TBI_SALES_HIER_REGIONWEST and TBI_SALES_HIER_REGIONEAST, assign user names to these roles and map these roles into your SALES cube using Teradata Schema


Chapter 9: Security SettingsMap a Role

Workbench. However, the DBA does not need to restrict access to the SALES' source tables by these roles.

The details of mapping roles into the Teradata BIO solution and then restricting access to particular cubes, dimensions, hierarchies, levels, and members is discussed in this chapter.

Map a Role

To allow a user access to Teradata BIO, you must map by identifying and specifying one of their Teradata Database roles, such as TBI_SALESCUBE_ALL, into the cube schema. Again, we are mapping a role from Teradata Database. This means the role should first be created within Teradata Database. In particular, validation will verify that all mapped roles exist within the chosen EDW.

Each Teradata Database role mapped into the Schema Tree View defaults to having full access to the entire schema after the schema is published. Unless you want them to see the entire schema, that is all aspects of all cubes, restrict that role in the Schema Tree View to just the cubes or other OLAP objects they should have access to.

If a user has multiple roles with conflicting rights on a schema, cube, dimension, hierarchy, level or members of a level, the most restrictive security is used.

To map a role

When you map a role, you give a role access to a particular schema.

1 Click File>Open to open a schema.

2 From the Schema Tree View, right-click on the Database Roles folder, and select New Role.



Chapter 9: Security SettingsDefining Security


• Type a role name in the Mapped Role box.

• If you are connected to a repository, select a role from the Mapped Role list.

Note: By default, the check boxes in the Permissions box are selected indicating the newly- mapped role has access to the entire schema.

4 Click anywhere inside the Schema Editor Window.

The new role appears under the Database Roles folder in the Schema Tree View.

Defining Security

Defining Cube Security

A Teradata role may be denied access to one or more cubes of a cube schema.

You cannot control access to particular cube measures using Teradata BIO security. If you want to prevent a user role from accessing certain measures, create a cube with less defined measures.

Changes to security policies take effect when the schema is published to the TBI Repository.

To withdraw access to a cube

1 From the Schema Tree View, select the role under the Database Roles folder.

The Schema Element Properties View displays in the right pane.

2 In the Permissions box, clear the check box next to the cube name to withdraw access to the entire cube.



3 If other OLAP permissions exist for the cube elements (for example, dimensions, hierarchies, levels, members), a prompt displays asking for approval to remove the security policies you have indicated. Click Yes to approve.

Example

1 Open a cube schema.

2 From the Schema Tree View, right-click on the Database Roles folder, and select New Role.


By default, the role has access to the entire schema.

3 The Mapped Role menu allows you to select an existing Teradata role to map the permissions onto. If this role does not exist yet, skip the mapping for now, and type HR_MANAGER in the Mapped Role box.

Note: This schema will not validate until the role is created.

In the Permissions box, you can see that the newly-created role, HR_MANAGER, is given full permission to all cubes by default.

4 Clear the check box for the Warehouse and Sales cube.

Figure 24 on page 76 shows the HR_MANAGER role has been restricted from accessing the Warehouse and Sales cube.

Figure 24: Example of Withdrawing Access to a Cube



Defining Dimension Security

For a dimension to be visible, a role must have access to the cube to which it belongs. A Teradata role might then be denied access to a specific dimension within that cube.

To withdraw access to a dimension



2 Expand the cube where the dimension resides.

Note: The role must currently have access to the cube.

3 In the Permissions box, clear the check box next to the dimension to withdraw access to the entire dimension.

4 If any policies exist for the dimension’s elements (for example, hierarchies, levels, members), a prompt displays asking for approval to remove the security policies you have

indicated. Click Yes to approve.

Example

Let us continue with the SampleSchema HR_MANAGER example from “Defining Cube Security”. We will withdraw access to the Product dimension for the HR_MANAGER role.

1 Select the HR_MANAGER role.

2 In the Permissions box, expand the permissions for the Sales and Employees cube. Currently, the HR_MANAGER role has full access to the Sales and Employees cube. As shown in Figure 24 on page 76, notice the dimensions and hierarchies under the Sales and Employees cube have their check boxes all selected.

3 Clear the check box for the Product dimension.

Figure 25 shows the HR_MANAGER role has now been restricted from accessing the Product dimension in the Sales and Employees cube.



Figure 25: Example of Withdrawing Access to a Dimension

If a hierarchy name in the Permissions box has a slightly highlighted background, there are more narrow security restrictions in the levels and members of the hierarchy. See “Defining Level Security” on page 79 and “Defining Member Security” on page 83.

Defining Hierarchy Security

For a hierarchy to be visible, a role must have access to the cube dimension to which it belongs. A dimension can have more than one hierarchy. For example, a Time dimension might have Calendar Year and Fiscal Year hierarchies. A role can be denied access to a specific hierarchy.

To withdraw access to a hierarchy



2 Expand the cube where the hierarchy resides.

Note: The role must currently have access to the cube and the dimension where the hierarchy is located.

3 In the Permissions box, clear the check box next to the hierarchy to withdraw access to the entire hierarchy.

If any policies exist for the hierarchy’s elements (for example, levels or members), a prompt displays asking for approval to remove the security policies you have indicated. Click Yes to approve.



Example

The following is an example on how to withdraw access to an entire hierarchy. You can also restrict access to a subset of levels in a hierarchy. See “Defining Level Security” on page 79.

Let us continue with the SampleSchema HR_MANAGER example from “Defining Dimension Security”. We will restrict access to the Store dimension’s Store State hierarchy for the HR_MANAGER role.


2 In the Permissions box, expand the permissions for the Sales and Employees cube and for the Store dimension.

Currently, the HR_MANAGER role has full access to the Store dimension. As shown in Figure 25 on page 78, notice the hierarchies and levels under the Store dimension have their check boxes selected.

3 Clear the check box for the Store State hierarchy.

Figure 26 shows the HR_MANAGER role has now been restricted from accessing the Store State hierarchy of the Store dimension.

Figure 26: Example of Withdrawing Access to a Hierarchy

Defining Level Security

A role can be denied access to a contiguous subset of levels in a hierarchy by specifying the Top Level and Bottom Level settings. Lowering the Top Level setting prevents users with that role from seeing the topmost aggregates.

Note: If you change All to another choice using the Top Level menu, the BI client user might not be able to see important information in the BI client application such as Grand Totals.

Raising the Bottom Level setting restricts how far an Teradata OLAP Connector user with that role can drill down. Use this setting when you do not want BI client application users to see individual fact table entries.



Teradata Schema Workbench defines how to compute aggregate values for levels by using the Aggregation Policy. For more information, see “Aggregate Policy” on page 81.

To withdraw drill down access to a level



2 Expand the cube where the hierarchy for the level resides.

Note: The role must currently have access to the hierarchy where the level is located.

3 In the Permissions box, select to highlight the hierarchy.

The permission settings for the levels under the hierarchy appear in the Levels tab.

The permitted levels are specified by the range that is set between Top Level and Bottom Level. For example, to exclude the All member for a hierarchy, select a level that is directly below it on the Top Level menu.

Example

Let us continue with the SampleSchema HR_MANAGER example from “Defining Hierarchy Security” by restricting the drill down access of the role to the Product dimension’s Products hierarchy, such that the role has drill down access only to Product Family and Product Department levels.


2 In the Permissions box, expand the permissions for the Sales and Employees cube.

3 Give the HR_MANAGER role full access to the Product dimension. Also, ensure that full access is available to the Products hierarchy.

4 In the Permissions box, click on Products.

The Top Level and Bottom Level default to All and Product, respectively, which indicates the user has drill down access to all levels of the Products hierarchy.



5 Select Product Department from the Bottom Level menu to remove drill down access to levels lower than Product Department.

Teradata OLAP Connector users with the HR_MANAGER role are now restricted from accessing the levels lower than Product Department.

If a hierarchy name in the Permissions box has a slightly highlighted background, there are more narrow security restrictions in the levels and members of the hierarchy. See “Defining Member Security” on page 83.

Aggregate Policy

The Aggregation Policy determines how Teradata OLAP Connector computes the aggregates for a level of the hierarchy if the security role of the user does not have complete access to the requested elements. In Teradata Schema Workbench, the two possible values for Aggregation Policy are unrestricted and restricted.

• Unrestricted

If the policy is set to Unrestricted, rolled-up aggregate values include all the members, regardless of member security.

For example, this might allow a Western Sales Manager to figure out eastern sales by subtracting western sales from national sales.

• Restricted

If the policy is set to Restricted, rolled-up aggregate values exclude members for which the user does not have access to.

In contrast to unrestricted, a restricted policy might display deceptive totals for national sales, since eastern sales are not included in the national sales that a security-restricted Western Sales Manager would see.



Let us look at a different example using the SampleSchema Product dimension and Store Sales measure. Figure 27 shows all the children for the Drink product family in Excel. The current user has complete access to the Drink product family and its children.

Figure 27: Aggregate Policy Example 1

Let us modify the role to restrict access of the user to Dairy. Figure 28 shows the role after it has been modified and the user’s view no longer includes Dairy. The aggregation policy is currently set to Unrestricted. Notice the rolled up aggregate value for Drink still includes the value from Dairy which is not accessible.


Let us modify the roll up policy to Restricted. Figure 29 shows the role after it has been modified. Notice the Store Sales value for Drink has changed and it no longer includes the Store Sales value for Dairy.




Defining Member Security

For a hierarchy Member to be visible, the user’s role(s) must have access to the Level to which it belongs. A role may be denied access to a specific Member.

To specify member access



2 In the Permissions box, expand the cube where the member’s hierarchy resides. Ensure the role has access to the cube and the dimension where the member’s hierarchy is located, as well as to the member’s hierarchy and level.

3 Click on the member’s hierarchy.

4 Click the Members tab.

5 Select the member’s level from the Available Levels menu.

The Available Levels menu is populated with the accessible members from the selected level for the current role.

6 [Optional] If the lower levels contains many members, you can reduce the number of displayed members. Type a partial or full member unique name in the Filter box and select Filter. The filter narrows the number of members in the Available Members box.



7 Select a member from the Available Members list and click the right arrow button to add it to the Selected Members box.

Repeat as necessary.

8 Select the policy to Allow or Deny the member in the Selected Members box.

If you choose to Allow the selected members, then access to all of the other members within this level and their descendants is withdrawn.

If you choose to Deny the selected members, then access to only the selected members and their descendants is denied.

Using Allow and Deny makes it easier to use levels with many members. For example:

• To grant access to 5 specific members out of 1,000, add those to the Selected Members box (perhaps even one at a time) and select Allow. This automatically restricts the other 995 members as if you had moved all 995 to the Selected Members box and specifically denied them.



• To grant access to all except 5 particular members, add those 5 exceptions to the Selected Members box and select Deny. This implicitly unrestricts the other 995 members, as if you had specifically allowed them.

Example

Let us continue with the SampleSchema HR_MANAGER example from “Defining Level Security.” Recall that a user with the HR_MANAGER role is restricted from drill down access to levels below Product Department for the Product dimension’s Products hierarchy. Let us also restrict access to the [Food] and [Non-Consumable] members of the Product Family level for the HR_MANAGER role.

1 Select the HR_MANAGER role

2 In the Permissions box, expand the permissions for the Sales and Employees cube and for the Product dimension.

3 Click on the Products hierarchy.

4 Click the Members tab.

5 Select Product Family from the Available Levels menu

6 Select [Food] and [Non-Consumable] from the Available Members box.

7 Click the right arrow to move them to the Selected Members box.

8 Click Deny.

The HR_MANAGER role can only access [Product].[Drink] and its children.

9 Click Product Department on the Available Levels menu to verify you cannot access children of [Food] and [Non Consumables].

The Available Members box only displays children members of [Drink].


CHAPTER 10

Calculated Measures

The following topics provide information on how to create calculated measures:

• Overview

• Create a Calculated Measure

• MDX Expressions in Calculations

Overview

Calculated measures are measures derived from other (stored or calculated) measures available in the cube. The calculations are specified as an MDX formula. The formula is saved in the cube schema definition. No calculated data is stored; the calculation is performed at query execution time.

Rather than requesting a restructuring of your fact table to have an additional column, creating a calculated measure allows the cube administrator to quickly add new measures that can be used in ad hoc query and reporting for timely business intelligence.

Note: To include a fact table column in a calculated measure, the column must first be defined as a measure using Teradata Schema Workbench.

MDX looks similar to SQL, but is actually quite different and conceptually more complicated. For more information, refer to the following books:

• Fast Track to MDX, 2nd edition, by Mark Whitehorn, Robert Zare, and Mosha Pasumansky and published by Wiley, 2006

• MDX Solutions, 2nd edition, by George Spofford and published by Springer, 2004

Create a Calculated Measure

If you had two normal stored measures called Product Cost and Product Selling Price, you could create a third measure called Product Profit. This measure would be derived using the following formula: Product Profit = Product Selling Price - Product Cost.


Chapter 10: Calculated MeasuresCreate a Calculated Measure

To create a calculated measure for a cube

1 From the Schema Tree View, right-click on your cube, and click New Calculated Measure.


2 In the Name box, type a name for the new calculated measure.





5 [Optional] To prevent measure visibility to BI client applications, uncheck the Visible check box.

6 Type the MDX query language formula for your calculation in the MDX Expression box and click Validate Expression to validate the MDX expression. For more information, see “MDX Expressions in Calculations” on page 89.


Chapter 10: Calculated MeasuresMDX Expressions in Calculations

Using fully qualified, bracket-delimited identifier names in your MDX is strongly recommended. For a list of supported MDX functions, methods and operators, see Appendix B: “Supported MDX Functions and Operators.”.

If an MDX validation error occurs, see “MDX Validation Errors” on page 102.

7 Type a format string or select a format string from the Format String menu.

For more information, see “Selecting a Format String” on page 45.

8 Type a number in the Solve Order box.

A cube can have calculated measures and other calculations such as calculated members. The value of a calculated measure or member’s Solve Order is used for disambiguating intersecting calculations. For example, calculations intersect when one calculation is on rows and the other is on columns. The specific Solve Order value does not matter. What matters is how the Solve Order value of one calculation compares to another. The calculation with the highest value takes precedence. We recommend using small positive integer values.

Find useful information by searching for solve order in the Microsoft Developers Network Library at http://msdn.microsoft.com/en-us/library/default.aspx.

Unless you are sure a non-default solve order is required, leave the value at zero.

MDX Expressions in Calculations

Teradata BIO supports a limited form of MDX partial qualification. Member names must always be fully qualified, but some expressions such as [Time].[Calendar].[Quarter].Members can be abbreviated to [Quarter].Members if Quarter is unique. Using fully-qualified names is the safest and most reliable method of expressing your calculation.

MDX expressions can be more complex. It is difficult to notice if there are unmatched pairs of brackets or many other syntax errors that could make an expression fail in Teradata OLAP Connector at runtime. Teradata Schema Workbench contains an MDX syntax checker (it is not a semantic checker) that catches many of these kinds of errors.



Chapter 10: Calculated MeasuresMDX Expressions in Calculations

The syntax error message only indicates whether the syntax is valid or not. You must reexamine the MDX to find the error. For more information, see “MDX Validation Errors” on page 102.


CHAPTER 11

Advanced Features

The following topics provide information on creating named set and calculated members:

• Create a Named Set

• Create Calculated Members

Create a Named Set

A named set is a set of dimension members that is complex, lengthy, or frequently used. Named sets are not supported by Excel 2003 or Excel XP (2002).

From a security point of view, Teradata BIO named sets are “globally scoped” meaning they are visible to users with access to the schema. Teradata Schema Workbench does not currently provide a security mechanism to control access to named sets. However, a user without the appropriate access and role to members explicitly named in the set will not be able to use the named set in BI client applications. Excel generates a “Query did not run...” message. For more information, see ““The query did not run...” Message” on page 104.

Creating a Named Set for a Specific Cube

In its set definition, cube-scoped named sets use members that belong to the dimensions specified in the cube. Adding a cube-scoped named set is similar to adding a schema-scoped named set. Cube-scoped named sets are added to the Named Sets folder that exists under the target cube in the Schema Tree View. For more information, see “Creating a Schema Scope Named Set” on page 91.

Creating a Schema Scope Named Set

Schema-scoped named sets are used with members that belong to a shared dimension.


Chapter 11: Advanced FeaturesCreate a Named Set

To create a schema-scoped named set

1 From the Schema Tree View, right-click on the Named Sets folder, and select New Named Set.


2 In the Name box, type a name for the new measure.


The caption is automatically filled with the same name as the measure.



5 Type the MDX expression in the MDX Expression box and click Validate Expression to validate the MDX expression.

See “MDX Expressions in Calculations” on page 89, Appendix B: “Supported MDX Functions and Operators,” and “MDX Validation Errors” on page 102.

Figure 30 uses the MDX Topcount function. It is also valid to enter a comma-separated list within braces of fully qualified members for the set.

Figure 30: Creating a Named Set

6 Select a hierarchy from the Hierarchy menu in which this named set will be displayed in BI client applications.


Chapter 11: Advanced FeaturesCreate Calculated Members

7 Type a display folder in the Display Folder box in which this folder will be displayed in BI clients applications. Figure 31 shows a newly-created display folder in Excel called Sets.

Figure 31: Creating a Display Folder for a Named Set

Create Calculated Members

A calculated member is a member whose value will be calculated at query execution run time. You can specify an MDX formula for the calculation. The formula and definition is saved in the cube schema definition. No calculated data is stored.

To create a calculated member for a hierarchy

1 From the Schema Tree View, right-click on the cube, and select New Calculated Member, or

click from the toolbar.



Chapter 11: Advanced FeaturesCreate Calculated Members

2 In the Name box, type a name for the new cube.





5 Select the parent hierarchy for the new calculated member from the Hierarchy menu.

6 [Optional] To prevent measure visibility to BI client applications, uncheck the Visible check box.

7 Type the MDX query language formula for the new calculated member in the MDX Expression box, and click Validate Expression to validate the MDX expression. For more information, see “Create Calculated Members” on page 93.

For a list of supported MDX functions, methods and operators, see Appendix B: “Supported MDX Functions and Operators.”.

If an MDX validation error occurs, see “MDX Validation Errors” on page 102.

8 Type a number in the Solve Order box.

Solve order is an integer priority for your calculated member relative to other MDX calculations. Unless you are sure a non-default solve order is required, leave the value at zero.

Find useful information by searching for solve order in the Microsoft Developers Network Library at http://msdn.microsoft.com/en-us/library/default.aspx.



CHAPTER 12

Best Practices

The following topics provide best practice information that you should consider when using Teradata Schema Workbench:

• High Performance Cube Development Strategy

• MDX Validation Using MDX Sample

• Level Member Columns

• AJI-Related Best Practices

• Query Banding Administration

High Performance Cube Development Strategy

The recommended way to develop high-performance cubes is as follows:

1 Define a cube schema without any calculated elements, that is without calculated measures, calculated members, or named sets.

2 Publish the schema to the TBI Repository using Teradata Schema Workbench.

3 Use the Teradata OLAP Connector User Guide to set up your chosen BI client application to test the specified cubes defined in the cube schema.

4 Add AJIs to significantly increase query performance. Use the Teradata Database Explain feature to verify you are actually hitting the AJIs.

5 Create a calculated measure for a cube and test it. If the calculated measure does not generate the correct value, check to ensure the MDX expression is logically correct. To check if the MDX expression is semantically correct, see“MDX Validation Using MDX Sample” on page 96.

6 Use your Teradata Database Explain feature to verify the calculated measure is hitting the AJIs as expected. If the calculated measure is not hitting the AJIs, recheck the MDX expression of the calculated measure and adjust the AJIs.

7 Add custom named sets or calculated members. Repeat steps 5 and 6 to ensure the MDX expression is correct, and verify that the named set or calculated member is actually hitting the AJIs.


Chapter 12: Best PracticesMDX Validation Using MDX Sample

MDX Validation Using MDX Sample

Teradata Schema Workbench validates the syntax of MDX expressions that you enter for calculated measures, named sets, calculated members, and hierarchy default members. However it does not check the semantics of the MDX. Therefore, you should validate MDX expressions for correctness with another tool before using them in Teradata Schema Workbench to define calculations. Validating MDX Syntax explains how to use Microsoft Analysis Services 2000 MDX Sample to validate MDX fragments.

Validating MDX Syntax

In the hierarchy schema element settings, you can specify a default member for a hierarchy. If you do not select the All Member check box, you must enter a proper MDX expression for the default member to avoid an MDX error when the end-user uses the hierarchy with a BI client application.

Calculated members, calculated measures, and named sets also use MDX formulas to specify how their calculations should be performed.

You can incrementally construct and test MDX formulas to validate the hierarchy default member using Microsoft Analysis Services 2000 MDX Sample.

To download MDX Sample source code

1 Search for sql2000analysisservicessamples in the Microsoft Developers Network Library at http://msdn.microsoft.com/en-us/library/default.aspx.

2 Download sql2000analysisservicessamples.cab.

3 Install the samples.

4 Use Microsoft Visual Basic 6 to build the MDX Sample application.

Using the MDX Sample Application

1 Open the MDX Sample application.

The Connect dialog box appears.

2 In the Server box, type a DSN name that contains a saved Teradata username and password.

3 In the Provider box, type TeradataMDXProvider.

4 Click OK.

5 From the DB menu, select a schema.

6 Type a SELECT query using your hierarchy default member MDX on one of the axes.

7 [Optional] If necessary, wrap your formula with curly brackets, such as { and }, to satisfy the requirement for a set expression on an axis.

If the query runs successfully, the MDX expression is correct and valid.



Chapter 12: Best PracticesLevel Member Columns

Figure 32 shows how to use MDX Sample to validate MDX formulas. Use the Cube box to get the exact names for the schema elements, as they vary depending on the MDX provider. If you click and drag an element from the Cube box and drop it in the Sample Query box, a fully-qualified name generates for the element. If the formula is correct, the resulting row for your default member displays in the Query Results pane.

Figure 32: Validating MDX Formulas Using MDX Sample

Level Member Columns

Has Unique Members

When you create a level, there are benefits to flagging the members of that level as unique. The Has Unique Members checkbox allows the user to do this. This notion of member uniqueness is based on whether all the members of a level are not only unique to each other when considering a single common parent member, but they are unique including all other possible members for that level under all possible parents.

For example, an administrator is considering a Time hierarchy and creating a Month level with member names Jan, Feb, Mar, and so on. These same member names exist under each parent member at the Year level; therefore, these Month members are not unique. However, if the Month member names are defined as Jan2009, Feb2009, and Mar2009, then these members would only make sense under Year member 2009. Year member 2010 would have unique members Jan2010, Feb2010, Mar2010, and so on.

The advantage of using Has Unique Members is that shorter member names are generated, which can result in some solution performance improvements


Chapter 12: Best PracticesAJI-Related Best Practices

Column Cannot be Compound

Teradata Schema Workbench allows you to only select a single Member Column when defining a level. If you need a compound key, do one of the following:

• Change your model, that is the hierarchy table, so there is just a single ID key. This is the best option.

• Create a view of the hierarchy table that combines the underlying columns, perhaps again by concatenation.

• Change your model to two levels, where one level takes you down using one column and the next level below uses the other column. Be sure to clear the Has Unique Members check box on all the involved levels, up to the level in the hierarchy where members are unique (among all the members of the whole hierarchy) again. This is the simplest solution.

AJI-Related Best Practices

Modeling Parent-Child Hierarchies

Teradata Business Intelligence Optimizer only supports fully populated hierarchies. It does not support ragged hierarchies, where leaf nodes can be at different levels. Additionally, it does not support hierarchies that are modeled as a relational Parent-Child table.

If a hierarchy is defined within a Parent-Child table, it must be flattened into a normalized set of table(s). The following example demonstrates how to flatten a hierarchy from a Parent-Child table into a normalized dimension.

Example

In the TAA database, Tdat_Sales_Org contains the Parent Child relationships of the TAA Sales Organization hierarchy. The TAA Sales Organization hierarchy contains four levels (Business Unit, Division, Area, and Sales Center), with names defined in the Region_Name column.

The database example also contains a ragged hierarchy, in that European data has three levels of reporting, where Sales Center, for example, may not have any values. In this case the Organization hierarchy will have to be flattened and then evened out.

Use the following examples and descriptions as a guide to flatten Parent-Child hierarchies.

The following example is a DDL for the Parent Child table:

CREATE SET TABLE TAA.tdat_Sales_Org ,NO FALLBACK , NO BEFORE JOURNAL, NO AFTER JOURNAL, CHECKSUM = DEFAULT ( Region_id CHAR(9) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL, Region_Name VARCHAR(255) CHARACTER SET LATIN NOT CASESPECIFIC, Parent_Region_id CHAR(9) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL, Country_cd VARCHAR(255) CHARACTER SET LATIN NOT CASESPECIFIC)PRIMARY INDEX ( Region_id );


Chapter 12: Best PracticesAJI-Related Best Practices

The following recursive view example navigates through the parent child table, defining the levels of the Organization hierarchy:

create RECURSIVE viewSales_Org_VW (Region_id, Region_Name, Parent_Region_id, root.Country_CD, level ) AS (SELECT root.Region_id,root.region_Name, Parent_Region_id, Country_CD, 0 as level FROM Tdat_Sales_Org root WHERE root.Parent_Region_id = 'ALL'UNION ALL SELECT indirect.Region_id,indirect.Region_Name, indirect.Parent_Region_id, indirect.Country_Cd, direct.level + 1 FROM Sales_Org_VW direct, Tdat_Sales_Org indirect WHERE direct.Region_id=indirect.Parent_Region_id);

Once a recursive view is created, you can use CREATE TABLE as SELECT from view to add tables at each level of the hierarchy.

Since there are four possible levels, each level represented in the view can be used to create an individual table. To flatten all four levels, add one table for each level as follows:

1 Run the following statement to determine the number of levels in the hierarchy:

select max(level) from Sales_Org_vw;

2 Execute a Create table DDL for each level of the hierarchy, creating a snowflake representation of the hierarchy:

Create table TAA_Sales_Center (Sales_Center_ID, Sales_Center_Name,Area_ID, Country_Cd)as(Select Region_ID,Region_Name, Parent_Region_ID, Country_Cdfrom Sales_Org_VWwhere LEVEL = 4)with dataUnique Primary Index (Sales_Center_ID);

Create table TAA_Areas (Area_ID, Area_Name, Division_ID, Country_Cd)as(Select Region_ID,Region_Name, Parent_Region_ID, Country_Cdfrom Sales_Org_VWwhere LEVEL = 3)with dataUnique Primary Index (Area_ID);

Create table TAA_Divisions (Division_ID, Division_Name, Business_Unit_ID, Country_Cd)as(Select Region_ID,Region_Name, Parent_Region_ID, Country_Cdfrom Sales_Org_VWwhere LEVEL = 2)with dataUnique Primary Index (Division_ID);

Create table TAA_Business_Units (Business_Unit_ID, Business_Unit_Name, Top_ID, Country_Cd)as


Chapter 12: Best PracticesQuery Banding Administration

(Select Region_ID,Region_Name, Parent_Region_ID, Country_Cdfrom Sales_Org_VWwhere LEVEL = 1)with dataUnique Primary Index (Business_Unit_ID);

3 To even-out the ragged hierarchy, add rows to the appropriate table to enable the three-level European Hierarchies to match the four-level U.S. data. This can be done by adding rows to the 4th level.

In the TAA model, a European region code only goes down three levels to Area_id. For example, if an Area_id for a European region code is 09000015 in the TAA_Areas table, in order to join the transaction table, add rows into the TAA_Sales_Center table which have a 09000015 value for the Area_id column. This enables data from ragged hierarchies to join to your facts.

Query Banding Administration

Teradata OLAP Connector uses query banding, which enables Teradata Database job prioritization for BI Client application users. This provides an enhanced user experience when competing bulk processing is taking place on the database.

After connecting to Teradata Database, Teradata OLAP Connector automatically sets the query band for the session, such as an Excel session, as shown in the example below. The parameter {0}, including the braces, is replaced with the Teradata Database user ID of the client user. The parameter {1}, including the braces, is replaced by the current Teradata OLAP Connector version, for example 13.01.00.00.

The DBA can configure query band priority for a name/value pair to enable query band prioritization. For example, the priority can be set based on the application name/value pair, such as Application=Teradata OLAP Connector. You can also set the priority based on a userid name/value pair.

Example

SET QUERY_BAND='UserId={0};Application=Teradata OLAP Connector;Version={1};' FOR SESSION


APPENDIX A

Troubleshooting and Known Issues

This appendix helps you diagnose or work around common issues that Teradata Schema Workbench users may experience. Some errors that BI client users experience are also covered in this appendix because they can often be solved by a cube administrator using Teradata Schema Workbench.

Cube administrators using Teradata Schema Workbench also need to be very familiar with the setup, troubleshooting, and known issues described in the Teradata OLAP Connector User Guide.

If Teradata Schema Workbench itself has an issue, more information can be gathered. See “Teradata Schema Workbench Event Logging” on page 106.

Troubleshooting

The following topics provide troubleshooting information:

• MDX Validation Errors

• Format Strings and Currency Conversion

• Calculated Members Not Showing

• #VALUE or Nothing in Excel Spreadsheet Cell

• “The query did not run...” Message

• MDX Issues, Functions and Operators

• “Unable to Connect to Selected EDW” Message

• “Unable to Establish Repository Connection” Message

• Teradata Schema Workbench Event Logging


Appendix A: Troubleshooting and Known IssuesTroubleshooting

MDX Validation Errors

Figure 33 shows an MDX validation error. The syntax error message only indicates whether the syntax is valid or not. You must reexamine the MDX to find the error.

Figure 33: MDX Validation Error

A common mistake when pasting MDX expressions from Microsoft Analysis Services is an ampersand (&) prefix on member names. Microsoft Analysis Services and Teradata BIO do not generate the same member unique names. MDX expressions from one system will not work verbatim in the other, particularly those using & prefixes on member names. This is caught by the Teradata BIO syntax validator. You must supply proper member unique names.

Validation checks the syntax of your MDX expression, but not the semantics. An MDX expression could thus pass the validation process, yet not function properly in BI client applications. It is helpful to pre-validate the MDX formula semantics using another tool. See the Excel error message for semantic errors in ““The query did not run...” Message” on page 104 and “MDX Issues, Functions and Operators” on page 104.

To pre-validate MDX formula semantics, use a tool that connects through the ODBO interface specifically to Teradata OLAP Connector. Semantically test the MDX using the Teradata OLAP Connector provider’s actual characteristics straight to the data. In particular, it is helpful to get ‘member unique names’ from this type of an auxiliary tool, as these can vary from provider to provider. A tool such as MDX Sample provides the ability to inspect the cube structure using Teradata OLAP Connector and see the various unique names. For more information, see “MDX Validation Using MDX Sample” on page 96. The Microsoft Analysis Services 2000 MDX Sample application allows you to test the expression.



Format Strings and Currency Conversion

A format string that begins with a dollar sign, such as $#,##0.00, causes the currency character to be localized based on the locale of the Teradata OLAP Connector machine running the BI client application. If the value really is in dollars, use a backslash before the dollar sign, such as \$#,##0.00, to force the dollar sign to remain even on a machine with a different operating system locale. Find useful information on format strings by searching for format string contents (MDX) in the Microsoft Developers Network Library at http://msdn.microsoft.com/en-us/library/default.aspx.

Note: Manually changing the format string from $#,##0 to €#.##0 does not cause mathematical currency conversion.

Calculated Members Not Showing

By default in Excel 2007, calculated members defined in your cube schema do not appear.

Note: Calculated members are not a feature of Excel 2003 or earlier versions.

To display calculated members

1 Right-click any cell in your PivotTable, and select PivotTable Options.

2 Click the Display tab.

3 Select the Show calculated members from OLAP server check box.

4 Click OK.





#VALUE or Nothing in Excel Spreadsheet Cell

An OLAP measure cell in Excel can end up with nothing in it. Behind the scenes, this is called null or #VALUE. Either can occur in a Teradata BIO MDX calculated cell or a cell that sums up a lot of MDX calculated values. One cause is a divide-by-zero error in an MDX calculated measure or calculated member. Check to ensure there are no zeroes in any denominator anywhere among the many calculations that might be aggregated into a displayed calculated cell. The null or #VALUE result depends on whether the database or Teradata OLAP Connector does the calculation.

Wrap the calculation in an MDX IFF statement for a consistent behavior (NULL); for example, IIF(Measures.Cost=0, NULL, Measures.Sales/Measures.Cost).

“The query did not run...” Message

The Excel message, “The query did not run, or the database table could not be opened.” might display for several different reasons. Excel has a limited set of error messages it presents to users.

This message is a symptom of several kinds of errors that can only be caught by Teradata OLAP Connector at run-time. Following are two explanations with suggested solutions:

• If the permission in the Database Roles folder of the Schema Tree View does not allow the Excel user to access hierarchy members used in an MDX expression, change the security restrictions.

• Teradata Schema Workbench has dependable syntax checking of MDX expressions of calculated measures, named sets, and calculated members. However, a semantic error might get through to a BI client application. Check your MDX for semantics to correct this issue. For more information, see “MDX Issues, Functions and Operators” on page 104.

MDX Issues, Functions and Operators

MDX is a very sophisticated and intricate multidimensional query language. Each implementation of the language has some differences and nuances. It is not always valid to copy and paste from one implementation to another.

MDX errors that cannot be caught by the MDX checker/parser in Teradata Schema Workbench often result in the Excel message, “The query did not run, or the database table could not be opened.” Unfortunately, Excel messages are often too generic to reveal the exact cause of MDX issues. You will need to debug each error carefully to isolate the issue.

Following are suggestions to help you isolate issues when using Teradata OLAP Connector and MDX:

• For a list of MDX functions and operators that Teradata OLAP Connector supports, see Appendix B: “Supported MDX Functions and Operators.”



For example, the first parameter of the IIF function is a boolean expression that evaluates true or false. Teradata OLAP Connector only supports boolean expressions that compare strings or numerical values. The MDX ‘IS’ operator is not supported, but often can be replaced semantically using an expression similar to: UniqueName = ‘some string’.

• Entity unique names (dimensions, level, member, and so forth) are provider-specific. You can use an application, such as MDX Sample, to determine the unique names used by Teradata OLAP Connector. For information on MDX Sample, see “Validating MDX Syntax” on page 96.

• To avoid issues with spaces and special characters, bracket-delimit member names.

• Be sure member names are fully-qualified. Names for dimensions, hierarchies or levels can be partially-qualified as long as they are not ambiguous. Unfortunately, it is easy to have an ambiguous situation. For example, a dimension might have the same name as a hierarchy or level. Generally, we recommend you fully qualify and bracket-delimit all names.

• If available, pretest all your MDX using the MDX Sample application.

• Scripted subcubes, also called implicit crossjoins, are not supported. Following is an example and a workaround:

Example

Implicit cross-join (not supported):

select { ([Time].[Calendar Time].[ALL].[(ALL)].children, [Measures].[Sales]), ([Time].[Calendar Time].[ALL].[(ALL)].children, [Measures].[Gross Profit]) } on columns, [Store Type].[Store Types].[ALL].[(ALL)].children on rows from [XYZ]

Workaround:

selectCrossJoin([TIME].[CALENDAR TIME].[ALL].[(ALL)].children, {[Measures].[Sales], [Measures].[Gross Profit]}) on columns, [STORE TYPE].[STORE TYPES].[ALL].[(ALL)].children on rows from [XYZ]

“Unable to Connect to Selected EDW” Message

The Teradata Schema Workbench message, “Unable to Connect to Selected EDW” occurs when:

• A bad server name is in the DSN

• Network problems occur

To narrow the diagnosis using the Windows “Application” event log, see “Teradata Schema Workbench Event Logging” on page 106.



“Unable to Establish Repository Connection” Message

The Teradata Schema Workbench message, “Unable to establish repository connection. Please verify you have permission to access the repository, that it exists, and is the correct version.” might display for several reasons. Following are three explanations with suggested solutions:

• The Teradata Schema Workbench user does not have the TBI_WORKBENCH role. You can associate the user with the TBI_WORKBENCH role.

• The TBI Repository does not exist. Ensure the repository exists by looking for the TBI_REPOSITORY database on your server. Use a SQL script to list the cubes and schemas in the repository to ensure it responds. See “Listing Schemas and Cubes in the Repository” on page 25.

• You might have an old version of Teradata Schema Workbench or a version newer than the TBI Repository. The TBI Repository version number rarely changes. Use the following SQL to see the TBI Repository version number:

SELECT * from TBI_Repository.TBI_InstanceSettings WHERE Setting='TBI_REPOSITORY_VERSION‘

To narrow the diagnosis using the Windows “Application” event log, see “Teradata Schema Workbench Event Logging” on page 106.

Teradata Schema Workbench Event Logging

When Teradata Schema Workbench itself has a problem and is unable to supply extensive information to the user, an error event will be added to the Windows Event ‘Application’ log. Some messages that begin with “Unable...” will write to this log.

Some examples include:

• “Unable to Connect to Selected EDW” Message

• “Unable to Establish Repository Connection” Message

These messages record more detailed diagnostic information in the Windows ‘Application’ event log. The log contains several log streams.

To start the Windows Event Viewer

1 Click Start>Control Panel>Administrative Tools>Event Viewer from the Windows desktop.


• On Windows XP, look in the Application log.

• On Windows Vista, look in Windows Logs>Application.


Appendix A: Troubleshooting and Known IssuesKnown Issues

Known Issues

The following topics provide information on known issues:

• Microsoft Excel Spreadsheet Does Not Refresh

• Multiple PivotTables Using the Same Connection

• Ragged and Skip-Level Hierarchies

• MDX Aggregate Function

• Use of Ampersand (&) Member Prefix

Microsoft Excel Spreadsheet Does Not Refresh

When using Microsoft Excel to create an OLAP-sourced PivotTable, you can refresh to get new data that has been put into a cube in the last few minutes or a recently-changed new cube structure.

Teradata OLAP Connector uses a high-performance caching system of cell data and cube metadata. To increase performance, Teradata OLAP Connector avoids sending many queries to Teradata Database. Using the Refresh feature in Excel might not get the latest data because the query from Excel can be satisfied using the Teradata OLAP Connector cache.

The solution is to close the spreadsheet and re-open it.

Note: In Excel 2007, access the Refresh button by selecting the Data tab and then Connections.

Multiple PivotTables Using the Same Connection

You can have multiple PivotTables in a spreadsheet that share a common Office Data Connection (.odc). Any refresh will cause all PivotTables that use that connection to refresh which might cause a longer-than-expected delay.

The refresh can be caused by using Refresh button from the Data tab in Excel or from manipulating a pre-existing spreadsheet that you just opened.


Appendix A: Troubleshooting and Known IssuesKnown Issues

Ragged and Skip-Level Hierarchies

Teradata BIO does not handle ragged or skip-level hierarchies. A ragged hierarchy is where leaves are not all at the lowest level. A skip-level hierarchy is where some low level leaves do not descend from an immediately-above parent level. For information on how to model hierarchies, see “Creating a Hierarchy” on page 51.

We recommend altering your model in the fact table and dimension tables to avoid anomalies.

Use the following examples to organize hierarchies, levels, and members so skip-level hierarchies do not occur:

• Some U.S. cities, such as Washington, D.C., do not belong to a state because they are considered a district. If you create a separate level in the hierarchy for Washington, D.C., a hole or gap in the hierarchy is created. Consider categorizing Washington, D.C. as a state. Even though it is officially a district, there are no other districts in the United States structure so this would be acceptable and does not create a whole or gap in the hierarchy.

• Repeat the leaf name up at the level with the hole. Although this strategy does not work if your hierarchy contains names of U.S. cities. For example, associating Washington, the city, with the state of Washington would not be accurate.

• Copy the name of the parent of the hole down into the hole level. This might be a strategy applicable to skip-level and ragged hierarchies.

MDX Aggregate Function

When using the MDX Aggregate function in calculated measures, the spreadsheet cell displays a #VALUE error in BI client applications.

Use of Ampersand (&) Member Prefix

Cube administrators might copy MDX expressions from Microsoft Analysis Services and paste them into Teradata BIO calculated measures, calculated members, named sets, and default measures. Although Microsoft allows an ampersand (&) prefix on a friendly member name (not an actual member name), Teradata BIO does not support this prefix.

For a workaround, see “MDX Expressions in Calculations” on page 89.


APPENDIX B

Supported MDX Functions and Operators

To define names sets, calculated measures, and calculated members, you write MDX query language expressions using a variety of MDX functions, methods, and operators. The following topics provide information on supported MDX functions and methods, and supported and not supported operators:

• MDX Function and Methods Supported

• MDX Operators Supported

MDX Function and Methods Supported

.ALLMEMBERS

.CHILDREN

.COUNT

.CURRENTMEMBER

.DEFAULTMEMBER

.DESCENDANTS

.DIMENSION

.FIRSTCHILD

.FIRSTSIBLING

.HIERARCHY

.ITEM

.LAG

.LASTCHILD

.LASTSIBLING

.LEAD

.LEVEL

.MEMBERS

.NAME

.NEXTMEMBER

.ORDINAL

.PARENT

.PREVMEMBER

.PROPERTIES

.SIBLINGS

.UNIQUENAMEADDCALCULATEDMEMBERSAGGREGATEANCESTORSASCENDANTSAVGBOTTOMCOUNTBOTTOMPERCENTBOTTOMSUMCLOSINGPERIOD


Appendix B: Supported MDX Functions and OperatorsMDX Function and Methods Supported

COUSINCROSSJOINDISTINCTDRILLDOWNLEVELDRILLDOWNLEVELBOTTOMDRILLDOWNLEVELTOPDRILLDOWNMEMBERDRILLDOWNMEMBERBOTTOMDRILLDOWNMEMBERTOPDRILLUPLEVELDRILLUPMEMBEREXCEPTEXTRACTFILTERGENERATEHEADHIERARCHIZEIIF (Note: The first parameter of the IIF function is a boolean expression that evaluates true or false. Teradata OLAP Connector only supports boolean expressions that compare strings or numerical values.)INSTRINTERSECTISEMPTYLASTPERIODSLCASELENMAXMEDIANMEMBERTOSTRMINOPENINGPERIODORDERPARALLELPERIODPERIODSTODATERANKRIGHTROUNDSQRSTDDEVSTDDEVPSTDEVSTDEVPSTRIPCALCULATEDMEMBERSSTRTOMEMBERSUBSETSUMTAILTOGGLEDRILLSTATETOPCOUNTTOPPERCENTTOPSUMUNIONVARVARIANCEVARIANCEPVARP


Appendix B: Supported MDX Functions and OperatorsMDX Operators Supported

MDX Operators Supported

Table 7: Supported MDX Operators

MDX Operators Support Notes

: (range) Supported

+ (arithmetic addition) Supported

+ (unary positive) Supported

+ (string concatenation) Supported

+ (set union) Supported

- (arithmetic difference) Supported

- (unary negation) Supported

- (set exception) Not Supported

* (multiply) Supported

/ (divide) Supported

^ (power) Not Supported

< (less than) Supported

<= (less than or equal to) Supported

<> (not equal to) Supported

= (equal to) Supported

> (greater than) Supported

>= (greater than or equal to) Supported

IS Not Supported (often worked around using

UniqueName = ‘some string’)

AND Supported

NOT Supported

OR Supported

XOR Not Supported

-- (Comment) Supported

/*...*/ (Comment) Supported

// (Comment) Supported


Appendix B: Supported MDX Functions and OperatorsMDX Operators Supported


APPENDIX C

Schema Workbench Toolbox

The Schema Workbench Toolbox is designed to provide a user-friendly interface for performing administrative tasks related to the Teradata Schema Workbench and Teradata OLAP Connector. These tasks can also be executed manually by using the scripts provided by the installation.

The tool box provides the following tools:

• Schema Workbench Repository Setup

• Sample Database Loader

Schema Workbench Repository Setup

Before using Teradata OLAP Connector and Teradata Schema Workbench, the metadata repository utilized by these products must be created and configured. In addition, the roles and permissions related to users of the Teradata Schema Workbench and Teradata OLAP Connector need to be set up. Following the Wizard user interface style, the Schema Workbench Repository Setup tool gathers environment information and sets up the Schema Workbench repository.

Note: The Teradata Schema Workbench requires Sun Microsystems Java Runtime Environment (JRE) for Windows version 5 or higher.

To set up the Schema Workbench Repository

1 Click Teradata Business Intelligence Optimizer 13.01>Teradata Schema Workbench>Tools>WorkbenchToolbox from the Windows desktop.

2 Click Setup Schema Workbench Repository.

3 The program starts with an instruction page, as shown in the example in Figure 34 on page 114.

Schema Workbench Toolbox creates database objects, roles and sets up the appropriate permissions, therefore, you need to create a database user, which will be the owner of the repository database, with the permissions specified on this page. This must be completed before continuing to the next step.


Appendix C: Schema Workbench ToolboxSchema Workbench Repository Setup

Figure 34: Introduction to the Repository Setup

4 Click Next.5 Type the repository database information, as shown in the example in Figure 35.

Figure 35: Example of the Server and User Information for Repository Setup

For informative descriptions, you can position the mouse so the cursor is over each box.

a In the Teradata Server box, type the name of the Teradata server.

b [Optional] In the Port box, type the port.


Appendix C: Schema Workbench ToolboxSchema Workbench Repository Setup

c In the User Account box, type the name of the user account that will become the owner of the repository database.

d In the Password box, type the password.

e In the Perm Space (KB) box, type the amount of permanent space you want to allocate for the repository database. The repository database will contain tables, views, macros, and triggers associated with Teradata Schema Workbench.

f Click Next.6 If the specified perm space is too large in your environment and the following error

message appears, click OK, and then decrease the perm space, and click Next.

7 The repository database, called the TBI_Repository, should not exist before setting up the Schema Workbench Repository. If the TBI_Repository already exists, a message appears stating, “Database: TBI_Repository exists. The tool can not create the database.” Click OK and exit the Schema Workbench Toolbox.

8 Type the service account information.

a In the Service Account box, type the service account that will be used internally to manage access to the repository and the target Teradata Database.

b In the Password box, type your password.

c In the Retype Password box, retype your password.

d Click Next.9 The Setup Information dialog box appears where you can verify the database server, port,

permanent space, repository owner, and service account. Click Back to modify any information you inputted in previous steps.

10 [Optional] Click Preview script to review the scripts that will be executed when you finish the set up.

11 Click Finish to execute the set up scripts.

12 A The repository is successfully setup dialog box appears, as shown in the example in Figure 36 on page 116. Read the information, and then click Close.

If there is any error during the set up, the TBI_Repository database will be deleted and dropped so you can rerun Schema Workbench Repository Setup after the issue is fixed.


Appendix C: Schema Workbench ToolboxSample Database Loader

Figure 36: Example of a successful repository set up

Sample Database Loader

A sample database is provided for educational purposes and can be used with a cube schema.

The default location of the cube schema is:

c:\Program Files\Teradata\Teradata Business Intelligence Optimizer\13.01\Teradata Schema Workbench\Samples\schema\TAADemoSchema.biml.

Users can publish this schema after loading the sample database and then use Microsoft Excel, with an OLAP Connector configured data source, to perform queries against the defined cube. The repository should be set up before publishing the schema.

The Teradata Schema Workbench installation contains sample database files to be loaded.

Note: To manually load the sample database, use ARCMAIN to load a supplied database archive instead of using the sample database loader. See “Creating and Using the Sample Database” on page 24.



To load the sample database

1 Click Teradata Business Intelligence Optimizer 13.01>Teradata Schema Workbench>Tools>WorkbenchToolbox from the Windows desktop.

2 Click Load Sample Database.

3 The program starts with an instruction page, as shown in the example in Figure 37 on page 117.

Schema Workbench Toolbox creates database objects, roles and sets up the appropriate permissions, therefore, you need to create a database user, which will be the owner of the sample database, with the permissions specified on this page. This must be completed before continuing to the next step.

Figure 37: Introduction to the Sample Database Loader

4 Click Next.5 Type the sample database information.

For informative descriptions, you can position the mouse so the cursor is over each box.

a In the Teradata Server box, type the name of the Teradata server.

b [Optional] In the Port box, type the port.

c In the User Account box, type the name of the user account that will become the owner of the database.

d In the Password box, type the password.



e In the Perm Space (KB) box, type the amount of permanent space you want to allocate for the repository database. The repository database will contain tables, views, macros, and triggers associated with Teradata Schema Workbench.

f Click Next.6 If the specified perm space is too large in your environment and the following error

message appears, click OK, and then decrease the perm space, and click Next.

7 The sample database should not exist before setting up the Schema Workbench Repository. If the database already exists, a message appears, for example “Database: TAADemo exists. The tool can not create the database.” Click OK and exit the Schema Workbench Toolbox.

8 Click Select Folder and browse to the folder containing the sample database, select the folder, and click OK.

The default location of the sample database folder for the Sample Loader is c:\Program Files\Teradata\Teradata Business Intelligence Optimizer\13.01\Teradata Schema Workbench\Tools\SampleLoaderData\TAADemo.

9 Click Next.10 The sample database loading information appears where you can verify the database

server, port, permanent space, database name, and database owner. Click Back to modify any information you inputted in previous steps.

11 Click Finish to execute the set up scripts.

12 A status message appears indicating, The sample database is successfully loaded. Click OK.

If there is any error during the set up, the sample database will be deleted and dropped so you can rerun Load Sample Database after the issue is fixed.


APPENDIX D

TBI Repository Grants Script

The TBI Repository is a small dedicated database that stores the cube metadata that you enter into Teradata Schema Workbench. The repository does not store any cell data and especially not any pre-aggregated data.

The SQL grant scripts are being provided to let you see the names of the tables in the TBI Repository and are only published in this appendix for reference purposes. Notice the three key roles being created and assigned to about two dozen small tables.

SQL Grants Script

CREATE ROLE "TBI_USER";CREATE ROLE "TBI_WORKBENCH";CREATE ROLE "TBI_SERVICE";

GRANT SELECT ON TBI_REPOSITORY.TBI_ServiceAccount TO TBI_USER;

GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_CalculatedMember TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_CalculatedMemberProperty TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_Cube TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_CubeDimension TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_CubeFilter TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_Dimension TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_DimensionFilter TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_Hierarchy TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_HierarchyFilter TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_Join TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_JoinKeys TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_Level TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_LevelFilter TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_Measure TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_MemberFilter TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_NamedSet TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_Property TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_Schema TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_SchemaGrants TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.BIW_Translations TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.TBI_InstanceSettings TO TBI_WORKBENCH;GRANT SELECT, INSERT, UPDATE, DELETE ON TBI_REPOSITORY.TBI_ServiceAccount TO TBI_WORKBENCH;

GRANT SELECT ON TBI_REPOSITORY.TBI_CalculatedMember_VW TO TBI_SERVICE;GRANT SELECT ON TBI_REPOSITORY.TBI_CalculatedMemberProp_VW TO TBI_SERVICE;GRANT SELECT ON TBI_REPOSITORY.TBI_Cube_VW TO TBI_SERVICE;GRANT SELECT ON TBI_REPOSITORY.TBI_CubeDimension_VW TO TBI_SERVICE;GRANT SELECT ON TBI_REPOSITORY.TBI_Hierarchy_VW TO TBI_SERVICE;


Appendix D: TBI Repository Grants ScriptSQL Grants Script

GRANT SELECT ON TBI_REPOSITORY.TBI_Join_VW TO TBI_SERVICE;GRANT SELECT ON TBI_REPOSITORY.TBI_Level_VW TO TBI_SERVICE;GRANT SELECT ON TBI_REPOSITORY.TBI_LevelProperty_VW TO TBI_SERVICE;GRANT SELECT ON TBI_REPOSITORY.TBI_Measure_VW TO TBI_SERVICE;GRANT SELECT ON TBI_REPOSITORY.TBI_MemberFilter_VW TO TBI_SERVICE;GRANT SELECT ON TBI_REPOSITORY.TBI_NamedSet_VW TO TBI_SERVICE;GRANT SELECT ON TBI_REPOSITORY.TBI_Schema_VW TO TBI_SERVICE;GRANT SELECT ON TBI_REPOSITORY.TBI_InstanceSettings TO TBI_SERVICE;GRANT EXECUTE ON TBI_REPOSITORY.TBI_InitializeUserTmpTables TO TBI_SERVICE;

GRANT SELECT ON DBC.RoleMembersV to TBI_REPOSITORY WITH GRANT OPTION;


APPENDIX E

Teradata OLAP Connector Caching

Teradata OLAP Connector has a sophisticated caching architecture to provide high performance ad hoc queries.

Dimension metadata, except members, are read in and kept permanently in RAM for the duration of the ODBO session. Dimension member metadata is kept in a transient member cache. OLAP measure cell values are cached using a Least Recently Used (LRU) mechanism.

This appendix contains descriptions of the caching mechanisms and the changeable settings.

Caution: Do not change cache settings without consulting with the Teradata Global Support Center. For the location of these settings, see Appendix F: “Teradata OLAP Connector Registry Settings.”

Metadata Caching

The structure of an OLAP cube is represented by metadata entities such as dimensions, hierarchies, levels, and members. These entities are requested by ODBO clients throughout the course of an ODBO session. By caching entities on the client PC, Teradata OLAP Connector avoids retrieving metadata repeatedly from Teradata Database.

In terms of caching, there are two classes of metadata entity:

• Permanent Entities

• Transient Entities

Permanent Entities

Permanent metadata entities are as follows:

• Dimensions

• Hierarchies

• Levels

• Level properties

• Named sets

• Members of the Measure dimension

• Hierarchy default members

When an ODBO client requests a cube, all of the cube’s permanent entities are pre-loaded from the TBI Repository. These entities are cached for the duration of the ODBO session.


Appendix E: Teradata OLAP Connector CachingCell Caching

There is no limit placed on the maximum number of entities in this category. The assumption is that the number of permanent entities is always going to be low.

Transient Entities

Transient entities are retrieved from Teradata Database and cached on demand. Members are the only class of transient entity. Members are subject to expiration based on their usage frequency and the size of the metadata cache. The maximum metadata cache size can be configured using the MaxMetadataCacheSize registry key. This value sets the maximum number of members that can exist in the cache at any time and defaults to 1,000,000 if not set.

If adding newly-retrieved members to the metadata cache will cause the maximum size to be exceeded, stale entities are ejected. Stale entities are identified based on the frequency of their use, using a Least Frequently Used (LFU) algorithm. Members cached as part of a parent set are ejected together.

If a set of members has been requested and is too large to fit within the cache, the set is retrieved, but is not cached. When the current command has completed execution, the set is discarded. If the maximum metadata cache size is set to 0, all members are applied to this policy, effectively disabling the metadata cache.

Members are retrieved from the cache individually or as part of a parent set. For example, if a group of members are requested as part of the set [Product].[Products].Members, the cached members can fulfill future requests for individual members of the set.

Note: While Teradata OLAP Connector routinely ejects metadata from the cache during execution, all cached metadata is destroyed when the ODBO client session terminates.

Metadata Pre-fetching

Teradata OLAP Connector attempts to minimize the number of Teradata Database retrievals used to satisfy member metadata requests by pre-fetching members. When a request is made for a single member or for the children of a member, all members on that level are retrieved and cached. The maximum size of a level that is subject to pre-fetching can be configured using the PrefetchLevelSize registry key. This value defaults to 20,000 members. To disable member pre-fetching, set the value to 0.

Teradata OLAP Connector also attempts to pre-fetch measures with a SUM aggregator. The MaxMeasuresForPrefetch registry key specifies the maximum number of measures to pre-fetch. This value defaults to 20. When the number of measures in the cube exceeds this value, Teradata OLAP Connector retrieves the first N measure, where N is the value specified in the registry. Setting the registry value to 0 disables measure pre-fetching.

Cell Caching

Whenever a SQL query is executed against Teradata Database to fulfill a request for cell data (measures as opposed to metadata), the resulting cell data is cached. The cell cache uses a simple LRU algorithm.



The cell cache maximum size is specified by the MaxCellCacheSize registry key. The type is DWORD and the default value is 100 (decimal) in units of megabytes. A setting of 100 results in a 100MB cell cache. To disable the cell cache, set the size to 0.

While Teradata OLAP Connector ejects cached cell data during execution, all cached cell data is destroyed when the ODBO client session terminates.


APPENDIX F

Teradata OLAP Connector RegistrySettings

BI client applications connect to your EDW and the TBI Repository using Teradata OLAP Connector. Teradata OLAP Connector has useful administrative settings that are not documented in the Teradata OLAP Connector User Guide, whose audience is the BI client application user. BI client application users typically do not have permission to change the Windows registry.

Caution: Do not change the registry settings without consulting a Teradata BIO expert or the Teradata Global Support Center.

The registry location root for these settings depends on the BI client user’s operating system word width, 32-bit Windows or 64-bit Windows:

• Win32: [HKEY_LOCAL_MACHINE\SOFTWARE\Teradata\Teradata Business Intelligence Optimizer\13.01\Teradata OLAP Connector\RuntimeSettings]

• Win64: [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Teradata\Teradata Business Intelligence Optimizer\13.01\Teradata OLAP Connector\RuntimeSettings]

Registry Settings

The first four settings in Table 8 are cache and pre-fetch-oriented. To understand these settings before changing them, you must read Appendix E: “Teradata OLAP Connector Caching.”

Table 8: Teradata OLAP Connector Registry Settings

Key Type Default Value

MaxCellCacheSize DWORD 100 Approximately specifies the maximum size of the measure cell cache in MB. To disable cell cache, set value to 0.

MaxMetadataCacheSize DWORD 1000000 Specifies the maximum size of the dimension member metadata cache. The quantity specified is the maximum number of members to keep in cache between MDX queries. To disable cache, set value to 0.


Appendix F: Teradata OLAP Connector Registry SettingsSpecialized Settings

Specialized Settings

These settings are only published in this appendix for reference purposes.

Caution: Do not change these settings without consulting a Teradata BIO expert or the Teradata Global Support Center.

PrefetchLevelSize DWORD 20000 Teradata OLAP Connector always attempts to pre-fetch all dimension members in a level. If the level size exceeds this value, the level does not pre-fetch. To disable pre-fetching, set value to 0.

MaxMeasuresForPrefetch DWORD 20 The maximum number of measures to pre-fetch. To disable pre-fetching, set value to 0.

MaxCachedCalculatedSetSize

DWORD 10000 Specifies the maximum number of members in a calculated set. If the set exceeds this size, the set is not cached.

SqlQueryTimeout DWORD ODBC driver default

Specifies the amount of time, in seconds, a SQL query should wait before returning to the application.

Table 8: Teradata OLAP Connector Registry Settings (continued)


Table 9: Teradata OLAP Connector Specialized Settings


PushdownCalculations DWORD 2 Valid values:

0:Only use internal MDX engine.

1: Always push down to Teradata Database when supported by expression.

2: Only push down to Teradata Database when supported by expression AND the solve order is 0 AND all calculated members have a solve order of 0.

UseGroupingSets DWORD 2 Specifies the setting for SQL grouping set usage. Valid values:

0: Disable grouping sets.

1: Always use grouping sets.

2: Grouping set support auto detection from Teradata Database.



UseNullIfZero DWORD 1 Specifies the setting for controlling the use of NullIfZero in database-evaluated calculated measures involving division. When set to 1, the SQL expression wraps the denominator with NullIfZero. When set to 0, the SQL expression might fail if there is a division by 0 on Teradata Database.

UseQueryBands DWORD 2 Specifies the setting for query band usage. Valid values:

0: disable query bands.

1: always use query bands.

2: query band support auto detection from database.

Table 9: Teradata OLAP Connector Specialized Settings (continued)



APPENDIX G

Teradata OLAP Connector Logging Setup

This appendix contains information about how to enable logging, and where to locate the log file and logger registry settings for the Teradata OLAP Connector.

Log Location

Teradata OLAP Connector install sets the log location, but does not enable logging. The location of the log is determined by the user profile of the user who installed the software.

The log location is defined as:

%USERPROFILE%\Local Settings\Temp\TeradataProvider.log

The %USERPROFILE% environment variable is commonly set to:

C:\Documents and Settings\ {Username}

Logger Registry Location

Teradata OLAP Connector uses Windows registry settings to control logging and runtime settings. The base registry key used is:

HKEY_LOCAL_MACHINE\SOFTWARE\Teradata\Teradata Business Intelligence Optimizer\13.01\Teradata OLAP Connector\

The logger settings reside in the TraceSettings sub-key of this base registry key.

Logger Registry Setup

The Teradata Schema Workbench install includes registry scripts that enable and disable logging that captures MDX and SQL without impacting performance. These scripts must be run on the client machine running the instance of Teradata OLAP Connector you wish to monitor. The scripts are located at ..\ Teradata Schema Workbench\Scripts\registry in the install location.

Note: To run these scripts successfully, a user must have rights to modify the HKEY_LOCAL_MACHINE portion of the registry.


Appendix G: Teradata OLAP Connector Logging SetupLogger Registry Setup

To Enable or Disable the Logger for Teradata OLAP Connector

1 From the Teradata Schema Workbench directory, move a copy of the appropriate logger-enabling script to the target client machine:

• Win32 Teradata OLAP Connector Trace Settings ON.reg

• Win64 Teradata OLAP Connector Trace Settings ON.reg

2 From the Teradata Schema Workbench directory, move a copy of the appropriate logger-disabling script to the target client machine:

• Win32 Teradata OLAP Connector Trace Settings OFF.reg

• Win64 Teradata OLAP Connector Trace Settings OFF.reg

3 From the Teradata OLAP Connector target machine, Run the appropriate script to enable or disable the logger.

4 Restart the BI Tool hosting the Teradata OLAP Connector.

Note: Only these registry files should be used to enable or disable logging. Modifying the logger settings in the registry could have unintended results. Contact customer support for more information about logging.


Glossary

A

ad hoc query A query of which the system has no prior knowledge. An ad hoc query differs from a standard report, which looks for specific information in a specific format on a scheduled basis.

aggregate Summary data that provides definitions for aggregate tables that help optimize a cube.

aggregation The process of merging multiple data values into one value. For example, sales data collected daily can then be aggregated to the week level, the week data could be aggregated to the month level, and so on. The data can then be referred to as aggregate data. Aggregation and summarization are synonyms, as are aggregate data and summary data.

AJI Aggregate Join Index. Combines one or more commonly-used columns of the base tables with the results from one or more aggregation expressions pre-computed from one or more columns of the tables. This is used to improve query performance of summarized data.

attribute A characteristic of a dimension member in a logical data model, representing a set of dimension members. It is associated with a database column. For example, the Time dimension might have a Year attribute which represents the set of years in a database column.

B

base table A base table can be any table that acts as an origin of detailed data. In OLAP, the fact table is often considered to be the base table in a star schema.

C

calculated member A member of a dimension whose value is calculated from the values of other members.

children Members of a dimension that are subordinate to a parent member. Typically, children would be used in a calculation that created a consolidated total for the parent. Children can also have children, or levels that are subordinate to themselves. Children can have more than one parent.

client An OLAP client usually handles most of the presentation work, and only some of the processing. The OLAP server handles the rest of the processing.

cube A named collection of measures and dimensions. Measures and dimensions are derived from a fact table, which identifies the columns from which the measures are calculated and contain references to the tables which hold the dimensions.


Glossary

D

data model An abstract model that describes how data is represented or structured, and how data elements relate to each other. A multidimensional data model in OLAP consists of cubes, measures, dimensions, hierarchies, levels, and attributes.

data repository A logical division of data where multiple databases reside; the databases apply to specific applications (such as accounting programs). A data repository can also represent a physical division of data.

data source The source of computer data or a site where data is stored and accessed.

data type A definition of a set of data that gives the range of values, such as date, number, string, and floating point.

dimension A logical grouping of attributes. A dimension acts as an efficient and intuitive way of organizing data for retrieval and analysis.

dimension table A database table that contains attribute-associated data and is created as a companion table to a fact table.

drill down/up To view data in different levels of detail. Specifically, a user can drill up to get more generalized data or down for more detailed data. The level to which a user can drill depends on the granularity of the data.

E

elements The actual data values that appear in a dimension table associated with an attribute. January and September would be elements of the Month attribute in the Time dimension. Also referred to as an attribute element.

F

facts Variables or measures, normally stored as numeric fields, which are the focus of the decision support investigation. Facts would be inventory levels, sales amounts, commissions, and so on.

fact table A fact table acts as the base table for a star schema and, when normalized, is surrounded by dimension tables containing attribute data. The fact table contains measure or fact data. See also base table.

formula A formula calculates or sets guidelines for manipulating data within a multidimensional database, and defines enterprise relationships. Users can use a formula to personalize data for their specific needs.

H

hierarchical relationships Parent/child relationships are examples of hierarchical relationships, where a parent member represents the consolidation of its children members. See hierarchy.


Glossary

hierarchy An organization of dimension attributes into a logical tree structure which defines parent-child relationships between the attributes, including how data can be aggregated from children to parent.

K

key A key identifies a column or a group of columns in a table.

L

levels Attributes organized in a hierarchical structure.

logical data structure A conceptual or virtual representation of a collection of data.

M

MDX Multidimensional Expression language. A query language for querying and manipulating the multidimensional data stored in OLAP cubes. MDX is also a calculation language, with syntax similar to spreadsheet formulas.

measure Normally corresponds to a fact table column and typically represents numerical data. Measures exist in a separate OLAP dimension.

member An attribute element value in an OLAP cube.

metric See measure.

modeling A process to define and analyze the data requirements that are needed to support business functions. Data modeling defines the relationships between data elements and structures.

Multidimensional OLAP (MOLAP) MOLAP is the more traditional way to do OLAP analysis. In MOLAP, data is stored in a pre-calculated optimized multidimensional array instead of in relational database format. MOLAP cubes are built for fast data retrieval, and are optimal for slicing and dicing operations. MOLAP can perform complex calculations quickly.

N

normalization The process of reducing a complex data structure to its simplest structure. Normalization can include the removal of redundant attributes, keys, and relationships from a conceptual data model.

O

ODBC Open Database Connectivity. A standard for database connectivity that provides a standard application interface to conforming databases, including Teradata.

ODBC driver Type of driver used to connect applications with databases. The ODBC driver processes ODBC calls from an application, but passes SQL requests to the Teradata Database for processing.


Glossary

OLAP Online analytical processing. Software technology that allows the user to interpret multidimensional data from enterprise data warehouse systems. OLAP tools can query and analyze the information, which has been transformed from raw data into information that reflects business views of the enterprise. OLAP is also known as decision support processing, and is a decision support counterpart to online transaction processing (OLTP).

OLAP Connector See Teradata OLAP Connector.

OLE DB A specification for how to build objects to extract data from a data source. With OLE DB it is easy to mix data from multiple data source providers and provider types.

OLE DB for OLAP (ODBO) A Microsoft-published specification and an industry standard for multidimensional data processing. ODBO is the standard API for exchanging metadata and data between an OLAP server and a client. ODBO extends the ability of OLE DB to access multidimensional (OLAP) data stores. Excel and other OLAP clients use ODBO to talk to an OLAP cube.

P

parent In a hierarchical structure, the parent member is one level higher than its child member. Usually, the value of the parent is a combination of its children’s values. See also children.

pivot To alter the dimensional orientation of a report or page display.

PivotTable A pivot table is a data summarization tool found in spreadsheets such as Microsoft Excel or business intelligence software. Among other functions, pivot-table tools can automatically sort, count, and total the data stored in one table or spreadsheet and create a second table (called a "pivot table") displaying the summarized data. Pivot tables are also useful for quickly creating cross tabs. The user sets up and changes the summary's structure by dragging and dropping fields graphically. This "rotation" or pivoting of the summary table gives the concept its name. The term pivot table is a generic phrase used by multiple vendors; however, Microsoft Corporation has trademarked the specific form PivotTable.

R

Relational Online Analytical Processing (ROLAP) Online analytical processing that provides multidimensional analysis of data, aggregates, and metadata stored in an RDBMS. The multidimensional processing can be done within the RDBMS, a mid-tier server, or the client.

S

schema The logical and physical definition of data elements, physical characteristics, and inter-relationships.

slice A slice can be a single value or a subset of values of a cube. For example, a subset could be represented as a two dimensional slice out of a three dimensional cube.


Glossary

slice and dice A complex process of data analysis that involves breaking down information into smaller parts and examining data from different viewpoints. Querying data and examining slices, pivoting the data, and drilling down on the data are examples of slice and dice.

snowflake schema A relational database scheme for representing multidimensional data. A snowflake schema builds on the concept of a star schema, but involves normalization of dimension tables into multiple tables where there is typically one table for each level of the dimension hierarchy. See also star schema.

sparse A multidimensional data set is sparse if a high percentage of the possible intersections of the data set’s members contain missing data.

star schema A relational database schema for representing multidimensional data. Star schemas normally have a primary or fact table and one or more dimensional tables. The dimensional tables supply supporting information, such as the demographics for the buyers listed in the primary fact table. See also snowflake schema.

T

Teradata Aggregate Designer Used to create Teradata AJIs to support high performance ROLAP queries to the EDW.

Teradata Aggregate Join Indexes (AJI) Used to accelerate the aggregation required by MDX.

Teradata Business Intelligence Optimizer (Teradata BIO) A set of software components that work together to specify the multidimensional model for a ROLAP system, and provide run-time handling of MDX queries from various BI client applications. The Teradata BIO solution provides an enterprise class, general purpose MDX/OLAP solution for use on a ROLAP architecture.

Teradata Schema Workbench Used by OLAP DBAs to indicate how star and snowflake schemas and fact tables in an RDBMS should be mapped to OLAP cubes, dimensions, hierarchies, levels, and measures. The resulting cube schema is published by Teradata Schema Workbench to the EDW for use by BI run-time client applications.

Teradata OLAP Connector A client-side component that enables Microsoft Excel and other BI client applications that emit MDX query language through a standard ODBO interface to slice and dice data.


Glossary


Index

Symbols.odc file 27, 107

Aadding

dimensions levels 56join keys to a hierarchy 54languages to the Localization element 70localization element, a 69OLAP objects 39secondary tables to hierarchy 53tables to a hierarchy 53

advanced features 91Aggregate Designer See Teradata Aggregate Designeraggregate policy 81

Bbest practices 95

Ccalculated measures 87

Aggregate function, using the MDX 108ampersand, use of 108creating 87deleting 34MDX expressions in calculations 89MDX functions, supported 109MDX syntax, validating 96size limitations 25specialized settings 127

calculated membersampersand, use of 108creating 93displaying 103MDX functions, supported 109MDX syntax, validating 96

caption, default 69cell caching 122cube dimensions See dimensionscube schemas See schemascubes

access, withdrawing 75calculated measures, creating new 87deleting 34development strategy 95

measures, creating new 44named sets, creating 91new, creating 43repository, listing in 25security, defining 75size limitations 25

Ddata source, setting up for Teradata ODBC 27default caption 69deleting

elements using Schema Editor toolbar 34, 38join keys from a hierarchy 55schemas 68

dimension levelsaccess, withdrawing 79adding 56deleting 34inserting 58move level down 58move level up 58reordering 58security, defining 79

dimensionsaccess, withdrawing 77deleting 34hierarchies for a dimension, creating 51modeling 47new, creating 49security, defining 77shared dimension, creating cube dimension using a 63size limitations 25

drill down access 80

EEDW connection

setting up 29status bar 34

EDW connection status bar 37error logs

event logging 106schema validation 40

examplesaggregate policy 82cube, withdrawing access to a 76DDL 98


Index

dimension level, withdrawing access to a 80dimension, withdrawing access to a 77fact table 48hierarchy, parent-child 98hierarchy, withdrawing access to a 79main hierarchy table 49MDX syntax, validating 96members, specifying access to 85parent-child hierarchy modeling 98query banding 100schema validation warnings and errors 66

Excel See Microsoft Excel

Ffact tables 19, 48Format String menu 45format strings

localized 71selecting 45troubleshooting 103

Hhierarchies

access, withdrawing 78calculated members, creating 93default member 96deleting 34editing 53join keys from a hierarchy, deleting a 55join keys in a hierarchy, editing 55join keys to a hierarchy, adding 54main hierarchy table example 49modeling 47, 98new, creating 51parent-child 98ragged 98ragged and skip-level 108secondary tables, adding 53security, defining 78size limitations 25tables to a hierarchy, adding 53

Hierarchy Wizard 51

Iicons

schema elements 34, 35toolbar 35, 38

Jjob prioritization 100join keys

adding to a hierarchy 54deleting from a hierarchy 55editing in a hierarchy 55

Kknown issues 107KRB5 authentication method 31

LLDAP authentication method 31least recently used algorithm 121, 122level member columns 97levels

compound keys, implementing 98deleting 34drill down access, withdrawing 80security, defining 79size limitations 25withdrawing access 79

localization element 34, 69, 70localized format strings 71LRU algorithm 121, 122

MMDX 22

Aggregate function 108errors 104expressions in calculations 89expressions, use of ampersand in 108functions and methods, supported 109operators supported 111service account settings, changing 31service account, setting up a 30validation errors 102

MDX Sample application, using 96measures

ampersand, use of 108deleting 34new, creating 44size limitations 25

memberssecurity, defining 83specifying access to 83unique 97

metadata cachingmetadata pre-fetching 122permanent entities 121transient entities 122

Microsoft Excel"Query did not run" message 104#VALUE in cell 104empty spreadsheet cell 104


Index

spreadsheet does not refresh 107

Nnamed sets

ampersand, use of 108creating 91deleting 34MDX functions, supported 109MDX syntax, validating 96

OODBC

data sources, setting up for Teradata 27documentation 5

ODBC Driver Setup for Teradata Database dialog box 27, 28OLAP connection, setting up 30OLAP Connector See Teradata OLAP ConnectorOLAP objects

adding 39size limitations 26

Pparent-child hierarchy modeling 98PivotTables

troubleshooting 107prerequisites to using product 4prioritization, job 100product release numbers 3properties

deleting 34new, creating 59

publishing a schema 67

Qquery banding

setting 127using 100

Query did not run message 104

Rrecursive view 98Release Definition 5restricted aggregate policy 81roles

mapping 74TBI_SERVICE 23, 26, 73TBI_USER 23, 26, 73TBI_WORKBENCH 23, 26, 73

Ssample MDX application 96Schema Editor toolbar 34, 38Schema Editor window 33, 37Schema Element Properties View 34, 39schema elements 34, 35

viewing problematic 40schema repository

creating 23default directory 24

schema status bar 34, 37Schema Tree View 34, 39schema validation error log 40Schema Workbench See Teradata Schema Workbenchschemas

copying to a different EDW 68creating 42default directory 31default language, selecting 42deleting 68mapping a role 74named sets, creating 91opening 31, 32publishing 67recommended strategy 41repository, listing in 25sample schemas 31saving 67schema development process 41schema status bar 34, 37size limitations 25validating 41, 65, 66

security 73cube, for a 75dimension level, for a 79hierarchy, for a 78level, for a 79member, for a 83restricted aggregate policy 81unrestricted aggregate policy 81

security roles, mandatory 26Set Default Member to ALL button 53setting up

EDW connection 29MDX service account 30OLAP connection 30Teradata ODBC data sources 27

shared dimensions 60hierarchy 61new, creating 60

software releases, supported 3status bars

EDW connection 37


Index

schema 37

Ttables

secondary tables to a hierarchy, adding 53tables to a hierarchy, adding 53

TBI Repository 23architecture 19size limitations 25SQL grants script 119

TBI_SERVICE role 23, 26, 73TBI_USER role 23, 26, 73TBI_WORKBENCH role 23, 26, 73Teradata Aggregate Designer

documentation 5TBI Repository 19using saved schemas 67

Teradata Archive/Recovery Utility Reference 5, 24Teradata BIO 17

architecture 18Teradata Database version 3Teradata DSN 27Teradata OLAP Connector 21

cell caching 122documentation 5metadata caching 121registry settings 125specialized settings 126

Teradata Query Scheduler version 3Teradata Schema Workbench 19

main window 33toolbar 35

Teradata Tools and Utilities version 3toolbar icons 35, 38troubleshooting 101

problematic schema elements, viewing 40

UUnable to Connect to Selected EDW message 105Unable to Establish Repository Connection message 106unique member handling 97unrestricted aggregate policy 81Use All Member check box 51

Vvalidating schemas 41, 65, 66validation error log 34, 40validation errors, MDX 102Visible check box 45
