Teradata Schema Workbench. User Guide

Transcription

1 Teradata Schema Workbench User Guide Release B K September 2013

2 The product or products described in this book are licensed products of Teradata Corporation or its affiliates. Teradata, Active Data Warehousing, Active Enterprise Intelligence, Applications-Within, Aprimo, Aprimo Marketing Studio, Aster, BYNET, Claraview, DecisionCast, Gridscale, MyCommerce, Raising Intelligence, Smarter. Faster. Wins., SQL-MapReduce, Teradata Decision Experts, "Teradata Labs" logo, "Teradata Raising Intelligence" logo, Teradata ServiceConnect, Teradata Source Experts, "Teradata The Best Decision Possible" logo, The Best Decision Possible, WebAnalyst, and Xkoto are trademarks or registered trademarks of Teradata Corporation or its affiliates in the United States and other countries. Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc. AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc. Apache, Apache Hadoop, Hadoop, and the yellow elephant logo are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. Apple, Mac, and OS X all are registered trademarks of Apple Inc. Axeda is a registered trademark of Axeda Corporation. Axeda Agents, Axeda Applications, Axeda Policy Manager, Axeda Enterprise, Axeda Access, Axeda Software Management, Axeda Service, Axeda ServiceLink, and Firewall-Friendly are trademarks and Maximum Results and Maximum Support are servicemarks of Axeda Corporation. Data Domain, EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation. GoldenGate is a trademark of Oracle. Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company. Hortonworks, the Hortonworks logo and other Hortonworks trademarks are trademarks of Hortonworks Inc. in the United States and other countries. Intel, Pentium, and XEON are registered trademarks of Intel Corporation. IBM, CICS, RACF, Tivoli, and z/os are registered trademarks of International Business Machines Corporation. Linux is a registered trademark of Linus Torvalds. LSI is a registered trademark 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. NetVault is a trademark or registered trademark of Quest Software, Inc. in the United States and/or other countries. Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries. Oracle, Java, and Solaris are registered trademarks of Oracle and/or its affiliates. QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation. Quantum and the Quantum logo are trademarks of Quantum Corporation, registered in the U.S.A. and other countries. Red Hat is a trademark of Red Hat, Inc., registered in the U.S. and other countries. Used under license. SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc. SPARC is a registered trademark of SPARC International, Inc. 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 registered trademark of Unicode, Inc. in the United States and other countries. 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 teradata-books@lists.teradata.com. 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 by Teradata Corporation. All Rights Reserved.

3 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 versions 13.00, 13.10, 14.00, and Teradata Schema Workbench Teradata Schema Workbench can connect to Teradata Database versions: or later or later or later or later Teradata Schema Workbench supports the following Teradata ODBC Driver versions: or later or later or later or later Teradata Schema Workbench User Guide, Release

4 Preface Prerequisites Use the same version of Teradata Schema Workbench as Teradata OLAP Connector unless the Teradata Schema Workbench Release Definition states otherwise. 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 Multidimensional 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. Date and Release September Description Numerous updates and corrections made to documentation, including information on trusted sessions, aggregation policy, and Teradata OLAP Server. 4 Teradata Schema Workbench User Guide, Release 14.10

5 Preface Additional Information Date and Release January March Description Check/uncheck all buttons added when selecting dimensions for a measuregroup. Documented new ability to add multiple composite keys from a fact table to a dimension table through aliases. Documented functions, methods, and operators that support calculations being done in the underlying Teradata Database rather than on the client system through OLAP Connector. These calculations are known as pushdown calculations. Default aggregator changed to SUM when defining fact table measures. Updated information on Query Banding to describe its use in Teradata Database job prioritization. MDX functions CORRELATION and DISTINCTCOUNT now supported. Documented ability to set Use value for all measures from a fact table in a measure group to one of three states (Visible, Not Visible, or Inactive). Updated steps and screen shot related to creating a cube to describe new Check All and Uncheck All buttons. Updated steps and screen shot related to setting up a database connection to describe new Check All and Uncheck All buttons. Appendix on using the Pushdown system added. Removed all instances of Teradata Business Intelligence Optimizer. Removed pushdown calculations support. IIF is fully supported, removed the note stating otherwise. Additional MDX functions added to Appendix B. Mapping a role is no longer an option in the Schema Editor toolbar. For instructions, see Map a Role on page 72. Removed shared and private dimensions. All dimensions are now scoped by schema. Documented updates to the user interface, including the Business Intelligence Data View. For information, see Chapter 4. The set exception, power, IS, and XOR MDX operators are now supported. For a complete list of supported MDX operators, see Table on page 123. Added Appendix I: Using the Schema Migration Assistant for converting schemas created in Teradata Schema Workbench to compatibility with Teradata Schema Workbench Additional Information Additional information that supports Teradata Schema Workbench is available at the web sites listed in the table that follows. Teradata Schema Workbench User Guide, Release

6 Preface Additional Information Type of Information Description Access to Information Release overview Late information Additional product information CD-ROM images Ordering information for manuals 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 Use the Teradata Information Products web site to view or download specific manuals that supply related or additional information to this manual. 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. Use the Teradata Information Products web site to order printed versions of manuals. 1 Go to 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. 1 Go to 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 Guide B Teradata Aggregate Designer User Guide B Teradata Archive/Recovery Utility Reference B Teradata OLAP Connector User Guide B Go to 2 Click Data Warehousing under the Online Publications, Browse by Category. 3 Click CD-ROM Images. 1 Go to 2 Click How to Order under Print & CD Publications. 3 Follow the ordering instructions. 6 Teradata Schema Workbench User Guide, Release 14.10

7 Preface Additional Information Type of Information Description Access to 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. Teradata Schema Workbench User Guide, Release

8 Preface Additional Information 8 Teradata Schema Workbench User Guide, Release 14.10

9 Table of Contents Preface Purpose Audience Supported Releases Prerequisites Changes to This Book Additional Information Chapter 1: Introduction Solution Architecture Teradata BI Model Repository What is Teradata Schema Workbench? What is Teradata OLAP Connector? What is MDX? Chapter 2: Configuration Cube Schema Repository Manually Creating the Cube Schema Repository Creating and Using the Sample Database Listing Schemas in the Repository Teradata BI Model Repository Limitations Mandatory Security Roles Chapter 3: Getting Started Setting Up a Teradata ODBC Data Source Teradata Schema Workbench User Guide, Release

10 Table of Contents Setting Up a Database Connection Setting Up an MDX Service Account and OLAP Connection Opening a Cube Schema Chapter 4: Introduction to the User Interface Main Window and Schema Editor Main Menu and Toolbar Schema Status Bar Database Connection Status Bar Schema Editor Window Schema Editor Toolbar Schema Tree View Schema Element Properties View Schema Validation Error Log Chapter 5: Cube Schemas Cube Schema Development Process Recommended Strategy Creating a New Schema Chapter 6: Fact Tables and Dimension Tables Mapping Fact Tables Defining Relationships Between Fact Tables and Dimension Tables Defining Fact Table Measures Format Strings Chapter 7: Dimensions, Hierarchies, Levels, and Properties Dimensions and Hierarchies Modeling Dimensions and Hierarchies Teradata Schema Workbench User Guide, Release 14.10

11 Table of Contents Creating a Dimension Creating a Hierarchy Editing a Hierarchy Levels and Properties Adding a Dimension Level Inserting and Reordering Dimension Levels Creating a Property Chapter 8: Measure Groups and Cubes Creating a Measure Group About Calculated Measures Creating a New Cube Additional Cube Settings Chapter 9: Security Settings Overview Map a Role Defining Cube Security Defining Level Security Aggregation Policy Defining Member Security Member Security Dialog Box Chapter 10: Save, Validate, Publish, and Transfer Schema Validation Save a Schema to the File System Publish a Schema to the Database Copy a Schema to a Different Database Delete a Schema Teradata Schema Workbench User Guide, Release

12 Table of Contents Chapter 11: Additional Features Drill-Through User Invocation Security Enabling Drill-Through Configuring Managed Drill-Through Create a Named Set Creating a Named Set for a Specific Cube Creating a Schema Scope Named Set Calculated Measures Create a Calculated Measure MDX Expressions in Calculations Create Calculated Members Cube Schema Localization Add a Localization Element Localized Format Strings Trusted Sessions How Security Is Applied For a Teradata OLAP Connector Session How Security Is Applied For a Teradata OLAP Server Session Chapter 12: Best Practices High Performance Cube Development Strategy MDX Validation Using MDX Sample Validating MDX Syntax Level Member Columns AJI-Related Best Practices Modeling Parent-Child Hierarchies Query Banding Administration Teradata Database Job Prioritization Appendix A: Troubleshooting and Known Issues Troubleshooting MDX Validation Errors Teradata Schema Workbench User Guide, Release 14.10

13 Table of Contents 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 An error occurred trying to connect Message Unable to Establish Repository Connection Message Teradata Schema Workbench Event Logging 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 Appendix B: Supported MDX Functions and Operators MDX Functions Supported MDX Methods Supported MDX Operators Supported Appendix C: Schema Workbench Toolbox Schema Workbench Repository Setup Sample Database Loader Appendix D: Teradata OLAP Connector Caching Metadata Caching Permanent Entities Transient Entities Metadata Prefetching Cell Caching Teradata Schema Workbench User Guide, Release

14 Table of Contents Appendix E: BI Model Repository Grants Script SQL Grants Script Appendix F: Teradata OLAP Connector Registry Settings Registry Settings Specialized Settings Appendix G: Teradata OLAP Connector Logging Setup Log Location Logger Registry Location Logger Registry Setup Appendix H: Configuring Schema Workbench Menus Configuring the Menus Appendix I: Using the Schema Migration Assistant Preparing Schemas for Migration Migrating a Schema Completing Migration Appendix J: Using the Pushdown System Pushdown Eligibility Overview Teradata Schema Workbench User Guide, Release 14.10

15 Table of Contents Functions and Operators Eligible for Pushdown on Their Own Functions and Methods Eligible for Pushdown When Specified as a Parameter to Other Functions and Methods Eligible for Pushdown Functions and Methods Eligible for Pushdown When Specified as Parameters to Specific Functions Eligible for Pushdown General Calculated Measure Structure Limitations Schema Configuration Overview Fully-Qualified Member Names Function-Specific Usages Eligible for Pushdown Overview Arithmetic Comparison Simple Aggregates Count DistinctCount Filter IIF Descendants ParallelPeriod PeriodsToDate YTD/QTD/MTD/WTD Opening/ClosingPeriod CrossJoin CurrentMember PrevMember Level Glossary Index Teradata Schema Workbench User Guide, Release

16 Table of Contents 16 Teradata Schema Workbench User Guide, Release 14.10

17 List of Figures Figure 1: Teradata OLAP Solution Figure 2: Teradata BI Model Repository Architecture Figure 3: Schema Tree Example Figure 4: Teradata OLAP Connector Architecture Figure 5: Teradata Schema Workbench User Interface Figure 6: Teradata Schema Workbench Main Window and Schema Editor Figure 7: Schema Status Bar Figure 8: Database Connection Status Bar Figure 9: Schema Editor Toolbar Figure 10: Schema Tree View Figure 11: Defining Relationships Between Fact Tables and Dimension Tables Figure 12: Add Relationship Dialog (Fact Table Column) Figure 13: Completed Example of an Alias Figure 14: Example Fact Table Figure 15: Example Main Hierarchy Table Figure 16: Adding a Dimension Level Figure 17: Example - Security Role Check boxes Figure 18: Example - Security Role Partial Access Figure 19: Example - Security Role Full Access Figure 20: Example of Withdrawing Access to a Cube Figure 21: Aggregate Policy Example Figure 22: Aggregate Policy Example Figure 23: Aggregate Policy Example Figure 24: Member Security Dialog Box Figure 25: Schema Validation Warnings and Errors Figure 26: Creating a Named Set Figure 27: Creating a Display Folder for a Named Set Figure 28: Adding Languages to the Localization Element Figure 29: Format String for Localization Figure 30: Applying Security in a Teradata OLAP Connector Session Figure 31: Applying Security in a Teradata OLAP Server Session Figure 32: Validating MDX Formulas Using MDX Sample Teradata Schema Workbench User Guide, Release

18 List of Figures Figure 33: MDX Validation Error Figure 34: Introduction to the Repository Setup Figure 35: Example of the Server and User Information for Repository Setup Figure 36: Example of a successful repository set up Figure 37: Introduction to the Sample Database Loader Figure 38: Configuring the Tools and Help menus Figure 39: A calculated measure eligible for pushdown Figure 40: Member keys of the top level in the [Time].[Calendar Time] hierarchy Figure 41: Member keys of the second level in the [Time].[Calendar Time] hierarchy Figure 42: Member keys of the third level in the [Time].[Calendar Time] hierarchy Teradata Schema Workbench User Guide, Release 14.10

19 List of Tables Table 1: File Menu Table 2: View Menu Table 3: Repository Menu Table 4: Tools Menu Table 5: Windows Menu Table 6: Help Menu Table 7: Schema Editor Toolbar Table 8: Member Security Dialog Box Table 9: Supported MDX Operators Table 10: Teradata OLAP Connector Registry Settings Table 11: Teradata OLAP Connector Specialized Settings Table 12: Levels and corresponding member key columns Teradata Schema Workbench User Guide, Release

20 List of Tables 20 Teradata Schema Workbench User Guide, Release 14.10

21 CHAPTER 1 Introduction The following topics provide an introduction to the Teradata Schema Workbench: Solution Architecture Teradata BI Model Repository What is Teradata Schema Workbench? What is Teradata OLAP Connector? What is MDX? Solution Architecture Teradata Schema Workbench is part of a solution providing customers with an enterpriseclass, general purpose MDX/OLAP solution for Teradata Relational Online Analytical Processing (ROLAP) architecture. Teradata Aggregate Join Indexes (AJIs), created using Teradata Aggregate Designer, improve performance. The Teradata OLAP solution consists of a set of software components that work together to specify the multidimensional model for your ROLAP system, and handle MDX queries from various BI clients. The four major components, shown in Figure 1 on page 22, are: Teradata OLAP Connector Teradata Aggregate Designer Teradata Schema Workbench Teradata OLAP Server Teradata Schema Workbench User Guide, Release

22 Chapter 1: Introduction Solution Architecture Figure 1: Teradata OLAP Solution Aggregate Designer XML Schema Workbench Client PC Excel, Tableau, arcplan or other Client Teradata OLAP Connector Teradata MDX Provider SAP BO or other XMLA Client Teradata OLAP Server JBoss XMLA service Bridge to MDX Teradata MDX Provider Publish Teradata-Optimized SQL BI Model Repository Star/ Snowflake Fact Tables AJIs Cube Schemas Cube + Dimension Security Info Teradata Security Roles User Accounts An OLAP cube administrator starts by using the 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 the Teradata Database system for later use by BI run-time client applications. The cube schema can also be sent via a BI Schema file to the Teradata Aggregate Designer. This allows the DBA to design Aggregate Join Indexes (AJIs) that support high performance ROLAP queries and store them to the Teradata Database System. The Teradata OLAP Connector functions as an OLE DB for OLAP (ODBO) provider data source for BI client applications such as MS Excel or Tableau. This allows business analysts to perform real-time OLAP queries such as slice and dice, cross-tab reports, and dashboards direct to the Teradata Database System. The Teradata OLAP Server provides direct access to the Teradata Database from any client platform to any server platform through XMLA web services that are supported by multiple BI vendors, like SAP BO. 22 Teradata Schema Workbench User Guide, Release 14.10

23 Chapter 1: Introduction Teradata BI Model Repository Teradata BI Model Repository The Teradata OLAP solution relies on a star or snowflake schema hosted in your Teradata 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 also uses a fact table, but has normalized dimensions to lower redundancy. The Teradata BI Model Repository, shown in Figure 2, is a key component of the Teradata OLAP solution. A Teradata BI Model 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, create aggregations as database objects to improve Teradata ROLAP performance. Teradata users and roles are leveraged by the solution to control access to all data. Figure 2: Teradata BI Model Repository Architecture Star/ Snowflake Fact Tables AJIs Teradata Security Roles Teradata BI Model Cube Schemas Cube + Dimension Security Info User Accounts 4105A 002 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 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 24 for an example. Teradata Schema Workbench User Guide, Release

24 Chapter 1: Introduction What is Teradata Schema Workbench? Figure 3: Schema Tree Example Teradata Schema Workbench is often used with a design-time connection to the Teradata Database. The DBA conveniently selects actual columns to use for ROLAP. All schemas are validated against the database 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 a database for use with Excel and other MDX and ODBO tools. MS Excel uses Teradata OLAP Connector as a source to generate optimal Teradata SQL from. 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 database 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 database, 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. 24 Teradata Schema Workbench User Guide, Release 14.10

25 Chapter 1: Introduction What 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 Microsoft 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. It interprets MDX queries (using cube metadata in the Teradata BI Model Repository) and sends Teradata-optimized SQL to Teradata Database. Figure 4: Teradata OLAP Connector Architecture Client PC MDX OLAP Connector ODBO Layer MDX Parser MDX Query Engine ODBO Interface Teradata ROLAP-Optimized SQL Generation SQL Star/ Snowflake Fact Tables AJIs Teradata Security Roles BI Model Repository Cube Schemas Cube + Dimension Security Info User Accounts 4105A 003 Teradata Schema Workbench User Guide, Release

26 Chapter 1: Introduction What is MDX? What is MDX? MDX is a language for querying and manipulating multidimensional data in OLAP cubes, analogous to SQL for relational databases. Teradata Schema Workbench uses MDX to define calculations. During pivot table operations, MS Excel sends MDX to Teradata OLAP Connector, which uses cube metadata to interpret MDX and generate SQL. To take full advantage of Teradata Schema Workbench, familiarize yourself with MDX before proceeding. For an excellent introduction to the language, we recommend Fast Track to MDX (Whitehorn, Zare, and Pasumansky 2006). Additionally, the Microsoft Developer Network Library provides an MDX reference. Links to these references are accessible from the Teradata Schema Workbench Help menu. For more information, see Table 6 on page Teradata Schema Workbench User Guide, Release 14.10

27 CHAPTER 2 Configuration The following topics provide configuration information: Cube Schema Repository Teradata BI Model Repository Limitations Mandatory Security Roles Cube Schema Repository The cube schema repository, known as the Teradata BI Model Repository, is a solutionmaintained database used to manage the OLAP metadata of the Teradata solution. It can be installed and configured on your database using the Workbench Toolbox described in Appendix C. The Teradata solution stores cube schema data and associated metadata in a database named BIM_REPOSITORY. The Teradata BI Model 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 Teradata BI Model Repository. The Teradata BI Model Repository contains tables, with views and macros, that do not relate to other tables on your server outside of the BIM_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 includes three mandatory roles: TBI_USER TBI_WORKBENCH TBI_SERVICE For more information on these roles, see Mandatory Security Roles on page 29. 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. Teradata Schema Workbench User Guide, Release

28 Chapter 2: Configuration Cube Schema Repository 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 127. 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\Client\14.10\Teradata Schema Workbench\Scripts\repository. 2 Execute BIM Repository DDL.sql. 3 Execute BIM Repository Grants.sql to set up access using Teradata roles for basic solution operation. If the scripts run without errors, the Teradata BI Model 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 Workbench Toolbox, to load a sample database named TAADemo. See Sample Database Loader on page 130 for instructions. Manually load the supplied database archive, named ARCTAA, using the ARCMAIN utility. This archive file is located at C:\Program Files\Teradata\Client\14.10\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. 2 Load the TAADemoSchema.biml file using the procedure, To open a cube schema stored in a.biml or.xml file on page 35. The TAADemoSchema.biml file is located at C:\Program Files\Teradata\ Client\14.10\Teradata Schema Workbench\Samples\schema. 3 Publish the TAADemoSchema using the procedure, To publish a schema on page Configure your BI client application to use this new cube data source. Refer to the Teradata OLAP Connector User Guide. 28 Teradata Schema Workbench User Guide, Release 14.10

29 Chapter 2: Configuration Teradata BI Model Repository Limitations Listing Schemas in the Repository To list all cube schemas in the repository SELECT SchemaName, BIWCreator, LastUpdate FROM BIM_REPOSITORY.BIW_Schema Teradata BI Model Repository Limitations The Teradata BI Model Repository has the following size limitations: Schemas in a repository: 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 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 solution. Your solution installation documentation explains how these are created. TBI_SERVICE This role grants access to all fact and dimension tables on the server for the MDX Service Account. The cube administrator uses Teradata Schema Workbench to restrict this broad access for each cube and cube dimension. For information, see Setting Up an MDX Service Account and OLAP Connection on page 34. The DBA must create one user associated with the TBI_SERVICE role, such as tbiservice, and keep the password confidential. This is called the Teradata BI Service Account. The username and password are entered one time into the Teradata Schema Workbench, which puts them in the Teradata BI Model Repository. The username and password are transmitted to and from the Teradata BI Model Repository in encrypted form and are kept in the repository in encrypted form. TBI_WORKBENCH This role grants schema publishing rights to the Teradata BI Model Repository. Without this right, a user does not have privileges to load or publish from the Teradata BI Model Teradata Schema Workbench User Guide, Release

30 Chapter 2: Configuration Mandatory Security Roles Repository. This role enables 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 This role grants individual user access rights to the Teradata BI Model Repository. Any user intending to use Teradata OLAP Connector must be granted this role. BI client application users can log in with their regular database account and password to make initial MS Excel connection. The cube administrator must ensure that these database accounts have the TBI_USER role. For more information, see Setting Up an MDX Service Account and OLAP Connection on page 34 and Chapter 9: Security Settings. 30 Teradata Schema Workbench User Guide, Release 14.10

31 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 a Database 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 a prompt displays 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. Teradata Schema Workbench User Guide, Release

32 Chapter 3: Getting Started Setting Up a Database Connection To set up an ODBC data source For 64-bit versions of Windows, you must use the 32-bit ODBC Data Source Administrator, which is not available from the Control Panel. 1 Perform one of the following: From the Tools menu, click ODBC Admin 32bit. The ODBC Data Source Administrator dialog box appears. (32-bit Windows systems) From the Windows Start menu click Control Panel > Administrative Tools > Data Sources (ODBC). (64-bit Windows systems) Use Windows Explorer to access the 32-bit version of ODBC Data Source Administrator. To do this, locate and run odbcad32.exe from the C:\%WINDIR%\SysWOW64\ directory. 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 5. 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 a Database Connection To set up a database connection 1 Open Teradata Schema Workbench. The database connection status, located in the lower left corner of the main window, displays Not Connected. 2 Click Repository>Connect to database system. The Connect to database system window appears. 3 From the Selection connection pane, select a database. 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 If Teradata Database credentials are not in your DSN, a Database credentials required dialog box appears. To enter your credentials: 32 Teradata Schema Workbench User Guide, Release 14.10

33 Chapter 3: Getting Started Setting Up a Database Connection a b c Select an option from the Authentication Method menu. Enter your username and password. OR Enter a credential string in the Authentication Parameter box. Click OK. The source database pane populates: 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 118. You can click the Check All or Uncheck All button to select or deselect all listed databases, or select only the check boxes of specific source databases. If you are connecting to a Teradata BI Model 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 Click OK. The database connection status, located in the lower left corner of the main window, displays Connected to database system: <Teradata Database name>. Now you are connected to the database. 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. Teradata Schema Workbench User Guide, Release

34 Chapter 3: Getting Started Setting 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 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 29. Every Teradata BI Model Repository-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 Teradata BI Model 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 Teradata BI Model 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 BI Repository solution. 1 Open Teradata Schema Workbench. 2 Click Repository>Service Account Settings. 3 From the Authentication Method menu, select TD2, KRB5, or LDAP. 34 Teradata Schema Workbench User Guide, Release 14.10

35 Chapter 3: Getting Started Opening 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 Teradata BI Model Repository. If someone has already published a cube schema to the Teradata BI Model Repository, you can open it at this point. To open a cube schema from a BI repository 1 Open Teradata Schema Workbench. 2 Click File>Open>From BI Model 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 a.biml or.xml file 1 Open Teradata Schema Workbench. 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\Client\14.10\Teradata Schema Workbench\Samples\schema. 4 Select a schema. 5 Click Open. The Teradata Schema Workbench installer maps the.biml extension, so you can double-click a.biml file to open Teradata Schema Workbench. Additionally, you can drag-and-drop.biml and.xml files in Teradata Schema Workbench. To open a cube schema from Windows Explorer From Windows Explorer, double-click a.biml file. Teradata Schema Workbench launches and the schema opens. Teradata Schema Workbench User Guide, Release

36 Chapter 3: Getting Started Opening a Cube Schema 36 Teradata Schema Workbench User Guide, Release 14.10

37 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 Teradata Schema Workbench Main Window Cube Schemas 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 Schema Editor Window 4106A_004 Teradata Schema Workbench User Guide, Release

38 Chapter 4: Introduction to the User Interface Main Window and Schema Editor Main Window and Schema Editor The Teradata Schema Workbench 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 a database. 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, fact table, measure group, measure, calculated measure, calculated member, or named set. Schema Elements - View the elements within your schema. Localization Element - Access the pane to localize member captions and formats. Schema Tree View - View the schema elements that you build and define. Business Intelligence Data View - Manage data tables, fact tables, and cube security. 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. Database Connection Status Bar - Displays the status of the database 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 shows the main window with one open schema. Figure 6: Teradata Schema Workbench Main Window and Schema Editor Schema Workbench Menus and Toolbar Schema Editor Titlebar Schema Editor Toolbar Business Intelligence Data View Schema Elements Localization Element Schema Status Bar Database Connection Status Bar Schema Tree View Schema Elements Properties View 4106A_ Teradata Schema Workbench User Guide, Release 14.10

39 Chapter 4: Introduction to the User Interface 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 Open>From BI Model Repository Save Opens existing schema from a BI Schema (.biml) file in the file system. Opens existing schema from the Teradata BI Model Repository. 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. Exit None Exits Teradata Schema Workbench. Table 2 describes the View menu. Table 2: View Menu Command Toolbar Description Toggles on or off the main window toolbar. Table 3 describes the Repository menu. Table 3: Repository Menu Command Connect to database system Disconnect from database system Delete a BI Schema Service Account Settings Description Sets up a connection to the database system. Closes the connection to the database system. Deletes a BI schema in the database system. Modifies settings for MDX Service Account. Teradata Schema Workbench User Guide, Release

40 Chapter 4: Introduction to the User Interface Main Window and Schema Editor Table 4 describes the default settings of the Tools menu. For information about how to add options to the Tools menu, see Configuring the Menus on page 145. Table 4: Tools Menu Command Options TAD ODBC Admin 32bit Description Change Teradata Schema Workbench user configurable options. Open the Teradata Aggregate Designer. Set Teradata Schema Workbench options. Table 5 describes the Windows menu. Table 5: Windows Menu Command New Window Cascade Tile Vertical Tile Horizontal Close All Arrange Icons Description Opens a New Schema window. Stacks all open windows so each window title bar is visible. Displays all open windows vertically so you can view two or more windows at the same time. Displays all open windows horizontally so you can view two or more windows at the same time. Closes all open windows. Arranges all icons in a row across the bottom of the Teradata Schema Workbench main window. Table 6 describes the default settings of the Help menu. For information about how to add options, see Configuring the Menus on page 145. Table 6: Help Menu Command Button Description Contents Displays this user guide. OLE DB for OLAP Standard MSAS2000 MDX Reference MSAS2005 MDX Reference MSAS2008 MDX Reference None None None None Displays the MSDN OLE DB for Online Analytical Processing (OLAP) reference. Displays the MSDN MDX Overview for SQL Server 2000 reference. Displays the MSDN Multidimensional Expressions (MDX) Reference for SQL Server Displays the MSDN Multidimensional Expressions (MDX) Reference for SQL Server 2008 R2. 40 Teradata Schema Workbench User Guide, Release 14.10

41 Chapter 4: Introduction to the User Interface Schema Editor Window Table 6: Help Menu (continued) Command Button Description About Teradata Schema Workbench None Displays the Teradata Schema Workbench version information. Schema Status Bar Figure 7: 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, and remains until the schema is saved. Figure 7 shows an example of the schema status bar. Database Connection Status Bar The database connection status bar displays the Connected to database status in the lower left of the Teradata Schema Workbench window. It includes the identity of the connected DSN. The DSN indicates which database you are connected to. To transfer a schema, open a schema from one database system, close it, connect to a different database system, and publish the schema to the other one. Figure 8 shows an example of the database connection status bar when connected. Figure 8: Database Connection Status Bar Schema Editor Window Schema Editor Toolbar 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 37. Shown in Figure 6 on page 38, 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. 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. As an example only, Figure 9 shows the schema editor toolbar with Teradata Schema Workbench User Guide, Release

42 Chapter 4: Introduction to the User Interface Schema Editor Window all buttons active. One or more icons display active depending on the element type you select in the Schema Editor. Figure 9: Schema Editor Toolbar Table 7 describes the Schema Editor toolbar. Table 7: Schema Editor Toolbar Active Button Context Label Description Fact Table Adds a fact table definition to the schema. Measure Group Defines a new measure group in the schema. Measure Creates a new measure for a cube. Cube Creates a new cube in the schema. Dimension Creates a new dimension for a cube. Hierarchy Creates a new hierarchy for a dimension. Level Creates a new level within a hierarchy. Property Creates a new property for a level. Calculated Measure Creates a calculated measure for a cube. Calculated Member Creates a calculated member for a cube. Named Set Creates a named set within a cube. Delete Deletes the currently selected element in the Schema Tree View from the schema. 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. The Schema Tree View includes the Business Intelligence Data View, which enables defining fact tables, dimension tables, relationships between them, and making cube security settings. As you make changes, the Schema Tree View automatically updates to reflect modifications made to the tree elements and properties. 42 Teradata Schema Workbench User Guide, Release 14.10

43 Chapter 4: Introduction to the User Interface Schema Editor Window 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 object of the new object to be located. 2 Right-click to display the shortcut menu. 3 Select the object 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 made, and remains until the schema is saved. Schema Validation Error Log The validation error log appears at the bottom of the Schema Editor Window, and 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. Teradata Schema Workbench User Guide, Release

44 Chapter 4: Introduction to the User Interface Schema Editor Window 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. 44 Teradata Schema Workbench User Guide, Release 14.10

45 CHAPTER 5 Cube Schemas The following topics provide information on creating new schemas and cubes: Cube Schema Development Process Recommended Strategy Creating a New Schema Note: Use Schema Migration Assistant to convert schemas created in previous versions for compatibility with Teradata Schema Workbench For instructions, see Appendix I. Cube Schema Development Process There are several steps to create a new cube. You can change design decisions after creating the cube, but the initial steps must be taken in order: 1 Create a blank schema. For instructions, see Creating a New Schema. 2 Define the fact tables and dimension tables for the cube. For instructions, see Chapter 6: Fact Tables and Dimension Tables. 3 Define the relationships between the fact tables and dimension tables. For instructions, see Defining Relationships Between Fact Tables and Dimension Tables on page Define a dimension for the cube. A dimension can be used by any cube in the schema. For instructions, see Creating a Dimension on page Define a hierarchy with at least one level in your dimension. For instructions, see Creating a Hierarchy on page Create at least one measure group. For instructions, see Creating a Measure Group on page Create a cube which includes one or more measure groups. For instructions, see Creating a New Cube on page Validate and publish the cube. For instructions, see Chapter 10: Save, Validate, Publish, and Transfer. Teradata Schema Workbench User Guide, Release

46 Chapter 5: Cube Schemas Recommended Strategy Recommended Strategy 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 5 to locate this resource. If errors occur while testing cubes, refer to Appendix A: Troubleshooting and Known Issues. The basic strategy to develop a high performing cube schema and cubes: Map a single fact table and a few dimension tables in the Business Intelligence Data View, and define the relationships between them Define a simple dimension, hierarchy, and level first Define a single measure group to contain a small number of measures and dimensions Define a simple cube Validate and publish the cube schema to the Teradata BI Model 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. Creating a New Schema A schema is a container that holds all the definitions of the database tables and columns in use, the dimensions in use (including hierarchies and levels), and the cubes you define using those dimensions. It also holds optional items such as named sets, level security, and localization information. The schema name should be unique within the Teradata BI Model 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 validate or publish an empty or partially-completed schema to the Teradata BI Model Repository, you can save the schema in XML to a.biml file on your hard drive. 46 Teradata Schema Workbench User Guide, Release 14.10

47 Chapter 5: Cube Schemas Creating a New Schema 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. Teradata Schema Workbench User Guide, Release

48 Chapter 5: Cube Schemas Creating a New Schema 48 Teradata Schema Workbench User Guide, Release 14.10

49 CHAPTER 6 Fact Tables and Dimension Tables The following topics provide information on Fact Tables and Dimension Tables: Mapping Fact Tables Defining Relationships Between Fact Tables and Dimension Tables Defining Fact Table Measures Format Strings Mapping Fact Tables Use the Business Intelligence Data View to map fact tables and dimension tables within BI schema files. To map fact tables 1 Open a cube schema in the Schema Editor window. For instructions, see Opening a Cube Schema on page In the Schema Editor Tree View, click Business Intelligence Data View. The Business Intelligence Data View displays the Data View tab. 3 Click Add Fact Table to open the Add New Fact Table window. 4 Select an option from the Database menu. The available dimensions and fact tables display in the list view. Teradata Schema Workbench User Guide, Release

50 Chapter 6: Fact Tables and Dimension Tables Defining Relationships Between Fact Tables and Dimension Tables 5 Select a fact table, and click OK. After you add a fact table, you can go directly to defining a relationship to a dimension table. The dimension table is automatically added to the Business Intelligence Data View when a relationship is defined with the dimension table. To map dimension tables (optional) 1 Click Add Dimension Table to open the Add New Dimension Table window. 2 Select an option from the Database menu. The available dimensions and fact tables display in the list view. 3 Select a dimension, and click OK. The dimension appears in the Data View table list with a caution icon. This icon displays until you define a relationship with a fact table or dimension table. 4 After adding fact tables and dimension tables, define relationships between them. Defining Relationships Between Fact Tables and Dimension Tables After adding fact tables and (optionally) dimension tables to the Business Intelligence Data View, you can define relationships between fact tables and dimension tables. All dimension tables must have a column mapped to a fact table column, or it is an invalid orphan table. Figure 11 shows mappings between the inventory_fact fact table and relationships with the product, store, and time_by_day dimension tables. Figure 11: Defining Relationships Between Fact Tables and Dimension Tables 50 Teradata Schema Workbench User Guide, Release 14.10

51 Chapter 6: Fact Tables and Dimension Tables Defining Relationships Between Fact Tables and Dimension Tables To define relationships between fact tables and dimension tables 1 In the Schema Editor Tree View, click Business Intelligence Data View. The Business Intelligence Data View displays the Data View tab. 2 To map a fact table ID to a dimension table ID, select the fact table from the table list, and click Add Relationship. The Add Relationship Dialog window displays. Figure 12: Add Relationship Dialog (Fact Table Column) 3 The selected fact table is listed under the Foreign Key Database and Foreign Key Table. The dimension table will be listed under the Primary Key Database and Primary Key Table. Select the appropriate database containing the dimension table (the default is the same database as the fact table) and then select the actual table. 4 After you have selected the dimension table, click the Add Columns button to define the join relationship between the fact and dimension tables. The Add Column dialog box appears. 5 Select the Foreign Key Column from the fact table. 6 Select the Primary Key Column from the dimension table. 7 Click OK. 8 If the relationship is defined by a composite key (multiple columns from each table are required to uniquely identify the relationship), the repeat steps 4 7 for the additional columns that are required to define the relationship. Teradata Schema Workbench User Guide, Release

52 Chapter 6: Fact Tables and Dimension Tables Defining Fact Table Measures 9 If more than one fact table column needs to refer to the same dimension table (such dimensions are often called role-playing dimensions), you can define an alias for the Primary Key Table. For example, the fact table contains an order date and a ship date, each of which needs to join to the same time dimension table. You could create one alias called Order Date for the join between the Order Date column in the fact table and the Date column in the time dimension table, and a second alias called Ship Date for the join between the Ship Date column in the fact table and the same Date column in the time dimension table. Figure 13: Completed Example of an Alias 10 After you have defined all the fact table column relationships with dimension table columns, you can add fact tables and dimension tables to the tree view. Note: You can only use an individual fact table column once in a relationship with a dimension column, unless it is part of a composite key (two or more columns that uniquely identify an entry in the fact table). In the case of composite keys, the same combination of columns that define a composite key can only be used once in defining a relationship to a dimension table. Otherwise, it would not be a proper star or snowflake schema. Defining Fact Table Measures Measures are fact data, typically numeric, that the user wants to explore aggregated along any dimension. To create a measure, designate a column in a fact table to become an aggregated measure cell in the cube. After mapping a fact table from the database to schema in Business Intelligence Data View, you can add a mapped fact table to the Tree View, then add measures and specify properties. For information on calculated measures, see Calculated Measures on page Teradata Schema Workbench User Guide, Release 14.10

53 Chapter 6: Fact Tables and Dimension Tables Format Strings To add a mapped fact table to Tree View To define fact table measures To add a mapped fact table to Tree View 1 In Tree View, right-click Fact Tables and select New Fact Table. The Schema Element Properties pane displays Database and Fact Table lists. Only databases and fact tables defined in the Business Intelligence Data View display. 2 Select the database from the Database menu. 3 Select the fact table from the Fact Table menu. The fact table name in Tree View concatenates the names of the database and fact table being defined. To define fact table measures 1 Right-click the fact table in Tree View and select New Measure. 2 Type the measure Name. By default, the text you enter in Name automatically fills the Caption field with the same text. You can modify the caption text. 3 Select the column this measure identifies from the Measure Column list. 4 Select the aggregation policy for this measure from the Aggregator list (default is Sum). 5 If the cube administrator designates the measure for a specific format, select the option from the Format String list. Format Strings The Format String setting enables specifying how BI client applications render a measure selection in Schema Editor Tree View. You can type a unique string in the text box or select a predefined format string from the Format String list. A format string "$#,##0.00" or "$#,##0" does not use the literal dollar-sign ($) character, it is a placeholder for the operating system's locale-specific currency character. This means the visual currency symbol changes if the operating system locale changes. For example, if the Teradata Schema Workbench User Guide, Release

54 Chapter 6: Fact Tables and Dimension Tables Format Strings locale is United States the string has the $ value however, if the locale is France the string has the value. To lock the currency symbol to a specific currency character regardless of locale, prefix the string with a backslash: "\$#,##0.00" or \$#,##0". Note: Letting the locale change a format does not perform mathematical currency conversion. Manually changing a format string from $#,##0 to #.##0 does not cause mathematical currency conversion. The following resources provide information on using format strings: Spofford, George, Format String Codes, in MDX Solutions: With Microsoft SQL Server Analysis Services 2005 and Hyperion Essbase Second Edition, (Indianapolis: Wiley Publishing, Inc., 2006), Teradata Schema Workbench User Guide, Release 14.10

55 CHAPTER 7 Dimensions, Hierarchies, Levels, and Properties This chapter provides information on creating dimensions, hierarchies, levels, and properties: Dimensions and Hierarchies Levels and Properties Dimensions and Hierarchies You can create a dimension with multiple hierarchies and levels. Modeling Dimensions and Hierarchies In a star schema, foreign keys in the fact table refer to dimensional table keys. When defining a dimension in Teradata Schema Workbench, specify the column(s) in the fact table that define the hierarchy or hierarchies of that dimension. Figure 14 shows a schema diagram with product_id as the foreign key in the Sales Fact table for the Product1 dimension. Figure 14: Example Fact Table Dimension Product 1 PK product_id Dimension Time product_class_id product_name brand_name... Dimension Promotion PK time_id Fact Table PK promotion_id... Sales Fact media_type promotion_name... product_id time_id promotion_id PK Dimension Customer customer_ id customer_name... customer_id store_id store_sales store_cost... PK Dimension Store store_id store_name store_location A_006 Teradata Schema Workbench User Guide, Release

56 Chapter 7: Dimensions, Hierarchies, Levels, and Properties Dimensions and Hierarchies 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 15 on page 56 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 15 on page 56 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 15: Example Main Hierarchy Table Main Hierarchy Table for Product Dimension Product Secondary Table for Product Dimension PK product_id Product Fact Table Sales Fact product_class_id product_name brand_name... PK product_class_id product_family product_department product_category product_subcategory product_id time_id promotion_id customer_id store_id store_sales store_cost... Main Hierarchy Table for Promotion Dimension PK Promotion promotion_id media_type promotion_name promotion_district_id... Secondary Table for Promotion Dimension PK PK Promotion Schedule promotion_name promotion_district_id start_date end_date... Main Hierarchy Table for Store Dimension Store PK store_id store_name store_location A_007 Teradata BI Repository 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 Teradata Schema Workbench User Guide, Release 14.10

57 Chapter 7: Dimensions, Hierarchies, Levels, and Properties Dimensions and Hierarchies Creating a Dimension When you validate or publish a schema, a warning displays if you do not have a Time dimension type. Although most cubes have a Time dimension type, it is not required and you can still publish the schema. Additionally, a warning displays if the cube has more than one Time dimension type. For best results with multiple Time dimension types, create a separate hierarchy for each, with levels consisting of Time types. For more information on foreign keys in fact tables, see Modeling Dimensions and Hierarchies on page 55. To create a dimension 1 From the Schema Tree View, right-click the Dimension folder, and select New Dimension. An empty Dimension icon displays within the folder, and the Dimension page appears in the Schema Elements Properties view. 2 In the Name box, type a name for the new dimension. 3 Click the Caption box. The Caption box automatically fills the same name as the dimension. The caption is a name that is displayed and can be localized to different languages in the BI client application. For more information, see Cube Schema Localization on page Select a dimension type from the Dimension Type menu. For more about dimension types, search available dimension types in the MS Developer Network Library at 5 From the Database and Primary Table menus, select the database and primary table associated with the dimension. 6 Follow instructions in Creating a Hierarchy on page 58 to add dimension hierarchies. This populates the Default Hierarchy menu in the dimension Schema Elements Properties. 7 Select the new dimension in Schema Tree View, and select an option from the Default Hierarchy menu. Teradata Schema Workbench User Guide, Release

58 Chapter 7: Dimensions, Hierarchies, Levels, and Properties Dimensions and Hierarchies Creating a Hierarchy All hierarchies that belong to the same dimension share the same set of foreign keys. The Teradata BI Repository solution only handles level-based dimension hierarchies. This means all hierarchies are balanced, with leaf members only at the bottom level. Parent-Child (value-based) hierarchies are not supported unless transformed into a level-based star schema in the underlying database. For information, see Modeling Parent-Child Hierarchies on page 110. 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 or Excel To create a hierarchy for a dimension 1 From the Schema Tree View, right-click a Dimension, and select New Hierarchy. The Hierarchy Wizard appears. 2 In the Name box, type a name for the new hierarchy. 3 Click the Caption box. The caption automatically fills with the same name as the hierarchy. The caption is a name that is displayed and can be localized to different languages in the BI client application. For more information, see Cube Schema Localization on page [Optional] Select the Use All Member check box to have Teradata Schema Workbench automatically create a default All level. 58 Teradata Schema Workbench User Guide, Release 14.10

59 Chapter 7: Dimensions, Hierarchies, Levels, and Properties Levels and Properties 5 Click OK. Editing a Hierarchy The Hierarchy is added under its Dimension in tree view, and the Hierarchy page appears in the Schema Elements Properties view. 6 [Optional] Click Set Default Member to ALL to set the MDX default member to the All member. When including an ALL level, the default member automatically sets to the ALL member. 7 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. You can modify hierarchy properties in the Schema Elements Properties view. To edit a hierarchy 1 In Schema Tree View, expand the Dimensions folder and select a hierarchy to edit. 2 Edit settings in the Schema Elements Properties view. Levels and Properties Each level within a dimension typically represents a group of data sharing a 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. Teradata Schema Workbench User Guide, Release

60 Chapter 7: Dimensions, Hierarchies, Levels, and Properties Levels and Properties To add a dimension level 1 From the Schema Tree View, vertically expand the Dimensions folder and right-click the hierarchy to add a new level to. The Schema Element Properties View appears in the right pane. 2 In the Name box, type a name for the new level. 3 Click in the Caption box. The caption automatically fills with the same name as the level. The caption is a name that is displayed and can be localized to different languages in the BI client application. For more information, see Cube Schema Localization on page 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 a data type the level represents. Properly set the type for time levels. MDX functions, other tools, and third party applications use dimension type and level type values. For example, PeriodsToDate, Account Intelligence, and Currency Conversion Wizard. For a list of Microsoft 2008 BI tool level types, search the Microsoft Developer Network Library ( for LevelTypeEnum Enumeration. For more information, see Level Member Columns on page Select the level database where the level table resides from the Database menu. 6 Select the level table from the Table menu. This table is from the level database Teradata Schema Workbench uses as the source data for hierarchy members at this level. 7 Select a caption column from the Caption Column menu. This caption column exists in the level table and represents caption data for this level. 8 Select a sort column from the Sort Column menu. 60 Teradata Schema Workbench User Guide, Release 14.10

61 Chapter 7: Dimensions, Hierarchies, Levels, and Properties Levels and Properties 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. Figure 16 shows the properties for a newly-added Product level. Figure 16: 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 on which to add a new level. 2 Right-click and select New Level Here to create a new level above the selected level. Teradata Schema Workbench User Guide, Release

62 Chapter 7: Dimensions, Hierarchies, Levels, and Properties Levels and Properties To reorder a dimension level 1 From the Schema Tree View, vertically expand the Dimensions folder and select the dimension 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. 62 Teradata Schema Workbench User Guide, Release 14.10

63 Chapter 7: Dimensions, Hierarchies, Levels, and Properties Levels and Properties Member properties are specified as Property elements under a level. The procedure in this section demonstrates creating member properties at the leaf level, but member properties can exist at any 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 on which to add a new property. 2 Right-click and select New Property. The Schema Element Properties View appears in the right pane. 3 In the Name box, type a name for the new property. 4 Click in the Caption box. The caption automatically fills with the same name as the property. The caption is a name that is displayed and can be localized to different languages in the BI client application. For more information, see Cube Schema Localization on page Select a property format style from the level table from the Property Format Style menu. Property Format Style formats how properties appear. For date columns, select Date. For time columns, select Time. For timestamp columns, select Date, Time, or Timestamp. Select General to disable formatting on values containing fixed numbers, such as an employee or account ID. Select Numeric to enable formatting for large numbers, such as 1,244, The Database field automatically displays the same database as the parent dimension. 7 Select a property table from the Table menu. 8 Select a property column from the Column menu. Teradata Schema Workbench User Guide, Release

64 Chapter 7: Dimensions, Hierarchies, Levels, and Properties Levels and Properties 64 Teradata Schema Workbench User Guide, Release 14.10

65 CHAPTER 8 Measure Groups and Cubes The following topics provide information on creating measure groups and cubes: Creating a Measure Group About Calculated Measures Creating a New Cube Additional Cube Settings Creating a Measure Group Measure Groups logically break measures from a fact table into meaningful groups, enabling association with specific dimensions. This allows calculating measures relative to selected dimensions. Measure Groups allow cube administrators to create semi-additive measures. When all dimensions in a cube have a relationship with a measure group, any two intersections in the multi-dimensional cube can be a different value. When only some dimensions in a cube have a relationship with a measure group, only those dimensions with a relationship can show different values for the measures in the group. Moving along a dimension that has no relationship with the measure group always results in the same value. This value depends on the measure aggregator. After assigning a measure group and specifying its properties, you can use a Measure Group in a data cube. For information, see Creating a New Cube on page 67. To add a measure group to a schema, set properties, and associate dimensions 1 Expand the schema in the Schema Tree View, right-click the Measure Groups folder, and click New Measure Group. The Measure Groups panel opens in the Schema Element Properties View. Teradata Schema Workbench User Guide, Release

66 Chapter 8: Measure Groups and Cubes Creating a Measure Group 2 In the Name box, type a name for the new measure group, then click the Caption box. The caption automatically fills with the same name as the level. The caption is a name that is displayed and can be localized to different languages in the BI client application. For more information, see Cube Schema Localization on page In the Fact Table list, select the option containing measures for this group. Note: A measure group can only group measures from a single fact table. However, the same fact table can be used for multiple measure groups. The list of measures available to the fact table display. 4 (Optional) In the Use list, select one of the following: To make a calculation-only measure available in BI client, select Visible. To restrict a calculation-only measure from BI client availability, select Not Visible. To completely restrict using a calculation-only measure, select Inactive. You can click the Set All Visible, Set All Not Visible, or Set All Inactive button to set all measures to the same value. 5 Select the Dimension Usage tab. The list of dimensions available in the schema display dimension names and captions. The measure group can use a subset of dimensions related to the selected fact table. 66 Teradata Schema Workbench User Guide, Release 14.10

67 Chapter 8: Measure Groups and Cubes About Calculated Measures 6 To associate a dimension with this measure group, check the boxes in the Use column. You can click the Check All or Uncheck All button to select or deselect all listed dimensions. The Fact Table column indicates RELATED or NO RELATION status for each dimension. Dimensions in the schema not related to the fact table appear but are not selectable. 7 [Optional] Enable Drill-Through. For information, see Drill-Through on page 89. About Calculated Measures Calculated Measures can be measure group-scoped or schema-scoped. Measure group-scoped calculated measures can only use measures from the same measure group. Schema-scoped calculated measures are specified as part of a schema, and can use measures from any measure group. Defining a calculated measure is the same if measure group-scoped or schema-scoped. For instructions, see Calculated Measures on page 94. Creating a New Cube A schema must contain the following before creating a new cube: At least one dimension, containing At least one hierarchy, containing At least one level At least one measure group To create a new cube and set properties 1 Expand the schema on the Schema Tree View. 2 Right-click the Cubes folder, then click New Cube. Teradata Schema Workbench User Guide, Release

68 Chapter 8: Measure Groups and Cubes Creating a New Cube The Schema Element Properties pane displays the Cube Properties tab with blank settings. 3 In the Name box, type a name for the new measure group, then click the Caption box. The caption automatically fills with the same name as the level. The caption is a name that is displayed and can be localized to different languages in the BI client application. For more information, see Cube Schema Localization on page 99. Note: The cube name can be up to 100 characters in length. The following punctuation and special characters are not allowed in cube names:., ; ' ` : / \ *? " & % $! + = ( ) [ ] { } < > 4 Click the Measure Groups tab. Available Measure Groups display measure group names, captions, and source fact tables. 5 To associate a measure group with this cube, check the boxes in the Use column. You can click the Check All or Uncheck All button to select or deselect all listed measure groups. 6 Click the Cube Properties tab, then select options to define the default measure from the Group and Measure lists. When an OLAP tool, such as MS Excel, sends MDX without a specified measure, Teradata OLAP Connector uses the default measure. 7 Modify additional properties as needed: For best results, leave Enabled and Cache cell values check boxes active. The Enabled check box indicates whether or not this cube is enabled (when published) for BI clients such as Excel. This allows you to publish a schema with usable new aspects, but hide defined and validated cubes from the Excel client user. Drill-Through Settings are active by default. For information, see Drill-Through on page Teradata Schema Workbench User Guide, Release 14.10

69 Chapter 8: Measure Groups and Cubes Additional Cube Settings Additional Cube Settings The Named Sets and Security tabs list available named set and security settings defined outside of the cube. For details, see the following sections: Create a Named Set on page 92 Defining Cube Security on page 73 Teradata Schema Workbench User Guide, Release

70 Chapter 8: Measure Groups and Cubes Additional Cube Settings 70 Teradata Schema Workbench User Guide, Release 14.10

71 CHAPTER 9 Security Settings This chapter describes mapping roles into the Teradata BI Repository solution, as well as restricting access to cubes, dimensions, hierarchies, levels, and members. The following topics describe how to map roles and define security: Overview Map a Role Defining Cube Security Defining Level Security Aggregation Policy Defining Member Security Member Security Dialog Box Overview Teradata BI Repository implements security using standard Teradata Database security roles. Teradata BI Repository 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 29. 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 BI Repository 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 BI Repository. 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 BI Repository supports the ability to map a Teradata security role into a given cube schema and allowing you to grant or deny access associated with this role. The list of Teradata Schema Workbench User Guide, Release

72 Chapter 9: Security Settings Map a Role usernames associated with a role is managed outside of Teradata BI Repository 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 Workbench. It is unnecessary to restrict access to the SALES source tables by these roles. As an alternative to the normal role based cube security model, Teradata OLAP Connector and Teradata OLAP Server facilitate the use of existing user/role based database access control, already set up in the database, by utilizing trusted sessions when establishing query connections with the database. Trusted sessions ensure the actual end user's credentials are passed to the database to support role based access control. See Trusted Sessions on page 101 for more information on trusted sessions. Map a Role To allow access to Teradata BI Repository, identify and specify one of the Teradata Database roles, such as TBI_SALESCUBE_ALL, into the cube schema. Create the role within Teradata Database first. Validation verifies all mapped roles exist within the chosen Teradata Database. Each Teradata Database role mapped into the Schema Tree View defaults to having full access to the entire schema after publishing the schema. Unless you want them to see the entire schema (all aspects of all cubes), restrict that role in Schema Tree View to just the cubes or other OLAP objects they should have access to. If a use has multiple roles with conflicting rights on a schema, cube, dimension, hierarchy, level or members of a level, the least restrictive security is the default, combining access for all roles together. To map a role Mapping a role provides role access to a particular schema. 1 Click File>Open to open a schema. 2 In Schema Tree View, click Business Intelligence Data View. 3 Select the Security tab. The Schema Editor Properties pane displays a table with all roles in the database. Beside each role is a check box indicating if the role is mapped into the schema. 4 Click the Grant check box to map a role into the database. Each checked role is immediately added to the Tree View under the Security folder. 72 Teradata Schema Workbench User Guide, Release 14.10

73 Chapter 9: Security Settings Defining Cube Security Note: The check boxes grant the mapped role to the schema, but not to any schema element. Access is granted to individual levels, hierarchies, dimensions, and cubes in the sections Defining Cube Security on page 73 and Defining Level Security on page Uncheck each role to be unmapped from the schema. Note: If a role is removed from the Teradata Database system, it is no longer available in the Security tab. Defining Cube Security A Teradata role may be denied access to one or more cubes of a cube schema. Additionally, a role can be denied access to a specific hierarchy. You cannot control access to cube measures using Teradata BI Repository security. To prevent a user role from accessing certain measures, create a cube with fewer defined measures. Security policy changes take effect when the schema publishes to the Teradata BI Model Repository. 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. For a hierarchy to be visible, a role must have access to the cube dimension it belongs to. A dimension can have more than one hierarchy. For example, a Time dimension might have Calendar Year and Fiscal Year hierarchies. To withdraw access by a role to a specific schema element 1 In Schema Tree View, expand the Security folder and select an available role. The settings for the selected role display in the Schema Element Properties pane. 2 Use the Permissions box, select a check box to grant access, and any underlying objects (dimensions, hierarchies, levels). Teradata Schema Workbench User Guide, Release

74 Chapter 9: Security Settings Defining Cube Security Check boxes can be in one of three states: An empty check box indicates no access to that schema element. In Figure 17, the role TBI_PANPROVIDER has no access to: Warehouse and Sales cube Promotion dimension in Sales and Employees cube Yearly Income hierarchy in Customer dimension of the Sales and Employees cube Note: A role can have access to a dimension in one cube but be denied access to the same dimension in another cube. Figure 17: Example - Security Role Check boxes A grey check box indicates partial access to that schema element. 74 Teradata Schema Workbench User Guide, Release 14.10

75 Chapter 9: Security Settings Defining Cube Security Figure 18, shows the role TBI_PANPROVIDER has partial access to the Customer dimension (all hierarchies except the Yearly Income hierarchy). Figure 18: Example - Security Role Partial Access A check mark indicates full access to that schema element, and all child elements. In Figure 19, the role TBI_PANPROVIDER has full access to the Product, Store, and Time dimensions, including all their hierarchies and levels. Figure 19: Example - Security Role Full Access 3 Validate and publish the repository. Security policy changes do not take effect until the schema is published to the repository. For instructions, see Chapter 10. Teradata Schema Workbench User Guide, Release

76 Chapter 9: Security Settings Defining Level Security Example 1 Open a cube schema. 2 From the Schema Tree View, expand the Security folder, and select an available role. The Schema Element Properties View appears in the right pane. By default, the role has access to the entire schema. In the example, the user selects TBI_PANPROVIDER role. 3 Clear the check box for the Warehouse and Sales cube. Figure 20 on page 76 shows the TBI_PANPROVIDER role has been restricted from accessing the Warehouse and Sales cube. Figure 20: Example of Withdrawing Access to a Cube 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 to prevent BI client application users from seeing individual fact table entries. Teradata Schema Workbench defines how to compute aggregate values for levels by using the Aggregation Policy. For more information, see Aggregation Policy on page Teradata Schema Workbench User Guide, Release 14.10

77 Chapter 9: Security Settings Defining Level Security To withdraw drill down access to a level 1 From the Schema Tree View, select the role under the Security folder. The Schema Element Properties View displays in the right pane. 2 In the Permissions pane, expand the cube and dimension until the hierarchy is in view. 3 Select the hierarchy (not the check box) The Allowed Range of Levels panel appears. 4 Under the Top Level column, select the radio button for the topmost level the role should be allowed to access. Note: Lowering the top level automatically removes the check mark from Allow All Levels, which removes the availability of BI client tools to see grand totals. 5 Under the Bottom Level column, select the radio button for the lowest level the role should be allowed to access. Note: The bottom level can be set at the same as the top level, but the bottom level cannot be set higher than the top level. Aggregation Policy The Aggregation Policy determines how Teradata OLAP Connector computes aggregates for a level of the hierarchy if the user security role does not have complete access to requested elements. In Teradata Schema Workbench, the two values for Aggregation Policy are: 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. Teradata Schema Workbench User Guide, Release

78 Chapter 9: Security Settings Defining Level Security 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. The following example uses the SampleSchema Product dimension and Store Sales measure. Figure 21 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 21: Aggregate Policy Example 1 Let us modify the role to restrict access of the user to Dairy. Figure 22 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. Figure 22: Aggregate Policy Example 2 Let us modify the roll up policy to Restricted. Figure 23 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. Figure 23: Aggregate Policy Example 3 78 Teradata Schema Workbench User Guide, Release 14.10

79 Chapter 9: Security Settings Defining Level Security 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 1 From the Schema Tree View, select a role under the Security folder. The Schema Element Properties View displays in the right pane. 2 In the Permissions box, expand the cube and select a hierarchy. 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 For the level at which member security needs to be applied, click Create. The Member Security Dialog box appears. For a description, see Member Security Dialog Box on page Select a member from the Members matching filter list and click the right arrow button to add it to the Selected Members box. Repeat as necessary. 5 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 Continuing with the SampleSchema TBI_PANPROVIDER example from Defining Level Security on page 76. A user with the TBI_PANPROVIDER role is restricted from drill down access to levels below Product Department for the Product dimension s Products hierarchy. This example demonstrates how to restrict access to the [Food] and [Non-Consumable] members of the Product Family level for the TBI_PANPROVIDER role. 1 Select the TBI_PANPROVIDER role. 2 In the Permissions box, expand the permissions for the Sales and Employees cube and for the Product dimension. Teradata Schema Workbench User Guide, Release

80 Chapter 9: Security Settings Defining Level Security 3 Click the Products hierarchy. 4 Select Top Level for the Product Family Level Name, and click Create. The Member Security Dialog box appears. 5 Select [Food] and [Non-Consumable] in the Members matching filter box, and click the right arrow to move them to the Access to these members is box. 6 Click Deny. 7 Click OK. The TBI_PANPROVIDER role can only access [Product].[Drink] and its children.the Clear button for the Product Family level is now enabled in the Schema Element Properties View. 80 Teradata Schema Workbench User Guide, Release 14.10

81 Chapter 9: Security Settings Defining Level Security Teradata Schema Workbench User Guide, Release

82 Chapter 9: Security Settings Defining Level Security Member Security Dialog Box This section describes the Member Security Dialog box. Figure 24: Member Security Dialog Box Table 8: Member Security Dialog Box Region Filter Members By Members Matching Filter Access To Members Description The number of members at this level may be very large (most likely at lower levels in the hierarchy), so it is useful to be able to filter on just those members of interest. By default, members are filtered by Caption, but can also be filtered by Member Name. If no filter is applied above, then this section lists all members at this level (to a maximum of 500). Otherwise, only those members matching the filter are displayed and available for selection. Member security applies specifically to the members in this list. Access to these members can be explicitly set to: Allow: access to any member (and its descendants) not listed in this window is denied to the group. Deny: access to any member (and its descendants) not listed in this window is allowed. 82 Teradata Schema Workbench User Guide, Release 14.10

83 CHAPTER 10 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 Database Copy a Schema to a Different Database 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 Teradata BI Model Repository in a database. 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 25 on page 84 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. Teradata Schema Workbench User Guide, Release

84 Chapter 10: Save, Validate, Publish, and Transfer Schema Validation Figure 25: 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 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 85. 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 8: Measure Groups and Cubes. 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. 84 Teradata Schema Workbench User Guide, Release 14.10

85 Chapter 10: Save, Validate, Publish, and Transfer Save a Schema to the File System This validates against the repository information, such as existing database, column and role names, in the database to which you are connected. 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 The schema contains duplicate names within the same node in the page 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 BI Repository 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 Database A schema is validated before it is published. A schema that fails validation cannot be published to the Teradata BI Model Repository, but it can be saved. See Save a Schema to the File System on page 85. If the schema fails to validate, no changes are made to the Teradata BI Model Repository. Teradata Schema Workbench User Guide, Release

86 Chapter 10: Save, Validate, Publish, and Transfer Copy a Schema to a Different Database 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 when complete. Copy a Schema to a Different Database 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 Model Repository. The Select Cube Schemas dialog box appears with a list of the schemas in the Teradata BI Model Repository. 2 Select a schema, and click Open. 3 Click Repository>Disconnect from Database System. 4 View the database connection status bar to ensure it states Not Connected. 5 [Optional] If there is risk of overwriting a similarly-named schema in the target Teradata BI Model Repository to keep, rename your schema. 6 Click Repository>Connect to Database System to connect to the database receiving a copy of the schema. 7 Publish the schema to this newly-connected database. See Publish a Schema to the Database on page 85. 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 Repository>Delete a BI Schema. 86 Teradata Schema Workbench User Guide, Release 14.10

87 Chapter 10: Save, Validate, Publish, and Transfer Delete a Schema The Delete a BI Schema dialog box appears with a list of the schemas in the Teradata BI Model Repository. 3 Select the schema to be deleted 4 Click Delete. If there is no error message, you have successfully deleted the schema. Teradata Schema Workbench User Guide, Release

88 Chapter 10: Save, Validate, Publish, and Transfer Delete a Schema 88 Teradata Schema Workbench User Guide, Release 14.10

89 CHAPTER 11 Additional Features The following topics provide information on creating named set and calculated members: Drill-Through Create a Named Set MDX Expressions in Calculations Cube Schema Localization Trusted Sessions Drill-Through Drill-Through is a feature whereby a user of a BI client such as Excel can select a measure cell in a PivotTable and ask to retrieve the underlying relational records that were aggregated to form that measure cell value. This feature is disabled by default. Drill-Through is to be contrasted with drill-down on a dimension hierarchy member. See the Teradata Schema Workbench User Guide for more information on drill-down. User Invocation Drill-though using an OLAP client application like Microsoft Excel is invoked by right-clicking on a measure cell, and selecting Show Details. Note: Calculated measures do not support drill-through. Excel displays drill-through results as a new worksheet in the existing workbook. Unmanaged Drill-Through If the cube administrator does not configure the results to be returned, the default drill-through result worksheet will have one column for each measure defined by the cube administrator for that cube, not just those measures in the Excel PivotTable actually drilled through. The sheet will also, by default, have one column for the lowest level of the default hierarchy of each dimension referred to by the fact table. Associated captions rather than the raw keys will be shown. The rows that appear in the drill-through results will be ordered according to the measure cell selected, in decreasing order. Teradata Schema Workbench User Guide, Release

90 Chapter 11: Additional Features Drill-Through Managed Drill-Through The cube administrator can use Teradata Schema Workbench to manage the drill-through result set in the following ways: Restrict the result column set to less than the full set of measures Reorder the sequence that the measure columns and dimension columns appear in the result set Define if the results are to be ordered according to one or more columns Extend the result column set to include some fact table columns not defined by the cube administrator as cube measures or as hierarchy keys For example, each transaction may contain a memo field. This field is not aggregated as a measure, but could be valuable to see as part of a drill through result set Security Drill-through is not enabled by default. The cube administrator is able to enable or disable drill-through on a per-measure group basis for each measure group in a schema. In addition to restricting access to transaction data for security reasons, leaving drill-through disabled may also help performance. There may be a slight performance hit on the database because of drill-through operations due to the database retrieving a large number of records and then sorting them. Drill-through is enabled or disabled per measure group, independent of user role. However, if drill-through is enabled, users on a per-security-role basis can then be allowed or denied by Teradata Schema Workbench to drill-through on any cube that includes that measure group. Users with multiple, conflicting BI Workbench roles regarding drill-through on a measure group will be allowed to drill-through. If the user has multiple conflicting roles regarding a particular measure's security, the user's least restrictive role applies. Enabling Drill-Through To enable drill-through on a measure group in a schema: 1 Expand the schema on the Schema Tree View. 2 Expand the Measure Groups folder on the Schema Tree View in the left pane. 3 Select the measure group that is to be enabled for drill-through. 4 The panel for Measure Groups will open in the Schema Element Properties View in the right pane. Select the Drill Through tab. 5 Select the Enabled box to enable Drill-Through. 6 The list of columns to be returned to the BI client is listed. If the list is empty, click the Reset to Default button. 90 Teradata Schema Workbench User Guide, Release 14.10

91 Chapter 11: Additional Features Drill-Through The default result set of a drill-through operation will include one column for each measure in the measure group, as well as one column for the lowest level of the default hierarchy of each dimension associated with the measure group. At this point, drill-through is unman aged. Configuring Managed Drill-Through Use the following procedures to change column order, remove a column, or add a column. Column Order To change the order in which the columns are returned to the client, select a column in the list and use the Move Column Up and Move Column Down buttons. Removing Columns To remove a column from the drill-through result set, select a column in the list and click Remove Column. Adding Columns To add a column previous removed from the result set, or extend the result set columns to include some fact table columns not defined as cube measures or as hierarchy keys. To reapply a column to the result set 1 Click Add Columns. The Add Drill-Through Columns dialog box appears. 2 Select the table that contains the desired column. The Available Columns list populates with all columns not currently in the result set. 3 Select the column(s) that are to be added to the drill-through result set. 4 Click the right arrow to add the selected columns to the result set, or click on the double right arrow to add all columns to the result set. 5 Click OK. The additional columns are added to the end of the drill-through result set. They can be reordered as described above. Result Set Order The result set rows can be sorted according to one or more columns. Each column can be given a sort priority. For example, a column with priority 1 sorts before a column with priority 2. The measure cell chosen for drill-through always sorts with priority 0 (before the column with priority 1). To define a sort priority for a column, select the appropriate column, and enter a positive integer in the Sort Priority box, which lists the order that the columns sort in. Entering a priority equal to an existing priority increments the priority created earliest. For example, if there was already a 1, 2, and 3, and the user entered 1 in a previously blank cell, then the Teradata Schema Workbench User Guide, Release

92 Chapter 11: Additional Features Create a Named Set original 1 becomes 2, the original 2 becomes 3, and so forth. The opposite happens if a number is removed; all other lower priority sorts decrement by one. The priority is specified using positive integers less than 100, restricting the value to one or two digits. To enter a number, click in the cell and types, consistent with any other text box. To remove a priority, delete the numbers in the cell using backspace or delete. Reset to Default To restore the drill-through result set to default settings, click Reset to Default. If the Enabled check box is unchecked, all settings for managed drill-through are lost for this measure group. The state is not maintained, so that if Enabled is again checked, it reverts back to the default setting. Create a Named Set A named set is a set of dimension members that is complex, lengthy, or frequently in use. Named sets are not supported by Excel 2003 or Excel XP (2002). From a security point of view, Teradata BI Repository 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 116. 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. Creating a Schema Scope Named Set Schema-scoped named sets are used with members that belong to a dimension. 92 Teradata Schema Workbench User Guide, Release 14.10

93 Chapter 11: Additional Features Create a Named Set To create a schema-scoped named set 1 From Schema Tree View, right-click the Named Sets folder, and select New Named Set. The Schema Element Properties View appears in the right pane. 2 In the Name box, type a name for the new named set. 3 Click in the Caption box. The caption automatically fills with the same name as the measure. The caption displays and can be localized to different languages in the BI client application. For more information, see Cube Schema Localization on page 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 96, Appendix B: Supported MDX Functions and Operators, and MDX Validation Errors on page 114. Figure 26 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 26: Creating a Named Set 5 Select a hierarchy from the Hierarchy menu in which this named set displays in BI client applications. Teradata Schema Workbench User Guide, Release

94 Chapter 11: Additional Features Calculated Measures 6 Type a display folder in the Display Folder box in which this folder will be displayed in BI clients applications. Figure 27 shows a newly-created display folder in Excel called Sets. Figure 27: Creating a Display Folder for a Named Set Calculated Measures 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 (Whitehorn, Zare, and Pasumansky 2006) MDX Solutions, 2nd edition (Spofford and Harinath 2006) Create a Calculated Measure With 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. 94 Teradata Schema Workbench User Guide, Release 14.10

95 Chapter 11: Additional Features Calculated Measures To create a calculated measure for a cube 1 From Schema Tree View, right-click a cube, and click New Calculated Measure. The Schema Element Properties View appears in the right pane. 2 In the Name box, type a name for the new calculated measure. 3 Click the Caption box. The caption automatically fills with the same name as the cube. The caption is a name that is displayed and can be localized to different languages in the BI client application. For more information, see Cube Schema Localization on page [Optional] To prevent visibility to BI client applications, clear the Visible check box. 5 Type the MDX query language formula in the MDX Expression box and click Validate Expression to validate the MDX expression. Teradata Schema Workbench User Guide, Release

96 Chapter 11: Additional Features Calculated Measures For more information, see MDX Expressions in Calculations on page 96. 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 Type a format string or select a format string from the Format String menu. For more information, see Format Strings on page 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 Solve Order value must be an integer greater than or equal to zero. Calculated measures are evaluated in order starting with the lowest Solve Order value first, continuing on with the next lowest value Find useful information by searching for solve order in the Microsoft Developer Network Library at Unless you are sure a non-default solve order is required, leave the value at zero. MDX Expressions in Calculations Teradata BI Repository supports a limited form of MDX partial qualification. Member names must be fully qualified, but expressions like[time].[calendar].[quarter].members can be abbreviated to [Quarter].Members if Quarter is unique. Using fully-qualified name is the safest and most reliable method to express 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 types of errors. 96 Teradata Schema Workbench User Guide, Release 14.10

97 Chapter 11: Additional Features Create Calculated Members The syntax error message only indicates whether the syntax is valid or not. You must examine the MDX to find the error. For more information, see MDX Validation Errors on page 114. Create Calculated Members A calculated member is a member whose value that calculates 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. Note: Calculated members are not supported by Excel 2003 or earlier versions. Teradata Schema Workbench User Guide, Release

98 Chapter 11: Additional Features Create Calculated Members To create a calculated member for a hierarchy 1 From the Schema Tree View, right-click on the cube, and select New Calculated Member. The Schema Element Properties View appears in the right pane. 2 In the Name box, type a name for the new calculated member. 3 Click in the Caption box. The caption automatically fills with the same name as the calculated member. The caption is a name that is displayed and can be localized to different languages in the BI client application. For more information, see Cube Schema Localization on page Select the parent hierarchy for the new calculated member from the Hierarchy menu. 5 [Optional] To prevent measure visibility to BI client applications, uncheck the Visible check box. 6 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 MDX Expressions in Calculations on page 96. 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 Type a number in the Solve Order box. 98 Teradata Schema Workbench User Guide, Release 14.10

99 Chapter 11: Additional Features Cube Schema Localization Solve order is an integer priority for your calculated member relative to other MDX calculations. Unless a non-default solve order is required, leave the value at zero. Find useful information by searching for solve order in the Microsoft Developer Network Library at 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: Create a Named Set MDX Expressions in Calculations 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. To create a localization element 1 From Schema Tree View, expand the hierarchy and click the Localization element. All captions and format strings that are used for the schema are visible in the Schema Element Properties View. 2 Select a language (locale) from the Add Language menu to specify a caption to translate. Teradata Schema Workbench User Guide, Release

100 Chapter 11: Additional Features Cube Schema Localization Figure 28: Adding Languages to the Localization Element 3 Click Add. A column displays for the new language. Figure 28 shows the result of adding a French (Canada) translation to the SampleSchema. Scroll down to see how the format string displays. 4 In the column for the new language, type the captions for the new locale. To delete a localization element 1 From Schema Tree View, expand the hierarchy and click the Localization element. 2 Right-click the language (locale) column and click Delete. 100 Teradata Schema Workbench User Guide, Release 14.10

101 Chapter 11: Additional Features Trusted Sessions 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 29. Figure 29: 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. For useful information on format strings: Read Appendix D in MDX Solutions, 2nd edition (Spofford and Harinath 2006). Search for format string contents (MDX) in the Microsoft Developer Network Library at Trusted Sessions Note: For background information on how security is implemented in Teradata, see Chapter 9: Security Settings. In a Trusted Session, security permissions for another user having access rights in the Teradata Database are applied to queries. A Trusted Session is defined using Query Banding. In general, query banding allows you to associate key-value pairs with queries, which enables job prioritization for BI client users connecting to a Teradata Database. The ProxyUser and ProxyRole keys are used to set up a trusted session. When initiating a session, the Teradata OLAP Connector and Teradata OLAP Server always attempt to set up a trusted session using credentials provided in the DSN or during the logon process. If permissions for credentials specified in the DSN or logon process are not defined in Teradata Schema Workbench User Guide, Release

102 Chapter 11: Additional Features Trusted Sessions the Teradata Database, then queries for the session are executed using the permissions defined for the MDX Service Account. See Setting Up an MDX Service Account and OLAP Connection on page 34 for further details on the MDX Service Account. For more details on Trusted Sessions and Query Banding, see Security Administration (B ). The following excerpt from a Teradata OLAP Connector log file shows how the OLAP Connector attempts to set up a trusted session using the ProxyUser key, and then reverts to using the MDX Service Account: <INFO> 2013/06/04 13:26: [[TBIUSER@]] [ ] SQL: SET QUERY_BAND='UserId=TBIUSER;ApplicationName=Teradata OLAP Connector;Version= ;ProxyUser=TBIUSER;' FOR SESSION </INFO> Page 83 of 100 <ERROR> 2013/06/04 13:26: [[TBIUSER@]] [ ] ExecuteDirect [Teradata][ODBC Teradata Driver][Teradata Database] Connect Through has not been granted to TBIUSER through TBISERVICE. SQL state = HY000, Native err = </ERROR> <INFO> 2013/06/04 13:26: [[TBIUSER@]] [ ] SQL: SET QUERY_BAND='UserId=TBIUSER;ApplicationName=Teradata OLAP Connector;Version= ;' FOR SESSION </INFO> Trusted Sessions are supported in Teradata Database version 13.0 or greater. How Security Is Applied For a Teradata OLAP Connector Session Figure 30: Applying Security in a Teradata OLAP Connector Session Excel OLAP Connector Cube Database Tables Teradata Schema Workbench User Guide, Release 14.10

103 Chapter 11: Additional Features Trusted Sessions The following example illustrates how and when security is applied on a query request using Excel and Teradata OLAP Connector and the impact on the returned result set. The numbered items correspond to the numbered call outs in Figure 30. The user starts Excel and selects Teradata OLAP Connector as the data source. The user selects an ODBC DSN to be utilized by Teradata OLAP Connector. This DSN may contain saved user credentials. If not, the user is prompted to enter user name and password as part of configuring the Teradata OLAP Connector. In the examples below, assume the user has provided user name = "Foo". 1 Teradata OLAP Connector attempts to establish trusted session with the database using: Set QueryBand = 'ProxyUser = Foo' 2 If DBA had previously allowed ConnectThrough for user Foo, the request is successful. If DBA did not enable ConnectThrough for user Foo, the request to establish trusted session fails. 3 If a trusted session is established, Teradata OLAP Connector queries cube metadata. Database uses access permissions for user Foo. If a trusted session is not established, Teradata OLAP Connector queries cube metadata. Database uses access permissions for user associated with TBI_SERVICE role (tbiservice in this example). 4 If a trusted session is established, cube metadata result set returned. Contents of result set comprises any cube metadata visible to user Foo. If a trusted session is not established, cube metadata result set returned. Contents of result set comprises any cube metadata visible to user tbiservice. 5 Measure or dimension is dragged to a row or column, or a filter is applied in pivot table, resulting in an OLAP request. 6 If a trusted session is established, Teradata OLAP Connector queries physical table. Database uses access permissions for user Foo. If a trusted session is not established, Teradata OLAP Connector queries physical table. Database uses access permissions for user tbiservice. 7 If a trusted session is established, result set returned. Contents of result set comprises any data visible to the user Foo. If a trusted session is not established, result set returned. Contents of result set comprises any data visible to the user tbiservice. 8 Teradata OLAP Connector applies any further security rules modeled into the cube definition based on the roles assigned to user Foo. PivotTable is updated with the result set data minus any Cube, Dimensions, Hierarchies, or Members filtered out by the application of the modeled security rules. Teradata Schema Workbench User Guide, Release

104 Chapter 11: Additional Features Trusted Sessions How Security Is Applied For a Teradata OLAP Server Session Figure 31: Applying Security in a Teradata OLAP Server Session Web Browser SAP BOE Server Teradata OLAP Server Cube Database Tables The following example illustrates how and when security is applied on a query request via SAP BOE and the Teradata OLAP Server and its impact on the returned result set. The numbered items correspond to the numbered call outs in Figure 31. The user accesses SAP BOE using a browser, and then selects an OLAP Connection which references the Teradata OLAP Server. The Teradata OLAP Server is configured to utilize an ODBC DSN. This DSN might contain saved user credentials. If not, the user is prompted to enter user name and password by the Teradata OLAP Server. In the examples below, assume the user has provided user name = "Foo." 1 Teradata OLAP Server attempts to establishes trusted session with the database using: Set QueryBand = 'ProxyUser = Foo' 2 If DBA had previously allowed ConnectThrough for user Foo, the request to establish trusted session is successful. If DBA did not enable ConnectThrough for user Foo, the request to establish trusted session fails. 3 If trusted session is established, Teradata OLAP Server queries cube metadata. Database uses access permissions for user Foo. If trusted session is not established, Teradata OLAP Server queries cube metadata. Database uses access permissions for user associated with TBI_SERVICE role (tbiservice in this example). 4 If trusted session is established, cube metadata result set returned. Contents of result set comprises any cube metadata visible to user Foo. 104 Teradata Schema Workbench User Guide, Release 14.10

105 Chapter 11: Additional Features Trusted Sessions If trusted session is not established, cube metadata result set returned. Contents of result set comprises any cube metadata visible to user tbiservice. 5 Measure or dimension is dragged to a row or column resulting in an HTTP request to the SAP BOE Server. 6 SAP BOE Server initiates an XMLA request to Teradata OLAP Server. 7 If trusted session is established, Teradata OLAP Server queries physical table. Database uses access permissions for user Foo. If trusted session is not established, Teradata OLAP Server queries physical table. Database uses access permissions for user tbiservice. 8 If trusted session is established, result set returned. Contents of result set comprises any data visible to the user Foo. If trusted session is not established, result set returned. Contents of result set comprises any data visible to the user tbiservice. 9 Teradata OLAP Server applies any further security rules modeled into the cube definition based on the roles assigned to user Foo and responds to SAP BOE Server with result set data minus any Cube, Dimensions, Hierarchies, or Members filtered out by the application of the modeled security rules. 10 SAP BOE Server updates web page content and forwards to browser. Teradata Schema Workbench User Guide, Release

106 Chapter 11: Additional Features Trusted Sessions 106 Teradata Schema Workbench User Guide, Release 14.10

107 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 Teradata BI Model 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 Where possible, use MDX functions, methods, and operators that are calculated by the underlying Teradata Database instead of using functions, methods, and operators where the Teradata OLAP Connector needs to retrieve all the data from the Teradata Database and do the calculations on the client system. The list of functions, methods, and operators which can be calculated in the Teradata Database are listed in Appendix B. 7 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. Teradata Schema Workbench User Guide, Release

108 Chapter 12: Best Practices MDX Validation Using MDX Sample 8 Add custom named sets or calculated members. Repeat steps 5-7 to ensure the MDX expression is correct, and verify that the named set or calculated member is actually hitting the AJIs. MDX Validation Using MDX Sample Validating MDX Syntax 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. 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 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. 108 Teradata Schema Workbench User Guide, Release 14.10

109 Chapter 12: Best Practices Level Member Columns 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. 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 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 Level member columns 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. Teradata Schema Workbench User Guide, Release

110 Chapter 12: Best Practices AJI-Related Best Practices AJI-Related Best Practices Modeling Parent-Child Hierarchies Teradata Business Intelligence Repository 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 ); The following recursive view example navigates through the parent child table, defining the levels of the Organization hierarchy: create RECURSIVE view Sales_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 ); 110 Teradata Schema Workbench User Guide, Release 14.10

111 Chapter 12: Best Practices AJI-Related Best Practices 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_Cd from Sales_Org_VW where LEVEL = 4) with data Unique 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_Cd from Sales_Org_VW where LEVEL = 3) with data Unique 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_Cd from Sales_Org_VW where LEVEL = 2) with data Unique Primary Index (Division_ID); Create table TAA_Business_Units (Business_Unit_ID, Business_Unit_Name, Top_ID, Country_Cd) as (Select Region_ID,Region_Name, Parent_Region_ID, Country_Cd from Sales_Org_VW where LEVEL = 1) with data Unique 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 in the TAA_Areas table, in order to join the transaction table, add rows into the TAA_Sales_Center table which have a value for the Area_id column. This enables data from ragged hierarchies to join to your facts. Teradata Schema Workbench User Guide, Release

112 Chapter 12: Best Practices Query Banding Administration Query Banding Administration Teradata OLAP Connector uses query banding which enables: Teradata Database Job Prioritization Teradata Database Job Prioritization 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 The parameter {2}, including the braces, is replaced with the name of the published schema associated with the client session. The parameter {3}, including the braces, is replaced with the name of the cube associated with the client session. 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};ApplicationName=Teradata OLAP Connector;Version={1};Schema={2};Cube={3};' FOR SESSION 112 Teradata Schema Workbench User Guide, Release 14.10

113 APPENDIX A Troubleshooting and Known Issues This appendix describes solutions to common issues that Teradata Schema Workbench users might experience. This appendix also describes errors that a BI client user might experience that a cube administrator can resolve using Teradata Schema Workbench. Cube administrators using Teradata Schema Workbench should be 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 118. This appendix contains the following sections: Troubleshooting Known Issues 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 An error occurred trying to connect Message Unable to Establish Repository Connection Message Teradata Schema Workbench Event Logging Teradata Schema Workbench User Guide, Release

114 Appendix A: Troubleshooting and Known Issues Troubleshooting 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 BI Repository do not generate the same member unique names. MDX expressions from one system do not work verbatim in the other, particularly those using & prefixes on member names. The Teradata BI Repository syntax validator catches improper 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 116 and MDX Issues, Functions and Operators on page 117. 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. Get member unique names from this type of tool, as these vary by provider. For example, MDX Sample enables inspecting cube structure using Teradata OLAP Connector and seeing unique names. For more information, see MDX Validation Using MDX Sample on page 108. The Microsoft Analysis Services 2000 MDX Sample application allows you to test the expression. 114 Teradata Schema Workbench User Guide, Release 14.10

115 Appendix A: Troubleshooting and Known Issues Troubleshooting 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. For information on format strings, search for format string contents (MDX) in the MSDN Library at Note: Manually changing the format string from $#,##0 to #.##0 does not cause mathematical currency conversion. Note: Only Excel 2007 and later support cube schema-specified format strings. Excel does this by always including a CELL PROPERTIES clause in the query to the database. If no server side formatting properties are specified for a measure, then the database only returns the VALUE property. Excel 2003 and earlier does not include this CELL PROPERTIES clause in its database query, and always uses the default cell formatting specified in the workbook. Calculated Members Not Showing By default in Excel 2007 and Excel 2010, calculated members defined in your cube schema do not appear. Note: Calculated members are not supported by 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. Teradata Schema Workbench User Guide, Release

116 Appendix A: Troubleshooting and Known Issues Troubleshooting #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 BI Repository 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: 116 Teradata Schema Workbench User Guide, Release 14.10

117 Appendix A: Troubleshooting and Known Issues Troubleshooting 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 117. MDX Issues, Functions and Operators MDX is a sophisticated and intricate multidimensional query language. Because each implementation is different, it might not be valid to copy and paste from one implementation to another. MDX errors that the MDX checker/parser in Teradata Schema Workbench does not catch might 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. Use the following tips to 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 108. 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, Teradata Schema Workbench User Guide, Release

118 Appendix A: Troubleshooting and Known Issues Troubleshooting [Store Type].[Store Types].[ALL].[(ALL)].children on rows from [XYZ] Workaround: select CrossJoin([TIME].[CALENDAR TIME].[ALL].[(ALL)].children, {[Measures].[Sales], [Measures].[Gross Profit]}) on columns, [STORE TYPE].[STORE TYPES].[ALL].[(ALL)].children on rows from [XYZ] An error occurred trying to connect Message The Teradata Schema Workbench message, An error occurred trying to connect 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 118. Unable to Establish Repository Connection Message The following Teradata Schema Workbench message might display for several reasons: Unable to establish repository connection. Please verify you have permission to access the repository, that it exists, and is the correct version. Possible reasons for the error 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 Teradata BI Model Repository does not exist. Ensure the repository exists by looking for the BIM_REPOSITORY database on your server. Use an SQL script to list the cubes and schemas in the repository to ensure it responds. See Listing Schemas in the Repository on page 29. You might have an old version of Teradata Schema Workbench or a version newer than the Teradata BI Model Repository. The Teradata BI Model Repository version number rarely changes. Use the following SQL to see the Teradata BI Model Repository version number: SELECT * from BIM_REPOSITORY.BIM_InstanceSettings WHERE Setting = 'BIM_REPOSITORY_VERSION' To narrow the diagnosis using the Windows Application event log, see Teradata Schema Workbench Event Logging on page 118. 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... write to this log. Some examples include: 118 Teradata Schema Workbench User Guide, Release 14.10

119 Appendix A: Troubleshooting and Known Issues Troubleshooting An error occurred trying to connect 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. 2 Look in Windows Logs>Application. Teradata Schema Workbench User Guide, Release

120 Appendix A: Troubleshooting and Known Issues Known 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 and Excel 2010, 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. Ragged and Skip-Level Hierarchies Teradata BI Repository 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 58. 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. 120 Teradata Schema Workbench User Guide, Release 14.10

121 Appendix A: Troubleshooting and Known Issues Known Issues MDX Aggregate Function 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. 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 BI Repository 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 BI Repository does not support this prefix. For a workaround, see MDX Expressions in Calculations on page 96. Teradata Schema Workbench User Guide, Release

122 Appendix A: Troubleshooting and Known Issues Known Issues 122 Teradata Schema Workbench User Guide, Release 14.10

123 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 Functions Supported MDX Methods Supported MDX Operators Supported MDX Functions Supported Any functions marked by an asterisk (*) can be computed by the Teradata Database. ABS ADDCALCULATEDMEMBERS AGGREGATE ANCESTOR ASCENDANTS AVG* BOTTOMCOUNT BOTTOMPERCENT BOTTOMSUM CDATE CLOSINGPERIOD* CORRELATION COUNT* Note: The COUNT function is only pushed down to the database if it takes the form COUNT(DISTINCT(... The general case is not pushed down. COUSIN CROSSJOIN CSTR DESCENDANTS* DIMENSIONS.COUNT DISTINCT DISTINCTCOUNT* DRILLDOWNLEVEL DRILLDOWNLEVELBOTTOM DRILLDOWNLEVELTOP DRILLDOWNMEMBER DRILLDOWNMEMBERBOTTOM DRILLDOWNMEMBERTOP DRILLUPLEVEL Teradata Schema Workbench User Guide, Release

124 Appendix B: Supported MDX Functions and Operators MDX Functions Supported DRILLUPMEMBER EXCEPT EXTRACT FILTER* GENERATE HEAD HIERARCHIZE IIF* INSTR INTERSECT ISEMPTY LASTPERIODS LCASE LEFT LEN MAX* MEDIAN MEMBERTOSTR MEMBERS MIN* MTD* NEST NONEMPTY OPENINGPERIOD* ORDER ORDINAL PARALLELPERIOD* PERIODSTODATE* QTD* RANK RIGHT RND ROUND SQR STDDEV STDDEVP STDEV STDEVP STRIPCALCULATEDMEMBERS STRTOMEMBER SUBSET SUM* TAIL TOGGLEDRILLSTATE TOPCOUNT TOPPERCENT TOPSUM UCASE UNION VAR VARIANCE VARIANCEP VARP WTD* YTD* 124 Teradata Schema Workbench User Guide, Release 14.10

125 Appendix B: Supported MDX Functions and Operators MDX Methods Supported MDX Methods Supported Any methods marked by an asterisk (*) can be computed by the Teradata Database..ALLMEMBERS.CHILDREN.COUNT.CURRENTMEMBER*.DEFAULTMEMBER.DIMENSION.FIRSTCHILD.FIRSTSIBLING.HIERARCHY.ITEM.LAG.LASTCHILD.LASTSIBLING.LEAD.LEVEL*.LEVEL_NUMBER.LEVELS.MEMBERS.MEMBER_CAPTION.NAME.NEXTMEMBER.ORDINAL.PARENT.PREVMEMBER*.PROPERTIES.SIBLINGS.UNIQUE_NAME.UNIQUENAME MDX Operators Supported Any operators marked by an asterisk (*) can be computed by the Teradata Database. Table 9: Supported MDX Operators MDX Operators : (range) + (arithmetic addition)* + (unary positive) + (string concatenation) + (set union) - (arithmetic difference)* - (unary negation) Teradata Schema Workbench User Guide, Release

126 Appendix B: Supported MDX Functions and Operators MDX Operators Supported Table 9: Supported MDX Operators (continued) MDX Operators - (set exception) * (multiply)* / (divide)* ^ (power) < (less than)* <= (less than or equal to)* <> (not equal to) = (equal to)* > (greater than)* >= (greater than or equal to)* IS AND NOT OR XOR -- (Comment) /*...*/ (Comment) // (Comment) 126 Teradata Schema Workbench User Guide, Release 14.10

127 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 Java Runtime Environment (JRE) for Windows version 5 or higher. To set up the Schema Workbench Repository 1 From the Windows Start menu, click All Programs->Teradata Client > Teradata Schema Workbench-> WorkbenchToolbox. 2 Click Setup Schema Workbench Repository. 3 The program starts with an instruction page, as shown in the example in Figure 34. Schema Workbench Toolbox creates database objects, roles and sets up the appropriate permissions. Therefore, you must create a database user as the owner of the repository database, with the permissions specified on this page. This must be completed before continuing to the next step. Note: Clicking Scripts to Set security Permissions for Repository Owner displays sample script you can edit to set the Teradata Database owner. Teradata Schema Workbench User Guide, Release

128 Appendix C: Schema Workbench Toolbox Schema Workbench Repository Setup Figure 34: Introduction to the Repository Setup 4 Click Next, then type the repository database information. 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 b c d e In the Teradata Server box, type the name of the Teradata server. [Optional] In the Port box, type the port. In the User Account box, type the name of the user account that will become the owner of the repository database. In the Password box, type the password. In the Perm Space (KB) box, type the amount of permanent space you want to allocate for the repository database. The repository database contain tables, views, macros, and triggers associated with Teradata Schema Workbench. 128 Teradata Schema Workbench User Guide, Release 14.10

129 Appendix C: Schema Workbench Toolbox Schema Workbench Repository Setup 5 Click Next. 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. Note: The BIM_REPOSITORY should not exist before setting up the Schema Workbench Repository. If the BIM_REPOSITORY already exists, a message appears. Click OK to exit the Schema Workbench Toolbox. 6 Type the service account information. a b 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. In the Password box, type your password. c In the Retype Password box, retype your password. 7 Click Next. 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. 8 [Optional] Click Preview script to view the scripts that will be executed after setting up. 9 Click Finish to execute the set up scripts. 10 A The repository is successfully setup dialog box appears, as shown in the example in Figure 36 on page 129. Read the information, and then click Close. If an error occurs during setup, the BIM_REPOSITORY database will be deleted and dropped so you can rerun Schema Workbench Repository Setup after the issue is fixed. Figure 36: Example of a successful repository set up Teradata Schema Workbench User Guide, Release

130 Appendix C: Schema Workbench Toolbox Sample Database Loader 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\Client\14.10\ 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 28. To load the sample database 1 From the Windows Start menu, click All Programs->Teradata Client > Teradata Schema Workbench-> WorkbenchToolbox. 2 Click Load Sample Database. 3 The program starts with an instruction page, as shown in Figure 37 on page 130. 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. Note: Clicking Scripts to Set security Permissions for Sample Database Owner displays sample script you can edit to set the Teradata Database owner. Figure 37: Introduction to the Sample Database Loader 130 Teradata Schema Workbench User Guide, Release 14.10

131 Appendix C: Schema Workbench Toolbox 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 b c d In the Teradata Server box, type the name of the Teradata server. [Optional] In the Port box, type the port. In the User Account box, type the name of the user account that will become the owner of the database. 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. 6 Click Next. If the specified perm space is too large in your environment and the following error message appears, click OK, decrease the perm space, and click Next. Note: 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. 7 Click Select Folder and browse to the folder containing the sample database, select the folder, and click OK. The default location of the Sample Loader database folder is C:\Program Files\ Teradata\ Client\14.10\Teradata Schema Workbench\Tools\SampleLoaderData\TAADemo. 8 Click Next. 9 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. 10 Click Finish to execute the set up scripts. 11 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. Teradata Schema Workbench User Guide, Release

132 Appendix C: Schema Workbench Toolbox Sample Database Loader 132 Teradata Schema Workbench User Guide, Release 14.10

133 APPENDIX D 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. Each ODBO session has a unique cache, so when multiple sessions are open by the same user on the same machine, each session will have a unique cache. 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 Teradata Schema Workbench User Guide, Release

134 Appendix D: Teradata OLAP Connector Caching Metadata Caching Transient Entities When an ODBO client requests a cube, all of the cube s permanent entities are pre-loaded from the Teradata BI Model Repository. These entities are cached for the duration of the ODBO session. 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 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 Prefetching Teradata OLAP Connector attempts to minimize the number of Teradata Database retrievals used to satisfy member metadata requests by prefetching 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 prefetching can be configured using the PrefetchLevelSize registry key. This value defaults to 20,000 members. To disable member prefetching, set the value to 0. Teradata OLAP Connector also attempts to prefetch measures with a SUM aggregator. The MaxMeasuresForPrefetch registry key specifies the maximum number of measures to prefetch. This value defaults to 20. When the number of measures in the cube exceeds this value, Teradata OLAP Connector retrieves the first N measures where N is the value specified in the registry. Setting the registry value to 0 disables measure prefetching. 134 Teradata Schema Workbench User Guide, Release 14.10

135 Appendix D: Teradata OLAP Connector Caching Cell Caching Cell Caching Whenever an 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. Teradata Schema Workbench User Guide, Release

136 Appendix D: Teradata OLAP Connector Caching Cell Caching 136 Teradata Schema Workbench User Guide, Release 14.10

137 APPENDIX E BI Model Repository Grants Script The Teradata BI Model 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 Teradata BI Model 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 BIM_REPOSITORY.BIM_ServiceAccount TO TBI_USER; GRANT SELECT, INSERT, UPDATE, DELETE ON BIM_REPOSITORY.BIW_Schema TO TBI_WORKBENCH; GRANT SELECT, INSERT, UPDATE, DELETE ON BIM_REPOSITORY.BIW_SchemaXML TO TBI_WORKBENCH; GRANT SELECT, INSERT, UPDATE, DELETE ON BIM_REPOSITORY.BIW_SchemaGrants TO TBI_WORKBENCH; GRANT SELECT, INSERT, UPDATE, DELETE ON BIM_REPOSITORY.BIM_InstanceSettings TO TBI_WORKBENCH; GRANT SELECT, INSERT, UPDATE, DELETE ON BIM_REPOSITORY.BIM_ServiceAccount TO TBI_WORKBENCH; GRANT SELECT ON BIM_REPOSITORY.BIM_Schema_VW TO TBI_SERVICE; GRANT SELECT ON BIM_REPOSITORY.BIM_SchemaXML_VW TO TBI_SERVICE; GRANT SELECT ON BIM_REPOSITORY.BIM_SchemaGrants_VW TO TBI_SERVICE; GRANT SELECT ON BIM_REPOSITORY.BIM_InstanceSettings TO TBI_SERVICE; Teradata Schema Workbench User Guide, Release

138 Appendix E: BI Model Repository Grants Script SQL Grants Script 138 Teradata Schema Workbench User Guide, Release 14.10

139 APPENDIX F Teradata OLAP Connector Registry Settings BI client applications connect to your database and the Teradata BI Model Repository using Teradata OLAP Connector. Teradata OLAP Connector has useful administrative settings that are documented here. 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 BI Repository expert or the Teradata Global Support Center. If the bitness of Teradata Schema Workbench matches the bitness of the Operating System, then the registry location root is defined at: HKEY_LOCAL_MACHINE\SOFTWARE\Teradata\Client\14.10\ Teradata OLAP Connector\RuntimeSettings If a 32-bit Teradata OLAP Connector is installed on a 64-bit OS, then the registry location root is defined at: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Teradata\Client\14.10\ Teradata OLAP Connector\RuntimeSettings Registry Settings The first four settings in Table 10 are cache and prefetch oriented. To understand these settings before changing them, you must read Appendix D: Teradata OLAP Connector Caching. Table 10: 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 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. Teradata Schema Workbench User Guide, Release

140 Appendix F: Teradata OLAP Connector Registry Settings Specialized Settings Table 10: Teradata OLAP Connector Registry Settings (continued) Key Type Default Value PrefetchLevelSize DWORD Teradata OLAP Connector always attempts to prefetch all dimension members in a level. If the level size exceeds this value, the level does not prefetch. To disable prefetching, set the value to 0. MaxMeasuresForPrefetch DWORD 20 The maximum number of measures to prefetch. To disable prefetching, set the value to 0. MaxCachedCalculatedSet Size DWORD 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, an SQL query should wait before returning to the application. Specialized Settings These settings are only published in this appendix for reference purposes. Caution: Do not change these settings without consulting a Teradata BI Repository expert or the Teradata Global Support Center. Table 11: Teradata OLAP Connector Specialized Settings Key Type Default Value 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. 140 Teradata Schema Workbench User Guide, Release 14.10

141 Appendix F: Teradata OLAP Connector Registry Settings Specialized Settings Table 11: Teradata OLAP Connector Specialized Settings (continued) Key Type Default Value 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. PushdownCalculations DWORD 1 Specifies whether qualifying calculations are pushed down to the underlying Teradata database, or whether they are all done internally within the OLAP Connector. 0: disables pushdown. 1: enables pushdown. Teradata Schema Workbench User Guide, Release

142 Appendix F: Teradata OLAP Connector Registry Settings Specialized Settings 142 Teradata Schema Workbench User Guide, Release 14.10

143 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\Client\14.10\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. Teradata Schema Workbench User Guide, Release

144 Appendix G: Teradata OLAP Connector Logging Setup Logger 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: Teradata OLAP Connector Trace Settings ON.reg Win6432 Teradata OLAP Connector Trace Settings ON.reg 2 From the Teradata Schema Workbench directory, move a copy of the appropriate loggerdisabling script to the target client machine: Teradata OLAP Connector Trace Settings OFF.reg Win6432 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. 144 Teradata Schema Workbench User Guide, Release 14.10

145 APPENDIX H Configuring Schema Workbench Menus Teradata Schema Workbench has two configurable menus for Tools and Help. The purpose of these configurable menus is to allow the configuration of and access to other tools and links in the Tools and Help menus. Configuring the Menus The Tools and Help menus are defined in a file called Teradata Schema Workbench.exe.config, located in C:\Program Files\Teradata\Client\14.10\Teradata Schema Workbench\bin. This XML configuration file can be modified with any text editor. The Help menu options are listed within HelpMenu, between the opening and closing Links XML tags. The Tools menu options are listed within ToolsMenu, between the opening and closing Apps XML tags. To add an option, insert an add XML tag, and provide information for the key and value attributes: <add key="" value ="" />. The content of these sections corresponds with the contents of the Tools and Help menus. The key attribute is the label that appears in the menu, and the value attribute is the target for the link or program that opens when the user clicks the item. To launch new applications or reference Web sites from the menus need to be added between these tags as a key-value pair. Figure 38 shows an example of the default HelpMenu and ToolsMenu code. Figure 38: Configuring the Tools and Help menus <HelpMenu> <Links> <add key="ole DB for OLAP Standard" value=" en-us/library/ms717005(vs.85).aspx"/> <add key="msas2000 MDX Reference" value=" <add key="msas2005 MDX Reference" value=" <add key="msas2008 MDX Reference" value=" </Links> </HelpMenu> <ToolsMenu> <Apps> <add key="tad" value="adt.exe"/> <add key="odbc Admin 32bit" value="odbcad32.exe"/> </Apps> </ToolsMenu> Teradata Schema Workbench User Guide, Release

146 Appendix H: Configuring Schema Workbench Menus Configuring the Menus By default, the Tools menu contains links to the Teradata Aggregate Designer, as well as the 32- bit ODBC Administrator. For more information, see Table 4 on page 40. The Help menu contains links to ODBO standards as well as MDX reference pages. For more information, see Table 6 on page Teradata Schema Workbench User Guide, Release 14.10

147 APPENDIX I Using the Schema Migration Assistant Schema Migration Assistant converts existing schema created in Teradata Schema Workbench to compatibility. The process requires an external schema file created with Teradata Schema Workbench and above. Preparing Schemas for Migration Migrating a Schema Completing Migration Preparing Schemas for Migration Prepare the schema to minimize issues that could arise during migration. If you have schemas created in Teradata Schema Workbench but do not have a Teradata Schema Workbench installation, go to Migrating a Schema on page 148. For instructions on how to access the Teradata Schema Workbench User Guide for 13.10, see Additional Information on page 5. Note: Ensure you are using the latest version of Teradata Schema Workbench before beginning the procedure. To prepare a schema for migration 1 In Teradata Schema Workbench 13.10, Open a schema to prepare for migration to Teradata Schema Workbench and above. 2 Remove any instances of the following from the schema: Cycles A cycle is a circular reference wherein a join path from one table refers to a table, which through a series of subsequent join references, returns to the original table. For example, Table A refers to Table B, Table B refers to Table C, and Table C refers to Table A. The Schema Migration Assistant does not migrate tables with cycles, because they cause invalid star or snowflake schema. Multiple hierarchies in the same dimension that use different leaf members tables This means all hierarchies in the dimension must join the fact table from the same dimension table. The lowest level in a hierarchy must join to the fact table. 3 Update dimension names (schema and cube-scoped) so no two dimension names match. Teradata Schema Workbench User Guide, Release

148 Appendix I: Using the Schema Migration Assistant Migrating a Schema The automatic naming format is originalname_cubename. For example, a measure Store Sales in cube OMart4 would rename to Store Sales_ OMart4. 4 Update all measure names so that no two measure names in the schema are the same. 5 Update calculated members and calculated measures referring to renamed dimensions or measures. 6 Validate the schema. For instructions, see Schema Validation on page Save the schema as an external file. For instructions, see Save a Schema to the File System on page Complete instructions in Migrating a Schema on page 148. Migrating a Schema The following procedure describes how to use Schema Migration Assistant to format an existing Teradata Schema Workbench created schema for compatibility with Teradata Schema Workbench and above. Note: For a smoother migration process, follow the instructions in Preparing Schemas for Migration on page 147 before performing this procedure. To migrate a schema 1 Start Schema Migration Assistant. To open Schema Migration Assistant from Start, All Programs: Teradata Client >Teradata Schema Workbench->Schema Migration Assistant 2 Click Browse for the Schema file, and select a schema file for migration. The Schema file and Translation log file fields automatically load to the same directory as the source. By default, Schema Migration Assistant renames the target file for conversion to be the same as the original, appending Teradata Schema Workbench User Guide, Release 14.10

149 Appendix I: Using the Schema Migration Assistant Completing Migration 3 Click Start Migration. The log window displays: High level information Elements and formulas renamed to avoid conflict Any errors or warnings for unsupported elements (cycles, degenerate dimensions, multiple hierarchies in the same dimension using different leaf member tables). Note: Schema Migration Assistant automatically renames any duplicates among the elements. 4 When migration completes, review the log window and click OK. Note: Schema Migration Assistant only saves new schema if translation is successful. Schema Migration Assistant saves the log file whether the translation is successful or not. The log contains translation details, any element renaming, errors, and warnings. 5 Check the log file for elements automatically renamed during the migration process. If you find automatically named elements, modify them in Teradata Schema Workbench for more meaningful names. 6 Finish the instructions in Completing Migration on page 149. Completing Migration After the schema migration file is complete and you modify any Schema Migration Assistant named elements, finish the migration process in Teradata Schema Workbench For installation instructions, see the Teradata Business Intelligence Optimizer Release Definition. To complete migration in Teradata Workbench Open Teradata Schema Workbench 14.10, and connect to Teradata Database. 2 Open the translated schema file. Note: If you open the schema file or double-click a BIML file to open Teradata Schema Workbench before connecting to the Teradata Database server, certain portions of the BIDV will not update correctly, resulting in validation errors. If this occurs, close the schema file, reconnect to the Teradata Database, and reopen the schema file. 3 Update schema security role access to cubes, dimensions, hierarchies, and levels. For instructions, see Chapter 9. Note: For security, Schema Migration Assistant only migrates cube grants (if specified). You must recreate any additional security roles. 4 Validate the schema. For instructions, see Schema Validation on page Publish the schema. For instructions, see Publish a Schema to the Database on page 85. Teradata Schema Workbench User Guide, Release

150 Appendix I: Using the Schema Migration Assistant Completing Migration 6 Test the schema cubes in MS Excel or other OLAP tool. 150 Teradata Schema Workbench User Guide, Release 14.10

151 APPENDIX J Using the Pushdown System The purpose of this document is to provide a guide for using the Pushdown system in Teradata OLAP Connector. The Pushdown system is an evaluation method that allows the entire dataset returned by an MDX query to be evaluated all at once, instead of the traditional Cell-by-Cell (Context) evaluation. This document describes the functions that can be evaluated using Pushdown and their corresponding restrictions. It also describes the necessary conditions under which the Pushdown system is utilized. All MDX examples in this document use entities from the TaaDemo1400. The following prerequisites are required for using this document: General knowledge of MDX expressions Pushdown Eligibility Overview This section provides the list of Functions, Methods, and Operators eligible for Pushdown when used as the MDX expressions for a Calculated Measure, as well as the general structure a calculated measure must have in order to be eligible for Pushdown. The Functions, Methods, and Operators listed in this section will fall under two categories: those that are eligible for Pushdown on their own, and those that are only eligible for Pushdown when found under another function eligible for Pushdown. Currently all of the operators eligible for Pushdown fall under the former category, and all of the methods eligible for Pushdown fall under the latter category. For a calculated measure expression to be eligible for Pushdown, it must contain only the Functions, Methods, and Operators listed in this chapter. Please see General Calculated Measure Structure on page 153 for more information on the general structure a calculated measure must have to be eligible for Pushdown. Functions and Operators Eligible for Pushdown on Their Own The functions and operators listed in this section are eligible for Pushdown and can be the calculated measure expression's outermost function, as they return values. These functions include: Teradata Schema Workbench User Guide, Release

152 Appendix J: Using the Pushdown System Pushdown Eligibility The following Arithmetic operations: +, -, *, /, abs The following Comparison operations: >, <, =, >=, <= The following Simple Aggregate functions: SUM, AVG, MAX, MIN, COUNT,DISTINCTCOUNT IIF Functions and Methods Eligible for Pushdown When Specified as a Parameter to Other Functions and Methods Eligible for Pushdown The functions and methods listed in this section are also eligible for Pushdown; however, since these functions and methods do not return Values, they are only eligible for Pushdown when found as parameters of other functions eligible for Pushdown. The functions and methods eligible for Pushdown only when specified as parameters to other functions eligible for Pushdown include: Descendants Filter PeriodsToDate YTD QTD MTD WTD ParallelPeriod OpeningPeriod ClosingPeriod CurrentMember PrevMember Level Functions and Methods Eligible for Pushdown When Specified as Parameters to Specific Functions Eligible for Pushdown The functions below are eligible for Pushdown only when specified as a parameter to a Simple Aggregate listed in Functions and Operators Eligible for Pushdown on Their Own on page 151: CrossJoin Simple aggregates have alternate forms where they take one parameter, the set expression. If the set expression is a function that returns a set (for example, Filter/ Descendants), then these simple aggregates must be cross-joined with a measure for the simple aggregate to evaluate properly. Count in particular has a form that takes a set and the flag EXCLUDEEMPTY. In this case, its set expression must provide some measure to count against to determine whether each set tuple has a value or not. 152 Teradata Schema Workbench User Guide, Release 14.10

153 Appendix J: Using the Pushdown System Schema Configuration General Calculated Measure Structure In order for a calculated measure expression to be eligible for Pushdown, its outermost expression must be a Function or Operator listed in Functions and Operators Eligible for Pushdown on Their Own on page 151. For example, Figure 39 shows a calculated measure whose outermost expression (SUM) is eligible for Pushdown. Figure 39: A calculated measure eligible for pushdown Limitations What this means for calculated measures whose outermost expression is a tuple, is that the tuple must be converted into a SUM function. For example: Ineligible for Pushdown (ClosingPeriod([Month], [Time].CurrentMember), [Measures].[Units]) Eligible for Pushdown SUM(ClosingPeriod([Month], [Time].CurrentMember), [Measures].[Units]) Max SQL Size If the SQL that will be produced for an MDX query through pushdown is determined by the system to be greater than 1MB, the MDX query automatically becomes ineligible for pushdown. The size of the SQL that will be produced for an MDX query will depend on what members are being selected in the MDX query as well as the functions that are used in the calculated measure expression as well as whether.currentmember is used or not. A complex calculated measure expression will yield a larger SQL size, and using CURRENTMEMBER can lead to a large SQL expression being produced when there are a lot of contexts (and/or results for each context). Schema Configuration Overview This section provides the additional configuration required in order for Pushdown to function properly. Teradata Schema Workbench User Guide, Release