Bi Query

BI/Query
User’s Guide
8363-0M
8363-0M
Hummingbird Communications Ltd.
1 Sparks Avenue, North York, Ontario, Canada M2H 2W1
Telephone: +1-416-496-2200
Fax: +1-416-496-2207
BBS: +1-416-496-9233
E-mail: getinfo@hummingbird.com
Web Site: www.hummingbird.com
FTP: ftp.hummingbird.com
RESTRICTED RIGHTS LEGEND. Unpublished rights reserved under the copyright laws of the United States. The SOFTWARE
is provided with restricted rights. Use, duplications, or disclosure by the U.S. Government is subject to restrictions as set forth in
subparagraph (c) (1)(ii) of The Rights in Technical Data and Computer Software clause at DFARS 252.227-7013, subparagraph (c)(1)
and (2) (a) (15) of the Commercial Computer Software-Restricted Rights clause at 48 CFR 52.227-19, as applicable, similar clauses in
the FAR and NASA FAR Supplement, any successor or similar regulation.
Copyright © 1998 Hummingbird Communications Ltd. All rights reserved. BI/Analyze, BI/Analyze CubeCreator, BI/Broker,
BI/Broker Admin, BI/Broker Repository, BI/Query, BI/Query Admin, BI/Query Reports, BI/Query Reports Chart Editor,
BI/Query Update, BI/Query User, BI/Web, and BI/Web Personal Portfolio are trademarks of Hummingbird Communications Ltd.
and/or its subsidiaries.
BI/Query Reports is made with MapInfo MapX, a product of MapInfo Corporation, Troy, New York USA, © 1997. All rights
reserved.
DB2 is a trademark, and OS/2 is a registered trademark, of International Business Machines Corporation.
Microsoft, Microsoft Excel, Microsoft Word, Visual Basic, Windows, and Windows 95 are registered trademarks, and Windows NT is a
trademark, of Microsoft Corporation.
Ingres/Net is a trademark of Computer Associates International, Inc.
Java is a trademark of Sun Microsystems, Inc.
Oracle and SQL*Net are registered trademarks of Oracle Corporation.
Photo clipart copyright © 1996 PhotoDisc, Inc.
SequeLink is a trademark of Intersolv, Inc.
Sybase is a registered trademark of Sybase, Inc.
Teradata is a registered trademark, and WinCLI is a trademark, of NCR Corporation.
All other copyrights, trademarks, and tradenames are the property of their respective owners.
DISCLAIMER. Hummingbird software and documentation has been tested and reviewed. Nevertheless, Hummingbird
Communications Ltd. makes no warranty or representation, either express or implied, with respect to the software and documentation
included. In no event will Hummingbird Communications Ltd. be liable for direct, indirect, special, incidental, or consequential
damages resulting from any defect in the software or documentation included with these products. In particular, Hummingbird
Communications Ltd. shall have no liability for any programs or data used with these products, including the cost of recovering such
programs or data.
Information in this document is subject to change without notice and does not represent a commitment on the part of Hummingbird
Communications Ltd. Not all copyrights pertain to all products.
This guide contains proprietary information that is protected by copyright. All rights are reserved. This guide may not be photocopied,
reproduced, or translated into another language, in whole or in part, without prior written consent from Hummingbird.
This edition published September 1998.
Printed in Canada.
Contents
Section 1: Before You Begin Working in Design Mode 19
Data Objects Represent Tables in the
Welcome to BI/Query 5 Database 20
About This Guide 5 Relationships Tie Information Together 21
Illustrations 7 Buttons Automate Activities 23
Conventions 7 Ornaments Enhance the Data Model 23
What to Look for Online 8 Types of Data Models 24
Online Help 8 The Split Data Model 25
Tool Tips 8 The Combined Data Model 27
Electronic Documents 8 Building Queries 28
Technical Support 9 Data Values Restrict Results 29
In North America 9 Prompts Focus Your Queries 30
Outside North America 9 Variables Automate Operations 31
Contacting Technical Support 10 Turning Data into Reports 31
Troubleshooting Problems using the Securing and Distributing Information 31
Trace Utility 10 Publishing Data Models and Queries 31
Professional Services 11 Securing Data Models and Queries 32
Contacting Professional Services 11 Scheduling Queries 33
The Business Intelligence Product Line 11
Hummingbird BI/Broker 12 Getting Started 37
Hummingbird BI/Web 12 Installing BI/Query 37
Hummingbird BI/Query 12 Starting BI/Query 37
Hummingbird BI/Analyze 13 Retrieving a Published Data Model 39

Opening a Split Data Model 40
Contacting Hummingbird Sales 14
Loading from the Database 41
Basic Concepts 17 Finding the Administrator Layer in a Split
The Data Model Represents the Data 18 Data Model 42
Design Windows Provide a Design
Environment 18
Contents i
Connecting to the DBMS 47 Creating Lookup Tables 77
Connection Files 48 Adding Indices 78
Creating Connection Files 48 Denormalizing Tables 78
Testing Connection Files 51 Computing Common Summarizations 79
Distributing Connection Files 52 Reorganizing Table Structures 79
Logon Scripts in TCP/IP Connection Providing Metadata 81
Files 52 Delivering the Right Data Model 82
How the Scripts Work 53 Controlled Data Model 82
Examples of Logon Scripts 54 Logical Data Model 82
Understanding Prompt/Reply Pairs 55
Modular Data Model 83
Editing Scripts 57
EIS Data Model 85
Editing TCP/IP Settings 58
Ad Hoc Data Model 88
Distributing TCP/IP Settings 60
Ad Hoc/Report Data Model 89
Setting Connections 61
Multiple Data Models 90
Default Connections 61
Automatic Connections 62 Creating a Data Model 93
To Multiple Databases 64 Opening a New Data Model 93
Connecting 68 Creating Design Windows 95
Using a Default Connection 69 Loading Tables from the Database 96
Using a Specific Connection 69 Simplifying Display Names 98

Organizing Attributes 99
Creating Relationships between
Section 2: Deploying BI/Query Tables 100
Embedded Relationships 101
Before You Begin 75 Actual Relationships 101
Assessing Your Users 75
Renaming Objects and Attributes 102
Information Needs 75
Data Objects and Relationships 103
Computer Skills 76
Attributes 104
Preparing the Database 77
ii Contents
Creating Join Conditions 104 Performing Calculations with Queries 146
That Include a Prompt or Variable 106 Scheduling Queries 146
Using Tables More Than Once 108 Saving Queries 147
Specifying Correlation Names 109 Creating Relationships between Data
Objects 147
Merging Data Objects 111
Performing Special Operations 148
Editing Join Conditions 113
Connecting to the DBMS 148
Creating Tables in the Database 114
Making Changes to the Database 149
From Query Results 115
From Data Objects 116
Balancing the Load on the Network 153
Assigning Permissions 121 Connecting to the DBMS 153
Assigning Default Settings 122 Optimizing Connection Performance 153
Setting Data Model Passwords 123 Setting Automatic Connections 155
Checking the Design 124 Running Efficient Queries 156
Saving the Data Model 125 Using Data Values Files 156
As a Split Data Model 126 Restricting Queries to Specific Information 157
As a Combined Data Model 127 Submitting Queries to a Table in the
Database 157
Controlling User Access 131
Modifying the SQL 158
Controlling What Users Can See 131
Estimating Database Resources 158
Within the Data Model 131
Ranking Data Objects for Oracle Databases 158
Using the BI/Broker Repository 137
Setting Query Limits 160
Controlling What Users Can Do 142
Using BI/Query Permissions 160
Assigning System Permissions 142
Using BI/Query Preferences 161
Assigning BI/Query Permissions 142
Scheduling Queries 161
Setting BI/Query Preferences 144
Managing Scheduled Jobs 162
Making Changes to a Data Model 145
Displaying Scheduled Jobs 162
Modifying Queries 145
Setting Display Options 163
Managing the Network Load 146
Managing Jobs 164
Contents iii
Creating an Effective Design 167 From a Query 191
Basic Principles 167 From Results Files 196
Decide What’s Appropriate 167 Creating Ornaments 198
Be Consistent 168 Assigning Icons to Data Objects 200
Use Restraint 169 Specifying Colors 201
Use Contrast 170 For Windows 202
Provide Unity 170 For Objects and Design Windows 202
Establishing a Layout 171 New Colors 204
Layout Grid 171 Customizing Online Help 205
Masthead and Logo 172 Adding Information 205
Lines 173 Creating Help Files 206
Adding Emphasis 173 Creating Additional Help 206
Type 173
Distributing a Data Model 211
White Space 174
Split Data Model 211
Boxes 175
Storing Each Layer in Separate Folders 212
Graphics 176
Establishing the Path to the Administrator-
Color 176 layer File 213
Combined Data Model 214
Adding Value to a Data Model 179
Providing Metadata 179
How the Data Model Is Stored 216
How Metadata Is Displayed 180
Setting Up to Publish 216
Adding Metadata to the Database 181
Using a File Server 219
Understanding Metadata Queries 183
Using Diskettes 220
Using Template Queries to Specify the
Metadata Source 186 Using Mail 220
Loading Metadata 188 Using the Database 221
Creating Attribute Descriptions 190 Minimizing File Size 222
Directly in BI/Query 191 Understanding BI/Query Database Tables 223
iv Contents
Distributing the Initial Version 226 Using Data Values, Prompts, and Variables 257
Distributing a Revised Version 226 Data Values Files 257
Naming and Storing Data Values Files 258
Maintaining a Data Model 233
Creating Data Values Results Files 260
Split Data Models 233
Creating Data Values Query Files 264
Combined Data Models 234
Using Data Values Files to Alias Data 266
Refreshing the Data Model 235
Prompts 269
Data Objects 235
Naming and Storing Prompts 270
Queries 238
Creating Single Prompts 270
Group Prompts 271
Section 3: Getting the Results You Conditional Prompts 274
Want Importing Prompts 279
Variables 280
Specifying Data Formats 245 Creating Variables 281
For Typing Data 245
Importing Variables from a File 286
Default Format 246
Matching Attribute Formatting 246 Building Queries 291
Numbers 247 The Basics 291
Dates 247 Qualifying Queries 293
Invalid Entries 248 Using the Qualification Tree 293
For Displaying Data 248 Using Data Values 296
Formatting Numbers 249 Using a Prompt 298
Formatting Dates 250 Applying Multiple Qualifications 300
Inserting and Deleting Characters 250 Combining Qualifications 301
Substituting Values 251 Restricting Qualifications with an

Operator 302
Converting Two-digit Years 252
Making Comparisons 303
Matching Character Strings 304
Contents v
Matching Items in a List 305 Without a Correlation 352
Finding a Range of Values 306
Finding Unknown Values 306
Naming and Prioritizing a Job 357
Applying Your Own Operator 307
Specifying When to Run a Job 358
Saving Standard Queries 307
Scheduling Once-only Jobs 358
Saving Results 309
Scheduling Recurring Jobs 359
Publishing Queries 310
Scheduling Jobs Based on Events 362
Retrieving Queries 312
Advanced Scheduling 364
Building Advanced Queries 315 Specifying Job Actions 365
Qualifying One Attribute with Actions for Running Queries and
Another 315 Refreshing Reports 366
Using a Subquery 316 Distribution and Notification Actions 367
Reversing Qualifications 319 Run Command on Server Action 371
Qualifying a Query with a Variable 320 Trigger Event Action 371
Modifying the SQL 321 Notifying Yourself 373
Modifying a Query for Selected
Results 323 Working with Results 377
Creating Dynamic Relationships 324 Sorting Results 377
Using Queries to Perform Before You Submit a Query 378

Calculations 326 After Results Are Returned 379
Applying Functions to Attributes 327 Narrowing the Range of Results 380
Creating Attributes That Perform Reordering Columns of Results 382
Calculations 334
Before You Submit a Query 382
Working with Super Queries 337
After Results Are Returned 382
Creating Super Queries 337
Combining Results 383
Editing Super Queries 340
Appending One Results Set to Another 384
Building Queries with a Circular Path 347
Joining One Column to Another 386
With a Correlation 348
Performing Calculations 390
vi Contents
Updating Records in the Database 393 Using Ornaments 426
Setting Up BI/Query 393 Updating the Database 426
Setting Key Fields 393 Using OLE 426
Assigning the Update Database Permission 394 Exporting Information 431
Granting Database Permissions 395 Queries 431
Adding, Modifying, and Deleting Results 432
Records 395 Preparing Results for Export 435
Adding Records from Another Application 397 Exporting to Excel using DDE 438
Applying Updates to the Database 400 Using Mail 445
Correcting Errors 400
Index 447
Section 4: BI/Query and Other

Applications
Automating Tasks 405

Using Buttons 405
Creating Buttons 406
Using SQL Scripts 414
Using OLE Automation 416
Using Application Scripts with BI/Query 416
Using Visual Basic to Control BI/Query
Objects 418
Sample Code 419
Visual Basic Reference Materials 422
Importing and Exporting Information 425

Importing Information 425
Using the Clipboard 425
Contents vii
Before You Begin
Welcome to BI/Query 5
Basic Concepts 17
Getting Started 37

Welcome to BI/Query
About This Guide 5

Illustrations 7
Conventions 7
What to Look for Online 8
Online Help 8
Tool Tips 8
Electronic Documents 8
Technical Support 9
In North America 9
Outside North America 9
Contacting Technical Support 10
Troubleshooting Problems using the
Trace Utility 10
Professional Services 11
Contacting Professional Services 11
The Business Intelligence Product Line 11
Hummingbird BI/Broker 12
Hummingbird BI/Web 12
Hummingbird BI/Query 12
Hummingbird BI/Analyze 13
Contacting Hummingbird Sales 14
Welcome to BI/Query
Hummingbird BI/Query is a query and reporting tool that provides a
comprehensive solution for accessing, analyzing, and presenting data in
a client/server environment. Its graphical approach and intuitive
interface gives users flexible access to the data while maintaining
organizational control. When it’s installed with Hummingbird BI/Broker
Repository, it also provides easy, secure exchange of corporate data.
For administrators, BI/Query provides the flexibility to tailor

information access to the exact needs of business users. The
administrator makes business-critical information available while
maintaining data security, quality, and integrity. Powerful and versatile,
BI/Query makes short work of deploying and maintaining controlled
information access.
For business users, BI/Query provides an easy-to-use, visual way to

query databases, integrate data with other applications, and generate the
reports you need to turn raw data into useful information. Its unique
approach to delivering business information means that decision makers
can better understand their data without having to understand the
database. It makes for better decisions — and better business.
About This Guide

This guide is written for administrators and users of the BI/Query
product line. It describes how to deploy BI/Query and use it to its full
benefit. Whether you’re an administrator or a user, a new or
experienced user, you can use the “roadmap” on Page 6 to find the
information you need.
Certain information applies to both administrators and users because

you perform some of the same tasks. For example, administrators build
queries and reports for users. And with the appropriate permissions,
users can make changes to the data model.
START HERE
Welcome to BI/Query
Page 5
Getting Started
Page 37
NEW USERS ALL USERS ADMINISTRATORS

Basic Concepts Adding Value to a Data Model Before You Begin
Page 17 Page 179 Page 75
Connecting to the DBMS Specifying Data Formats Creating a Data Model
Page 47 Page 245 Page 93
Using Data Values, Prompts, and Controlling User Access
Variables Page 131
Page 257
Building Queries Balancing the Load on the Network
Page 291 Page 153
Building Advanced Queries Creating an Effective Design
Page 315 Page 167
Scheduling Queries Adding Value to a Data Model
Page 357 Page 179
Working with Results Distributing a Data Model
Page 377 Page 211
Updating Records in the Database Maintaining a Data Model

Page 393 Page 233
Automating Tasks
Page 405
Importing and Exporting
Information
Page 425
6 Welcome to BI/Query
This guide applies to BI/Query Admin, BI/Query User, and BI/Query
Update for Windows 95 and Windows NT. It’s organized into four
sections. The table of contents at the beginning lists the sections, the
chapters in them, and the main sections in each chapter. A table of
contents at the beginning of each chapter lists its contents in detail.
The guide provides conceptual and background information on the

features and functionality of BI/Query. It gives examples of how to use
it and apply it to the work you do.
Illustrations
The illustrations in this guide are based on data from a fictitious data
model. Depending on the appearance of your own data model and the
DBMS and connection types you use, some illustrations may look
somewhat different than what you see on your monitor. Nevertheless,
their functionality is the same.
Conventions
This guide uses certain terminology and conventions to help you use it
effectively.
This Is Used for This
folder Directory, subdirectory, and folder.
italics New terms, file names, and information that you

type in BI/Query.
Providing useful hints and suggestions.
What to Look for Online
Everything you need to work with BI/Query is available online — in
the form of online Help, tool tips, and electronic documents.
Online Help
You can find Online Help provides step-by-step instructions that answer the
out what’s new question “How do I…” Context-sensitive Help gives information on
in BI/Query
online. Choose the spot. And a full-text search facility allows you to find exactly what
Help>Contents, then click you’re looking for. Online Help is quick and easy to use. Best of all,
What’s New in BI/Query. you don’t have to leave BI/Query to find the answers you need.
You can access online Help in a number of ways.
To Do This Do This
Display contents Choose Help>Contents.
Locate specific information Choose Help>Search for Help On,

then specify what you’re looking for.
Get Help about using Help Choose Help>How to use Help.
Get Help for a dialog box Click the Help button in the dialog
box.
Tool Tips
Tool tips allow you to find information about menu commands and
toolbars. Position the cursor over the item to display a brief description
on the status bar.
Electronic Documents
All of our user’s guides are available online as Adobe Acrobat Portable
Document Format (PDF) files. If you installed the documentation
when you installed BI/Query, it’s accessible from the Start menu. It’s
also available on the installation CD.
To open a PDF file, you need Acrobat Reader. It’s provided on the
installation CD and is also available at Adobe’s World Wide Web site
(http://www.adobe.com). Using Acrobat 3.0 or later allows you to
take advantage of its Find facility.
Technical Support
The administrator should be your first contact for technical support.
The administrator, or the connectivity person in your organization, is
most familiar with your particular configuration. If the problem isn’t
resolved, the next step depends on where this product was purchased.
In North America
If you purchased this product within North America (United States and
Canada), you can obtain technical support from Hummingbird’s
Business Intelligence Division. Technical support is available Monday
to Friday between 8:00 a.m. and 7:00 p.m. Eastern time. It’s also
available online.
Outside North America

If you purchased this product outside North America, contact your
Hummingbird distributor or reseller, who can provide technical
support in your language and time zone and who is more familiar with
your particular environment. You can also reach Hummingbird online.
Contacting Technical Support
You can report problems and suggest enhancements in our software by
contacting Technical Support at:
Voice +1-613-548-4355
Fax +1-613-548-7616
E-mail hbi-support@kingston.hummingbird.com
Web www.hummingbird.com
FTP ftp.hummingbird.com
Before we can investigate your problem, we need certain information

from you. This information is outlined on our Web site on the
Technical Support page. You can use the form provided, supply the
information by phone or fax, or use the form provided in the online
Help under Technical Support.
Troubleshooting Problems using the Trace Utility

A trace utility is installed with the software to help us troubleshoot
problems that our customers are having. The trace utility simplifies
problem-solving by monitoring the performance of our products.
It logs information in files that you can send to our Technical
Support staff. If you’re having a problem with the software, Technical
Support will ask you to run the trace utility and send them the
resulting log file.
To run the trace utility

1 Double-click the trace.exe file in Program Files\Hummingbird
BI\Utility.
2 In the Trace Utility, make sure that tracing is enabled. (If it isn’t,
choose File>Tracing Enabled.)
Professional Services
Hummingbird supports its products by offering consulting and training
services worldwide. Working alongside your own technical and non-
technical staff, our Professional Services group can help you identify
areas where improved information management can enhance your
business performance. And we can supply the expertise you need to
bring these opportunities to fruition.
Hummingbird offers standard training to help users and administrators

become confident using our products. We also design courses that are
tailored to meet your organization’s specific needs. These courses can
take place at your workplace or at our own training centers.
Contacting Professional Services

To register, or for more information, pricing, and detailed course
outlines, contact Hummingbird Professional Services at:
Voice +1-613-548-4355 ext. 1700
Fax +1-613-548-7801
E-mail proservices@hummingbird.com
The Business Intelligence Product Line

Managed business intelligence from Hummingbird satisfies a spectrum of
corporate needs. It allows users to better understand their business by
asking questions about information in the corporate database, analyze
the answers for more effective decision-making, present that
information in reports, and distribute it in a variety of ways, including
over the World Wide Web.
Hummingbird BI/Broker
Hummingbird BI/Broker is the cornerstone of Hummingbird’s managed
business intelligence solution. It’s an application server that provides
shared services and a common repository of information that users can
access using Hummingbird BI desktop applications or their Web
browsers. BI/Broker manages security, scheduling, and distribution
services in a centrally managed client/server environment.
BI/Broker includes the following key components, which are fully

integrated with Hummingbird BI desktop applications:
BI/Broker Admin Allows the administrator to manage the

BI/Broker configuration.
BI/Broker Provides the central storehouse of data

Repository models, queries, results sets, and reports.
User and Group Allows the administrator to provide user,

Manager group, and role-based security.
Scheduler Schedules queries and reports and distributes

the results.
Hummingbird BI/Web
Hummingbird BI/Web uses the services of BI/Broker to provide query
and reporting capability to Web users without requiring the installation
of any desktop software.
Hummingbird BI/Query
Hummingbird BI/Query is a query and reporting tool that provides a
comprehensive solution for accessing, analyzing, and presenting data in
a client/server environment. With its graphical approach and intuitive
interface, BI/Query gives users flexible access to the data while
maintaining organizational control.
The BI/Query product line consists of four separate applications.
BI/Query Admin An all-in-one solution for the administrator.

In addition to creating and customizing data
models, the administrator can submit queries,
produce reports, and update the database.
BI/Query User The user’s query application. It provides an

easy-to-use, visual way of querying
corporate databases and producing reports.
BI/Query Update An extended version of BI/Query User. It

allows users with special access privileges to
add, modify, and delete information in
corporate databases.
BI/Query Reports A reporting tool installed with BI/Query. It

allows administrators and users to present the
data obtained in BI/Query in a variety of
presentation styles — tables, crosstabs, charts,
and maps.
Hummingbird BI/Analyze
Hummingbird BI/Analyze is an Online Analytical Processing (OLAP)
tool that allows users to extract summary information from corporate
databases and analyze it from various business perspectives.
BI/Analyze creates reports with tables, charts, and graphs from multi-
dimensional data sources called HyperCubes. Hypercubes are
constructed using BI/Analyze CubeCreator, an integrated cube-building
engine. They allow users to drill up and down through successive layers
of detail to discover trends, patterns, and relationships in their business.
Contacting Hummingbird Sales
Regional sales offices are located worldwide. For a current list of
contacts and phone numbers, contact Hummingbird Sales at:
Voice +1-416-496-2200
Fax +1-416-496-2207
E-mail getinfo@hummingbird.com
Basic Concepts
The Data Model Represents the Data 18 Securing Data Models and Queries 32
Design Windows Provide a Design Environment 18 Scheduling Queries 33
Working in Design Mode 19
Data Objects Represent Tables in the Database 20
Relationships Tie Information Together 21
Actual and Embedded Relationships 22
Buttons Automate Activities 23
Ornaments Enhance the Data Model 23
Types of Data Models 24
The Split Data Model 25
Administrator Layer 25
User Layer 26
The Combined Data Model 27
Building Queries 28
Data Values Restrict Results 29
Prompts Focus Your Queries 30
Variables Automate Operations 31
Turning Data into Reports 31
Securing and Distributing Information 31
Publishing Data Models and Queries 31
Saving and Publishing 32
Opening and Retrieving 32
Basic Concepts
In information-driven organizations, people need to turn corporate
data into information they can use to make informed business decisions.
At the same time, Information Technology (IT) professionals are
concerned with corporate security and standards. And organizations
want to make data accessible without compromising IT goals.
Sometimes, that means providing people with predetermined access; at
other times, it means allowing people more freedom. BI/Query gives
organizations the flexibility to provide the right mix of user access with
IT support for the perfect corporate fit.
IT staff customize the data access environment to meet people’s business

needs. They determine what database information people can access as
well as which facilities they can use. They can deliver customized data
access or let people build their own tailored information centers without
compromising database security or integrity.
Whatever the mix, BI/Query’s visual interface provides people with a

view of the corporate database that’s easy to understand. Insulated from
the complexities of SQL, people point and click their way through
queries and reports with ease.
Basic Concepts 17
The Data Model Represents the Data
BI/Query makes data access easy because it allows organizations to
depict their databases in a way that makes sense. Its data model, a
graphical representation of data in the database, is the user’s gateway to
corporate information. This visual approach to delivering business
information means decision makers can understand the data without
having to understand the database.
Data objects in this data model represent a database containing information on regional
offices, staff, retailers, sales, and products.
The administrator creates the data model, tailoring it to the exact needs
of the user community — getting the right data to the right people and
providing support for novices and “power users” alike.
Design Windows Provide a Design Environment

Design windows are the workspace in which the administrator designs a
data model and users formulate queries. Design windows contain the
data objects that represent tables in the database and the relationships
that tie them together. They can also provide buttons that automate
activities and ornaments that enhance the design. If the administrator
provides them with the appropriate permissions, users can create their
own design windows and add their own buttons and ornaments.
Design windows provide a means of organizing information so that

users can quickly and easily understand what’s available to them.
18 Basic Concepts
Windows can be linked to tie related information together; buttons
provide a means of navigating from one window to another.
Ornaments
Executive buttons
Data objects Relationships
Working in Design Mode

BI/Query differentiates between activities that access the database (for An application
example, to submit queries, update the database, and submit SQL toolbar allows you
to carry out com-
scripts) and activities that modify the design and layout (changing the
mon activities
grid setting and creating buttons and ornaments). Activities that modify such as switching in and out
the data model are performed in Design Mode. Activities that access the of Design Mode, connecting
database are not. When the administrator opens a new data model, to and disconnecting from the
DBMS, and submitting and
BI/Query is in Design Mode. canceling queries.
The tools on the drawing toolbar allow you to create objects and assign
properties to them (color, line thickness, and so on). The layout palette
Basic Concepts 19
provides tools for resizing and aligning objects. The illustration below
shows a design window in Design Mode.
Layout palette
Drawing toolbar Application toolbar
Data Objects Represent Tables in the Database

Data objects are the rectangular or graphical icons in a data model that
represent the tables of information stored in the database. They have
additional information, or attributes, associated with them. Attributes
represent columns in the database tables; they allow users to specify the
information they want to retrieve from the database. Users select the
attributes they want, and they can apply conditions that restrict the data
they retrieve.
20 Basic Concepts
Data objects display attributes in an attribute window
Attributes specify the information to Conditions restrict results

be retrieved from the database
While the administrator can provide data objects in any design

window, a query can include data objects from only one window.
Relationships Tie Information Together

The lines connecting the data objects in the data model represent the A data model can
relationships between the objects. Relationships hold the join conditions display relation-
ship icons, rela-
that associate two data objects containing related data; they allow users tionship names, or
to formulate queries using more than one data object. By specifying both. This can make it easier
attributes or conditions associated with two data objects, users activate to create join conditions,
build queries, and so on. (But
the relationship to retrieve related information.
it may make the data model
look “busy.”) Choose Edit>
Preferences, then set the pref-
erences you want.
The place relationship (represented by the diamond-shaped icon) allows users to

retrieve information about retailers and the sales they’ve placed.
Relationships are named to illustrate how the information in one data

object can be combined with information in another. Typically a brief
Basic Concepts 21
verb phrase describes how two data objects are related so that the first
data object, the relationship, and the second data object can be read as a
sentence (such as retailers, place, sales).
Data objects can have more than one relationship, allowing users to
retrieve different results using the same data objects. The example
below shows that users can use the works in relationship to find
information about an employee who works in a particular department;
they can also use the managed by relationship to find information about
an employee who manages a particular department.
Actual and Embedded Relationships

Data models can contain actual and embedded relationships. Actual
relationships have a shadow behind them; embedded relationships don’t.
Double-click to
display attributes
Both types of relationships relate two data objects, but actual

relationships, like data objects, represent tables in the database and have
attributes associated with them. Actual relationships can connect two or
more data objects, while embedded relationships can connect no more
than two. Users can ignore the distinction between actual and embedded
relationships when formulating most queries. When users want to access
information associated with an actual relationship, they specify attributes
and conditions for it in the same way as for a data object.
22 Basic Concepts
Buttons Automate Activities
Buttons (sometimes called executive buttons) automate frequent activities.
Buttons are versatile — they allow users to automatically connect to the
database, submit multiple queries, combine the results, and generate a
report or HyperCube — all with a single click of the mouse. Buttons
can also display design windows, save results to files, export results to
other applications, and run Visual Basic and Excel applications.
Ornaments Enhance the Data Model

Ornaments are text and graphical objects such as titles, logos, borders,
backgrounds, and notes that provide additional information, act as
visual organizers, or simply enhance the appearance of design windows.
Basic Concepts 23
Types of Data Models
The administrator creates a data model that includes data objects and
relationships, join conditions, and permissions. It may also include
“value-added” items such as buttons, queries, prompts, variables, data
values query and results files, computed attributes, ornaments, attribute
formatting, and multiple design windows. If the administrator assigns
them the appropriate permissions, users can also add those items.
Data models are designed to be as flexible as possible. Sites that allow

users to add their own customizations to a data model (including
changes to their preferences and other default settings), can create a split
data model, which stores the administrator’s data model separately from
the customizations added by users. It allows users to retain their
customizations when a new version of the data model is distributed. A
combined data model stores the data model in one file and is designed for
sites where users aren’t permitted to make changes.
24 Basic Concepts
The Split Data Model
A split data model is stored as two layers — an administrator layer and a
user layer. Because changes made by the administrator don’t typically
affect those made by the user, this is the type of data model
recommended for most sites.
Administrator Layer
The administrator layer of a split data model is the data model as created
by the administrator. It consists of a file with the extension .gqa, a
Queries folder, and a DataVals folder. The Queries folder stores
queries, prompts, and variables. The DataVals folder stores data values
query and data values results files.
The administrator-layer file includes the data objects and relationships,

computed attributes, join conditions, permissions, and default
preferences that make up a basic data model plus a set of design
windows, buttons, ornaments, and drawing objects. The administrator
distributes this file, plus the Queries and DataVals folders, to all users.
Administrator Layer
Sales.gqa Queries Data Values

• design windows • query files • data values query files
• data objects • prompts file • data values results files
• relationships • variables
• computed attributes
• buttons
• ornaments (graphics)
• drawing objects
• permissions
• default preferences
Basic Concepts 25
User Layer
The user layer of a split data model consists of a file with the extension
.gqu, a Queries folder, and a DataVals folder. Along with the
administrator layer, the administrator distributes an essentially empty
copy of the user-layer file to all users. The user-layer file contains a few
default settings, such as preferences. It also contains the path to the
administrator layer; when a user opens the user-layer file, the path
allows BI/Query to find the administrator layer. BI/Query then
combines all the elements stored in the user-layer file with the elements
stored in the administrator-layer file.
User Layer
Sales.gqu Queries Data Values

• computed attributes • prompts file • data values results files
• buttons • variables
• drawing objects
• preferences
The first time a user opens a split data model, the user sees the data
model stored in the administrator layer. When the user layer is stored in
a folder separate from the administrator layer, empty Queries and
DataVals folders are created to store user-defined queries, prompts,
variables, and data values files. Any other customizations the user adds
(such as extra buttons, ornaments, and design windows) are saved in the
user-layer file.
26 Basic Concepts
In a split data model, the user layer contains only the elements added by the user; the
administrator layer contains only the elements provided by the administrator. When a
user opens the data model, the administrator and user layers are combined seamlessly.
The next time the user reopens the data model, the user sees the
administrator’s data model as well as all the customizations he or she has
added. The changes made by one user don’t affect those made by other
users. In addition, users can’t make changes to the administrator layer.
The Combined Data Model

In a combined data model, the data model consists of the data model file with
the extension .gql and the Queries and DataVals folders. Each time a
combined data model is revised by the administrator and distributed to
users, any user customizations are overwritten. Combined data models
are designed for organizations that don’t allow users to make any
changes to the data model.
Basic Concepts 27
Combined Data Model
Sales.gql Queries Data Values

• buttons
• drawing objects
• permissions
• preferences
Building Queries
The data model is the starting point for building queries to retrieve
information from the database. You build queries by selecting the
attributes that represent specific information you want to retrieve,
placing restrictions on your query, then sending the query to the
database. The query results are displayed in a separate window.
28 Basic Concepts
You can use more than one object in the data model to build a query.
You can also define all of your specifications in one step, or you can
build a query incrementally by adding specifications query by query
until you retrieve exactly the information you want.
You can specify a range of conditions to restrict the information you

retrieve. For example, when you select attributes, you can also specify
that you want to sort, group, qualify, and/or apply arithmetical
functions to one or more of them.
Apply a function to an attribute
Group or sort results
Qualify with one or more data

values, a prompt, a variable,
another attribute, or a subquery
Data Values Restrict Results

Data values are all the possible values of an attribute. The data values for
the Country attribute, for example, might include the values France,
Germany, Spain, Denmark, and so on.
You can qualify an attribute with one or more data values in order to
retrieve results that correspond only to those values. For example, you
Basic Concepts 29
can retrieve information about retailers located in Canada and USA by
qualifying a query with those countries.
You can type values into a qualification or select them from a list.
Choosing from a list of data values is easier than typing and avoids
potential uncertainty about capitalization and spelling.
Prompts Focus Your Queries

BI/Query provides a facility for incorporating prompts into queries.
Prompts are requests to enter a value into a qualification, requests that
are made when a user submits the query. If a prompt is included in a
query, users can submit that query to retrieve information for a
different value each time. For example, to retrieve the same kind of
information about retailers located in different countries, a query about
retailers prompts for a country each time a user submits the query.
A user can also build a query with multiple prompts, in which the value
entered into one prompt restricts the values available for the next. This
feature allows users to quickly zoom in on increasingly detailed
information when they submit the query.
30 Basic Concepts
Variables Automate Operations
Variables allow users to define an operation in a query that is performed
when the query is submitted. That operation specifies the search
conditions for the query and can contain anything that is valid in an
SQL WHERE clause (attributes, operators, values in the database,
calculations, functions, subqueries, or stored procedures). Variables
determine values in the database while the query is running so users
don’t have to specify them in queries. For example, you can use a
variable to retrieve retailer sales that were placed today, before today,
and so on. The variable determines what today’s date is, and BI/Query
returns the corresponding results.
Turning Data into Reports

Once you’ve gathered the data you want, you often need to present it
in a report. BI/Query Reports provides a flexible reporting environment
that includes tables, crosstabs, charts, and maps to answer every type of
business question. BI/Query Reports is installed with BI/Query. (For
more information about this reporting tool, see the BI/Query Reports
user documentation.)
Securing and Distributing Information

When people create data models and queries that others in the You’ll know that
organization will use, they need efficient ways to secure and distribute you have access to
the repository
them. If your corporate environment includes BI/Broker, you may have when Publish and
access to the BI/Broker Repository, a readily accessible central storehouse Retrieve are available on the
for data models, queries, and reports. File and Query menus.
Publishing Data Models and Queries

Administrators and users with the appropriate permissions can publish
data models and queries to the repository, making it possible for other
Basic Concepts 31
BI/Query users to retrieve them. Published data models and queries
can even be made accessible to people in the organization who don’t
have BI/Query on their desktops. For these people, a view of the
repository is available by opening the BI/Web Personal Portfolio from
their Web browsers.
Saving and Publishing

When you create data models and queries, you have a variety of
options for saving them. You can save them locally (on your computer
or on a server to which your computer is networked), and
administrators can save data models in the database. You can also publish
items to the repository. You must save a data model or query locally
before you can publish it.
Opening and Retrieving

When you want to use an existing data model or query, you have to
know where the version you want is stored. You can open it locally
(from your machine or from a server to which it’s networked) or from
the database. You can also retrieve it from the repository. If your
organization uses the repository to deploy updated versions of data
models and queries, you must retrieve them from the repository to
ensure that you have the current version.
Securing Data Models and Queries

It may not be appropriate for everyone who has access to the repository
to make use of every data model and query published there. The person
who publishes a model or query can determine who else has access to it
by setting security from BI/Query. Working from a hierarchy of user
and group accounts supplied by the administrator, the publisher can
decide who has access to the model or query and what kind of access
they have.
32 Basic Concepts
Scheduling Queries
With the appropriate system permissions, users can schedule queries that
have been published to the repository. They can schedule queries to be
submitted to the database at set intervals or after specific events have
occurred, and they can choose from a variety of methods to deliver the
results to those who need them. If they have the appropriate system
permissions, they can schedule other users’ queries as well as their own.
Basic Concepts 33
Getting Started
Installing BI/Query 37
Starting BI/Query 37
Retrieving a Published Data Model 39
Opening a Split Data Model 40
Loading from the Database 41
Finding the Administrator Layer in a Split Data
Model 42
When It’s Been Moved or Renamed 42
When It’s Been Copied Elsewhere 43
Getting Started
This chapter describes how to start BI/Query and open a data model.
Installing BI/Query
For installation instructions, see the BI/Query installation guide.
Starting BI/Query
BI/Query consists of three applications User, Update, and Admin. One
of the three appears under Hummingbird Applications on your Start
menu. You’ll click it to start the application.
When you start the application, the Hummingbird Business

Intelligence dialog box may appear. That’s an indication that your
corporate environment includes BI/Broker Repository, a central
storage area for data models, queries, results, and reports. The
repository provides a secure means of distribution and scheduling. To
use this additional functionality, you’ll need to enter your user name
and password.
Although you may have access to the repository, you don’t always need
to be logged in to it while you run BI/Query. Instead, you can choose
to work “offline” — without logging on. This doesn’t affect your
ability to connect to the database. And you can choose to connect to
the BI/Broker later in the session.
When you start BI/Query, you can choose one of four options.
• open the data model you were using when you last exited from
BI/Query
• open a data model you have stored locally or on a networked server
• retrieve a data model from the repository (available only if you have
access to the repository)
Getting Started 37
• open a design window in which to create a data model
To start BI/Query
1 Choose Start>Programs>Hummingbird BI>BI/Query Admin,
BI/Query User, or BI/QueryUpdate.
2 To log in to the BI/Broker Repository, in the Hummingbird
Business Intelligence dialog box, type your user name and
password.
OR
Choosing Work To use BI/Query without access to the repository, click Work Offline.
Offline means you
won’t have access
to the repository.
It doesn’t affect your ability to
connect to the database; you
can still submit queries and
work with the results. If you
need to publish, retrieve,
schedule, or secure your 3 In the Welcome to BI/Query window, click the icon that
work, you can log in to the
represents the data model you want to open. (The Repository Data
repository at any time; choose
File>Work Online.
Model option is available only if you’ve logged in to the BI/Broker
Repository.)
38 Getting Started
4 If a message informs you that a newer version of the data model
exists in the database, to open it, click Yes.
Retrieving a Published Data Model

If your corporate query environment includes Hummingbird’s BI/Web users can
BI/Broker, you may have access to the BI/Broker Repository. The also use data mod-
els published to
repository is a central storage area from which, with the appropriate
the repository.
permissions, administrators and users alike can retrieve data models. For information, see the
When you retrieve a data model, BI/Query copies it locally (to the online Help in the BI/Web
Program Files\Hummingbird BI\Documents folder), then saves it Personal Portfolio.
there. Any queries, data values files, connection files, and BI/Query
reports that were published with the data model are retrieved and
stored in the appropriate folders.
When you open a published data model, a message tells you that a
newer version exists in the repository and give you the opportunity to
retrieve it.
To retrieve a data model

1 If you’re starting BI/Query, in the Welcome to BI/Query dialog
box, click Repository Data Model.
OR
If you’ve been working in BI/Query, close the data model you’re
using, then choose File>Retrieve.
2 In the Retrieve dialog box, double-click New Items.
Getting Started 39
3 Select a data model, then click Open.
If you’re not sure

which data model
you want to open,
click it, then read
the description of it in the
Description text box.
Opening a Split Data Model

When you open a data model, it’s either a split or a combined data
model. (See “The Split Data Model” on page 25 and “The Combined
Data Model” on page 27.) A split data model is stored as two files —
the administrator-layer file with the extension .gqa and the user-layer
file with the extension .gqu.
40 Getting Started
No matter which BI/Query application you are using, you open the If you can’t select
user-layer file. The user-layer file contains a path to the administrator- a button or orna-
ment in Design
layer file. When you run BI/Query User or BI/Query Update and open Mode using
the user-layer file, this reference allows BI/Query to combine the two BI/Query User or BI/Query
layers. Both the core data model plus the user’s own customizations are Update, it’s because you’re
using a split data model and
available; there’s no visible difference between the user and
the object is stored in the
administrator layers. When the administrator runs BI/Query Admin administrator layer. Users can
and opens the user-layer file, the contents of the file are moved to the select and modify only ele-
administrator-layer file, where they’re saved when the file is saved. In ments in the user layer. Any
item in a dialog box that has a
other words, the administrator’s changes to the user layer become part
lock icon beside it was created
of the core data model. by the administrator and also
can’t be modified by the user.
A combined data model is a single file with the extension .gql. Unlike a
split data model, users can change anything for which they have the
appropriate permissions. (For more information on split and combined
data models, see “Types of Data Models” on page 24.)
Loading from the Database

If the administrator has revised a data model and saved it in the
database, users can load it to update their local versions. When a newer
version exists, a message appears when the data model is opened,
describing the changes that have been made and asking whether the
user wants to load it.
When the user loads the revised data model, any associated queries,
prompts, and data values files that have been saved in the database are
also loaded, as are any reports created with BI/Query Reports that have
been stored in the Reports folder with the data model. BI/Query
makes a local copy of the older version of the administrator-layer file
and gives it the extension .old. (Users can still use the older version of
the administrator-layer file by deleting the new .gqa file, then renaming
the .old file to .gqa.)
In the case of a split data model, BI/Query closes the data model, then
re-opens it using the new version of the administrator-layer file. The
Getting Started 41
data model appears, containing the existing user elements plus all the
elements in the revised administrator layer.
Finding the Administrator Layer in a Split Data Model

When you open a split data model, BI/Query may not be able to find
the administrator layer. A split data model stores the path to the
administrator-layer file in the user-layer file. When the administrator-
layer file is moved or renamed, the link between it and the user-layer
file can be broken.
When the administrator changes the name or location of the

administrator-layer file, he or she can use File>Save As to update the
new user-layer file to point to the new administrator-layer file. Other
ways of finding the administrator layer are discussed below.
When It’s Been Moved or Renamed

If the administrator-layer file has been moved or renamed and the user-
layer file can’t locate it when you open the data model, a message alerts
you. Once you’ve located the file, save the data model to save the new
link with it.
To find the administrator layer when it’s been moved or renamed

1 In the message box, click Find It.
2 In the Find dialog box, find and open the administrator-layer file.
3 Click Save.
4 In the Save dialog box, specify the new location for the file.
42 Getting Started
When It’s Been Copied Elsewhere
If a revised data model has been distributed but the changes aren’t
displayed when you open it, you may not be using the latest version.
This may be because the administrator has copied the administrator-
layer file to another folder and not deleted or renamed the original file.
To find the administrator layer when it’s been copied elsewhere

1 Choose Edit>Permissions.
2 In the Permissions dialog box, click Path to Admin Layer.
3 Click OK.
Getting Started 43
Connecting to the DBMS
Connection Files 48 Creating Connection Files 65

Creating Connection Files 48 Assigning Connection Files to Design
Windows 65
Setting Connection Preferences 50
How BI/Query Connects 67
Testing Connection Files 51
Connecting 68
Distributing Connection Files 52
Using a Default Connection 69
Logon Scripts in TCP/IP Connection Files 52
Using a Specific Connection 69
How the Scripts Work 53
Examples of Logon Scripts 54
Using Reply Tags 54
Using Static Strings 55
Understanding Prompt/Reply Pairs 55
Editing Scripts 57
Editing TCP/IP Settings 58
Distributing TCP/IP Settings 60
Setting Connections 61
Default Connections 61
Automatic Connections 62
For a BI/Query Session 62
For the Duration of a Query 63
To Multiple Databases 64
Assigning the Connect per Window
Permission 65
BI/Query connects to a wide range of DBMSs using a variety of
network connections. A network connection establishes an electronic link
between BI/Query on your computer and the host computer, where
the database is stored.
Many network connections that BI/Query supports are established Because the mid-
using middleware, connectivity software that allows application programs dleware market
changes so often,
to retrieve information from a database. Middleware may in turn use a information about
gateway, a layer of software between the client middleware and the network connections cur-
DBMS that translates one vendor’s DBMS to another’s. rently supported is available in
the online Help. You can also
Certain network connections are established using TCP/IP, a type of confirm connectivity options
middleware that starts a session with a host machine in which the host with Hummingbird Sales.
treats a user’s computer as a terminal. TCP/IP connections eliminate

the need for a workplace to use a specific vendor’s middleware, and
they make it easier for users to dial in from remote machines. BI/Query
sets up network connections using connection files.

Connection Files
One of the administrator’s first tasks in setting up BI/Query in the
workplace is to create connection files, test them, and distribute them to
users so that they can connect to the DBMS. Connection files store the
parameters required to connect to the DBMS. It’s not possible to
connect until these connection parameters have been set. The
parameters required for each network connection are different and site-
dependent. If you’re using a TCP/IP connection, the connection file
includes a logon script.
The administrator can set a connection file to be the default connection

for a data model; when users open the data model and connect,
BI/Query uses the default connection file. The administrator can also
set up BI/Query to connect automatically for the duration of a session
or only for the time required to submit queries and return results.
Alternatively, users can connect each time they open a data model.
Users can connect to one DBMS, using one connection file, per data
model. If your organization stores data in more than one DBMS, users
can access all of them using a single data model.
Creating Connection Files

The administrator typically creates connection files, tests them, and
distributes them. Users can also create connection files or edit files that
are distributed to them. They can’t change the DBMS, but they can
change the middleware and database parameters.
Different users can use the same data model with different network
connections. This is useful, for example, if a database is being moved
from one machine to another. Users can continue to use the data
model with the original network connection while a copy of the
database is being tested on another machine using another network
connection. If users will create or edit connection files, you need to
supply them with the appropriate connection information (database
name, host name, and so on).
48 Connecting to the DBMS

It’s good practice to create a set of connection files for each different
configuration that will be used. Store the files in the same folder; this
makes them easier to find, use, edit, and distribute.
If the Save Passwords permission is assigned, users can save passwords

(in encrypted form) in connection files. If this permission isn’t assigned,
or if a password isn’t provided in the connection file, users are
prompted to supply a password when they connect. While allowing
users to save a password in a connection file saves them from having to
supply it each time, it allows any user with access to that file to use the
connection. This situation may not be appropriate for your site.
To create a connection file

1 Choose Host>Connections.
2 In the Connections dialog box, specify a DBMS in the DBMS text
box.
3 In the Connection text box, specify a network connection.

4 Click New.
5 In the New Connection dialog box, specify the appropriate
parameters according to the instructions in the documentation for
the network connection.

6 Click Save.
7 In the Browse Connection Directories dialog box, specify a name
and location for the file, then click Save.
8 In the Connections dialog box, click Done.
Setting Connection Preferences

You or your users can set preferences for connection files to optimize
connection performance. For example, you can set row buffering
preferences to control the transfer of data across the network and
between BI/Query and DBAccess. (DBAccess is a utility that is
installed with BI/Query that allows the application to connect to the
DBMS.) For Oracle, Sybase, and Teradata DBMSs, you can also specify
the width of certain data that is returned from the database. (For more
information, see “Optimizing Connection Performance” on page 153.)
You can also set preferences that minimize the load on the network.
For example, you can set the Rows Retrieved before Prompt
preference to specify the number of rows to be retrieved before users
are prompted to retrieve more. And you can set the Query Time
before Prompt preference to be prompted to cancel a query.
If the Rows Retrieved before Prompt and the Query Time before
Prompt permissions have been assigned, the corresponding connection
preferences must be of lesser value. For example, the Rows Retrieved
before Prompt permission for a data model may be set to 20,000. If the
data model has multiple connections and one connection is slower than
the others, you may decide to set the Rows Retrieved before Prompt
preference for that connection to 10,000. Users are prompted after

20,000 rows have been returned for each connection except the one
whose preference is set to 10,000.
To set preferences for a connection file

1 In the New Connection or Edit Connection dialog box, click
Preferences.
2 In the Connection Preferences dialog box, set the preferences you
want, then click OK.
3 In the New Connection or Edit Connection dialog box, click Save.

Testing Connection Files

Before distributing a data model, it’s good practice to test the
connection file(s) it uses. (The test won’t work if the Enforce Connect
per Query permission is assigned or if the Connect per Query
preference is set.) If the connection is unsuccessful and you’re using
other applications that use the same connection, run one of them to
verify that the connection is working. If you’re still unable to connect,
call Technical Support for assistance. (For guidelines on obtaining
technical support, see “Tool Tips” on page 8.)
To test a connection file


2 In the Connections dialog box, select a connection file.
3 Click Connect.
4 If the connection fails, check the connection parameters and
reconnect using BI/Query or another application that uses that
connection.
Distributing Connection Files

Once you’ve created and tested one or more connection files, you can
distribute them to your users. Before they use them to connect, users
can edit them — for example, if the files don’t have userids or
passwords defined, users can add them.
To distribute a connection file

1 E-mail the connection file.
OR
Place it in a shared folder. (For more information on mailing files,
see “Using Mail” on page 220.)
Logon Scripts in TCP/IP Connection Files

When you connect to the DBMS using TCP/IP, the connection files
you use include a logon script that automates the process of starting a
session with the host machine.

A logon script contains a series of matching prompt/reply pairs that you
can edit to make the script unique for each TCP/IP connection. When
the user connects, the logon script starts a Telnet session and supplies it
with information contained in the connection file. If any information is
missing (for example, userid, password, and so on), the script prompts
the user for it.
TCP/IP logon script
How the Scripts Work

The logon script, the Telnet session, and the connection file ensure that
About Telnet Sessions
users can connect to the DBMS using TCP/IP by exchanging
Each time users connect
information in the following manner: using TCP/IP, the logon
script starts a Telnet ses-
• BI/Query retrieves the first prompt value from the logon script. sion. Users can’t view the
• BI/Query starts a Telnet session and looks for the prompt value in it. Telnet session because no
interactive terminal win-
• After BI/Query finds the prompt value, it retrieves the first reply dow is displayed.
value from the logon script.
• If the reply value is a tag to something defined in the connection
file, BI/Query looks in the connection file for that value and
returns it to the Telnet session.
OR

If the reply value is a static string, BI/Query returns that string to
the Telnet session.
• After a prompt/reply pair is successfully processed, BI/Query
moves on to the next pair.
Examples of Logon Scripts

The following examples describe how scripts work in two different
situations. The first example shows how BI/Query uses a script
containing reply tags; the second example explains when you’d use
static strings in a script and how they work.
Using Reply Tags

You can place Scripts can contain reply tags. The following script could be used to
static text in a connect to a VAX/VMS machine:
reply tag (for
example, logon
<hostuserid>. This is useful if a TCPIP.Prompt01 “Username:”
command and a reply have to TCPIP.Reply01 “<hostuserid>”
be on the same line. TCPIP.Prompt02 “Password:”
TCPIP.Reply02 “<hostpassword>”
TCPIP.Prompt03 “$”
TCPIP.Reply03 “<startdbms>”
If BI/Query finds a prompt with the value Username:, it starts a Telnet

session and looks for Username:. It then returns to the logon script and
retrieves the correct reply for that value — for example, <hostuserid>.
BI/Query checks the connection file for the field that corresponds to
<hostuserid>, then returns the corresponding value (such as Paul) to the
Telnet session. This process continues for each prompt found.
Using this example, the Telnet session would look like this:

Welcome to VAX/VMS
Username: Paul
Password:
Welcome to VAX/VMS
Last interactive login on Thursday, 3-JUL-1997

09:54
Last non-interactive login on Wednesday, 2-JUL-
1997 11:42
$
Using Static Strings

Scripts can contain static strings instead of reply tags. They may be Some logon
used, for example, at sites that start a database from a menu that scripts may
require special
provides users with various commands. If Start Database is the second
Telnet escape
command on the menu, you’d set the nth prompt value to Choice? and sequences. To use one of
the nth reply value to 2. BI/Query retrieves the nth prompt value from these sequences, preface the
the logon script. It returns to the Telnet session, which is probably reply tag with ESC, followed
by the required ASCII charac-
already running, and looks for Choice?. After it finds it, BI/Query ters. For example, to send F2
retrieves the nth reply value from the logon script, in this case 2, and to a Telnet session, use the
sends it back to the Telnet session. reply tag ESCOQ.
The following script uses a static string to start the DBMS:
TCPIP.Prompt01 “Username:”
TCPIP.Reply01 “<hostuserid>”
TCPIP.Prompt02 “Password:”
TCPIP.Reply02 “<hostpassword>”
TCPIP.Prompt03 “Choice”
TCPIP.Reply03 “2”
Understanding Prompt/Reply Pairs

Before you can edit a logon script, you need to determine what
prompts the DBMS displays and in which order. You also need to edit

the default prompts to correspond to the DBMS prompts. (For details
on editing prompts, see “Editing Scripts” on page 57.)
Once you determine what prompts the DBMS uses, you can provide
the corresponding replies. In many cases, the replies are tags pointing to
information in a corresponding connection file. This table describes the
available reply tags.
This Tag Does This
<hostuserid> Retrieves the host machine’s userid from the

connection file.
<hostpassword> Retrieves the host machine’s password from the

connection file.
<host> Retrieves the name of the host machine from

the connection file.
<userid> Retrieves the database’s userid from the

connection file.
<show> Opens a dialog box that contains all information

sent to the Telnet session since the last prompt.
<getreply> Opens a dialog box that contains all information

sent to the Telnet session since the last prompt.
Users have to supply certain information. When
they click OK, the information is sent to the
Telnet session.
<startdbms> Starts an interactive SQL session and uses all tags

following it while logging out.
<stopscript> If a database is started from a menu command,

tells BI/Query that the database has been started
and stops BI/Query from processing the script.
When users disconnect, the script begins
processing again by looking for the next prompt.

This Tag Does This
<no-op> Sends nothing back to the Telnet session. This

tag works well with the <show> and
<getreply> tags. It can mark the starting point of
a message you want users to see.
<> Sends a carriage return to the Telnet session. An

empty tag is the equivalent of pressing Enter —
for example, in a message box that says, “Press
Enter to continue.”
Editing Scripts
You need to edit the default logon script for each TCP/IP connection You can insert a
file. Modifications may be as simple as changing the TCP/IP.Prompt01 prompt/reply pair
into the logon
value from Username: to Logon:. Or they may be more complex, adding script. (The order
several new prompt/reply pairs. of the pairs must reflect the
order in which the Telnet ses-
To edit a script sion asks for them.) Click the
pair above which you want to
1 Choose Host>Connections. insert the new pair, click
2 In the Connections dialog box, select the TCP/IP connection file Insert, then edit the pair.
that contains the script you want to edit, then click Edit.
3 In the Edit Connection dialog box, click the prompt/reply pair that
you want to edit, then click Edit.
4 In the Edit Script Item dialog box, type a value into the Prompt
text box.
5 In the Response text box, specify a reply tag.

6 Click OK.
7 Repeat steps 3 to 6 for each prompt/reply pair you want to edit.

8 In the Edit Connection dialog box, click Save.
9 In the Connection dialog box, click Done.
Editing TCP/IP Settings

When BI/Query is installed, it adds a number of TCP/IP settings to
the Registry on that computer. You can modify these settings and
distribute them to users. These TCP/IP settings work in conjunction
with the logon script settings, as described below. All setting names are
prefixed with TCPIP.
This Setting Does This
AutoStartDbms Specifies whether the logon script starts

the database. When set to True, the
<startdbms> tag causes BI/Query to start
the DBMS. When set to False, BI/Query
assumes that the logon script is sufficient
to log the user in and start an interactive
SQL session with the database. In this
case, the <stopscript> tag should appear in
the logon script.
DebugTrace When set to True, sends all of the Telnet

session characters to the review traffic file.
Use this setting to complete a full trace of
connection activity before reporting a
problem to Technical Support.
Ingres.Float Specifies the length and precision of Ingres

Ingres.Float4 float types. The format for these settings is
-fXYM.N, where:
• X is set to 4 or 8 for float4 or float8,
respectively.
• Y is represented by E for exponential
format, F or N for floating point format,
or G for floating point format with
decimal alignment.

This Setting Does This
Ingres.Float • M represents the column’s total width,

Ingres.Float4 (continued) including N decimal points.
For example, the default format for float4
is -f4n11.3; for float8, it’s -f8n15.3.
ReviewTraffic.Filename Specifies the name of the file that retrieves

output from the Telnet session. By
default, this file is called Traffic.rev. It’s
created in the same directory as DBAccess.
Refer to it before reporting problems to
Technical Support.
ReviewTraffic.State Specifies the way the review traffic file

operates. There are three options:
• Off sends no output to the file. (This is
the default.)
• Overwrite replaces the contents of the file
with output from the current session.
• Append attaches output from the current
session to the end of the file.
Telnet.Port Specifies the Telnet port. By default, and

for most sites, this value is 23.
WaitTime Specifies the amount of time BI/Query

spends trying to perform a task. It’s Example of WaitTime
measured in seconds and should be set If TCPIP.Prompt01 is
Username: and the Telnet
according to the type of connection. For
session starts by prompt-
example, a dial-in connection over a 9600 ing for Userid, BI/Query
modem may require a longer wait time eventually times out. This
than connecting to a machine on site. By occurs because BI/Query
default, this value is set to 20 seconds. can’t find Username: in the
If BI/Query can’t complete a task, it times current Telnet session.
out and reports an error. Generally, this
time-out is caused by errors in the logon
script. If the errors persist, set the Review
Traffic State setting to Append or Overwrite
and examine the output.

To edit TCP/IP settings
To run the Regis- 1 In the Registry Editor, open HKEY_LOCAL_MACHINE\
try Editor, choose SOFTWARE\Andyne\DBAccess\Current Version\
Start>Run, then TCPIP.Settings).
type regedit into
the Open text box. Or dou- 2 Double-click an item under Name.
ble-click regedit.exe in your 3 In the Edit String dialog box, type a new value into the Value
Windows folder. Name text box.
4 Click OK.
Distributing TCP/IP Settings

Once you’ve modified the settings, you can distribute them to your
users. You can export them using the Registry Editor; this creates a .reg
file. Or you can e-mail the file or place it in a shared folder on a
network server.
Users can copy the .reg file to their computers. When they double-click
the file, the TCP/IP settings are copied to the appropriate location in
the Registry.
To distribute TCP/IP settings

1 In the Registry Editor, open HKEY_LOCAL_MACHINE\
SOFTWARE\Andyne\DBAccess\Current Version\
TCPIP.Settings.
2 Choose Registry>Export Registry File.
3 In the Export Registry File dialog box, specify a name and location
for the file, then click Save.

4 E-mail the .reg file or place it in a shared folder.
Setting Connections
Once you’ve created, tested, and distributed connection files, you can
set users up to use them to connect. You can set default connections,
automatic connections, and connections to multiple databases.
Default Connections
You can set a connection file as the default connection for a data model
to make connecting fast and easy. Setting a default allows users to
connect without having to specify a connection each time.
To set a default connection

2 In the Connections dialog box, select a connection file, then click
Set Default.

3 Click Done.
Automatic Connections
Users can connect automatically to the DBMS in two ways. They can
connect for the duration of a BI/Query session or only while they’re
submitting queries.
For a BI/Query Session

You or your users can set the Connect Automatically preference so that
the data model automatically connects, using the default connection,
each time a user opens the data model.
To set an automatic connection for a BI/Query session

1 Choose Edit>Preferences.
2 In the Preferences dialog box, set the Connect Automatically
preference.

3 Click OK.
For the Duration of a Query

Instead of connecting for an entire session, users can connect to the
DBMS each time they submit a query, then disconnect once the results
are returned. Connecting to the DBMS only for the duration of a
query minimizes the resources being used on the database server.
(BI/Query also connects when users open a data model so it can
determine whether a new version is stored in the database. Once users
open the data model, BI/Query disconnects.)
You can set users up to connect in this manner by assigning the Enforce
Connect per Query permission. If you don’t assign this permission,
users can set the Connect per Query preference.
To set an automatic connection for the duration of a query


2 In the Permissions dialog box, assign the Enforce Connect per
Query permission.
3 Click OK.
To Multiple Databases
You can connect If your organization stores data in multiple databases, users can access all
to different data- of them using a single data model. You set them up by assigning
bases when
they’re of the
connection files to specific design windows. For example, if you want
same type (homogeneous) or users to connect to Oracle and Sybase databases from one data model,
when they’re of different you can assign a connection file to one design window that connects to
types (heterogeneous). Oracle, then assign another connection file to a second design window
that connects to Sybase. (Any design window with no connection file
assigned uses the same connection file as the data model.) When users
submit a query, BI/Query connects using the connection file assigned
to the design window they used to build the query.
By building queries in different design windows, users can combine the

results and build super queries that widen the scope of information they

include in their business reports. (For information on building super
queries, see “Super Queries That Combine Results” on page 310.)
To set users up to connect to multiple databases, you need to:
• assign the Connect per Window permission

• create the appropriate connection files
• assign the connection files to design windows
Assigning the Connect per Window Permission

Assigning the Connect per Window permission ensures that when
users submit a query, BI/Query connects using the connection file
assigned to the design window they used to build the query. (When
you assign this permission, BI/Query automatically assigns the Enforce
Connect per Query permission, then disables it so it can’t be removed.)
Creating Connection Files

Different databases require different connection settings, so you need to If the connection
create the appropriate connection file for each one. (See “Creating file you want to
use was created
Connection Files” on page 48.) It’s good practice to create connection
using an earlier
files that contain all the required parameters, such as userid and version of the application, you
password. Otherwise, users are prompted to specify the missing must open and save it first.
information the first time they connect during a session, then uses that
information for all subsequent connections rather than prompting for it
again. However, if a parameter is identical for each database, you don’t
need to provide it.
Assigning Connection Files to Design Windows

Once you’ve created the appropriate connection files, you can assign them
to the appropriate design windows. (For instructions on creating design
windows and loading tables into them, see “Creating Design Windows”
on page 95 and “Loading Tables from the Database” on page 96.)

To assign a connection file to a design window
1 Make sure the Connect per Window permission is assigned.
2 In Design Mode, choose Layout>Windows.
3 In the Design Windows dialog box, select a design window, then
click Connections.
4 In the Choose Connection dialog box, select a connection file.
5 Click OK.
6 In the Design Windows dialog box, click Done.

How BI/Query Connects
The connection file BI/Query uses depends on the activity you’re
performing. (For more information on setting default connections, see
“Setting Connections” on page 61.)
Doing This Uses This
Retrieving data values or The connection file assigned to the

loading attribute design window that contains the
comments corresponding attribute. (If one isn’t
assigned, the default connection file.)
Creating or loading The connection file assigned to the

tables active design window. (If one isn’t
assigned, the default connection file.)
Refreshing tables The connection file assigned to the

design window that contains the table.
(If one isn’t assigned, the default
connection file.)
Restoring data models The default connection file.

from or saving them to
the database
Sending an SQL script If the active window is a design

window, the connection file assigned to
it. (If one isn’t assigned, the default
connection file.)
If the active window isn’t a design
window, the default connection file.
Submitting a query to a The connection file assigned to the

results window, file, or design window where the query was
table created. (If one isn’t assigned, the
default connection file.)
Submitting a super query The connection file for each

component query.

Connecting
Any activity that requires access to the database requires connecting to
the database management system (DBMS). These activities are:
• loading tables from the database

• saving data models to the database
• loading data models from the database
• creating tables in the database
• submitting queries
• sending SQL scripts to the DBMS
• updating the database
Many activities in BI/Query don’t require access to the database —

such as:
• customizing data models (setting permissions and preferences;

creating design windows; creating and manipulating buttons and
ornaments)
• publishing data models and queries to the repository
Consider performing these activities off-line so that you’re not using

database server resources unnecessarily. You don’t need to remember
when to connect. You’re prompted for a connection before you carry
out any activity that requires access to the database.
Once users have the appropriate connection files, they can connect to
the DBMS. If the data model they’re using is set up to connect
automatically, BI/Query connects to the DBMS each time they open
the data model or each time they submit a query. If the data model isn’t
set up to connect automatically, they need to connect to carry out
activities requiring access to the DBMS. If the user needs to supply any
information such as a password or user ID not included in the
connection file, they’re prompted for it.
When users no longer need access to the DBMS, it’s good practice to
disconnect from it to reduce the load on the database server.

Using a Default Connection
When the data model you’re using has a default connection,
connecting is fast and easy.
To connect using a default connection

1 Choose Host>Connect.
Using a Specific Connection

You can also connect using a specific connection.
To connect using a specific connection

1 To use any other connection, choose Host>Connections.
2 In the Connections dialog box, select a connection file.
3 Click Connect.
4 If the Enter Connection Information dialog box appears, type the
required information, then click OK.

Deploying BI/Query
Before You Begin 75
Creating a Data Model 93
Creating an Effective Design 167

Before You Begin
Assessing Your Users 75 Ad Hoc/Report Data Model 89

Information Needs 75 Multiple Data Models 90
Computer Skills 76
Preparing the Database 77
Creating Lookup Tables 77
Adding Indices 78
Denormalizing Tables 78
Computing Common Summarizations 79
Reorganizing Table Structures 79
Providing Metadata 81
Delivering the Right Data Model 82
Controlled Data Model 82
Logical Data Model 82
Modular Data Model 83
EIS Data Model 85
Creating Design Windows 86
Creating Data Objects and Relationships 87
Creating Queries, Reports, and
HyperCubes 87
Creating Buttons 87
Ad Hoc Data Model 88
Before You Begin
The administrator is responsible for creating the data model, maintaining
it, and distributing it to users. You’re typically required to deliver
customized data access to a large user community with often widely
different needs. Delivering information can entail creating one data
model for the user community, then granting or denying access to
specific parts of it to individual users and groups. Or it might encompass
supplying “canned” queries and reports for users who want everything
done for them to providing ad hoc access for users who want the
flexibility to create their own queries and reports.
You have to balance users’ information needs with their computer

skills, accommodating novices and “power users” alike. At the same
time, you need to pay close attention to performance, ensuring that the
data access environment maintains data integrity and security and
minimizes network traffic problems and server overload. It might seem
like an onerous task. But BI/Query’s deployment features and strategies
make it easy to satisfy all users’ data access needs.
Assessing Your Users

Before you can deliver information to users, you need to establish what To determine
database information your users need to perform their jobs and how users’ informa-
tion needs, col-
they’re going to use BI/Query to access and present that information. lect the reports
You can then build the data access environment to meet those needs. they run and check the
attributes in them — those are
the attributes users need.
Information Needs
Users have different information needs depending on where in an
organization they work. Users in the Sales Department need access to
customer, product, and shipping data to track products shipped,
warranties, and invoices. The Human Resources Department needs
access to employee and payroll data to track vacation time, analyze
Before You Begin 75

performance, and determine how well the company is addressing
employment-equity legislation. And Finance needs access to financial
data to analyze sales by product, regional office, period, and so on.
Users’ job functions also determine how they use BI/Query. Even
users in the same department need different information or different
ways of accessing it. For example, sales managers who need quick
answers to standard questions may want to generate reports for weekly
sales meetings that analyze sales by month and quarter. Sales
representatives may need to build specialized queries including
qualifications and calculations in order to analyze sales by product,
region, and country.
And different user groups have different security requirements. Human

Resources, for example, needs secure access to employee and payroll
records. You can restrict access to specific parts of a data model as well
as to certain data and facilities in BI/Query.
For users who will submit queries and use reports that you supply, you
can provide a data model that provides push-button access to those
activities; the data model can also contain an EIS interface to give users
access to increasingly specific data. You need to know what queries
users will submit so that you can build “canned” queries and predefined
report templates. You also need to know how complex those queries
and reports are, and how frequently they will be run, in order to
balance the load on the database server.
Computer Skills
Don’t underesti- In each user group, novices and “power users” will have varying
mate users’ ability computer skills and technical facility. Some will feel confident enough
to hone their
to use the advanced features of BI/Query, and those advanced users
computer skills as
they become familiar with may want the flexibility to specify their own SQL in queries, perform
BI/Query and the tasks calculations, combine results sets, or create their own joins between
they’re carrying out. Even tables. Novice users, on the other hand, may be content to build simple
casual users will realize the
benefit of building their own queries or use queries that you provide.
ad hoc queries.
76 Before You Begin

Preparing the Database
BI/Query offers the administrator a number of facilities for modeling If you’re unsure of
relational databases. Features such as merging data objects and using the meaning of
any of the terms
tables more than once help the administrator create a more productive
and concepts dis-
environment for users to access data. However, some users may request cussed in this section, consult
information that’s difficult to formulate or unnecessarily inefficient to an SQL reference manual or
obtain, resulting in a significant load on the database server. The your DBMS documentation.
administrator can make changes at the server to improve performance
and help users access the data they need.
Creating Lookup Tables

BI/Query’s data values facilities provide a number of mechanisms for
obtaining a list of values from which users can choose when they’re
qualifying queries and entering values into qualification prompts. (See
“Using Data Values, Prompts, and Variables” on page 257.) The default
mechanism executes a select distinct query for the attribute being
qualified. However, if that attribute is an unindexed column of a table
with a large number of rows (called a fact table), that mechanism may
result in an expensive query. To alleviate that potential problem, you
can create a data values query that redirects the query to a different
table — typically a smaller one — called a lookup table. You can create a
lookup table in the database to support that mechanism.
You can use BI/Query to create a lookup table by submitting a select

distinct query and submitting the results to a named table in the
database. (See “Creating Tables in the Database” on page 114.) Each
time you need to update the contents of the table, submitting the
results of the new query overwrites the current table. Keep in mind that
you also need to develop a procedure to ensure that when the fact table
changes (values are added, modified, or deleted), the values in the
lookup table are updated accordingly.
Before You Begin 77

Adding Indices
When you add You can dramatically decrease the time it takes to process a query when
indices to a table, you use indices on the tables represented in the data model. For
keep in mind that
example, indexing any columns that are used to join two tables
most DBMSs
can’t use an index for qualifi- improves performance. Indexing the attributes being qualified or sorted
cations that use the LIKE on also speeds up querying time. Before deciding to index an attribute,
operator. you need to weigh the benefits versus the cost of maintaining the
index. To find out what the issues are for your DBMS, see your DBMS
documentation.
When deciding whether to index an attribute, consider the following:
• If an attribute is often used as a qualification in a query, it’s a

candidate for indexing.
• If a table is large, at least some of its attributes are candidates for
indexing.
• If a table is being heavily updated (that is, if one or more authorized
users are adding, updating, or deleting data), the expense of
maintaining the indices may outweigh the advantage of improved
performance for the users.
Denormalizing Tables
The pattern of access to a data warehouse or database used primarily for
decision support is very different than the pattern of access to an
operational database used to capture data. The design of databases for
OLTP (OnLine Transaction Processing) usually involves reducing
redundancy by creating a schema of normalized tables. However, this
design creates a large number of tables, which users can find confusing.
BI/Query provides facilities to simplify the data model. For example, it

allows you to merge data objects. (See “Merging Data Objects” on
page 111.) But you can achieve the same simplification by denormalizing
the tables in the database. Denormalizing tables has a second major
benefit in that the tables are usually accessed much more efficiently than
the joins between normalized tables allow.
78 Before You Begin

Computing Common Summarizations
Users can easily obtain summary information from detail data using
BI/Query. For example, using a Sales data object, the user can create a
calculated attribute called Total Sales that sums sales amounts using the
Amount attribute. If many users want this summarized information,
you can store it in the database and make it available as part of the data
model. This pre-computing of commonly used summary information
can greatly reduce the load on the database server and improve query
response time for each user.
To determine what summary information users most frequently

require, you may need to undertake some consultation or analysis. For
example, you can interview users to gather their requirements, or you
can monitor their queries and analyze the usage patterns that appear.
Hummingbird BI/Analyze accesses information stored in

multidimensional, summarized information sources called HyperCubes.
The approaches to designing HyperCubes and even the tools for
creating them may be of use in designing and building databases for
access by BI/Query. (To obtain more information about BI/Analyze,
see “Contacting Hummingbird Sales” on page 14.)
Reorganizing Table Structures

The way in which users want to present the data they retrieve in
BI/Query can require reorganizing the data in the database.
Reorganizing tables (possibly including denormalization or
summarization) can improve how BI/Query information is organized
in results sets and presented in reports. (See “Denormalizing Tables” on
page 78 and “Computing Common Summarizations” on page 79.)
Before deciding on the optimum benefit, be sure that any conflicting
requirements are analyzed. The ability to reorganize tables is also
constrained by the manner in which the data is fed to the database in
the first place and may be most appropriate in data warehouse or data
mart environments.
Before You Begin 79

The following example shows how the organization of data in a table
affects the way information is presented in a BI/Query report. The
report compares sales for the last two quarters, and the user wants the
information to look like this:
Company 2nd Last Quarter Last Quarter Change
ABC Inc. 723,356 137,893 -11.8%
XYZ Corp. 762,873 569,581 -25.3%
It’s easy for the user to retrieve this data when the table is organized like
this (call it “wide” format):
TABLE sales
Company char(20)
Q1 money
Q2 money
Using the organization shown in the table below (call it “narrow”

format), retrieving this data isn’t so easy. The user has to generate two
queries (one for Period = ‘Q1’ and one for Period = ‘Q2’), join the
results sets, then generate the report. (For more information on joining
results, see “That Combine Results” on page 339.)
TABLE sales
Company char(20)
Period char(2) ; Q1 or Q2
Amount money
80 Before You Begin

The following organization (over two tables) once again requires the
user to submit two queries (or a super query containing a join) to
retrieve the required information.
TABLE salesq1
Company char(20)
Q1 money
Table salesq2
Company char(20)
Q2 money
The choice between making “wide” tables (tables with several columns
containing the same type of data) and “narrow” tables (tables with one
column that indicates the type of data and one column for the data)
depends on the need to compare data of each type in a report
calculation. For example, it’s easier to compare (calculate with) data in
the same row than data in different rows. However, it’s easier to
aggregate over all the data when it’s in a single column.
Providing Metadata
You can provide metadata for the data objects and attributes in a data
model to give users a clearer understanding of their data and help them
build queries. For data objects, metadata replaces database table names
with display names; for attributes, it replaces database column names
with business terms. And it provides short descriptions for both that
explain what kind of information they represent. You set up the
necessary queries to specify the metadata source. (If your database
doesn’t already store metadata, you can use BI/Query to create it.)
Loading the metadata into the data model submits the queries to the
Before You Begin 81

metadata source and retrieves the metadata. (For more information, see
“Providing Metadata” on page 179.)
Delivering the Right Data Model

The right data model delivers the right information in the right way. It
Find the Right Balance
There are no hard and fast
gives users access to the information they need in a way that’s easy to
rules for delivering the understand and simple to use. It strikes a balance between the number
right data model. What and size of tables in the database and users’ information needs; it weighs
you build depends on: the facilities it provides against users’ computer skills and how they like
• the number and size of to work.
tables in the database
• users’ information needs The facilities in a data model and the way it organizes information are
and computer skills essential to users’ ability to use it effectively. They’re particularly
• the number of users or important when the data model represents a large number of tables. On
user groups with unique the one hand, a data model that’s too complex to understand makes it
needs difficult for users to access even the simplest information. On the other
hand, a data model that’s too simple doesn’t allow users access to
enough useful information to make the data model worthwhile.
There are a number of strategies you can use to deliver a data model
that strikes the balance you need.
Controlled Data Model

A controlled data model controls what’s seen by different users and user
groups.
Logical Data Model

The easiest data model to build is a physical data model. A physical data
model is a direct representation of the database and is modeled after the
entity-relationship diagram. However, including all the tables in the
database would likely make the data model too large and complex, so
the physical data model is often not useful for users. The most useful
82 Before You Begin

data model is a logical data model. A logical data model presents a
A Logical Data Model
business view of the database — in a way that makes sense from the
• provides a business
users’ point of view.
view, not a physical
view, of the database
For example, a physical data model might store address information for
customers, sales representatives, and offices in one table because it’s • provides only the tables
and relationships users
most efficient. A logical data model, on the other hand, might provide need
this information for customers in the customers, sales representatives, • reuses and combines
and offices data objects because that’s where users would most likely tables when appropriate
look for it.
A sample physical model. A sample logical model.
Modular Data Model

If there are hundreds of tables in the database, you need to decide
A Modular Data Model
whether they can be represented in one data model. Including a large
number of tables can make the data model more complex and more • groups related
information in one or
unwieldy or intimidating to use — especially if some users need access more design windows
to only a few tables. • provides a focused data
access environment
One method of handling a large number of tables is to build a modular
data model. A modular data model displays different sets of data objects
and relationships in different design windows; each set of objects in a
window is related.
If different user groups or departments use some of the same data (such
as tables that store employee information), and if they’re allowed access
to each other’s data, you can build a separate data access environment
Before You Begin 83

for each department within the same data model. For example, you can
create one set of data objects and relationships for Human Resources in
one design window, one set for Finance in a second window, one set
for Manufacturing in a third window, and so on.
If your company produces bicycles and carries a number of product

lines, it may be beneficial to organize the data model by product line.
Different design windows can display a set of data objects and
relationships for road bikes, touring bikes, racing bikes, and so on.
On the other hand, if your company produces one product but

packages it in a variety of ways, you can create two groups of data
objects and relationships in one design window — one group that
represents the product and another that represents the packaging.
84 Before You Begin

EIS Data Model
An EIS data model provides an EIS (Executive Information System)
interface. It organizes information hierarchically and combines a
number of facilities to give users a quick way of finding exactly the
information they need. Buttons allow users to navigate from one
window to another; each window in the series provides increasingly
detailed information. Buttons also run stored queries, reports, and
HyperCubes. The result is a focused query environment in which users
can quickly drill down on increasingly detailed information.
When your data is complex and users aren’t technically skilled, an EIS
data model provides a controlled environment that’s easy to use. It can
be used in the first phase of implementation to give users time to learn
BI/Query and the data model. And if there’s no time for training, it
gets them up and running quickly.
You create an EIS interface by creating the design windows you need;
adding data objects and relationships; creating the queries, reports, and
HyperCubes users will run; then creating the buttons that display the
windows, run the queries, and generate the reports and HyperCubes.
Before You Begin 85

You can include the following design windows:
This Window Provides This
Introduction A welcome; includes the company logo and

buttons that display other windows. For a
company with offices worldwide, for example,
it may include a map of the world.
Building Queries Data objects and relationships that users will

use to build queries.
Series Buttons linked to, for example, areas of the

world and placed over maps of those areas.
Pressing these buttons run queries by sales
region, country, or domestic versus
international sales), generate different types of
reports, and generate reports for different
aggregation levels.
In a split data model, the elements of an EIS interface created using

BI/Query Admin are stored in the administrator layer; users can’t
modify or delete them. If the appropriate permissions are assigned, users
can customize their user layer to include their own EIS interface.
Creating Design Windows

The first step in creating an EIS interface is to create the design
windows users need. (See “Creating Design Windows” on page 95.) In
each window, create text and graphic ornaments to provide a visual cue
to the information available. You can add text ornaments that display
titles and instructions, and you can create graphic ornaments in the
form of maps, diagrams, charts, or your company logo. (See “Creating
Ornaments” on page 198.)
86 Before You Begin

Creating Data Objects and Relationships
Next, create the data objects and relationships users will use (see “From
Data Objects” on page 116) and specify the appropriate join conditions
between them (see “Creating Join Conditions” on page 104). Create
the data objects in a window that isn’t in the series. (Or create them in
one of the EIS windows, then move them to the bottom of the
window so users won’t use them to build their own queries.)
Creating Queries, Reports, and HyperCubes

Now create the necessary queries and reports that users will use. (See
“Building Queries” on page 291 and the BI/Query Reports user
documentation.) Be sure to include prompts so that users can insert the
necessary values to retrieve exactly the information they want. (See
“Prompts” on page 269.) In addition, build the HyperCubes users need
to create reports in BI/Analyze. (See the BI/Analyze CubeCreator user
documentation.)
Creating Buttons
Buttons provide the mechanism for moving from one design window
to another in the series and for running queries, reports, and
HyperCubes. In the first window, create a button and link it to a
second window; in the second window, create a button and link it to a
third window, and so on. In each window, link buttons to the queries,
reports, and HyperCubes that users will run. Test each button to ensure
it works properly. (See “Creating Buttons” on page 406.)
Before You Begin 87

In this data model, the main design window displays a map of the world with a button
identifying each sales region. Clicking the button on the map of Europe displays a design
window in which users can obtain information on European sales.
Ad Hoc Data Model

An ad hoc data model provides data objects and relationships that allow
users to submit their own queries and generate their own reports and
HyperCubes. This type of model is useful when users are constantly
analyzing data and their requests for information are unique to every
query. An ad hoc model can include the following design windows:
88 Before You Begin

Introduction A welcome; includes the company logo

and buttons that display other windows.
Ad Hoc Queries (one Data objects and relationships.

or more)
“For Help, Contact” Information on contacting internal

technical support.
User Queries/ Typically left blank so users can add their

User Reports own buttons.
Ad Hoc/Report Data Model

An ad hoc/report data model supports a user group with varying technical
skills. It provides an ad hoc interface for users whose data access
requirements are unique to every query and who create their own
queries, reports, and HyperCubes. This data model also supplies
predefined queries, reports, and HyperCubes for users who don’t need
to create their own. A third group of users can use both.
The following table suggests the design windows that you can include
in an ad hoc/report model. Providing buttons in each window allows
users to navigate from one window to another.
Introduction A welcome; includes the company logo

and buttons that display other windows.
Predefined Buttons that automatically execute

Queries/Reports predefined queries and reports.
User Queries/ User Typically left blank so users can add their
Reports own buttons.
Before You Begin 89

Ad Hoc Queries (one Data objects and relationships.

or more)
“For Help, Contact” Information on contacting technical

support.
Data Model The purpose of the data model.

Information
“How to Leave Instructions for leaving BI/Query.

BI/Query”
Multiple Data Models

To save time and If there are hundreds of tables in the database and different users and
effort in creating user groups need access to different information, you can take
multiple data
advantage of BI/Query’s security feature, as well as its ability to
models, start by
creating a model that includes connect to multiple databases, to reduce the number of data models
the information all users need, you need to build. You can build one model, then grant or deny access
then use it as a template for to certain parts of it to individual users and groups. (For more
each additional model.
information, see “Setting Up Security” on page 59 of the BI/Broker
administrator’s guide.)
Alternatively, you need to create more than one data model. While
creating a different data model for each group may be initially more
time-consuming, it can satisfy each group’s data access needs better
than one data model that includes all information for all users.
90 Before You Begin

Creating a Data Model
Opening a New Data Model 93 Reloading the Table 120

Creating Design Windows 95 Populating the Table 120
Loading Tables from the Database 96 Assigning Permissions 121
Simplifying Display Names 98 Assigning Default Settings 122
Organizing Attributes 99 Setting Data Model Passwords 123
Creating Relationships between Tables 100 Checking the Design 124
Embedded Relationships 101 Saving the Data Model 125
Actual Relationships 101 As a Split Data Model 126
Renaming Objects and Attributes 102 Understanding a Split Data Model 126
Data Objects and Relationships 103 As a Combined Data Model 127
Attributes 104
Creating Join Conditions 104
That Include a Prompt or Variable 106
Using Tables More Than Once 108
Specifying Correlation Names 109
Merging Data Objects 111
Editing Join Conditions 113
Creating Tables in the Database 114
From Query Results 115
From Data Objects 116
Directly in the Database 117
Using an SQL Script 118
Creating a Data Model
The data model is the user’s gateway to the database. Users are busy
professionals who need easy access to information so that they can
make informed decisions quickly. A good data model is one that
delivers information quickly and effectively. It gives users access to the
information they need, and it’s easy to understand and simple to use.
The administrator creates a basic data model that gives users access to
the data and the BI/Query functionality they need. The administrator
can also add value to a data model by including metadata, buttons,
queries, prompts, reports, data values query and results files, computed
attributes, graphics, and so on. The administrator may create different
versions of the data model for groups of users depending on their needs.
Create a standard data model that includes Add value to the data model by adding
data objects, relationships, join conditions, buttons, graphics, queries, and so on.
default settings, and permissions.
This chapter describes the things you need to do to create a data model
that contains data objects, relationships, and join conditions and that
allows users to query the database.
Opening a New Data Model

The first step in creating a data model is to open a new model. This
displays a blank design window.

To open a new data model
You must be in 1 Run BI/Query Admin.
Design Mode to
create a data
2 In the Welcome to BI/Query window, click New Data Model.
model.To switch
in and out of Design Mode,
choose Layout>Design
Mode. Design Mode pro-
vides a drawing toolbar and
layout palette.
OR
If you’re already running BI/Query and you’ve opened a data
model, close it, then choose File>New.
3 Rename the Untitled window. (See “Creating Design Windows”
on page 95.)
4 Click Done.
Depending on the number of tables you need to represent in the data

model and how you want to organize them, you may need to create
other design windows. If you know which tables you want to include
and how many windows you need, you can start by creating the
windows. (See “Creating Design Windows” on page 95.)
Alternatively, you can load tables into this design window and create
additional windows as you need them. (See “Loading Tables from the
Database” on page 96.)
94 Creating a Data Model

Creating Design Windows
Design windows provide a means of organizing data objects,
relationships, buttons, and ornaments in a data model. For example,
one design window can act as an introduction to the data model,
displaying a “table of contents” with buttons that display other design
windows where the specified information is available. Another design
window can be devoted to submitting ad hoc queries and reports,
another to submitting “canned” queries and reports using buttons, and
others to organizing information into groups (a different window for
each sales region, for example).
After you’ve created data objects, relationships, buttons, and

ornaments, you can copy them, or cut and paste them, from one
window to another. You can also copy data objects and actual
relationships to be used in the same design window; in this case, you
must assign each copy a correlation name so that BI/Query can
correctly execute queries that specify them. (See “Using Tables More
Than Once” on page 108.) When you’re organizing data objects and
creating relationships between them, keep in mind that users can create
queries that specify data objects or actual relationships in the same
design window; they can’t build queries using more than one window.
If you assign the Edit Data Model and Save Data Model permissions,
users can create their own design windows and add, copy, move, edit,
and delete buttons and ornaments. In a split data model, objects and
windows created by the administrator are stored in the administrator
layer; users can’t modify or delete them. Objects and windows created
by a user are stored in the user’s user layer.
To create a design window

You can use the
1 Make sure you have the Edit Data Model and Save Data Model Design Windows
permissions. dialog box to
2 In Design Mode, choose Layout>Windows. rename a window.
Select the window name, type
3 In the Design Windows dialog box, type a name into the text box the new name into the text
at the bottom, then click New. box at the bottom of the dia-
log box, then click Rename.

4 To specify that the window should appear when the data model
opens, select the window name, then click Startup.
5 Click Done.
Loading Tables from the Database

You can load tables into any design window in a data model, and you
can move the resulting data objects, or cut and paste them, from one
window to another. Limiting the number of data objects and grouping
related ones in a design window breaks up the information and
provides a more focused querying environment that’s easier to
understand and faster to use. When you include data objects in multiple
windows, group them appropriately, keeping in mind that users can
create queries that specify data objects in only one window at a time.
The data objects that appear in BI/Query represent the corresponding

tables in the database. Data objects and the attributes they contain
inherit the names of their counterparts in the database. If the database
names aren’t very meaningful to users, rename them. The names you
specify in BI/Query don’t affect the names of the corresponding tables
and columns in the database. (See “Renaming Objects and Attributes”
on page 102.)
In addition to loading tables from the database, you can load any
associated metadata. You can also create new tables (see “Creating

Tables in the Database” on page 114) and restrict access to information
in the database (see “Controlling What Users Can See” on page 131).
To load tables from the database

Provide only the 1 In Design Mode, display a design window.
tables users need
— no more, no 2 Connect to the database. (See “Creating Connection Files” on
less. Unnecessary page 48.)
clutter design windows 3 Choose Host>Load Tables.
ake a data model more
lt to use and maintain. 4 In the Tables text box of the Display Table Names Matching dialog
box (displayed for certain databases), specify a subset of tables from
the DBMS catalog (or system tables). (For example, to specify all
tables starting with the letter C, type C%.)
OR
To display all tables, leave the Tables text box blank.
5 Type the creator (or collection or database) that created the tables
into the Creator text box.
6 Click OK.
7 In the Load Tables dialog box, select the tables you want to load.

8 If you’re loading metadata for the tables and you don’t want to
display names or short descriptions, click Display Names and Short
Descriptions to deselect them.
9 Click Load Tables.
10 When the tables have loaded, click Done.
Simplifying Display Names

BI/Query includes a quick way for the administrator to make the
database names of data objects and attributes in a data model more
understandable. Many database names make perfectly adequate data
model display names if punctuation (typically underscores and periods)
is removed and they use mixed case (upper- and lower-case letters).
Changing data object names automatically changes the corresponding
attribute names.
To simplify database names

1 In Design Mode, choose Design>Simplify Names.
2 In the Simplify Attribute and Object Names dialog box, select the data
object(s) whose names you want to simplify. (To display all the data
objects in the data model, click Data Objects From All Windows.)

3 If you don’t want to remove punctuation or change the names to
mixed case, click those options to deselect them.
4 Click OK.
5 In the BI/Query Admin window, to accept the simplified names
for the first data object and its attributes, click Change. (To accept
the simplified names for all the objects, click Change All.)
Organizing Attributes You can create an

attribute that
Data objects display attributes in the same order as the corresponding organizes groups
tables store columns. If attributes aren’t organized in a logical order, of attributes — for
example, to set off little-used
you can reorder them in the attribute window to make it easier for
attributes from those that are
users to find the ones they need. For example, you can: used often. Choose Design>
Insert Attribute, then type a
• alphabetize them row of asterisks or dashes
• place the most commonly used ones at the top instead of a name.

• group date attributes together
• group address attributes together
• group attributes that return codes at the bottom of the list
To organize attributes
1 In Design Mode, double-click a data object.
2 In the attribute window, choose Design>Reorder Attributes.
3 In the Attribute Order dialog box, specify an organization for the
columns using the First, Last, Up, Down, and Sort buttons.
If a large number
of attributes is dis-
played, start by
using the Unorder
All button to move all the col-
umns under Unordered
Attributes, then use the Move
button to move the attributes
under Ordered Attributes in
the order you want.
4 Click OK.
Creating Relationships between Tables

You can move Data objects require connecting lines between them in order to set up
data objects and the relationships between them. Relationships are necessary for
relationships in a
design window formulating queries using more than one data object. Data models can
and kink the lines that con- contain embedded and actual relationships. Actual relationships can
nect them to accommodate connect two or more data objects, while embedded relationships can
the space available.
connect no more than two.
When you connect data objects, the diamond-shaped icons that

represent relationships are displayed along with the relationship names.
When design windows contain a number of data objects, however, you
may prefer not to display relationship icons or names in order to keep

the window from appearing cluttered. In this case, users see only the
data objects and the lines that connect them. When you have enough
room to display relationship icons and names, they help users
understand how the information in one data object relates to the
information in another.
Relationship icons and their names are displayed by default. If you

don’t want to display them, choose Edit>Preferences, then deselect the
Show Relationships and Show Relationship Names preferences.
(While you can display relationship icons without displaying their
names, it’s not particularly useful to do so.)
Once you’ve created relationships, you need to specify the join

conditions for the corresponding data objects. (See “Creating Join
Conditions” on page 104.)
Embedded Relationships
Connecting two data objects creates an embedded relationship.
To create an embedded relationship

1 In Design Mode, select both data objects, then choose Design>
Connect Objects.
2 If a relationship icon appears between the objects with the default
name Unnamed, name it. (See “Renaming Objects and Attributes”
on page 102.)
Actual Relationships
Certain tables in your database may already contain data that relates to
data in other tables. For example, a database may contain one table with
information about employees, another with information about
committees, and another that relates information about employees and
the committees on which they serve. You can load these tables into a

data model, convert the one containing the related information into an
actual relationship, and connect it to the other two tables. Users can
then retrieve information about employees and committees based on
the committees on which the employees serve.
The relationship between employees and committees can be one-to-

many (in which one employee can serve on several committees) or
many-to-many (in which one employee can serve on several
committees and each committee has several employees). Actual
relationships can relate two or more data objects.
When you create an actual relationship, a shadow appears behind the

icon to indicate that it’s an actual relationship. (You can convert actual
relationships to data objects in the same way.)
To create an actual relationship

1 In Design Mode, load the table containing the related data into the
data model. (See “Loading Tables from the Database” on page 96.)
2 Click a data object, then choose Design>Data Object<>
Relationship.
3 To connect the actual relationship with a data object, select the
relationship and the object, then choose Design>Connect Objects.
Renaming Objects and Attributes

Name data
objects, relation- Data objects and attributes inherit the names of their counterparts in the
ships, and database, and database names often aren’t very meaningful to users. You
attributes as early
can rename objects and attributes to make them more meaningful (for
in the design process as possi-
ble; don’t use placeholder example, by changing the database name mjr_accnts to Major Accounts).
names, then replace them By doing so, you improve users’ ability to use the data model and
with real names later. Chang- understand what information they’re retrieving. (You can also rename
ing names after you create
queries may invalidate the
data objects and attributes in order to simplify their database names. See
queries. “Simplifying Display Names” on page 98.)

If the Show Relationships and Show Relationship Names preferences
are set, you can also name relationships to help users understand how
the information in one data object relates to the information in another.
Names can contain spaces and other punctuation characters not allowed Attribute names
in the SQL string for a query. All data objects and relationships must become column
headings in
have names, and their names must be unique. (If you provide the same
reports. If names
data object more than once and no satisfactory names come to mind, are understandable, users
simply number them — for example, Employee1 and Employee2.) won’t need to edit them each
Objects with the same names can cause ambiguity and errors when time they generate a report.
And if the values returned by
users attempt to load stored queries.
an attribute are short, use a
short attribute name so users
Names you apply to data objects, actual relationships, and attributes
don’t need to shorten it.
don’t affect the names of the corresponding tables or columns in the
database. When users formulate queries, BI/Query automatically
converts to the underlying database names when it generates the
corresponding SQL string.
Data Objects and Relationships

Use a brief verb phrase to describe how two data objects are related so
that the first data object, the relationship, and the second data object
can be read as a sentence (such as Employee, Works In, Department).
To rename a data object or relationship

1 In Design Mode, double-click the name of a data object.
OR
Make sure the Show Relationships and Show Relationship Names
preferences are set, then click a relationship.
2 In the Edit Object Name dialog box, type the name of the object.
3 Click OK.

Attributes
Provide attribute names that are meaningful to users. For example,
instead of retailers.cust_num, use Retailer Number.
To rename an attribute
1 In Design Mode, double-click a data object.
2 In the attribute window, click an attribute.
3 In the Edit Attribute dialog box, type a new name into the Name
text box.
4 Click OK.
Creating Join Conditions

Once you’ve connected data objects and relationships, the next step is
to create join conditions. A join condition associates two data objects that
contain related data. It includes the attributes’ database names (not the
names used in the data model) and an operator that identifies the
relationship between them. When a user formulates a query using
related tables, the DBMS finds all possible combinations of data from all
tables, then eliminates the data that doesn’t satisfy the join conditions.
Join conditions allow users to include attributes from both data objects
(and if the data objects are related by an actual relationship, the actual
relationship as well) in a query. For example, if you join Employee ID
of the Employee data object with Employee ID of the Serves On data
object, and the Committee Name of Serves On with the Committee
Name of the Committee data object, BI/Query can determine which
employee serves on which committee.

Embedded relationships require a minimum of one set of join
conditions to join the data objects they connect. Actual relationships
require a join condition for each connecting line in the relationship.
The attributes you choose should represent the same or similar data in
each table. (If you’ve selected attributes to be joined that have different
data types, a warning appears. If the data types are similar, such as
varchar and char, you can override the message.) For example, you might
provide a relationship between the Retailers and Sales data objects,
specifying an equal join on the retailer number in each table so that
users can retrieve information about retailers who have placed sales.
If your DBMS supports outer join syntax, users can specify an outer
join in a join condition. If your DBMS or middleware doesn’t support
outer joins, users can perform an outer join within BI/Query by
joining results sets. (See “Joining One Column to Another” on
page 386.) They can also create a super query that submits multiple
queries and performs the outer join automatically. The result is a query
that retrieves the same results as if the underlying database supported
the outer join. (See “Saving Standard Queries” on page 307.)
To create a join condition

1 For an embedded relationship, in Design Mode, click the
connecting line, then choose Design>Join Conditions.
OR
For an actual relationship, in Design Mode, click the relationship
icon or a connecting line, then choose Design>Join Conditions.
2 In the Join Conditions dialog box, click an attribute in the list on
the left, then click Add.

3 Click a related attribute in the list on the right, then click Add.
4 To change the operator, select one from the operator list.
5 To change an attribute name, click the attribute in the join
condition, then click Edit and type a new attribute name.
6 Click OK.
That Include a Prompt or Variable

You can include a prompt in a join condition to force users to qualify any
query that specifies the related data objects. For tables that contain a large
number of rows, prompts can improve query performance and protect
users from submitting queries that retrieve more data than they need.
You can also include a variable in a join condition to allow users to

qualify a query dynamically. Using a variable in a query rather than a
specific attribute gives more flexibility. For example, your database may
be updated regularly to reflect current sales; including a variable for
current month into a join condition allows users to obtain sales figures at
any time during the month.
To create a join condition that includes a prompt or variable

1 In the Join Conditions dialog box, add the attribute to which the
prompt will be joined.
2 Click in the opposite column where you want to add the second
attribute, then click Edit.

3 In the Edit Join Condition dialog box, to insert a prompt, click
Insert Prompt, then use the Prompts dialog box to select and insert
a prompt. (To insert a variable, click Insert Variable, then use the
Variables dialog box to select and insert a variable.)
4 Click OK.
5 In the Join Conditions dialog box, click OK.

Using Tables More Than Once
There are cases where it’s necessary to create a copy of a data object in
a design window to allow users to formulate certain types of queries
that wouldn’t otherwise be possible — queries in which the data object
has two roles. For example, suppose a design window contains a data
object for the Employee table and another for the Department table. By
including the Employee and Department data objects in a query, users
can retrieve a list of the names of employees and the departments they
work in.
Employee Name Department Name
Anastasi Human Resources
Bening Human Resources
Bradley Human Resources
Czeckov Sales
O’Brian Sales
Smythe Sales
Soonie Sales
Trussault Sales
Users may also need to find out information about employees who
manage a particular department. In this case, you can copy the
Employee data object and create a second relationship with the
Department data object that allows users to retrieve that information.
Data objects must have unique names in order for BI/Query to
correctly execute queries that specify them, so you need to change the
name of the copy — for example, to Manager — to reflect the new
relationship with the Department data object. By including Manager
and Department in a query, users can retrieve a list of the names of
employees and the departments they manage.

Manager Name Department Name
Bening Human Resources
Czeckov Sales
If you want users to be able to use both objects in a single query, you
need to specify one or more correlation names. (See “Specifying
Correlation Names” on page 109.) By including the Employee,
Department, and Manager data objects in a query, users can retrieve the
names of managers and the departments and employees they manage.
Manager Department Employee
Bening Human Resources Anastasi
Bradley
Czeckov Sales O’Brian
Smythe
Soonie
Trussault
To use tables more than once

1 Copy a data object and give it a unique name. (See “Renaming
Objects and Attributes” on page 102.)
2 Create a relationship between it and another data object. (See
“Creating Relationships between Tables” on page 100.)
3 Specify a correlation name for the original object, the copy, or
both. (See “Specifying Correlation Names” on page 109.)
Specifying Correlation Names

If you’ve created data objects in a design window from the same table
in the database and joined them, you need to give one or both of them

In case you allow a correlation name. A correlation name (or alias in SQL terminology)
users to create allows BI/Query to distinguish the roles of the two data objects in a
dynamic relation-
query. For example, if BI/Query uses one data object to retrieve
ships at a later
date, where these two tables information about employees who belong to a department and another
might be joined, it’s good to find information about employees who manage a department, it
practice to create correlation requires a correlation name to process the query. Some databases
names right away.
require a correlation name for both the original object and the
duplicate; others require one for the duplicate. It’s good practice to
assign them both.
When you create a correlation name, BI/Query preserves the database

name in order to generate valid queries. You can specify any
correlation name — even the same name as the data object — as long as
it isn’t the same as the correlation name for another data object in the
same design window and there are no spaces in the name.
To specify a correlation name for a data object

1 In Design Mode, click a data object, then choose Design>Name in
Database.
2 In the Edit DB Name dialog box, type a correlation name into the
Correlation Name text box.
3 Click OK.

Merging Data Objects
When a design window contains many data objects, you can simplify it You can unmerge
by merging, or consolidating, certain objects. When you merge an a data object that’s
been previously
object into another object, the attributes from the first object are added merged. (For
to the second, and the first object is removed from the design window. more information, see the
Merging allows you to group related attributes together, even when online Help.)
they’re stored in different database tables.
Before merging, the design window After merging Retailer Phones into
contains the related data objects Retailers, Retailer Phones is removed
Retailers and Retailer Phones. from the design window, and its
attributes are added to Retailers.
You can merge data objects only when there’s a relationship between
them and the relationship has a join condition assigned to it. (You can’t
merge actual relationships.) The join condition remains associated with
the object that’s been merged and is applied when a user builds a query
that uses an attribute from the object. For example, in the data model
shown above, after Retailer Phones is merged into Retailers, the join
condition remains associated with Retailer Phones and is applied when
a user selects an attribute from Retailers that was in Retailer Phones.
Merging data objects is useful when the benefit — a design window

with fewer data objects — outweighs the complexity of the resulting
objects. For example, if a data object is used often but contains only
two attributes, and a related object contains 20 attributes, adding the
two attributes of the smaller object to those of the larger one will create
an object with 22 attributes — not appreciably larger or more complex
than the original. If, however, you merge two objects into a third
object, and the final object has 50 attributes, it may be too large, and its
relationships too complex, for your users to use easily.

When you want to merge data objects, it’s good practice to identify the
object that’s most important from a user’s perspective, then merge
other objects into it so that users can easily find the attributes they need.
Consider merging objects in the following instances:
Merge Objects When Example
Using BI/Query One of the data objects Retailer names, addresses, and phone
to update tables in isn’t used very often or numbers might be contained in three
the database also doesn’t contain many separate data objects, each containing a
plays a role in attributes. few attributes. Merging Retailer Phones
determining which objects to
and Retailer Addresses into Retailers
merge. If some tables are often
updated, they shouldn’t be
creates an object that is small enough for
merged. users to work with.
The data objects contain Information on regional offices and

related information, and regions might be contained in two
it would be logical for separate objects. You can merge
users to look for that Regional Offices into Regions because
information in the it would be logical for users to look for
merged object. information about regional offices in the
Regions object.
The data objects contain Information on employees might be

some of the same contained in two objects — one
information, and containing general information on all
merging them would employees, the other information on
create one object that some employees’ management
contains complete experience. Merging the second object
information. into the first results in one object that
contains complete employee information.
When designing a
data model, you Once you’ve merged a data object, you can merge other objects into it,
can facilitate but you can’t merge it into another. For example, you can merge
merging by plac-
ing the largest data objects on Retailer Phones into Retailers, then merge Retailer Addresses into
the inside of a set of objects Retailers, but you can’t merge Retailers into Staff.
and relationships; those
objects have the greatest num- If you merge one data object into another when there’s more than one
ber of connections to other relationship between them or when the first object has a relationship
objects. Place the smallest
with a third, the relationships are lost. A useful guideline is to merge
objects on the outside.

“outside objects in” because outside objects (those on the perimeter of
the data model) don’t generally have connections to other objects.
To merge one data object into another

1 In Design Mode, click a data object.
2 Choose Design>Merge Data Object.
3 In the Object to Merge Into dialog box, click an object.
4 Click OK.
5 If a warning appears, click Yes to continue merging and delete the
connections to other objects.
OR
Click No to cancel the merge.
Editing Join Conditions

When you build a query that uses attributes from a data object that’s
been merged, that object’s join conditions are applied. If you want to
change the way BI/Query restricts the results returned from the
database, you can edit the object’s join conditions. The more join
conditions you use, the more restricted the results. (For more
information on join conditions, see “Creating Join Conditions” on
page 104.)
To edit join conditions

1 Click a merged object, then choose Design>Merge Joins.
2 In the Choose Merged Table dialog box, select an object.

3 Click OK.
4 In the Join Conditions dialog box, edit the join conditions.
5 Click OK.
Creating Tables in the Database

Most of the time, the tables you need already exist in the database.
Occasionally, however, it may be necessary to create new tables that
users can query. You can create a table from existing information in the
database by submitting a query that retrieves that information, then
creating a table from the results. You can also create a table from
scratch by creating data object and attributes in BI/Query, then
creating the corresponding table.
Once you’ve created the tables you want, make sure that users have the
appropriate database permissions to use them.

From Query Results
Any query that retrieves information from a number of tables takes
time because it uses multiple joins. Summarizing the information in
one table eliminates the joins and reduces the number of rows that the
DBMS has to process. This gives users faster access to the information
and reduces the load on the database server. For example, instead of
querying the Retailers and Sales tables each time they need to retrieve
information about a retailers’ monthly sales, users can query a table that
contains retailers’ sales summarized by month.
This works particularly well when users need to analyze information

that doesn’t change regularly. For example, by creating a table that
summarizes sales for a particular year, users can query the table and
perform calculations on the results without the values changing and
becoming out of date. BI/Query creates the table in the database as
well as the corresponding data object in the data model.
Users can create their own tables in the database if they’ve been granted
the appropriate database permissions and have the Edit Data Model,
Save Data Model, and Submit to Table permissions. Having the Submit
to Named Table permission also allows users to name the new table and
the corresponding data object. (See “Creating New Tables” on
page 150.)
To create a table from query results

1 Formulate a query that retrieves the information you want the table
to include.
2 Choose Query>Submit Query — To Table.
3 In the Temporary Data Object dialog box, type a name for the new
table, then click OK.

From Data Objects
If the data you need for a table doesn’t already exist in the database, you
can create the table from scratch in BI/Query. For example, you may
find it useful to create a table that provides a list of codes and their
descriptions so that users can find the meaning of a code. Or you can
create a table that contains descriptions for all attributes in the data
model. (See “Creating Attribute Descriptions” on page 190.)
You can create the table in three basic steps:
• create a data object with the appropriate attributes

• create the table in the database
• populate the table with the data you want it to store
Once you’ve created the data objects and attributes you want, check
the data model design and fix any problems before creating the
corresponding tables in the database. (See “Checking the Design” on
page 124.) You can create the tables directly in the database or create a
script containing SQL-creation commands, then send the script to the
DBMS, where the commands are executed and the new tables created.
If you create a script, you can modify it to include additional SQL
commands that you want to be executed when the tables are created.
To create a data object

2 In the Connections dialog box, specify the DBMS you’re using.
(This establishes the data types of the attributes you create.)
3 In a design window, make sure you’re in Design Mode.
Data Object tool 4 Click the Data Object tool, then click in the window where you
want the object to appear.
5 Double-click Unnamed.
6 In the Edit Object Name dialog box, type the name of the object.

7 Click OK.
8 To add an attribute to the data object, double-click it.
9 In the Insert Attribute dialog box, specify a name and data type.
10 Click Insert.
Directly in the Database

Once you’ve created a data object, you can create the corresponding
table directly in the database.
To create a table directly in the database

1 Connect to the DBMS.
2 In a design window, choose Host>Create DB Tables.
3 In the Tables text box of the Display Table Names Matching dialog
box (displayed for certain databases), specify a subset of tables from
the DBMS catalog (or system tables). (For example, to specify all
tables starting with the letter C, type C%.)
OR
To display all tables, leave the Tables text box blank.
4 Type the creator (or collection or database) that created the tables
into the Creator text box.
5 Click OK.

6 In the Create DB Tables dialog box, select a data object in the Data
Model list.
Lists the data objects and actual Lists existing tables in

relationships in the data model the database
7 Click Create.
8 When the table is created, click Done.
Using an SQL Script

You can create a script file in BI/Query that contains the appropriate
SQL commands to create a table for all data objects in the data model.
BI/Query sends the file to the DBMS, where the SQL commands are
executed and the corresponding tables are created.
For the Retailers data object with the Retailer # and Name attributes,
the SQL statement that BI/Query generates to create the table in the
database might look like this:
create table Retailers (Retailer # char(12), Name

char(8));
Using any text editor, you can modify the script to include additional
SQL syntax. For example, you can specify a segment (Sybase),
tablespace (Oracle), location (Ingres), or database (DB2) that’s different

from the default by appending the appropriate SQL command. To
include a tablespace called XXX, for example, the SQL statement
becomes:
create table Retailers (Retailer # char(12), Name

char(8)) in tablespace XXX;
Similarly, you can include a prefix for the table name. Some databases
require this information to identify the owner or creator name (Oracle)
or database name (Teradata). If you add mydatabase. as the prefix for the
table, for example, the SQL statement becomes:
create table mydatabase.Retailers (Retailer #

char(12), Name char(8));
To create a table using an SQL script

1 To create the script, in BI/Query Admin, choose Host>Create DB
Script.
2 If a message appears to say that there are errors in the data model
design, click Cancel, then correct the errors. (See “Checking the
Design” on page 124.)
OR
Click OK.
3 In the Save Script File dialog box, specify the name and location of
the script.

4 Click Save.
5 In a text editor, modify the script to include the SQL you want.
6 To send the script, in BI/Query Admin, connect to the DBMS.
7 Choose Host>Send SQL Script.
8 In the Open Script File dialog box, select a script file.
9 Click Open.
Reloading the Table

When you create a table using BI/Query, the DBMS may adjust the
data types of attributes to whatever is most appropriate for the DBMS.
To ensure that BI/Query has an accurate representation of the table,
it’s good practice to delete the corresponding data object from the data
model, then load the table to recreate the data object. (See “Loading
Tables from the Database” on page 96.)
Populating the Table

Once the table is created, you can populate it using BI/Query Admin,
BI/Query Update, or any other tool that allows you to insert records
into a table. (See “Applying Updates to the Database” on page 400.)

Assigning Permissions
You can assign permissions for a data model to allow users to carry out You can be in
certain activities in BI/Query User and BI/Query Update while Design Mode or
not in order to
preventing them from carrying out others. (At the same time, you can
assign permissions
check certain information about a data model, such as a user’s password and preferences.
and information that’s been stored in the database.) Users can’t change
the permissions you assign.
When you create a data model, BI/Query assigns default permissions

based on the permissions you set for the previous data model. When
you use BI/Query Admin, you aren’t restricted by the following
permissions (even if they’ve been assigned):
• Edit Data Model

• Save Data Model
• Edit Queries
• Save Queries
• Dynamic Relationships
• Submit to Named Table
• Send SQL Scripts
• Update Database
• Allow Non-select SQL
• Computed Attributes
Some activities also require other setup options as well as certain

database permissions. Information on assigning permissions is provided
in this guide where the corresponding activities are described. (See also
“Controlling What Users Can Do” on page 142.)
To assign permissions
2 In the Permissions dialog box, assign the permissions you want.

3 Click OK.
Assigning Default Settings

You can assign users’ default settings for a data model. When you set
preferences for a new data model, BI/Query uses the preferences you
set for the previous data model. Users can change these preferences in
BI/Query User and BI/Query Update. Preference settings take effect
immediately. They don’t affect previous work or saved files. For
example, if users change their results options, the new settings apply to
new results, not to saved results files or results just retrieved from a
query. Information on assigning preferences and other default settings is
provided in this guide where the corresponding activities are described.
To assign default settings

2 In the Preferences dialog box, assign the preferences you want.

3 Click OK.
Setting Data Model Passwords

Data models can be password-protected to prevent unauthorized users If a user forgets a
from using or making changes to them. When you open a data model password, you can
check it in
with BI/Query Admin, it checks to see whether an administrator
BI/Query Admin.
password has been set. When a user opens a data model with BI/Query Choose Edit>Permissions,
User or BI/Query Update, it checks to see whether a user password has then click Show User Pass-
been set. If it has, BI/Query prompts for it and doesn’t open the file word. (If you’re using a split
data model, open the user’s
until the correct password is entered. user-layer file.) There’s no
similar “escape hatch” for
Administrator and user passwords are independent of each other. In a administrators who forget
split data model, the administrator password is stored in the their own passwords; in this
administrator-layer file; the user password is stored in the user-layer file. case, call Technical Support.
Only BI/Query Admin checks for an administrator password.
Similarly, only BI/Query User and BI/Query Update check for a user
password. In all cases, passwords are stored in encrypted format.

While you can also use BI/Query Admin to set a user password, it’s
recommended only for combined data models. It’s not recommended
for split data models because opening a user-layer file with BI/Query
Admin would absorb all the user’s customizations into the
administrator-layer file.
To set a data model password

It’s easy to change 1 To set an administrator password, in BI/Query Admin, choose
your password. Edit>Permissions. In the Permissions dialog box, click Set
Type your cur- Administrator Password.
rent password into
the Old Password text box, OR
then type your new password To set a user password, in BI/Query User or BI/Query Update,
into the New Password and choose Edit>Preferences. In the Preferences dialog box, click Set
Verify Password text boxes.
User Password. (For a combined data model, use BI/Query
Admin.)
2 In the Set Password dialog box, type a password into the New
Password text box.
3 Type the password into the Verify Password text box.

4 Click OK.
5 In the Permissions or Preferences dialog box, click OK.
Checking the Design

Before distributing a data model, be sure to check the design for
consistency and completeness. You can check the design once you’ve
completed the data model or at any stage while you’re creating it.
If there are no errors in the data model design or warnings associated

with it, BI/Query displays a message to that effect. If there are errors or

associated warnings, BI/Query displays them. Correct any problems,
then check the design again to make sure you’ve corrected all the
errors.
To check the data model design

1 In Design Mode, choose Design>Check Design.
2 In the Check Design dialog box, specify the design checks you
want (or click Select All), then click OK.
3 Correct any design errors.

4 Check the design again to make sure you’ve corrected all the errors.
Saving the Data Model

You can save a data model as a split data model or a combined data When you save a
model. A split data model is recommended for organizations that allow data model, make
sure you’re no
users to make changes to the data model. It’s stored as two files — an longer in Design
administrator-layer file and a user-layer file — to allow users to retain Mode; otherwise, users have
their customizations when a new version of the data model is to switch out of it to build
distributed. A combined data model consists of one file and is designed their queries.
for sites where users aren’t allowed to make changes. (You can, of
course, prevent users from changing the data model by not assigning
related permissions.) (For more information on data model types, see
“Types of Data Models” on page 24.)
You can begin by creating a combined data model, then split it later.
Similarly, you can change a split data model to a combined data model

at any time. You can remove or assign the Save Split Data Model
permission whenever it suits your needs.
As a Split Data Model

When you save a split data model, it’s split into two layers — an
administrator-layer file with the extension .gqa and a user-layer file with
the extension .gqu. BI/Query also creates the Queries and DataVals
folders if they don’t already exist. (If you saved queries or data values
files before saving the data model, BI/Query already created the
folders.) The user-layer file is an empty shell that contains only the path
to the administrator layer and a few default settings, such as preferences.
Be sure to keep a copy of the empty user-layer file; you’ll need it to
make revisions to the data model.
Distribute the administrator-layer file, its Queries and Datavals folders,

and a copy of the user-layer file to all users. (See “Distributing a Data
Model” on page 211.)
Understanding a Split Data Model

• The first time you save a split data model, BI/Query Admin saves
the data model in two layers: as an administrator-layer file with the
extension .gqa and an empty user-layer file with the extension .gqu.
It also creates the Queries and DataVals folders.
• Keep a copy of the empty user-layer file; you’ll need it later to
revise the data model.
• Because the user-layer file contains the path to the administrator
layer, opening a split data model requires opening the user layer.
BI/Query combines the contents of the user-layer file (buttons,
ornaments, and so on) with the administrator-layer file.
• If the user-layer file is stored in a separate folder than the
administrator layer, BI/Query creates empty Queries and DataVals
folders the first time the user-layer file is opened.
• When you want to incorporate a user’s customizations into the
administrator layer, open a copy of the user’s user-layer file with
BI/Query Admin.

• Storing the administrator and user layers in separate folders is the
best way to maintain separate administrator and user prompts,
variables, queries, and data values files. (BI/Query Admin saves
these files in the administrator layer; BI/Query User and BI/Query
Update save them in the user layer.)
• Storing a data model in the database is an efficient means of
distributing revisions to the administrator layer. Any reports created
using BI/Query Reports and stored with the data model in the
Reports folder can also be stored in the database. (See “Using the
To save a data model as a split data model

2 In the Permissions dialog box, assign the Save Split Data Model
permission, then click OK.
3 Choose File>Save.
4 In the Save Data Model dialog box, specify the name and location
of the data model, then click Save.
As a Combined Data Model

Saving a combined data model saves the data model as one file with the
extension .gql and creates the Queries and DataVals folders.
To save a data model as a combined data model

2 In the Permissions dialog box, make sure that the Save Split Data
Model permission isn’t assigned, then click OK.
3 Choose File>Save.
4 In the Save Data Model dialog box, specify the name and location
of the data model, then click Save.

Controlling User Access
Controlling What Users Can See 131 Performing Special Operations 148
Within the Data Model 131 Connecting to the DBMS 148
Securing Access to Tables 132 Saving Passwords in Connection Files 148
Securing Access to Columns in a Table 132 Connecting While Submitting Queries 149
Securing Access to Rows in a Column 133 Making Changes to the Database 149
Securing Access to Data Values 135 Updating Data 149
Using the BI/Broker Repository 137 Creating New Tables 150
Users and Groups 137
Understanding Inheritance 138
Controlling Access Item by Item 139
Controlling Access by User and Group 141
Controlling What Users Can Do 142
Assigning System Permissions 142
Setting BI/Query Preferences 144
Making Changes to a Data Model 145
Modifying Queries 145
Managing the Network Load 146
Performing Calculations with Queries 146
Saving Queries 147
Creating Relationships between Data Objects 147
Controlling User Access
The administrator faces the challenge of making business-critical
information readily available to users without compromising database
security, integrity, and performance. BI/Query provides the tools the
administrator needs to tailor the data access environment to the exact
needs of the user community and, where those needs require advanced
data access, their computer skills. The administrator controls what
information users access and which activities they carry out.
If the data access environment includes BI/Broker, the administrator

gains another layer of control over user access to data models and
queries using the BI/Broker Repository. (See “Securing and
Distributing Information” on page 31).
Controlling What Users Can See

A typical database contains hundreds of tables. Users don’t need access
to all the tables or all the information in each table. And in certain cases,
only authorized users should have access to certain information. For
example, you may give sales departments access to your organization’s
sales information but not its accounting information. Similarly, you
may give regional sales managers access to their own regional sales
figures but not the sales figures of other regions.
Within the Data Model

You can ensure that information in the database is accessible only to the
users who need to see it. Depending on the database and the security
system your organization is using, you can set up different levels of
restricted access. In some cases, you can restrict access at the table level,
allowing users access to some of the information in a table or none of it.
In other cases, you can restrict access to specific values in a table. Access

to tables can be restricted by the database administrator at the database
level or by the administrator in the data model.
You can include a table in a data model for which some users have
access at the database level and others don’t. If a user doesn’t have
access and attempts to include the table in a query, the database
disallows it.
Securing Access to Tables
You can provide Before creating a data model, you need to determine what tables users
additional tables need to access and which ones they’re allowed (or not allowed) to see.
by loading them
Depending on the number of user groups and their specific information
from the database.
You can prevent users from needs, you may need to create more than one data model. When
accessing tables by removing different users or user groups share certain tables in the database, you
the corresponding data objects can start by loading them (see “Loading Tables from the Database” on
or actual relationships from
the data model; in Design
page 96), then add or remove tables as needed.
Mode, click an object, then
choose Edit>Cut.
Securing Access to Columns in a Table
Display only the Certain information in a table may be useful to some users and not
attributes users others. You can prevent users from seeing columns they don’t need by
need so they don’t
hiding the corresponding attributes in BI/Query. You hide attributes
have to spend time
searching for them. Hide sys- by turning off the corresponding Visible toggle in the attribute window
tem-generated primary and in Design Mode. Attributes are hidden in BI/Query User and
foreign keys. BI/Query Update but remain visible in BI/Query Admin in Design
Mode and are moved to the bottom of the list.
You can also remove attributes from a data model, but hiding them
makes the data model easier to maintain. For example, BI/Query
allows you to refresh the data model to reflect changes such as additions
and deletions of attributes in the database. If you remove an attribute
from a data model and subsequently refresh the model, BI/Query sees
that the attribute you removed from the data model exists in the
database and prompts you to add it. By hiding an attribute instead of
deleting it, you can avoid having BI/Query indicate that the attribute
132 Controlling User Access

exists each time you refresh tables. If you later need to give users access
to the hidden attribute, you can simply make it visible.
To secure access to columns in a table

1 In Design Mode, double-click a data object or actual relationship.
2 In the attribute window, to remove an attribute, click the attribute
line, then choose Edit>Clear.
3 To hide an attribute, turn off the Visible toggle.
Securing Access to Rows in a Column

Once you’ve loaded the tables you want, you can qualify the
corresponding data objects and actual relationships to restrict users’
queries to specific information in a table. In other words, you can place
restrictions on queries on an individual table. (This facility is called an
object qualifier.) For example, you can restrict queries on the Retailers
table to retailers in one or more countries.
You can also include prompts and variables in an object qualifier to

force users to qualify any query that uses the data object. For example,
you can ensure that BI/Query prompts users to specify a country when
they use the table in a query. You can also include a variable that
determines which retailers were active during a particular time period,
such as the last quarter.
Qualifying tables isn’t just a way of preventing users from seeing certain
information. For tables that contain a large number of rows, it’s also a
way of improving query performance and protecting users from
submitting queries that retrieve more data than they need. For example,
regional sales managers may need sales information only for countries in
their region. If access was unrestricted, their queries would retrieve data
for all countries.
Any object qualifiers you create are combined with users’ qualifications
when they formulate queries, so be sure to test object qualifiers before
distributing them with the data model. Users can’t modify the object
qualifiers you create unless you assign the Edit Query permission.

To secure access to rows in a column
1 In Design Mode, click a data object or actual relationship, then
choose Design>Object Qualifier.
2 If the Choose Merged Table dialog box appears, select a table
name, then click OK.
3 In the Object Qualifiers dialog box, click New.
4 In the Edit Table Qualifier dialog box, in the Qualifier ID text box,
type a name that will identify the qualifier when you’re assigning
access to the data model.
5 In the Qualification String text box, specify the database name of

the attribute to which you want to restrict access. (Type it or click
Insert DB Name, then use the Insert DB Name dialog box to select
and insert it.)
6 Type an operator (for example, IN, =, >, <), then type a space.

7 To restrict queries to specific values in the table, specify the values
you want. (Type them or click Insert DB Name, then use the Insert
DB Name dialog box to select them. Enclose them in parentheses,
and separate each one with single quotation marks and a comma.)
The Retailers data object is qualified to restrict queries to retailers in Canada,

Mexico, and the United States.
8 To include a prompt or variable in the qualifier, type it or click Insert You can include
Prompt or Insert Variable, then use the Prompts or Variables dialog more than one
box to select it. prompt, or more
than one variable,
by separating them with the
plus sign (+).
The Retailers data object is qualified with a prompt. When users submit a query
using this table, they’re prompted to specify one or more countries to restrict the
results to retailers in those countries.
9 Click OK.
Securing Access to Data Values

Data values are all the values in the database for an attribute. The data
values for the Country attribute, for example, might include France,

Germany, Spain, and so on. When users formulate queries, they can
qualify an attribute with one or more data values in order to retrieve
results that correspond only to those values. For example, they can
retrieve information about retailers located in Canada and USA by
qualifying a query with the data values for those countries.
When users qualify an attribute, they can select from a list of data values
stored in the database. By default, BI/Query queries the database for all
the values for the attribute and displays the list in the Data Values dialog
box. However, you can disable access to the default query. Disabling
access is recommended when loading all the values in the database uses
unnecessary network resources — for example, when an attribute has a
large number of values or when the values are just numbers and dates.
Even if you disable access to the default query, you and your users can
provide access to a subset of values by creating data values files. For
example, rather than displaying a list of all the countries in the database
(in Europe, North America, Asia, and so on), users may simply need a
list of countries in Europe. (See “Using Data Values, Prompts, and
Variables” on page 257.)
To secure access to specific values

1 In Design Mode, double-click a data object or actual relationship.
2 In the attribute window, click the Data Values box for an attribute
to deny or allow access, respectively.
Access to data values is denied for Product # and allowed for Product Name and
Product Category.
3 Close the attribute window.

Using the BI/Broker Repository
If you have access to the BI/Broker Repository, you may be able to
postpone your concerns about security until after you have created the
data model. You may find you need build only one data model for the
whole organization. You can secure the data model as a whole, any of
its folders (including the DataVals folder), and any of its design
windows, data objects, relationships, and attributes, as well as its queries
and reports.
For example, you want to give the sales department access to your
organization’s sales information but not its accounting information.
Likewise, the accounting department is to have access to accounting
information, but not be inundated with sales information. You build
one data model containing two data objects, one for sales information
and one for accounting information. You don’t restrict either data
object in any way.
When you’re ready to publish the data model to the repository (see
“Using the BI/Broker Repository” on page 215), you set security for
the sales department, granting access to the sales information data
object, denying access to the accounting information data object. Next,
you set security for the accounting department on the same data model
by granting access to the accounting information data object and
denying access to the sales information data object. Perhaps you’ll set
security as well for top administrators, by granting access to both data
objects. The same data model can be secured in as many different ways
as there are users and groups that need to access it.
Users and Groups

You control access to a data model in the repository by means of a
hierarchical structure representing the users and groups within your
organization. This user and group structure is implemented by the
BI/Broker administrator. (For information on how to design and
implement such a structure, see “Designing a User and Group
Hierarchy” on page 59 of the BI/Broker administrator’s guide.)

Administrators and users with the necessary publishing permissions can
decide who has access to the models they publish. You can set security
for a model and its parts when you first publish it, but you can also later
retrieve the model from the repository and change the security settings.
You assign access privileges to data models directly from BI/Query.
Understanding Inheritance
To set security, you work your way down through the hierarchy of
users and groups. At the top level, you determine for each group
whether its members are to be granted or denied access to the model.
When you set security for a group, members of that group (users or
other groups) inherit the setting unless you decide to make an
exception. The Everyone group, however, can’t be set to inherit; it
must be explicitly granted or denied.
For example, you publish a Sales Model and grant the Sales Team
access to it. A green light in front of a the Sales Team group indicates
that you’ve specifically granted access for that group. Green check
marks indicate that all members of the Sales Team group have inherited
that access.
You can override inherited security settings for any user or group by
setting security specifically for that user or group. For example, it turns
out that Focus Group 3, which is a member of the Sales Team, should
not have access to the Sales Model. You can set its security individually
and deny the group access to the report. A red stop sign indicates that
you’ve specifically denied access to Focus Group 3. A red “x” indicates
that Rabindrinath O’Grady and Rene Sanchez have inherited the
denied access.

When you specifically grant or deny access for a user or group, the
setting continues to apply to that user or group when you make it a
member of other groups, no matter where in the hierarchy that may
happen. The user or group no longer inherits its security setting from
any group. If you later want such a user or group to inherit its setting,
however, you can set it to inherit.
When a user or group inherits its security setting, there is a possibility

of conflict. A user or group can be a member of one group that is
granted access as well as of another group that is denied access. The
conflict is always resolved so that the user or group is granted access.
For example, although members of the Sales Team group inherit access
to the Sales Report, you specifically denied that access to members of
Focus Group 3. If Rabindrinath is a member of the Sales Team group You’ll know that
as well as of Focus Group 3, the conflict is resolved so that he’s granted you have permis-
sion to secure data
access by inheritance from the Sales Team group. models that you
publish to the repository if Set
Security is available on your
Controlling Access Item by Item Edit menu.
You can set access on a model by model, or model part by model part
basis, selecting a specific item to secure and then specifying which
groups and users are granted or denied access to it.

To control access item by item
1 In a data model, choose Edit>Set Security.
2 From the list of Data Models in the Set By Item page of the Set
Security dialog, select the data model or the part of the data model
you want to secure.
Access to the Model1.gql data model has been granted to the Focus Group. Both
members of the group have access, Pierre Sanchez by inheritance, Rabindrinath
O’Grady by specific grant.
At the data model 3 In the Users and Groups list, select each user and/or group for
level, the Every- which you want to control access, then click Grant, Deny, or
one list is denied Inherit.
access by default.
You can specifically grant or
4 Repeat step 3 until you have set the access for all the users and
deny access to the Everyone groups you want.
list, but you can’t set the 5 Click OK.
Everyone list to inherit.
6 Choose File>Publish to publish the model, with your security
settings, to the server.

Controlling Access by User and Group
You can also set access group by group or user by user, selecting a
group or user and then specifying which models or parts of models that
group or user is granted or denied access to.
To control access item by item

1 In a data model, choose Edit>Set Security.
2 In the Control Access window, click Set by User or Group.
3 From the list of users and groups, select those for which you want
to control access.
4 From the list of items, select a data model or part of a data model,
then click Grant, Deny, or Inherit.
5 Repeat step 3 until you have set the access for all items you want.
6 Click OK.
7 Choose File>Publish to publish the model, with your security
settings, to the server.

Controlling What Users Can Do
The administrator can customize the level of database activity and
BI/Query capability to reflect the skills and needs of various users.
Novice users with limited knowledge of the database may need simple,
predefined access. Advanced users who know how to create
sophisticated queries and understand complex data access strategies may
need the freedom to specify their own SQL in a query, for example, or
create their own joins between tables.
If your data access environment includes BI/Broker, system permissions

determine who can make use of the BI/Broker Repository and to what
extent.
Assigning System Permissions

BI/Broker administrators and users must have appropriate system
permissions in order to use the repository to distribute and secure data
models. Typically, system permissions are assigned by the BI/Broker
administrator. In some data access environments, BI/Query
administrators may also have the ability to assign system permissions.
Information on system permissions is available in the BI/Broker
administrator’s guide.
Assigning BI/Query Permissions

The administrator can assign permissions for a data model to allow users
to carry out certain activities in BI/Query User and BI/Query Update
while preventing them from carrying out others. Users can’t change the
permissions they’re assigned. BI/Query permissions don’t override
DBMS permissions. (For certain activities, you need to provide other
setup options, and users need certain database permissions.)
To assign permissions
2 In the Permissions dialog box, assign the permissions you want.

Suggested permissions for novice users.
Suggested permissions for advanced users.

3 Click OK.
Setting BI/Query Preferences

If you don’t assign certain permissions, and depending on how much
flexibility you want your users to have, you can set the corresponding
preferences. Keep in mind that users can’t change their permissions, but
they can change their preferences.
To set preferences
2 In the Preferences dialog box, set the preferences you want.
3 Click OK.

Making Changes to a Data Model
For sites that allow users to add their own customizations to a data
model, it’s good practice to use a split data model. It stores the data
model in two layers — an administrator layer and a user layer— and
allows you to distribute a new version of the data model without
affecting any customizations users may have made in their user layer.
You assign the Edit Data Model permission to allow users to add their
own design windows, buttons, and ornaments to the user layer and
change their preferences and other default settings. You also assign the
Save Data Model permission to allow users to save their changes. (For
more information on split data models, see “Saving the Data Model”
on page 125.)
A combined data model, which consists of one file, is designed for sites
that don’t allow users to make changes to a data model. With the
permissions mentioned above, users can make changes to a combined
data model. However, assigning those permissions is generally not
recommended: when you distribute a new version of the data model,
the changes you’ve made may overwrite users’ customizations.
Modifying Queries
Advanced users who understand SQL and the database can modify the
SQL string generated when they formulate a query. To do so, you need
to set the Show SQL String preference to display the SQL in the Query
window, then assign the Edit Queries permission to allow users to
modify the SQL. Users can then modify anything after the SELECT
statement. This permission doesn’t compromise any restrictions placed
on users by the DBMS.
When the Allow Non-select SQL permission is assigned, authorized

users can also perform special functions in the database, such as
updating and deleting data. When the Show SQL String preference is
set, they can type anything into the SQL string. When the Allow Non-
select SQL permission isn’t assigned, users can’t submit a query for
which they’ve modified the SQL string to add, delete, or update data,

even when the Edit Queries permission is assigned. (BI/Query Update
commands for inserting, updating, and deleting aren’t restricted.)
Managing the Network Load

You can manage the load on the network by limiting the number of
rows that a query returns (Maximum Rows Retrieved permission) or
the maximum time a query can run before it’s automatically canceled
(Maximum Query Time permission). Users can also set the Rows
Retrieved before Prompt preference to specify the number of rows to be
retrieved before BI/Query prompts to retrieve more. And they can set
the Query Time before Prompt preference to be prompted to cancel a
query. Depending on the data they need or the type of analysis they want
to perform, certain users may need access to more data than others.
If the corporate querying environment includes Hummingbird’s

BI/Broker, you can also schedule queries to control the load on the
network. See “Scheduling Queries” on page 146.
Performing Calculations with Queries

When you assign the Computed Attributes permission, users who need
to be able to perform calculations on their data can add attributes to an
attribute window that request the DBMS to perform user-defined
calculations. For example, a data model might include Quota and Sales
attributes that retrieve a salesperson’s sales quotas and total sales,
respectively. By creating a new attribute that calculates Quota minus
Sales, they can determine the shortfall in sales quotas.
Scheduling Queries
If the data access environment includes Hummingbird’s BI/Broker,
users and administrators with access to the BI/Broker Repository and
who have the appropriate system permissions can schedule and manage
queries.

You submit your scheduling requests from your desktop to BI/Broker,
where the scheduling process takes place. That means you can schedule
queries to be run when you aren’t present and your computer isn’t
even turned on. You can schedule them to run once or repeatedly, at
specific times, or when specific events have occurred. You can also
decide what notification should be sent when a query or report is
complete, where the results should be sent, and who can retrieve those
results. See “Scheduling Queries” on page 161.
Saving Queries
When you assign the Save Queries permission, users can save queries in
order to reuse them in BI/Query or in other applications. This
permission isn’t necessary for data models that provide only canned
queries and reports instead of ad hoc querying capability.
Creating Relationships between Data Objects

There are countless possibilities for creating relationships between
tables in most databases. But creating every possible relationship would
make it difficult for users to understand and use the data model. To
minimize confusion and maximize flexibility, you can create the most
important relationships between data objects yourself, then assign both
the Allow Dynamic Relationships permission and the Allow Dynamic
Relationships preference. They allow advanced users who understand
the database and know how to draw related information from more
than one table to create their own relationships between data objects.
For example, to satisfy the needs of most users, you might provide a
relationship between the Retailers and Sales data objects, specifying an
equal join that allows users to retrieve information about only those
retailers who have placed sales. You can then add flexibility for
advanced users by allowing them to create their own join conditions —
for example, to specify an outer join that retrieves retailers even when
they haven’t placed an order.

Performing Special Operations
Advanced users who want to do something in the database other than
retrieve data need the Send SQL Scripts permission. It allows them to
send scripts of SQL commands to the DBMS to be executed. While the
scripts can’t be used to retrieve data, they can perform other useful tasks
such as creating a stored procedure or trigger. This permission doesn’t
compromise any restrictions placed on users by the DBMS.
With the help of Technical Support, you can create a dynamic link
library (DLL) file called gqlcheck.dll. If the Custom Checks permission is
assigned, BI/Query calls a routine in the resource file before submitting
any SQL string to the DBMS. This routine accepts the SQL string that
BI/Query is about to send and returns a potentially modified string,
which BI/Query submits in its place. This feature can be used to check
security, optimize performance, and so on.

You can control how users connect to the DBMS by allowing them to
save passwords in connection files and by setting them up to connect
only when they submit queries.
Saving Passwords in Connection Files

When you assign the Save Passwords permission, users can save
passwords (in encrypted form) in connection files. If this permission
isn’t assigned, or if the password isn’t included in the connection file,
BI/Query prompts users to type their passwords when they connect.
Allowing users to save their password in a connection file saves them
from having to type it each time. However, it allows any user to use
the connection and therefore may not be appropriate for certain sites.

Connecting While Submitting Queries
You can set up BI/Query to connect to the DBMS each time users
submit a query, then disconnect once the results are returned.
Connecting to the DBMS only for the duration of a query minimizes
the resources being used on the server at one time. You enforce this
type of automatic connection by assigning the Enforce Connect per
Query permission. If this permission isn’t assigned, users can still take
advantage of this facility by setting the Connect per Query preference.
Users also have the option of connecting automatically for the duration
of a session. (See “Automatic Connections” on page 62.)
Assigning the Enforce Connect per Query permission is recommended

for sites that have concurrent user licenses for their database (licenses
that permit only a certain number of users to connect at one time) and
are reaching their maximum number of users. It isn’t recommended for
sites where users submit queries throughout the day because connecting
and disconnecting from the database with every query takes up time
and server resources.
Making Changes to the Database

Because organizations need to maintain the quality and security of data
in the corporate database, only authorized users can use BI/Query to
make changes to corporate data. With the appropriate authorization,
users can update data and create new tables in the database.
Updating Data
BI/Query Admin and BI/Query Update include a facility for adding,
modifying, and deleting data in the corporate database. This facility is
primarily designed for users who are responsible for maintaining
database tables. (See “Applying Updates to the Database” on page 400.)
Users can update the corporate database only if the database

administrator grants the appropriate database permissions and the
administrator sets up the data model to perform updates — assigning

key fields to the tables that users are allowed to update as well as
assigning the Edit Model, Save Model, and Update Database
permissions. (See “Setting Up BI/Query” on page 393.)
Creating New Tables

When users formulate a query, they can send the results to a new table
in the database. They can then use the table to formulate additional
queries. Users can create their own tables in the database if the database
administrator grants permission to create tables and the administrator
assigns the Submit to Table permission.
It can be useful to allow users to create their own tables for a number of
reasons. If they’re extracting information from a number of tables, their
queries take time because they use multiple joins. Summarizing the
information in one table eliminates the joins and reduces the number of
rows that the DBMS has to process. This gives users faster access to the
information and reduces the load on the database server. For example,
instead of querying the Retailers and Sales tables each time they need to
retrieve information about a retailer’s monthly sales, users can query a
table that contains retailer sales summarized by month. This works
particularly well when users need to analyze information that isn’t
changing regularly. For example, by creating a table that summarizes
sales for a particular year, users can query the table and perform
calculations on the results without the values changing and becoming
out of date.
Users can also name the new table and the corresponding data object
when you assign the Submit to Named Table permission. This is useful
when users send query results to a new table in the database using
buttons; each time they click the button, BI/Query drops and re-
creates the table with the current results. When this permission isn’t
assigned, BI/Query creates a unique table each time. The database
administrator must grant users permissions to create and drop tables.
(Keep in mind that this permission allows users to drop the named
table. And because they can enter arbitrary table names, it gives them
the facility to drop any table from the database.)

Balancing the Load on the Network

Optimizing Connection Performance 153
Fine-tuning 155
Setting Automatic Connections 155
Running Efficient Queries 156
Using Data Values Files 156
Restricting Queries to Specific Information 157
Submitting Queries to a Table in the Database 157
Modifying the SQL 158
Estimating Database Resources 158
Ranking Data Objects for Oracle Databases 158
Setting Query Limits 160
Using BI/Query Permissions 160
Using BI/Query Preferences 161
Managing Scheduled Jobs 162
Displaying Scheduled Jobs 162
Setting Display Options 163
Managing Jobs 164
Balancing the Load on
the Network
The load on the network server varies with the number of users
running BI/Query, how often they query the database, and the size and
complexity of their queries. BI/Query takes one step in reducing the
demands on the server by storing query results on the user’s computer
so that users can manipulate results locally instead of in the database.
You can take additional steps to optimize how data is processed and
ensure the best performance for your site. And if your data access
environment includes Hummingbird’s BI/Broker, you can also balance
the load by scheduling queries.

Your connection to the database management system (DBMS) allows
BI/Query to communicate with the database — submitting queries and
retrieving data. You can ensure that your connection optimizes the process.
Optimizing Connection Performance

When BI/Query retrieves rows of data, it holds them in a portion of
memory (called a buffer) on the user’s machine until they can be
transferred to BI/Query. Row buffering affects the time it takes to
retrieve data and consequently affects the network load. You can
optimize row buffering to dramatically improve data-retrieval time and
reduce network load.
BI/Query allows you to set two types of row buffering:
• middleware row buffering — for middleware capable of performing

its own row buffering
• DBAccess row buffering — for DBAccess (a utility installed with
BI/Query that allows BI/Query to connect to the DBMS)

Not all DBMSs If the middleware specified for the data model you’re using is capable of
that you connect performing its own row buffering (DB2 Call Level Interface,
to with ODBC
support row buff- EDA/SQL, Ingres/Net, ODBC, SequeLink, or SQL*Net), you can
ering. (For example, Oracle optimize connection performance by increasing its row buffering value.
does, but Access doesn’t.) If The default is 1 (no buffering), and a value of 10 seems to provide the
the DBMS supports row buff-
best performance; however, you need to experiment with different
ering, it’s available in
BI/Query; if not, the DBMS values to find which work best at your site. Keep in mind that as you
sends a single row at a time. increase the value, BI/Query allocates more temporary buffer space;
this can lead to problems when BI/Query retrieves very long rows.
DBAccess is installed with row buffering set to 71. While DBAccess

row buffering works with any middleware, it may conflict with
middleware capable of performing its own row buffering. You may be
able to regain performance lost to row-buffering conflicts by changing
the middleware row-buffering setting to match the value for DBAccess
row buffering. When the two row-buffering settings are the same, the
performance of BI/Query immediately improves.
To optimize connection performance

2 In the Connections dialog box, select a file, then click Edit.
3 In the Edit Connection dialog box, click Preferences.
4 In the Connection Preferences dialog box, type a new value into
the Row Buffering text box, then click OK. (For DB2 Call Level
Interface, EDA/SQL, Ingres/Net, ODBC, SequeLink, or
SQL*Net, type a value up to 10.)
154 Balancing the Load on the Network

5 Click OK.
6 In the Edit Connection dialog box, click Save.
Fine-tuning
You may be able to further enhance BI/Query’s connection When you test
performance by fine-tuning row buffering. The optimum settings row-buffering set-
tings, start by
depend on a number of factors, which you can determine using a series using fairly large
of tests and adjustments. values — for example, Row
Buffering = 10, then Row
To fine-tune row buffering Buffering = 150. Work
towards the middle to
1 Run a typical query and note the time it takes to run. “bracket” the optimum value.
2 Change both row-buffering settings to a new value, run the query
again, then note the difference in performance.
3 Repeat until you find the optimum performance.
4 To save the row-buffering settings, save the data model.
Setting Automatic Connections

In order to submit queries, users need to connect to the DBMS. But
the larger the number of users who connect and the longer they’re
connected, the greater the load on network resources as the server
authenticates each user, writes log or audit records, starts a new task to
handle each user, and so on. You can minimize the resources being
held by assigning the Enforce Connect per Query permission. This
forces BI/Query to connect only for the duration of a query —
connecting each time a user submits a query and disconnecting once
the results are returned. If you don’t assign this permission, users can
take advantage of this facility themselves by setting Connect
Automatically preference.
Setting up BI/Query to connect in this manner is useful when query

traffic is light or users don’t need regular access to the database. For users
who submit queries regularly, consider setting the Connect

Automatically preference to connect for the duration of a session instead.
(For more information, see “Automatic Connections” on page 62.)
Running Efficient Queries

BI/Query provides a number of features that help you ensure that
queries don’t make unnecessary demands on the network.
Using Data Values Files

Users can qualify an attribute with one or more data values in order to
retrieve results that correspond only to those values. For example, they
can retrieve information about customers located in France and USA
by qualifying a query with the data values for those countries.
When users qualify an attribute, they can select from a list of data values
stored in the database. By default, BI/Query queries the database for all
the values for the attribute and displays the list in the Data Values dialog
box. However, you can disable access to the default query. Disabling
access is recommended when loading all the values in the database uses
large number of values or when those values are simply numbers and
dates. (For details on disabling access to data values, see “Securing
Access to Data Values” on page 135.)
You and your users can make qualifying a query more efficient by
using data values files. Data values query files retrieve a subset of values
for an attribute from the database. Data values results files display a
stored set of values; they further reduce the load on the database server
because they eliminate the need to query the database each time users
need a list of values. (For information on creating data values files, see
“Data Values Files” on page 257.)

Restricting Queries to Specific Information
You can qualify data objects and actual relationships in order to restrict
users’ queries to specific information in the corresponding tables. This
also helps improve query performance by preventing users from
retrieving more data than they actually need.
For example, you can qualify the Customer data object with the value
Canada on the Country attribute so that any query that includes that
data object retrieves only information about customers in Canada.
Alternatively, you can qualify a data object with a prompt that forces
users to qualify any query that includes the data object — for example,
specifying one or more countries. (For information on both these
facilities, see “Securing Access to Rows in a Column” on page 133.)
Submitting Queries to a Table in the Database

The greater the number of tables users include in a query, the greater
the number of joins and rows the DBMS has to process. If users are
regularly retrieving information from multiple tables, you can improve
performance by allowing them to summarize the information they need
in their own tables in the database. The database administrator also has
to grant permission to create tables.
Users formulate a query, send the results to a new table in the database,
then use the table to formulate additional queries. (For instructions on
creating tables, see “Creating Tables in the Database” on page 114.)
Summarizing information in one table eliminates the joins and reduces

the number of rows that the DBMS has to process. It gives users faster
access to the information and reduces the load on the database server.
(You can also assign the Submit to Named Table permission to allow
users to name the new table as well as the corresponding data object.
See “Creating New Tables” on page 150.)

Modifying the SQL
When users formulate a query, BI/Query generates the corresponding
SQL string. Advanced users who understand SQL and the data in the
database can recognize opportunities to make queries run more
efficiently by modifying the SQL string. You can allow users to modify
the SQL string by assigning the Edit Queries permission. Users can
then include any SQL statement after the SELECT statement (within
the limits placed on users by the DBMS).
Estimating Database Resources

If you’re using a DB2 or Teradata database, you can obtain information
about a standard query before you send it. This information includes
the length of time it will take to return the results as well as details
about the database resources the query will use (for example, which
tables it will use and how many times the same table will be used).
Rather than returning results, the database returns information about
the query, and BI/Query displays it in a window.
This facility helps you plan the queries you provide to users, and it
helps users determine whether or not to issue a query. For example, by
determining how a query will use the database, you can restructure a
query to perform the same function more efficiently. This feature can’t
be applied to super queries.
To estimate database resources

1 Formulate or load a query.
2 Connect to the DBMS, then choose Query>Estimate Resources.
Ranking Data Objects for Oracle Databases

You can improve the efficiency of queries that run against an Oracle
database by ranking data objects in a data model based on the number
of rows of results they can potentially return. (This feature is supported

for both Oracle 6 and Oracle 7 if you’re not already running the Oracle
optimizer.)
Tables appear in the FROM clause of an SQL statement in the order in

which the corresponding data objects are ranked. The optimal
sequence of tables in the statement places the table that returns the
fewest number of rows, based on its WHERE conditions, last in the
from clause. That table is processed first (and is therefore called the
“driving table”). The driving table isn’t necessarily the one that
contains the least amount of data but rather the one that returns the
fewest number of rows of results. In the following SQL example, the
smallest_num_rows table returns the fewest rows of results and is
processed first. When you rank it first, any query containing that data
object has that table last in the FROM clause and has the greatest
potential for being optimized.
SELECT
(*)
FROM
large_num_rows, small_num_rows,
smaller_num_rows,smallest_num_rows;
In order to achieve the best results, you need to know how the database
is being used and how many rows of results any table can return. For
example, a table returns fewer rows when it’s joined to another table.
(You may need to consult the documentation for your DBMS.)
When a user formulates a query using data objects that have been
ranked, BI/Query uses the ranking order to arrange the FROM clause
for optimal performance.
To rank data objects for Oracle databases

2 In the Connections dialog box, select Oracle from the DBMS list.
3 Click OK.
4 Display the design window that contains the data objects you want
to rank.

5 In Design Mode, choose Design>Rank Data Objects.
When a number 6 In the Set Data Object Ranking dialog box, specify an order using
of data objects is the First, Last, Up, and Down buttons. (The object that returns the
displayed in the fewest number of rows must be ranked first.)
Set Data Object
Ranking dialog box, you can
start by clicking Sort to sort
them alphabetically.
7 Click OK.
Setting Query Limits

Depending on the data they need or the type of analysis they want to
perform, certain users may need access to more data than others. You
can minimize the load on the network using certain permissions and
preferences.
Using BI/Query Permissions

You can assign permissions that limit the number of rows that a query
returns and the maximum time a query can run before BI/Query
automatically cancels it.
To set query limits using permissions


2 In the Permissions dialog box, under Governor Settings, type the
values you want into the Maximum Rows Retrieved and
Maximum Query Time text boxes.
3 Click OK.
Using BI/Query Preferences

Users can set preferences for the connection file they’re using that
specify the number of rows to be retrieved before BI/Query prompts
them to retrieve more and that prompts them to cancel a query.
To set preferences that set query limits for a connection file

2 In the Connections dialog box, select a file, then click Edit.
3 In the Edit Connection dialog box, click Preferences.
4 In the Connection Preferences dialog box, type the values you
want into the Rows Retrieved before Prompt and Query Time
before Prompt text boxes.
Scheduling Queries
If your data access environment includes Hummingbird’s BI/Broker, With the appro-
and you have appropriate system permissions, you can monitor and priate system per-
missions, you can
manage the load on the database server by scheduling queries. System also schedule
permissions for scheduling are assigned by the BI/Broker administrator. reports. (For more informa-
For information on these permissions, see “Assigning System tion, see the BI/Query
Reports user documentation.)
Permissions” on page 89 in the BI/Broker administrator’s guide.
With the appropriate system permissions, administrators and users can

schedule their own queries, and administrators can monitor and
manage queries that other users schedule. They can hold queries during
critical transaction and maintenance events and control the queue of
queries so that reports from high-priority users, or groups of users, are
processed first. They can ensure that complex queries are executed
when the load on the database server is at its lightest.

To be scheduled, queries have to be published in the BI/Broker
repository. (See “Publishing Queries” on page 310.)
Managing Scheduled Jobs

Administrators and users with the appropriate system permissions can
view all scheduled jobs and change, cancel, postpone, or delete them.
Displaying Scheduled Jobs

In order to manage scheduled jobs, you need to display them. The
Scheduled Jobs window identifies each job by its name and owner (the
user who scheduled it). You can decide what else to display in the
window. It can display when the job is scheduled to execute and what
the current state of its execution is. Jobs can be pending (waiting to
run), active (running), done, expired (end date has passed), aborted (job
was canceled), or held (job was paused.) The job list can also display the
job’s priority, expiration date (if any) and its job ID. It can include
comments that the owner entered and list errors, the number of times
the job has run, which application (BI/Query or BI/Query Reports)
produced the job, the job’s document ID, and whether the job is
running a query or refreshing a report.
To display scheduled jobs

1 Choose Hummingbird Applications>Utilities>Scheduler from the
Windows Start menu.
OR
In BI/Query, choose File>Schedule>View Jobs.
2 In the Scheduled Jobs window, to display jobs for a different user or
group, choose a user or group from the Show Jobs For list.
3 To sort the display on a different column heading, double-click it.
4 To refresh the display, click the Refresh tool.

Setting Display Options
You can specify how frequently the display is to be automatically
refreshed, limit the number of columns you display, and specify the
order in which they appear.
To set display options

1 In the Scheduled Jobs window, click the Options tool.
2 In the Options dialog box, under Refresh, specify how often you
want the display to be refreshed.
3 To hide a column, click the column name to deselect it.

4 To reorder a column, click it, then click Move Up or Move Down.
5 To apply the options you’ve selected and set additional options,
click Apply.
6 When you’re finished setting options, click OK.
Managing Jobs
If you have the appropriate system permissions, from the Scheduled
Jobs window you can intervene in the way jobs run. You can cancel
jobs, reset them to start again after they’re done or after they’ve been
cancelled, pause them and then allow them to resume, and delete them.
To manage jobs
1 In the Scheduled Jobs window, select one or more jobs.
2 To cancel a job, click Cancel, then click Yes to confirm.
3 To start a job again after it’s finished or has been cancelled, click
Reset Job.
4 To temporarily keep a job from running, click Pause; to allow a job
that has been paused to continue running, click Resume.
5 To delete a job, click Delete, then click Yes to confirm the
deletion. (You can’t undo a deletion.)

Creating an Effective Design
Basic Principles 167

Decide What’s Appropriate 167
Be Consistent 168
Use Restraint 169
Use Contrast 170
Provide Unity 170
Establishing a Layout 171
Layout Grid 171
Masthead and Logo 172
Lines 173
Adding Emphasis 173
Type 173
White Space 174
Boxes 175
Graphics 176
Color 176
Creating an Effective
Design
The design of a data model isn’t simply using graphics and color for the
sake of decoration. It’s an extension of the organization process and a
way of communicating information. When it comes to design, there
are no hard and fast rules. And you don’t have to be a graphic designer
to design an effective data model. Without investing a lot of time, you
can create a good-looking data model that’s easy to use by following a
few basic guidelines.
Basic Principles
Design elements are components that you build into your data model Always balance the
layout to make it more attractive and help communicate information. use of innovative
typefaces, graphics,
Examples include graphics, color, and white space. A few basic and colors in a data
principles ensure an effective design. model with legibility. Your first
consideration should be the
information you want to con-
vey to your users.
Decide What’s Appropriate
When you design a data model, you need to choose design elements
and an arrangement that work best for your organization or a particular
user group. That means designing a data model that’s suitable for the
audience and content — setting the right tone and incorporating
graphics that support or enhance the type of information they
represent. A data model for a bank, for example, may have a different
tone and appearance than one for a bicycle company.

Depending on the nature of the company, a data model can have a more formal,
structured design or one that’s more relaxed.
Appropriateness also means designing in the right proportions, where

the size of any design element is appropriate for the size of the design
window, the number of elements in it, and where you want to place
emphasis. For example, when you include a corporate logo, it should
be large enough to establish a corporate identity but not so large that it
distracts users and takes the focus away from the data objects and
buttons they need to access information.
The corporate logo dominates the The corporate logo provides corporate
design window. identity without distracting the user.
Be Consistent
Consistency enhances clarity, readability, and reliability because it
reinforces users’ expectations. The more consistent you are in your
treatment of design elements, the easier it is for users to find what they
need and understand what to do. When you create more than one
heading in a data model, for example, use the same typeface and size for
168 Creating an Effective Design

each one. When you’re naming data objects, attributes, buttons, and so
on, use the same case — whether it’s lower case, UPPER CASE, Title
Case, or Sentence case. Use even spacing between objects, and make
objects of the same type (for example, buttons) the same size, especially
if they’re grouped together; otherwise, any differences between them
are more obvious.
Design windows should use the same or similar design treatments — mastheads,
graphics, fonts, and so on — to provide consistency and reinforce users’ expectations.
Be consistent in how you handle elements both within a design

window and from one design window to another. For example, if you
decide to include a corporate logo in each design window, make sure
it’s the same size and in the same place in each one. Introduce a change
selectively — to draw attention to an element, for example.
Use Restraint
While a wide range of typefaces, graphics, and colors are available to
you, keep in mind that design elements gain impact when you use
them selectively and lose impact when they’re overused. A good
general rule is “less is more.” In a well-designed data model, the design
is invisible — users can focus on the information they need and not on
the design elements used.
Keep the design simple and uncluttered. Avoid putting too many data
objects in a design window and creating so many relationships between
them that it’s impossible to understand what information relates to
what. Consider dividing data objects over multiple design windows.

A “busy” data model is difficult to use. A “clean” design is easy to use.
Use Contrast
Contrast adds “color” to a data model. It gives elements extra impact
and keeps users interested. You can create contrast by adding color
selectively and varying the size and shape of objects.
Without contrast, the elements in a Varying the color, size, and shape of
design window blend together. objects provides visual contrast.
Provide Unity
Users need a focal point in a design window — something that
determines how they scan the window and communicates the relative
importance of elements in the window. You can achieve this by
organizing each design window around one dominant visual element
— a heading, the data objects and relationships in a data model, or a
group of buttons.

Elements of equal importance don’t Dominant images provide a focal point and
provide a focal point. emphasize important elements.
Establishing a Layout
The layout or organization of your data model provides a structure for The user’s natural
tendency is to read
data objects, buttons, and ornaments and gives users direction for
from upper left to
digesting the information. Different tools can help you organize design lower right. Orga-
elements so that users can find the information they need quickly and nize design elements to accom-
easily. If you provide more than one design window, present a modate this tendency.
consistent layout in each one.
Layout Grid
When objects are lined up, they’re easier to understand. BI/Query
provides a layout grid that helps you organize and align objects in design
windows and create a consistent layout from one window to the next.
The grid is a useful tool for placing data objects, relationships,
connecting lines, buttons, and ornaments. BI/Query displays the grid
by default. It appears on the screen as a series of horizontal and vertical
dotted lines. (The grid doesn’t print.) To specify grid settings, choose
Layout>Grid Settings.
To align objects on the grid, you can move them manually or use the
tools on the Layout palette. You can change the spacing between grid
points, and you can place objects anywhere on the grid or have
BI/Query automatically place them on the closest point. You can

display the grid while you work and turn it off when you’re ready to
distribute the data model to users.
Use the layout grid to align objects in a Turn the grid off before distributing the data
design window. model.
Masthead and Logo

The masthead is a title that’s been designed in some way (with a unique
typeface or with a rule or box that makes it stand out). A masthead is
typically created in the main design window to identify the data model.
It often includes a corporate logo. The logo acts as a “signature” on the
data model, adding corporate identity.
A masthead can include both a company A company name with a rule under it can
name and logo in a box. serve as a masthead; the logo can appear
elsewhere in the design window.

Lines
Horizontal and vertical lines help you organize a design window by
separating one area from another. You create a line using the Line tool.
And you format it (assign line thickness, line color, and fill color) by Line tool
selecting it, then clicking the corresponding tool.
Thick lines work

only if they’re set
off by a lot of
white space.
Lines organize and separate information. Horizontal and vertical lines contrast how
information is organized.
Adding Emphasis
In order to make a data model easy to use, you need to distinguish
important elements from less important ones. For example, the buttons
users use to access information shouldn’t be overpowered by
supporting graphics. There are a number of design elements that allow
you to strengthen a data model by adding emphasis where you need it.
Type
Type refers to size, shape, and spacing of letters. You can specify type Avoid typefaces
that draw attention
for text buttons and ornaments. The type available to you depends on to themselves. A
what fonts, or typefaces, you have installed on your computer. typeface shouldn’t
distract the user from the
Type is divided into two categories. Serif type has “feet” attached to the information you’re trying to
ends of letters that guide the eye from letter to letter. This type is often communicate.
used in body text (paragraph text) to assist readability. Sans serif type has
no “feet” — it has a clean, crisp, straightforward look and is often used

for short phrases such as headings and subheadings to distinguish it from
body text.
Times Roman (serif) and Helvetica (sans serif) are common typefaces.
In BI/Query, sans serif typefaces work well for buttons and ornaments;
you might use a serif typeface if you’re including a block of text. The
key is to use only one or two typefaces and to use them consistently.
Typeface (the style and shape of type) influences tone and adds
expressiveness:
Use italics or script The Bembo typeface is formal. While Tekton is casual.
typefaces sparingly
— they can be dif- Style and weight (normal, bold, italics, bold italics) influence the
ficult to read on
appearance and tone of type by adding contrast and emphasis. Size of
screen. The same goes for
reverse type (white type on a type is also a factor. Use large type to emphasize important information
dark background). Use it only and small type for less important information. But don’t use large type
at large font sizes. in a small area where it’s hard to read and looks cramped. Similarly,
don’t use small type in a lot of white space, or it will appear lost.
Not all typefaces reproduce well on screen. You need to experiment

with the typefaces installed on your computer. When you’re creating
data models for distribution to other users, or when you’re designing a
data model for use over the World Wide Web, you can avoid having to
make adjustments from one computer to the other by using standard
fonts such as Helvetica, Times Roman, and Courier.
White Space
Avoid white space White space is any blank space, whatever the background color. It allows
in the middle of a more background to appear, making whatever it surrounds stand out.
design window. It
White space focuses attention and enhances readability. It opens up, or
creates a “hole,”
which gives an unfinished “lightens,” a design window and avoids visual monotony. Without
look. white space, you end up with a “run-on” effect that makes it difficult
to distinguish elements in a design window. And if spacing is uneven, it
can jar the eye and convey poor organization and a careless design.
(However, you may occasionally want to introduce uneven spacing to
create contrast.)

You can create white space by limiting the number of elements you
include in a design window and by resizing and aligning them.
An overcrowded, unevenly spaced Good use of white space “lightens” a data

design window conveys poor model and makes it easier to use.
organization and a careless design.
Boxes
Boxes draw attention to elements that are otherwise lost in their
surroundings. They also organize elements. For example, you can
create a box around a set of buttons or data objects to group them
together and set them apart. You can also add gray shading or a color to
a box for more impact or to create a particular effect. Using BI/Query’s
drawing toolbar, you can create boxes in a variety of shapes and sizes.
A rectangle with buttons at the top of a Shaded boxes help visually organize groups
design window creates the leading-edge of data objects that provide related
look of a toolbar. information.

Graphics
Graphics dress up a data model and add variety. They also help convey
information. You can apply graphics to data objects and buttons to give
users an idea of what they do. For example, a button that displays a
graphic of a report communicates that the button generates a report.
You can also include graphics as a background in a design window to
establish a connection with the information that’s available. For
example, a design window can display a map of a country, and you can
place buttons that submit queries on specific regions in the country in
the corresponding region on the map.
Color
Color draws attention to design elements and helps you organize and
emphasize information. For example, applying one color to a group of
buttons or data objects allows users to perceive them as a group. Color
also evokes an emotional response and sets a tone. Bright colors
indicate excitement, while subdued colors indicate dignity.
You can apply color to windows and objects in BI/Query. For the best
results, decide what you want to achieve, then choose a main color (for
the background of a design window, for example) and complementary
colors (for individual objects). Complementary colors are color
combinations such as red-orange or blue-green that visually enhance
one another. Apply a contrasting color to achieve a focal point in your
data model or to accent smaller areas of emphasis.

Adding Value to a Data Model
Providing Metadata 179 From a Query 191

How Metadata Is Displayed 180 Creating the Table 193
Display Names Use Business Terms 180 Populating the Table 194
Tool Tips Display Short Descriptions 180 Creating the Query 195
Adding Metadata to the Database 181 From Results Files 196
Creating Metadata Tables 181 Using Descriptions in a Table 196
Loading Them from the Database 182 Using a Text Editor 197
Populating Metadata Tables 182 Creating Ornaments 198
Understanding Metadata Queries 183 Assigning Icons to Data Objects 200
How They’re Structured 183 Specifying Colors 201
How They Work 185 For Windows 202
Using Template Queries to Specify the For Objects and Design Windows 202
Metadata Source 186 For Individual Objects 204
When You Used BI/Query to Create New Colors 204
the Metadata Tables 186
Customizing Online Help 205
When You Didn’t Use BI/Query to Create
the Metadata Tables 187 Adding Information 205
Loading Metadata 188 Creating Help Files 206
Into Existing Data Models 189 Creating Additional Help 206
While Loading Tables 189 Data Model Help 207
While Refreshing Data Objects 190 Site-specific Help 207
Creating Attribute Descriptions 190
Directly in BI/Query 191
Adding Value to a Data
Model
You can add value to a data model to make it more usable and more
attractive and to provide additional information. For example, you can
provide metadata for the data objects and attributes in the data model,
and you can create attribute descriptions. You can also add ornaments
in design windows, replace the default data object icons with graphical
ones, and add color to windows and objects. And you can customize
BI/Query’s online Help and add your own Help files.
The same principles that the administrator applies to designing a data

model — consistency, contrast, white space, graphics, color, and so on
— apply to adding ornaments, icons, and color. By following these
principles, you can ensure that the data model communicates
information effectively and makes the impact you want. (See “Creating
an Effective Design” on page 167.)
Providing Metadata
Metadata is data about data. It labels, summarizes, and suggests the
Metadata at a Glance
questions that can be answered by the data in the corporate database. It
Providing metadata in a
does so in familiar terminology rather than database terminology. Like
data model involves three
other data, metadata is stored in the database in tables. It can provide basic steps:
information about the database as a whole, about a particular table, or
• Create tables in the
about a column in a table. database and populate
them with metadata.
You can provide metadata for the data objects and attributes in a data
• Edit BI/Query’s query
model. For data objects, metadata replaces database table names with
templates to specify the
display names; for attributes, it replaces database column names with metadata source.
business terms. And it provides short descriptions for both that explain • Load the metadata into
what kind of information they represent. Including metadata in a data the data model.
model gives users a clearer understanding of their data and helps them

build queries. And because the metadata is stored in the data model, it’s
always available.
To provide metadata, you start by making sure that your database stores
metadata (contains a metadata source). (If it doesn’t, you can use
BI/Query to create it.) You then set up the necessary queries to specify
the metadata source. Loading the metadata into the data model submits
the queries to the metadata source and retrieves the metadata.
To help you set up the queries you need to specify the metadata source,
you can use one of a number of editable template queries. In addition
to BI/Query’s own, you can use template queries for metadata supplied
by IBM’s DataGuide, Informatica’s PowerMart Mx, and Prism’s
Directory Manager (using the Prism MetaLink option).
How Metadata Is Displayed

Metadata provides display names for data objects and business terms for
attributes as well as short descriptions for both.
Display Names Use Business Terms

Display names for tables provide clear, natural-language labels that users
understand. For example, a table with the database name sales_na might
be loaded into a design window as the North American Sales data
object. Similarly, display names for columns replace a data object’s
attribute names with common business terms. For example, a column
with the database name quartsale might become the Sales by Quarter
attribute in the North American Sales data object.
Tool Tips Display Short Descriptions

Short descriptions displayed as tool tips provide additional information
about a table (data object) or column (attribute). A short description in
the metadata for a table, for example, might include the number of
rows returned or the frequency with which the table is updated. A
180 Adding Value to a Data Model

short description for a column that returns a number might include the
unit of measure represented and where the data originated.
Adding Metadata to the Database

If your database doesn’t contain metadata, you can create metadata
tables for the data models you use.
Creating Metadata Tables

You create metadata tables in the same way as any other table. (See
“From Data Objects” on page 116.)
To create metadata tables

1 In a design window, create the data objects you want, name them You can use any
(for example, tablemeta and columnmeta), and add attributes to names for these
them. (For instructions, see “From Data Objects” on page 116. For data objects and
sample attribute names, see the examples below.) their attributes as
long as you edit the template
2 Double-click the tablemeta data object. metadata queries to conform
3 In the attribute window, set table_name as a key field. (See “Setting to them. (See “Using Tem-
Key Fields” on page 393.) plate Queries to Specify the
Metadata Source” on
page 186.)

4 Close the window.
5 Double-click the columnmeta data object.
6 In the attribute window, set table_name and column_name as key
fields. (See “Setting Key Fields” on page 393.)
7 Close the window.

8 Create the corresponding tables in the database. (See “Directly in
the Database” on page 117.)
Loading Them from the Database

Once you’ve created metadata tables in the database, it’s good practice
to load them into the data model to be sure that they’ve been created
properly. (For instructions on loading tables, see “Loading Tables from
the Database” on page 96.) After you’ve loaded the tables, you need to
reselect the key fields: this information is retained in the data object,
not in the database, and is lost when you load the tables.
When the metadata is loaded, the display names replace the data object
names, and the short descriptions are available as tool tips.
Populating Metadata Tables

Populate the metadata tables using BI/Query Admin, BI/Query
Update, or any other tool that allows you to insert data into a table.
(See “Populating the Table” on page 194.)

Understanding Metadata Queries
Before you set up queries to retrieve metadata, it’s important to
understand how they’re structured and how they work.
How They’re Structured

The tables below summarize the structure of the queries used to
retrieve metadata. The tables also show what to include in the SQL for
a query to retrieve metadata for both data objects and attributes.
When display names and short descriptions each occupy only one row in
the metadata table, the SQL for a query should contain the following.
(As an example, see the template queries that are displayed when you
select Other from the Vendor list in the Metadata Source dialog box.)
SQL for Tables SQL for Columns
select disp_name, select col_name,

short_desc from disp_name, short_ desc
tablemeta where from columnmeta where
tablemeta.tab_name= columnmeta.tab_name=
”<<table_name>>” “<<table_name>>”
• Selects the display names and • Selects the display names and
short descriptions for the data short descriptions for the
objects you choose when you attributes in the data objects
load metadata. you choose when you load
• No ordering is required. metadata.
• No ordering is required.

When display names and short descriptions contain multiple rows of
data, the SQL for the queries should contain the following:
SQL for Tables SQL for Columns
select disp_name, select col_name,

short_desc, sequence disp_name, short_ desc,
from tablemeta where sequence from
tablemeta.tab_name= columnmeta where
”<<table_ name>>” order columnmeta.tab_name=
by sequence ”<<table_ name>>” order
by sequence
• Selects the display names and
short descriptions for the • Selects the display names and
data objects you choose short descriptions for the
when you load metadata by: attributes within the data
• selecting the first row of objects you choose when
data for each display name you load metadata by:
• appending the short • selecting the first row of
descriptions for each data for each display name
additional row in order • appending the short
• Order by sequence. descriptions for each
additional row in order
• Order by sequence.
If you’ve created metadata tables using the names provided in the

example “Creating Metadata Tables” on page 181, you can use the
SQL shown above. If you’ve used other naming conventions, you can
substitute those names as follows:
For This Substitute This
col_name The name of the attribute in the columns

metadata table that contains the database names of
the columns for which there is metadata.
disp_name The name of the attribute in the metadata table

that contains the display names.
short_desc The name of the attribute in the metadata table

that contains the short descriptions.

For This Substitute This
columnmeta The name of the table (data object) that contains

the columns metadata.
tablemeta The name of the table (data object) that contains

the tables metadata.
How They Work

The query to the tablemeta table in the design window shown in “Tool
Tips Display Short Descriptions” on page 180 might look like this:
select disp_name, short_desc from tablemeta where

tablemeta.tab_name="<<table_name>>"
When you load metadata (see “Loading Metadata” on page 188), the
<<table_name>> table variable is replaced successively with the
database names of the tables in the data model for which there is
metadata (retailers, sales, salespeople, and offices). The query associates
the corresponding display name and short description with each table.
Similarly, the query to the columnmeta table in the data model

illustrated on page 180 might look like this:
select col_name, disp_name, short_desc from

columnmeta where
columnmeta.tab_name="<<table_name>>"
When you load metadata, the <<table_name>> table variable is

replaced with the database name of the successive tables. All of the
metadata for each table is retrieved, and each metadata row returned by
the query is found in the table by its database name. The column
display name and short description are associated with the
corresponding column.

Using Template Queries to Specify the Metadata Source
To provide metadata for the data objects and attributes in a data model,
you need to specify the source for the metadata in the database —
which tables and columns store the metadata. You specify the source by
using the template queries supplied with BI/Query or editing them.
When you or your users load metadata, BI/Query submits these

queries to the database and retrieves the corresponding metadata. (See
“Loading Metadata” on page 188.)
When You Used BI/Query to Create the Metadata Tables

If you created the metadata tables using BI/Query, and you used the
Principles of Building
data object and attribute names suggested in “Creating Metadata
Metadata Queries
Tables” on page 181, you can use the template queries without editing
• The SQL must select
the display name first,
them.
then the short
description from the To use a template query when you used BI/Query to create the tables
metadata table.
1 Choose Edit>Metadata Source.
• For columns metadata,
2 In the Metadata Source dialog box, specify Other in the Vendor text
the columns database
name must be selected box.
first.
• For metadata tables
containing more than
one row of data per
column, any display
names after the first row
for each column or
table are ignored, while
the descriptions are
appended sequentially.
• For DB2, Oracle, and
Teradata databases,
include a Creator (DB2,
Oracle) or Database
name (Teradata) where
appropriate.

3 Click OK.
When You Didn’t Use BI/Query to Create the Metadata Tables

If you didn’t create your own metadata tables in BI/Query or didn’t
use the naming conventions suggested in “Creating Metadata Tables”
on page 181, you must edit a set of template queries (one for table
metadata, one for columns metadata) before you use it. You can edit
BI/Query’s template queries or queries that support other vendors’
metadata tables (IBM’s DataGuide, Informatica’s PowerMart Mx, and
Prism’s Directory Manager).
Be sure to create a query only for the type of metadata you want. For
example, if you want metadata only for columns, create a query only in
the Columns Query text box and delete the query in the Tables Query
text box.
For DB2, Oracle, or Teradata databases that require it, a creator or

database name must appear in front of columnmeta in both the FROM
and the WHERE clauses, as in this example for one-row columns
metadata.
select col_name, disp_name, short_desc from

dbaname.columnmeta where
dbaname.columnmeta.tab_name = "<<table_name>>"
IBM DataGuide queries always target a DB2 database, and DB2 always
requires a creator name. For that reason, BI/Query supplies a default
creator name in the appropriate places in those queries. You need to
change that name to reflect the actual creator name you’re using. If
you’re editing a Prism or PowerMart Mx query that targets a database
requiring a creator or database name, you must manually insert that
name into the FROM and WHERE clauses.
To use a template query when you didn’t use BI/Query to create the
tables
1 Choose Edit>Metadata Source.

2 In the Metadata Source dialog box, specify a template query in the
Vendor text box.
The text of metadata queries is case-sensitive and must match the attributes stored
in the metadata table.
3 Edit the queries in the Columns Query and Tables Query text
boxes.
OR
Type your own queries.
4 To submit the query to a DB2, Oracle, or Teradata database
requiring an Owner or Creator name, add the name in front of
columnmeta in both the FROM and the WHERE clauses.
5 To insert the table variable into the SQL string, click Insert Table
Variable.
6 If the Creator name must be included as part of the substitution for
the table variable when you load metadata or refresh data objects,
click Use Creator Name in Table Variable.
7 Click OK.
Loading Metadata
Once you’ve specified the metadata source for a data model, you can
load the metadata in a number of ways. Loading metadata associates the

display names and descriptions with the data objects and attributes in
the data model.
Into Existing Data Models

Both you and your users can load metadata into a data model. As a
result, when the metadata changes, you can simply inform users that
they need to load the metadata; you don’t need to load it into the
model, then distribute an updated version.
To load metadata into an existing data model

1 Choose Host>Load Metadata.
2 In the Load Metadata dialog box, click Data Objects From All
Windows to display all the tables in the data model.
3 Select the tables you want, then click Load.
While Loading Tables

Loading tables into a data model automatically loads the corresponding
metadata. (See “Loading Tables from the Database” on pages 90.)

While Refreshing Data Objects
You can load metadata into an existing data model by refreshing data
objects. (See “Determining What Changes Have Been Made” on page 235.)
Creating Attribute Descriptions

You can add an If you have information about an attribute that can help users decide
attribute at the top when and how to use it in a query, you can provide a description of the
of an attribute
attribute. For example, a description for the Title attribute can clarify
window to pro-
vide a description of the data that the attribute represents business titles (Director, Manager,
object. Choose Design> Specialist), not personal titles (Mr., Mrs., Ms.). Or if data for an
Insert Attribute, type “Data attribute is updated only at certain intervals, that information can help
Object Description,” click the
users decide when to schedule their queries. An attribute description
question mark, then type the
description into the Attribute can include any information — the type of data the attribute returns,
Comment text box. When possible values, any restrictions on the data, and so on — that helps
users click the question mark, users use the attribute in a query effectively.
the description appears in the
text box. The description is In many organizations, the database already contains a catalog table or a
saved with the data model.
data dictionary that stores information about tables and attributes. If
you have such a table, you can create a query that queries that table and
returns the attribute information, or you can store the information in a
results file. If such a table doesn’t exist, you can create one.
Instead of creating a table in the database, you can type descriptions

directly in BI/Query. Alternatively, you can create results files that
store attribute descriptions. (A results file takes precedence over a query
file.) Descriptions can contain up to about 400 characters, depending
on the size and style of the text.
Users can see the descriptions you provide by clicking the question
mark beside an attribute in the attribute window. When you type a
description in BI/Query, the description is automatically displayed in
the Attribute dialog box. When you create a query or a results file that
provides a description for the attribute, the Load Comment button is
enabled. When users click the button, BI/Query runs the query or
loads the contents of the results file and displays the description.

The Attribute
Comment text
box displays
descriptions of up
to about 400 characters, but
your database may not sup-
port character fields longer
than 256. To add a longer
description, type it as two
rows. (If you use BI/Query to
Attribute Comment populate the table, assign an
text box attribute other than the
attribute name as the key
field; otherwise, it won’t be
unique.)
In a split data model, attribute descriptions you create are stored in the
administrator layer. Any attribute descriptions users create are saved with
their user layer and take precedence over descriptions stored in the
administrator layer. (Typically, users won’t create attribute descriptions
from query or results files, but they can type them directly in BI/Query.)
Directly in BI/Query
When attribute descriptions aren’t available in a table, the simplest way
to create them is directly in BI/Query. When users click the question
mark for an attribute in an attribute window, the description is displayed.
To create an attribute description in BI/Query

1 In an attribute window, click the question mark beside an attribute.
2 In the Attribute dialog box, type a description into the Attribute
Comment text box.
3 Click OK.
From a Query
If your database stores a table containing attribute descriptions, you can
create a generic query that queries that table for the appropriate

description of an attribute in the data model. When users click the
question mark for an attribute, then click the Load Comment button in
the Attribute dialog box, the query is submitted, and the results (the
description of that attribute) are displayed. Using a query to generate
attribute descriptions ensures that users obtain up-to-date information
about an attribute if the descriptions in the table are updated. It also
means that you can create one file that retrieves information for all
attributes for a data object. If you create a results file, you have to create
one for each attribute you want to describe.
If the database contains a catalog table or a data dictionary, ensure that

it contains one column of database names of attributes, another of
database names of their corresponding tables, and another of attribute
descriptions. If the database doesn’t contain a table with attribute
information, you can create one using BI/Query or another tool. Be
sure to populate the table with the database names of the attributes and
their corresponding tables, not their BI/Query names.
BI/Query uses the data object you create or load to query the
descriptions table. Users can also use the data object itself to retrieve
attribute descriptions. You can prevent them from doing so if the table
is large and you want to avoid tying up the database server — such as if
a user attempts to retrieve all of the descriptions in one query. You can
prevent users from using the data object by hiding all of the attributes.
(In Design Mode, turn off the Visible toggle for each attribute.)
You can create an attribute description from a query in a few steps.
• If the database contains a catalog table or a data dictionary, ensure

that it contains a table with attribute information. (If it doesn’t,
create one using BI/Query or another tool.)
• Populate the table with the database names of the attributes and)
their corresponding tables, not their BI/Query names.
• Load the table into the data model. (See “Loading Tables from the
• Create the appropriate query.

Creating the Table
The table you create needs three columns —one for the database names
of the attributes, another for their corresponding table names, and a
third for the attribute descriptions.
If you won’t need to change the attribute and table names in the table
or in BI/Query later, you can assign key fields to those attributes. (Both
must be key fields if more than one table has attributes with the same
name; that allows queries to distinguish between the attributes.) If
you’ll need to make changes to attribute and table names using
BI/Query, create another attribute to serve as your key field. Its sole
purpose is to allow you to populate and update the table. (See also
“Creating Tables in the Database” on page 114.)
To create the table

1 In a design window, create the data object you want and name it
(for example, Descriptions). Add attributes to it, specifying a text or
character data type for each attribute. (For instructions, see “From
Data Objects” on page 116. For sample attribute names, see the
example below.)
The attribute window for this Descriptions data object shows suggested names for
the three attributes and their order.
2 Assign one or more key fields. (See “Setting Key Fields” on page 393.)
3 Connect to the DBMS, then choose Host>Create DB Tables.
4 In the Create DB Tables dialog box, select the new data object in
the Data Model list.

5 Click Create.
6 When the new object is created, click Done.
Populating the Table

Once you’ve created the table in the database, you can populate it using
BI/Query Admin, BI/Query Update, or any other tool that allows you
to insert data into a table. (See “Updating Records in the Database” on
page 393.) You’ll need to know the database names of the data object
and its attributes; use the table below to determine them.
To Determine the Database Name
Of an Attribute In the attribute window, click the question

mark beside the attribute. The database name
appears after the period in the DB Name text
box (such as cust_num in retailers.cust_num). Or in
Design Mode, click the attribute in the attribute
window.
Of a Data Object In the attribute window, click the question

mark beside the attribute. The database name
appears before the period in the DB Name text
box (in retailers.cust_num, it’s retailers). Or in
Design Mode, click the data object, then
choose Design>Name in Database.

Creating the Query
Now you’re ready to create the query that retrieves the description for
an attribute. When users click the Load Comment button in the
Attribute dialog box, BI/Query submits the query. It replaces the
values ^0 and ^1 in the qualification with the database name of the
attribute and table, respectively, retrieves the attribute description, and
displays it in the Attribute Comment text box.
To create the query

1 Double-click the Descriptions data object.
2 In the attribute window, click the Description attribute.
3 Qualify the Attribute Name attribute with the value ^0 and the
Table Name attribute with the value ^1.
4 Choose Query>Save Query.

5 In the Save Query dialog box, click Data Values Queries.

6 Type query(info) into the Query Filename text box. (Use this exact
name, and use lower case.)
7 Click Save.
From Results Files

If your database stores a table containing attribute descriptions, you can
create results files that store them. When users click the question mark
for an attribute, then click the Load Comment button in the Attribute
dialog box, the results file is loaded and the result (the description) is
displayed. Results files take precedence over a query file, so they
provide descriptions faster. They also help reduce the load on the
database server because they eliminate the need to query the database
each time users click the Load Comment button. However, while you
can create one query file that retrieves information for all attributes for
a data model, you have to create a results file for each attribute you
want to describe.
If you’ve created or loaded a descriptions table, you can retrieve

descriptions from it and save them in results files. If you don’t have a
table of descriptions, you can use a text editor to create results files that
contain descriptions.
Using Descriptions in a Table

If you’ve created or loaded a Descriptions table, you can retrieve
descriptions from it and save them in results files.
To create an attribute description using a table

1 Create a query that retrieves the attribute description.
2 Double-click the Descriptions data object.
3 In the attribute window, click the Description attribute.
4 Qualify the Attribute Name attribute with the attribute’s database
name and the Table Name attribute with the table’s database name.

5 Submit the query.
6 In the results window, choose Results>Data Values Results.
7 In the Data Values dialog box, type the name table name.attribute
name(info) — for example, Retailers.cust_num(info) — into the
available text box. (You must use lower case.)
8 Click Save.
Using a Text Editor

You can use any text editor or spreadsheet program to create a results
file that contains a description of an attribute. To do so, create a results
file in BI/Query first. It will serve as a template for the description.
This is necessary because BI/Query stores results files in two separate
files. The .qrd file stores results in text format, and the .qrr file stores
additional information that BI/Query needs to read the text file.
Without the .qrr file, BI/Query can’t open the .qrd file. Once you’ve

created these files, you’ll replace the values in the .qrd file with the
attribute description.
To create an attribute description using a text editor

1 In an attribute window, click an attribute.
2 Submit the query.
3 In the results window, choose Results>Results Options.
4 In the Results Options dialog box, specify <CR> for the Record
separator and <None> for the End of File separator.
5 Click OK.
6 To create the results file template, choose Results>Data Values
Results.
7 In the Data Values dialog box, specify a name for the file. Use the
format table name.attribute name(info) — for example,
retailers.cust_num(info). (You must use the database names of the
table and attribute, and case is important. Make a note of the name
in the File Name text box; this is the name you’ll give the file you
create.)
8 In the text editor or spreadsheet program, type the attribute
description. (Don’t press Enter at the end.)
9 To replace the values in the .qrd file with the attribute description,
save the file in text-only format using the same path and file name.
Creating Ornaments
If you’ve placed Ornaments are text and graphic objects such as titles, logos, borders, and
an item on the notes that provide additional information, act as visual organizers, or
Clipboard, choose
Edit>Paste to
simply enhance the appearance of design windows.
paste it into a design window.
The resulting ornament
If the Edit Data Model and Save Data Model permissions have been
behaves in the same way as assigned, you can create ornaments in design windows and save them
those you create in BI/Query. with the data model. In a split data model, the ornaments that users
create are stored in the user layer; the ornaments the administrator
creates are stored in the administrator layer. Users can’t edit or delete
ornaments created by the administrator.

You can create ornaments in a variety of ways; you can edit, resize,
copy, move, and delete them. Autosizing is turned on automatically so
that an ornament fits the text or graphic it displays.
Ornaments can display text, icons, and pictures. You can create your
own text and use graphics stored in files. You can also use text and
graphics created in other applications by copying them from the
Clipboard. (This allows you to use graphics in formats BI/Query
doesn’t normally support.) Using the drawing toolbar, you can create
ornaments that display lines and shapes, such as circles and squares.
Icons are graphics with a specific dimension (32 pixels by 32 pixels). BMP format is a
Icon files usually have the extension .ico. If you’re using a monochrome good choice for
creating graphics
icon, you can assign a color to it. Pictures are stored in BMP, GIF, or
files for use in
WMF format. Graphics imported from the Clipboard are metafiles (the BI/Query. BMP format stores
most common format for graphics used by applications like Corel graphics with the lowest reso-
DRAW) or bitmaps (created in a paint program). lution and is available using
any paint program. Keep in
You can also use Windows’ Object Linking and Embedding (OLE) to mind, however, that graphics
can add substantially to the
create ornaments. (For more information about creating linked and size of a data model.
embedded objects, see “Using OLE” on page 426.)
To create an ornament
1 Make sure you have the Edit Data Model and Save Data Model
permissions.
2 In Design Mode, choose Layout>Create Ornament.
3 In the Create Ornament dialog box, type a name into the Name
text box that will identify the ornament when you’re assigning
access to the data model.

A fast way to copy 4 To create an ornament that displays text, click Edit Text, then use
text from the the Text Style dialog box to type the text and specify the options
Clipboard is to you want.
click Edit Text,
then copy the text into the OR
text box in the Text Style dia- To copy text from the Clipboard, click From Clipboard. Click Edit
log box. Text, then use the Text Style dialog box to specify the options you
want.
5 To create an ornament that displays an icon, click Icon. Click Select
Icon, then use the Select Icon dialog box to specify an icon. (If the
icon you want isn’t displayed, click Open File and use the Open
Icon File dialog box to specify one.) Click OK.
OR
To copy an icon from the Clipboard, click Icon, then From
Clipboard.
6 To create an ornament that displays a picture, click Picture. Click
Select Picture, then use the Open Picture dialog box to specify a
picture.
OR
To copy a picture from the Clipboard, click Picture, then From
Clipboard.
7 To add a border, click Border.
8 Click OK.
Assigning Icons to Data Objects

Instead of displaying the default rectangle, a data object can display an
icon. Icons provide visual cues to the information they represent in the
database and enhance the appearance of a data model. (Relationships
can’t display icons.) Icons are graphics with a specific dimension (32
pixels by 32 pixels). An icon file usually has the extension .ico. If you’re
The next time
you open the using a monochrome icon, you can assign a color to it.
Select Icon dialog
box, BI/Query To assign an icon to a data object
displays the default icons as
1 In Design Mode, click a data object.
well as the icons contained in
the last icon file you opened. 2 Choose Layout>Select Table Icon.

3 In the Select Icon dialog box, double-click an icon.
OR
Click Open File and use the Open Icon File dialog box to specify
an icon.
4 Click OK.
Specifying Colors
You can specify the color of windows and objects in a data model to
make them more attractive and to provide visual organization. For
example, using color draws users’ attention to important elements of
the data model.
You can specify default colors for the text and background for all
windows in the data model, for the text, borders, and background of
buttons and ornament, and for the borders and background of data
objects and relationships. For data objects that display icons, you can
specify the border but not the background color. When you save the
data model, the colors are saved with it. If you specify a composite
color (made up of dots of different colors) and your monitor doesn’t
support 256 colors, BI/Query may select the closest solid color match.

For Windows
You can specify colors for most windows using the Set Window Colors
dialog box. (To specify colors for design windows, see “For Objects
and Design Windows” on page 202.) The legend in the bottom left
corner indicates to which part of a window a color box corresponds.
Fill 1 and Fill 2 correspond to the fill colors for any boxes that appear
within a window. (For example, in results and update windows, Fill 1
corresponds to the column heading and row numbers cells, and Fill 2
corresponds to the results cells.)
To specify colors for windows

2 In the Preferences dialog box, click Window Colors.
3 In the Set Window Colors dialog box, specify the colors you want.
4 Click OK.
5 In the Preferences dialog box, click OK.
For Objects and Design Windows

You can specify colors for objects and design windows as well as for
individual objects. For example, you can specify the text, border, and
background colors of buttons and ornaments as well as the border and

background colors of data objects and relationships. For data objects
that display icons, you can specify the border but not the background
color. You can also use the Line Color and Fill Color tools to color
objects and specify the color of buttons and ornaments while you’re
creating or editing them.
To specify colors for objects and design windows

1 Choose Edit>Preferences. In the Preferences dialog box, click
Object Colors.
2 In the Set Default Object Colors dialog box, specify the colors you
want.
Border Background Text Background
Unselected Selected
lines lines
3 To apply colors to objects in the active design window, click Color

Objects in Active Window.
4 Click OK.

For Individual Objects
You can specify colors for individual data objects and relationships in a
design window.
To specify colors for individual objects

1 In Design Mode, click an object.
2 Choose Layout>Set Object Color.
3 In the Set Object Color dialog box, specify the colors you want.
4 Click OK.
5 To see the color, click off the object.
New Colors
The list you use to assign colors to windows and objects displays a basic
set of colors. If you don’t want to use these colors, you can create your
own. You can experiment with a broad range of additional colors
before choosing the one you want. BI/Query saves a color only if you
apply it to an object. If you create one or more colors that you’d like to
use in the future, take a note of the values in the boxes under the color
refiner so that you can readily re-create the color.
To specify a new color

1 In the appropriate dialog box, click a color, then click Custom Color.
2 In the Color dialog box, use the color refiner and luminosity bar
alternately until the color is the shade you want.

Color refiner Luminosity bar
3 Click OK.
4 In the appropriate dialog box, click OK.
Customizing Online Help

While BI/Query’s online Help provides answers to most users’
questions, the administrator can add information to it and create
customized Help files. The administrator can also augment the online
Help to provide information specific to the data model (data model
Help) and organization (site-specific Help).
Adding Information
You can add information directly to an online Help topic as an
annotation. When you add an annotation, then close the annotation
window, a paper clip icon appears in the topic you annotated. Users
can view the annotation by clicking the paper clip. When you save the
data model, the annotation is saved with it.

To add information to an online Help topic
1 In the Help file, choose Help>Contents, then display a topic.
2 Choose Edit>Annotate.
3 In the Annotate dialog box, type the information you want.
4 Click Save.
5 Close the Help file.
Creating Help Files

When you want to provide more information than is appropriate for
Customized Help Files
annotations in the online Help, you can create your own Help files.
These files must be:
You need a Help compiler (see your software vendor for commercially
• saved in Rich Text available applications) and a text editor that can save RTF (Rich Text
Format
Format) files, such as Microsoft Word. The Help compiler translates
• saved with the
extension .hlp
the RTF files into the required format. The files you create must follow
the format for Help files. (For instructions on using the Help compiler,
• stored in the same
folder as the data model see the documentation for that product.)
Creating Additional Help

You can add information to the data model about the tables it
represents and any restrictions that have been placed on them. You can
also add definitions of terms that are specific to an industry,
organization, or database. And you can give users additional guidance
about connecting to the DBMS by providing information about which

connection file(s) to use or, if they’re allowed to create their own
connection files, which parameters to specify.
Data Model Help

You can provide additional Help on the data model you’re using. The
Help file is named after the data model. When users run BI/Query, it
finds this Help file and adds a command to the Help menu. (For
example, if a data model is called mymodel.gql, call the Help file
mymodel.hlp. Running BI/Query creates Help>mymodel Help.) When
users choose this command, the online Help you’ve provided is
displayed.
To provide online Help about a data model

1 Create a Help file that contains the information you want.
2 Save it using the same name as the data model and with the
extension .hlp.
3 Store it in the folder where the data model is stored.
Site-specific Help
You can also provide additional Help about your organization. When
users run BI/Query, it finds this Help file and adds the corresponding
command to the Help menu. Users can choose Help>Site Help to
display the online Help you’ve provided.
To provide online Help about your organization

1 Create a Help file that contains the information you want about
your organization.
2 Save it using the name site.hlp.
3 Store it in the folder where the data model is stored.

Distributing a Data Model
Split Data Model 211 Distributing a Revised Version 226

Storing Each Layer in Separate Folders 212 Understanding the Save to Database
Options 228
Establishing the Path to the Administrator-
layer File 213
Combined Data Model 214
How the Data Model Is Stored 216
Setting Up to Publish 216
Checking System Permissions 217
Setting the Default Connection File 217
Using a Meaningful Name 217
Storing the Associated Files 218
Using a File Server 219
Using Diskettes 220
Using Mail 220
Using the Database 221
Minimizing File Size 222
Understanding BI/Query Database Tables 223
Granting Permissions 225
Distributing the Initial Version 226
Distributing a Data
Model
BI/Query provides a range of options for distributing a data model.
Depending on how your site is set up, you can distribute the initial
version of a data model as well as subsequent revisions by publishing it
to the repository or by using a file server, diskettes, or mail. You can
also distribute revisions efficiently using the database itself. It’s good
practice to compress or archive a data model before you distribute it.
This makes it easier to distribute the file on diskettes or over electronic
mail, and it saves storage space in the repository or on a file server.
Once you’ve distributed the data model, users can retrieve it from the
repository, run it from their own computers, or run it from the file
server.
Split Data Model

The first time you create a split data model, it consists of an Before you dis-
tribute a split data
administrator-layer file with the extension. gqa, a user-layer file with
model, keep a
the extension .gqu, a Queries folder containing queries and prompts, copy of the empty
and a DataVals folder containing data values query and results files. The user-layer file; you’ll need it
administrator-layer file contains the data objects and relationships, join later to revise the data model.
conditions, permissions, buttons, ornaments, and design windows that
you provide. With the exception of the path to the administrator-layer
file and a few default settings such as preferences, the user-layer file is
initially empty.
Distribute the administrator-layer file, its Queries and DataVals folders,

and the empty user-layer file according to the setup at your site. For
example, if you’re storing the data model on a file server, store the
administrator layer on the server, then distribute the empty user-layer
file to each user. If you’re storing the data model on users’ computers,

distribute a copy of the administrator layer and the empty user-layer file
to each user.
When a user opens the user-layer file with BI/Query User or

BI/Query Update, the path it contains to the administrator-layer file
allows BI/Query to find the administrator-layer file. BI/Query then
combines all the elements stored in both files. When the user-layer file
is stored in a separate folder than the administrator layer, BI/Query
creates empty Queries and DataVals folders the first time the user-layer
file is opened.
Storing Each Layer in Separate Folders

Whatever method you use to distribute the data model and have users
Split Data Model run it (for example, from their own computers or a file server), the best
way to maintain it is to store the user and administrator layers in
BI/Query
separate folders. That prevents user files from being inadvertently
overwritten by administrator files when you distribute new versions of
Administrator
the administrator layer. And it prevents administrator files from being
Layer
overwritten by user files when users create and modify their own files.
User Layer (You can store the administrator and user layers of a split data model in
the same folder if revisions to the data model don’t include
administrator query files, prompts, or data values files — that is, if
you’re distributing only the .gqa file.)
When you have more than one split data model, store each one in its
own folder with their corresponding administrator and user layers
stored in separate folders.
212 Distributing a Data Model

Administrator Layer
Sales.gqa Queries Data Values

• buttons
• drawing objects
• permissions
• default preferences
User Layer
Sales.gqu Queries Data Values

• computed attributes • prompts file • data values results files
• buttons • variables
• drawing objects
• preferences
Establishing the Path to the Administrator-layer File

When you distribute the initial version of a data model, you typically
change the location of the administrator-layer file. This requires users
to reestablish the path to that file when they open the user-layer file.
(See “Finding the Administrator Layer in a Split Data Model” on
page 42.)

You can eliminate this step by establishing the path for users before you
distribute the user-layer file. (Make sure you have write access to the
folders containing the administrator and user layers.) When users open
the user-layer file, BI/Query finds the administrator layer and combines
the contents of the two files.
To establish the path to the administrator-layer file

1 If you’re distributing using diskettes or mail, store the
administrator- and user-layer folders on your own computer in the
same location as they’ll be stored on each user’s computer (for
example, in C:\BI Query\Admin and C:\BI Query\User).
OR
If you’re distributing using the server, make sure you have the write
access you need. Copy the empty user-layer file to one write-
protected folder on the server and copy the administrator layer,
including the Queries and DataVals folders, to a separate write-
protected folder.
2 Open the user-layer file and reestablish the path to the
administrator-layer file.
3 Save the data model to save the new path with it.
Combined Data Model

A combined data model consists of the data model file with the
extension .gql, a Queries folder containing queries and prompts, and a
DataVals folder containing data values query and results files. When
you distribute a combined data model to users, you distribute the data
model file and its Queries and DataVals folders. When you have more
than one combined data model, store each one in its own folder.
When the user opens the data model file with BI/Query User or
BI/Query Update, he or she sees the core BI/Query application. Users
typically aren’t given permission to add their own customizations to a
combined data model because they’d be overwritten each time the
administrator distributed a new version of the data model.

Combined Data Model
Sales.gql Queries Data Values

• buttons
• drawing objects
• permissions
• preferences
Using the BI/Broker Repository

If your corporate query environment includes Hummingbird’s The terms publish
BI/Broker and you have the appropriate system permissions, you can and retrieve are
only used with
use the BI/Broker Repository to distribute a data model. You publish regard to the
the administrator layer of a split data model (or a combined data model) repository. You save a data
to the repository. Once a data model has been published, users can model locally, but you publish
retrieve it from the repository. (See “Retrieving a Published Data it to the repository. Similarly,
you open a data model from
Model” on page 39.) your local machine, but you
retrieve it from the repository.
The repository stores data models and their associated metadata —
information about who created them, who’s allowed to see and use
them, and so on. (The repository also stores queries and reports created
in BI/Query. See “Publishing Queries” on page 310 of this guide and
“Publishing to the BI/Broker Repository” on page 269 of the
BI/Query Reports user’s guide.)
There are compelling advantages to distributing data models by

publishing them to the repository. It allows you to place data models in
a central location where they can be made accessible to anyone
anywhere on the corporate Intranet, not just to the users of the full
BI/Query application. It makes data models easy to administer and

maintain. You can set security for the data models centrally. (See
“Using the BI/Broker Repository” on page 137). You don’t need to
load BI/Query on every desktop because users can open a data model
using their Web browser. When you need to update a data model, you
do that centrally as well, and your users receive the changes the next
time they retrieve the data model. This eliminates problems with
software and data currency.
If users have the appropriate permissions, they can publish their user
layers to the repository so that they, or other users, can retrieve them.
This gives them access to the same information whether they’re using a
computer in the office or a laptop at a trade show and makes it possible
for users to share their customizations.
How the Data Model Is Stored

If you want to Publishing a data model creates a package in the repository. A package
secure your data contains the data model and its associated queries, BI/Query reports,
model using the
data values, and connection files. It uses the same name as the data
repository, make
sure the data model isn’t also model and is given a version number, which BI/Query creates, then
available from a corporate file increments each time you publish the data model. (Each time you
server. Your security settings publish, BI/Query also saves the data model locally with the
will apply only to users who
incremented version number.)
access the data model using
the repository. See “Using the
BI/Broker Repository” on
page 137. Setting Up to Publish
Before publishing a data model, make sure that:
• you have system permissions that allow you to publish data models,
and your users have system permissions that allow them to publish
their user layers
• you (and any users who’ll be publishing their user layers) have
permission in BI/Query to edit and save the data model
• the data model is saved with a default connection file
• the data model is saved with a name that users will recognize when
they retrieve it from the repository

• the associated files are stored in the appropriate folders
Checking System Permissions

The BI/Broker administrator assigns the system permissions that allow
you and your users to publish. You need permission to publish data
models and users need permission to publish their user layers. (For
more information, see “Assigning System Permissions” on page 78 of
the BI/Broker administrator’s guide.)
Assigning BI/Query Permissions

You need permission in BI/Query to edit the data model, save the data
model, and save a split data model. Users need BI/Query permissions
to edit and save the data model. (See “Assigning BI/Query
Permissions” on page 217.)
Setting the Default Connection File

When you create the data model, it’s good practice to create a
connection file and set it as the default. (See “Using a Default
Connection” on page 69.) You can publish a data model that doesn’t
have a default connection file, but doing so requires users to create their
own connection file to run queries from BI/Query or from their Web
browser. In addition, queries scheduled by users require default
connection files.
Using a Meaningful Name

Save the data model using a file name that’s meaningful to your users.
The name you give the data model is the name that users will see when
they open the data model in BI/Query or in their Web browser.

Storing the Associated Files
Publishing a data model publishes the queries, data values, BI/Query
reports, and connection files associated with the data model. (It doesn’t
publish results files.) In order for these files to be published with the
data model, they must be stored in the appropriate folders within the
folder where the data model is stored. This structure is outlined in the
table below. (See also “As a Split Data Model” on page 126 and “As a
Combined Data Model” on page 127.) While queries and data values
files are automatically saved in the Queries and DataVals folders, you
must manually save reports in the Reports folder.
You can store These Are Stored Here

reports in a folder
other than the Queries Queries folder.
Reports folder
and still give users access to Data values DataVals folder.
them using a published data
model. When a data model BI/Query Reports Reports folder.
contains a button that gener-
Connection files With the data model.
ates a report stored outside the
Reports folder, the model
retains the reference to the It’s good practice to check the PublishLogger.txt file, found in your
report after publishing. To
Windows Temp folder, to verify that all reports were published. Check
enable users to generate the
report, store it on a network the file as soon as possible after publishing the data model because it’s
using a common path. (For available only until BI/Query Reports is next opened.
example, have all users map
the network location to drive To publish a data model to the repository
G.) Or use Universal Naming
Convention (UNC) path 1 In BI/Query, open an existing data model.
names, such as \\Sales Data OR
Model\Reports.
Create a data model, then save it. (See “Saving the Data Model” on
page 125.)
2 To set security on the model before publishing it, in Design Mode,
choose Edit>Set Security. (See “Using the BI/Broker Repository”
on page 137.)
3 Choose File>Publish.
4 In the Publish to Repository dialog box, under Also Publish,
specify which associated files you want to publish.

5 To require users to retrieve the latest version of the model
published, under Downloading, click Required.
6 Under Description, type information that will help users identify
the data model.
7 Click Publish.
8 Test the data model to be sure that it’s been published. Close it,
retrieve it. (See “Retrieving a Published Data Model” on page 39.)
Using a File Server

If users have access to a common file server, you can use it to distribute
a data model. When you distribute revisions to a split data model, when
users open their user-layer file, the path it contains to the administrator-
layer file allows BI/Query to open the revised version.
To distribute a data model using a file server

1 Copy the administrator layer of a split data model, including the
Queries and DataVals folders (or a combined data model), to the file
server.
2 Establish the path to the administrator layer. (See “Establishing the
Path to the Administrator-layer File” on page 213.)
3 Instruct users to copy the user-layer file to their own computers.

OR
Distribute it using diskettes or e-mail.
Using Diskettes
If you have a small number of workstations, it may be most practical to
distribute a data model using diskettes.
To distribute revisions, copy the revised administrator-layer file and the

Queries and DataVals folders of a split data model (or a combined data
model) onto diskettes. Then copy the contents of the diskettes onto
each user’s computer.
To distribute a data model using diskettes

2 Copy the empty user-layer file and the administrator layer of a split
data model (or a combined data model) onto one or more diskettes.
Copy the contents of the diskettes onto each user’s computer. On
each computer, open the user-layer file and establish the path to the
administrator-layer file, then save the data model to save the new
path with it.
OR
Store the folders in the same location on your computer as they’ll
be stored on each user’s computer. Open the user-layer file and
reestablish the path to the administrator-layer file. Save the data
model to save the new path, then copy the data model to each
user’s computer.)
Using Mail
If you have hundreds of users with access to different file servers and
you want to save the work of distributing a data model to each server,
you can use mail instead. Depending on the number and size of files
you need to send, consider compressing or archiving them first to
reduce transmission time.

You can send mail directly from BI/Query using any mail system that
supports Microsoft’s Messaging API (MAPI), such as Microsoft Mail.
(See “Using Mail” on page 445.) In your mail message, be sure to tell
users to store the administrator layer of a split data model (the
administrator-layer file and the Queries and DataVals folders) in one
folder and the user-layer file in another. They would store a combined
data model in its own folder.
To distribute revisions, mail the revised administrator-layer file and the

Queries and DataVals folders of a split data model (or combined data
model). Instruct users to store these files in the folder containing the
administrator layer (or the combined data model).
To distribute a data model using mail

2 Mail the empty user-layer file and the administrator layer of a split
data model (or the combined data model) to users. (If there is a
number of files, or if they’re large, compress or archive them.)
3 Instruct users to store the administrator layer of a split data model in
one folder and the user-layer file in another. (They would store a
combined data model in its own folder.)
Using the Database

If your site has hundreds of users, or if you’re running BI/Query on a
distributed network with offices located in different cities but sharing a
common database, you need an efficient way of distributing revisions to
the data model. If your site is set up to provide access to the BI/Broker
Repository, this is the simplest and most efficient way to distribute the
data model and any subsequent revisions. (See “Using the BI/Broker
Repository” on page 215.)
If you don’t have this additional functionality, you can store the
administrator layer of a split data model (or a combined data model),
including the Queries and DataVals folders, in the database. (If you

store BI/Query reports in a Reports folder with the data model, you
can store them in the database too.) This mechanism is strictly for
distributing revised versions of the data model; it can’t be used for
initial distribution.
Minimizing File Size

You can minimize the size of a data model in BI/Query by creating an
empty data model with a model ID. You can then include the content
in the data model and save the revised version in the database.
To minimize the size of a data model

1 Run BI/Query Admin.
2 In the Open Data Model dialog box, click Cancel.
3 In an empty design window, connect to the DBMS.
4 Choose File>Save. (To save it as a split data model, assign the Save
Split Data Model permission first.)
5 Choose File>Save To Database.
6 In the Save to Database dialog box, type a model ID.
7 Click Save.
8 Distribute the resulting data model file.

9 Revise the data model to include the actual content, then save the
revised version in the database.
Understanding BI/Query Database Tables

The first time you store the data model in the database, up to five tables
are created in the order listed below. The data in these tables shouldn’t
be modified in any way other than by saving revised versions of a data
model in the database using BI/Query Admin. The GQLMETA2 table
is created only if it doesn’t already exist in the database. All data models
that are saved in the database use the same GQLMETA2 table.
This Table Stores This
GQLMnnnn Information about the administrator-layer file of a

split data model (or a combined data model).
GQLVnnnn Contents of the data values files (optional).
GQLQnnnn Contents of the query files (optional).
GQLRnnnn Contents of the BI/Query report files (optional).
GQLMETA2 Model ID of the data model, its version number,

(a metatable) the names of tables storing data for the data model,
and other information. (To view the model ID,
choose Edit>Permissions, then click Model Info.)
The nnnn in the table names represent digits. All of the table names for a
data model use the same digits. Each table stores the model ID of the
model plus other pertinent information. The tables are illustrated below.

Attributes of the GQLMETA2 data object.
Attributes of the GQLMnnnn data object. The same attributes are contained in the
GQLQnnnn, GQLVnnnn, and GQLRnnnn data objects.
Before creating these tables, the data for the GQLDATA columns is
converted from binary format to ASCII format to be stored as a
varchar. The data in the other columns doesn’t need to be converted.
The columns in these tables are described below.
Attribute Description
GQLMODEL/ The data model ID.

GQLMODL
GQLVERS The data model version number.
GQLMAND Controls whether BI/Query displays a message to

indicate that downloading a new version of the data
model is optional or mandatory. (The message is for
users’ information only; they can still choose not to
download.)

Attribute Description
GQLMTAB The name of the table that stores the data model.
GQLDVTAB The name of the table that stores the data values.
GQLQRYTAB The name of the table that stores queries.
GQLREPTAB The name of the table that stores the BI/Query

reports.
GQLREASON The description of the changes contained in the

new version of the data model.
GQLFID A number identifying the query or data values file.
GQLSEQ A sequential number identifying each record in the

query or data values file.
GQLDLEN The length of the data in the record.
GQLDATA The actual data in the record.
Each time you store a new version of the data model in the database, the
GQLVERS column in the GQLMETA2 table is updated with the new
version number. The GQLMnnnn table is dropped and replaced with
another table (with new digits). If the Queries, DataVals, and Reports
folders are also stored in the database, the old GQLQnnnn, GQLVnnnn,
and GQLRnnnn tables are dropped, and new tables are created.
Granting Permissions
To enable users to use a data model stored in the database, you must
ensure that they have read access to, or select permission on, the tables
BI/Query creates. If users are granted access on a table-by-table basis
rather than automatic access to all new tables, you’ll need to determine
the names of the new tables. You can do that by creating a new data
model, loading the GQLMETA2 table, then using the corresponding
data object to query the table and retrieve the table names. Once you
know the table names, you (or the database administrator) can grant

users access to the tables by sending an SQL script to the DBMS using
BI/Query; alternatively, use a front-end DBMS tool.
Distributing the Initial Version

Even if you’re not Before saving the data model in the database, distribute the initial
planning to revise version to users.
the data model
right away, it’s To distribute the initial version of a data model in the database
good practice to store it in the
database before you initially 1 Using the file server, diskettes, or mail, distribute the empty user-
distribute it. This creates a layer file and the administrator layer of a split data model (or the
model ID in the data model, combined data model) to users.
something you need to dis-
tribute revisions to the data 2 Make sure users store the administrator and user layers of a split data
model using the database at a model in separate folders on their computers. (They would store a
later time. combined data model in its own folder.)
Distributing a Revised Version

To distribute a revised version of the data model in the database, you
simply save the data model in the database. This saves the administrator
layer (with the new ID and version number) and user layer on your
computer, then stores the administrator layer in the database. (If you
specify that BI/Query should also save queries, data values, and
BI/Query reports, they’re stored there too.) The administrator layer
stores the model ID of the data model, its version number, and a flag
that it’s been saved in the database. When users run BI/Query User or
BI/Query Update and open the data model, the administrator-layer file
(or the combined data model) checks for a new version in the database;
if one is stored there, users have the option of loading it.
Saving a revised data model in the database creates a number of tables.

(See “Understanding BI/Query Database Tables” on page 223.) Each
time you save a revised version of the data model in the database,
BI/Query deletes any older version that exists there along with the
tables it created.

Once you’ve stored a revised version of the data model in the database,
be sure to test it to make sure users are prompted to download the new
version and that the version they download contains the changes you
made.
To distribute a revised data model using the database

1 Save the data model. (To save it as a split data model, assign the
Save Split Data Model permission. To save it as a combined data
model, don’t assign the permission.)
2 Make sure that you’ve been granted the appropriate database
permissions and that users are granted permissions to the tables
BI/Query creates.
3 In BI/Query Admin, connect to the database.
4 Choose File>Save To Database.
5 In the Save to Database dialog box, specify the options you want.
You can view the

options you’ve
specified for sav-
ing a data model
in the database. Choose
Edit>Permissions, then click
Saves reports created in BI/Query Model Info.
Reports and stored in the Reports
folder with the data model
6 To specify additional information, click Options.

7 In the Save to Database Options dialog box, specify the options you
want. (For information on these options, see “Understanding the
Save to Database Options” on page 228.)

8 Click OK.
9 In the Save to Database dialog box, click Save.
10 Test the data model to be sure the new version has been saved in
the database. (In BI/Query User or BI/Query Update, open your
empty user-layer file and connect to the database. When you’re
asked whether you want to load the new version, click Yes.)
Understanding the Save to Database Options

The options you can specify in the Save to Database dialog box are
discussed below.
Option Purpose
Model ID A name, preferably one based on the data model

name, of up to 12 alpha-numeric characters
containing no spaces or special characters. It’s saved
with the model and stored in the GQLMETA2 table.
New Version The data model version plus one. (It must be one
digit greater than the version stored in the database.)
BI/Query automatically increments this number; you
can also increment it yourself. This information is
saved with the data model and stored in the
GQLMETA2 table.

Option Purpose
Downloading Specifies whether downloading is optional or

required. (Optional is the default.) It’s included in the
message that informs users that a new version of the
data model exists in the database. (It’s for users’
information only; even when you specify Required,
users can choose not to download.)
Also Save Saves the contents of the Queries, DataVals, and

Reports folders in the database (even if no changes
have been made to the files). When a user loads a
new version of the data model from the database,
these files are also loaded.
Description of A description of the changes in the new version of

Changes the data model. It’s stored in the GQLMETA2 table
and is the message that informs users that a new
version of the data model exists in the database.
Table Prefix This string is prefixed to the names of all tables

on Save BI/Query creates in the database. (Some databases
require the string to identify the owner or creator
name [Oracle] or database name [Teradata].) For
example, BI/Query creates the GQLMETA table
with the default SQL statement create table
GQLMETA (GQLMODEL char(12), GQLVERS
number, GQLMAND number, GQLMTAB char(8),
GQLDVTAB char(8), GQLQRYTAB char(8),
GQLREASON char(240));
If you type mydatabase. as the prefix on save, the SQL
statement becomes: create table mydatabase.GQLMETA
(GQLMODEL char(12), GQLVERS number,
GQLMAND number, GQLMTAB char(8),
Type the exact string, including the period.

Option Purpose
Table Prefix This string is prefixed to the names of all BI/Query

on Load tables in the database that BI/Query accesses when it
attempts to load a data model from the database.
(Some databases require the string to identify the
owner or creator name [Oracle] or database name
[Teradata].) For example, the GQLMETA table is by
default accessed with the SQL statement: select * from
GQLMETA where…
If you type myuserdatabase. as the prefix on load, the
SQL statement becomes: select * from
myuserdatabase.GQLMETA where…
Type the exact string, including the period.
This string is appended to the SQL string that

BI/Query uses to create tables in the database. For
example, the default SQL used to create the
GQLMETA table is: create table GQLMETA
(GQLMODEL char(12), GQLVERS number,
Additional If you type in tablespace XXX as the additional SQL,

SQL in Create the SQL statement becomes: create table GQLMETA
Table (GQLMODEL char(12), GQLVERS number,
GQLREASON char(240)) in tablespace XXX;

Maintaining a Data Model
Split Data Models 233

Combined Data Models 234
Refreshing the Data Model 235
Data Objects 235
Determining What Changes Have
Been Made 235
Applying the Changes to the Data Model 236
Updating Other Elements 237
Queries 238
Correcting the Queries 239
Maintaining a Data
Model
As the database and business needs change within your organization,
you’ll receive requests for new information and facilities. A group of
sales executives may need a button that queries a new table and
generates reports with new business forecasts. Or advanced users may
want to manipulate their queries by modifying the SQL so they can
retrieve information that they can’t using standard queries. BI/Query
provides a number of features that simplify the job of maintaining data
models so you can accommodate users’ needs.
Split Data Models

Maintaining a split data model is easier than maintaining a combined
data model because you can revise the administrator layer and distribute
it to users without affecting any customizations they may have made. In
addition, by storing the user and administrator layers in separate folders,
you can prevent the files stored in the corresponding Queries,
DataVals, and Reports folders from being inadvertently overwritten
when new versions of the administrator layer are distributed or when
users create and modify their own files. (For more information on split
data models, see “The Split Data Model” on page 25 and
“Understanding a Split Data Model” on page 126.)
Some of the time, you’ll revise a split data model by making your own
changes. At other times, you may want to incorporate a user’s
customizations (buttons, ornaments, queries, and so on) to make them
available to other users. In that case, you can incorporate only those
customizations into the administrator-layer file.
Changes to the administrator layer are stored in the administrator-layer

file along with the contents of the user-layer file. Changes to the user
layer are stored in the user-layer file.

When you make Once you’ve made the necessary changes and saved the data model,
changes to a split distribute the administrator-layer file. If you’ve added or made any
data model, use
changes to queries, prompts, data values files, or BI/Query reports,
BI/Query Admin
to change the administrator distribute those as well. (See “Distributing a Data Model” on page 211.)
layer; use BI/Query User or
BI/Query Update to change
To Do This Do This
the user layer.
Make changes to the 1 In BI/Query Admin, open the empty
data model copy of the user-layer file that was
created when you first saved the data
model.
2 Make the necessary changes, then
save the data model.
Include all or most of a 1 Make a copy of the user’s user-layer

user’s customizations in a file and open it with BI/Query
data model Admin.
2 Delete any customizations that you
don’t want to include, then save the
data model.
Include one or more of a 1 In BI/Query Admin, open your

user’s customizations in a empty copy of the user-layer file.
data model 2 In BI/Query User or BI/Query
Update, open the user’s user-layer
file.
3 Copy and paste the elements you
want to include, then save the data
model.
Combined Data Models

Combined data models are easy to maintain if users aren’t given
permission to make changes to the data model. When new versions of a
data model are distributed, users’ changes aren’t overwritten.
To make changes to a combined data model

1 Run BI/Query Admin.
2 Open the data model.
234 Maintaining a Data Model

OR
Retrieve the data model from the repository.
3 Make the necessary changes, then save the data model.
Refreshing the Data Model

As the database changes, you need an easy way to incorporate those
changes into the data model. BI/Query allows you to compare the data
model with the database and refresh the data model — for example, to
include data objects that correspond to new tables. Once a data model
has been refreshed, both you and your users can determine which
queries have been affected and update them accordingly.
Data Objects
Using BI/Query Admin, you can compare a data model to the current
structure of the database and refresh the data model to include the
following changes:
• new and deleted attributes

• attributes whose data types have changed — for example, char(12)
to char(20) or smallint to largeint
• attributes whose Nulls flag has changed — for example, from null to
not null
• tables that have been deleted or renamed
In addition to refreshing data objects, you can load any associated

metadata. (See “Providing Metadata” on page 179.)
Determining What Changes Have Been Made

BI/Query determines what changes have been made by comparing the
tables in the data model with their counterparts in the database and
displaying the differences.

To determine what changes have been made
1 Open a data model and connect to the database.
2 In a design window, in Design Mode, choose Host>Refresh Data
Objects.
3 In the Compare Data Objects dialog box, click Data Objects From
All Windows to display all the tables in the data model.
4 Select the data object(s) you want to refresh.

5 If you’re loading metadata for the tables and you don’t want to
display names and short descriptions, click Display Names and Short
Descriptions to deselect them.
6 Click Compare.
7 Apply the changes. (See “Applying the Changes to the Data
Model” on page 236.)
Applying the Changes to the Data Model

Once you’ve determined the differences between the data model and
the database, you can apply the changes to the data model. BI/Query
updates the data model and displays the changes. It also identifies the
computed attributes, object qualifiers, and join conditions that are
affected by the changes; you need to update those manually.

When you apply changes from a table, BI/Query automatically adds
any new attributes to the data model — even if you don’t select them.
Attributes that you don’t select appear in the corresponding attribute
window in BI/Query Admin in Design Mode with the Visible toggle
turned off. They aren’t visible in BI/Query User or BI/Query Update.
BI/Query hides these attributes instead of removing them to make it

easier to maintain the data model. If BI/Query removed them, it
would recognize that the attributes still exist in the database and would
prompt you to add them the next time you refreshed the data model.
Including and hiding the attributes avoids this. There’s an added
benefit: if you later need to give users access to these attributes, you can
simply make them visible by turning the Visible toggle on rather than
refreshing the data model.
To apply a change to the data model

1 In the Refresh Data Objects dialog box, select a data object.
Displaying the changes in the database for the selected data object.
2 Select the change(s) you want to apply, then click Apply Changes.
Updating Other Elements

Once you’ve refreshed the data model, you need to make any necessary
changes to computed attributes, object qualifiers, and join conditions

that use attributes that have changed in the database. Warnings in the
log window identify changes you need to make yourself, for example
***Warning: credit limit occurs in computed attribute

(retailers.credit limit +1) of object retailers
Be sure to read each warning carefully because it may not apply to the
data object it’s listed under. For example, if both the Retailers and Sales
data objects contain the Credit Limit attribute and Credit Limit is used
in a computed attribute, BI/Query produces a warning for both data
objects even though it applies only to Retailers.
Queries
After a data model has been refreshed, some of the stored queries may
not work — for example, because they include attributes that no longer
exist in the database. When a user opens a data model, BI/Query
compares the dates on which the data model and the queries were last
refreshed. If the data model was refreshed more recently than the
queries, BI/Query prompts the user to refresh them.
BI/Query compares each query with the data model and identifies
where it uses attributes or data objects that no longer exist — for
example, in qualifications or join conditions. BI/Query detects only
when attributes, data objects, and join conditions have been deleted,
not when they’ve simply changed. (For example, it doesn’t detect
changes to data type.)
While only the administrator can refresh a data model, both the
administrator and users can refresh queries. Data values queries can’t be
refreshed.
To refresh queries
1 Choose Query>Refresh Queries.
2 In the Refresh Query dialog box, select the queries you want to
refresh.

3 Click Refresh.
4 In the message box that gives the differences between the query and
the data model, click Change to change the query.
A message box gives the differences between the query and the data model.
5 Rerun queries that have been refreshed to make sure they still
retrieve the results you want.
Correcting the Queries

You can correct specific queries or all the queries affected by changes to
the data model. BI/Query makes the changes, then saves the queries in
the Queries folder. BI/Query also saves the original queries there with
the extension .bak, then displays a list of the changes it applied.

The Log Window displays the changes to the selected query.
Rerun the queries you’ve modified to make sure they retrieve the same
results. Often they won’t — for example, when an attribute has been
deleted from a qualification or join condition.

Getting the Results You Want
Specifying Data Formats 245
Using Data Values, Prompts, and Variables 257
Building Queries 291
Building Advanced Queries 315
Working with Results 377
Updating Records in the Database 393

Specifying Data Formats
For Typing Data 245

Default Format 246
Matching Attribute Formatting 246
Numbers 247
Dates 247
Invalid Entries 248
For Displaying Data 248
Formatting Numbers 249
Formatting Dates 250
Inserting and Deleting Characters 250
Substituting Values 251
Converting Two-digit Years 252
Specifying Data Formats
Data formats govern how numbers, dates, and text characters are You specify data
represented. For example, numbers can be represented as 99999, formats for reports
in BI/Query
99,9999, and 99.999, and dates can be represented as 1/14/1998,
Reports. (See
1998.1.14, and January 14, 1998. BI/Query lets you specify different “Specifying Data Formats” in
formats for different purposes. the BI/Query Reports user’s
guide.)
This Format Is This
Data-entry The format in which BI/Query interprets and

displays data when you type it into a qualification,
prompt, or variable or when you add, modify, or
delete records.
Display The format in which BI/Query displays data in

results windows. It can also be set for individual
attributes.
The Control Panel settings on your computer determine the default

data-entry and display formats. The administrator can change the
default display format for each attribute in BI/Query. (With the Edit
Data Model and Save Data Model permissions, users can also change
the display format and save it with the data model.) The display formats
specified in BI/Query take precedence over the default database
formats and Control Panel settings for results windows.
For Typing Data

The format in which you type dates and numbers (the data-entry format)
applies when you type data that will be used to update the database (in
BI/Query Admin and BI/Query Update).

Default Format
The default data-entry format is normally based on the Control Panel
settings on your computer. Any changes you make to these settings
take effect immediately.
To specify the default data-entry format

1 In the Regional Settings Control Panel (Windows 95) or the
International Control Panel (Windows NT), specify a format.
Matching Attribute Formatting

When you set the By default, the data-entry format applies when you edit values in
data-entry format qualifications, prompts, and variables, but you can change it to match
to match attribute
the attribute formatting specified in BI/Query. (For information on
formatting, it
applies to all attributes for specifying attribute formatting, see “For Displaying Data” on
which attribute formatting has page 248.) Using the attribute format rather than the default format is
been specified. To use the useful when you want to display an integer (such as 2017434411) as a
default format for an attribute,
set its format to the default.
phone number (201-743-4411) or when a currency is specified as a
(See “For Displaying Data” number and you want the data to appear with the currency symbol.
on page 248.) (You can’t change the data-entry format for character data types.)
If you use the attribute format rather than the default data-entry format
for numbers and dates, be careful when the format is one that “hides”
information. For example, if the format for a date attribute doesn’t
include the year, such as MMM/D, if you type Sept 15, 1998 into a
qualification, BI/Query converts it to Sep 15 but inserts Sept 15, 1998
into the SQL for the query. If you edit the value to be Sept 25,
BI/Query interprets it as the complete value (as Sep 25, not as Sept 25,
1998). The “hidden” year is lost, and the query may retrieve
unnecessary or incorrect data. If you use attribute formatting, it’s good
practice not to use “hidden” formats for attributes.
BI/Query hides the year when the attribute uses a “hidden” format.
246 Specifying Data Formats

BI/Query is flexible in recognizing the data you type. You can use the
format specified in the Control Panel or a comparable one. If
BI/Query is able to interpret the format, it automatically converts it to
the default data-entry format. If in doubt, use the Control Panel format.
To specify a data-entry format that matches the attribute format

2 In the Preferences dialog box, click Attribute under Qualification
Format.
3 Click OK.
Numbers
When you specify numbers (including currencies), simply type them.
BI/Query converts them to the format specified in your Control Panel.
BI/Query applies the default numeric format.
Dates
You can type dates using the date format specified in your Control To ensure that
Panel or any comparable format. For example, if the default date format BI/Query inter-
is 1/14/1998, you can type dates in the format 1998.1.14, 1.14.1998, prets dates cor-
rectly, make sure
January 14, 1998, or even 1998 Jan 14. As long as you include the day, that you type dates using all
month, and year and BI/Query is able to unambiguously interpret the four digits of the year.
format, it converts the date to the default format.
BI/Query applies the default date format.

Invalid Entries
BI/Query alerts you when you type data in a format it can’t interpret.
To return to the entry and correct it, click Cancel in the alert window.
(If you’re not sure what format to use, check your Control Panel.) If
you want BI/Query to accept the entry you typed, click Add { }; your
entry appears within brace brackets. When you submit a query,
BI/Query enters the entry as straight text into the SQL string. This is
an escape mechanism designed for users with advanced knowledge of
SQL database access.
For Displaying Data

To view an When results are returned from the database, the format in which
attribute’s default they’re displayed (the display format) may not be how you want them
display format,
click the question
represented in the results window. BI/Query offers a wide range of
mark beside the attribute in display formats for formatting columns of data. You can change the
the attribute window. default display format for each attribute in an attribute window, and
after results are returned, you can specify a display format in a results
window. Saving the data model saves the new format.
You may need to change the display format for a particular set of
results. Whether you select a single cell or an entire column, the
formatting is applied to all the results in the column.
To specify a display format

1 In an attribute window, click the question mark beside an attribute.
In the Attribute dialog box, click Edit.
OR
In a results window, select one or more cells or column headings,
then choose Results>Format.

2 In the Specify Display Format dialog box, specify a format. (For
instructions, see the sections below.)
3 Click OK.
Formatting Numbers
You can select from a number of predefined formats for numeric data. When columns
You can also modify one of these formats by including, for example, a contain currency,
include the cur-
dollar sign or percent symbol as a prefix or suffix. You can also
rency symbol —
highlight negative values in red, hide zero values, and display in $, £, ¥, and so on. This saves
exponent notation. users doing it in reports they
create in BI/Query Reports.
To format numbers
1 In the Specify Display Format dialog box, click Numeric.
2 Select a format from the Predefined Formats list.

3 To modify the format, use the available text and check boxes.

4 Click OK.
Formatting Dates
You can select from a number of predefined formats for dates, and you
can include the time.
To format dates
1 In the Specify Display Format dialog box, click Date.
2 Select a format from the Predefined Formats list.

3 To include the time, click Show Time.
4 Click OK.
Inserting and Deleting Characters

By inserting and deleting characters in character, number, and date
strings, you can adjust data formats to include punctuation, include
information that is missing, and exclude unwanted information.
BI/Query recognizes special characters that tell it to include or exclude
characters in the original data. For example, you can specify that
telephone numbers stored in the database in the format
6135484355x15 be displayed as (613) 548-4355 Ext. #15 by typing
them in the format (###) ###-#### Ext. \#*.
To insert and delete characters

1 In the Specify Display Format dialog box, click String.

2 Type a format into the Format String text box using the following
special characters:
# inserts a character from the original data
_ suppresses a character in the original data
* inserts the remaining characters in the original data
\ inserts the next character(s) you type; use it to include one of the
special characters (for example, to insert the # character, type \#)
3 Click OK.
Substituting Values
You can substitute values in a results column to highlight trends, focus
on general information rather than specific details, and flag exceptions.
For example, it may be useful to assign a single value (the word
Unsatisfactory) to a range of values (all sales below a certain amount) so
that you can easily identify areas that require further attention. You can
also apply a color for emphasis in any corresponding reports. (The color
is displayed only in standard reports, not reports created using
BI/Query Reports.)
To substitute values in results

1 In the Specify Display Format dialog box, click Computed String.

To insert a row, 2 Select an operator from the list beside the Comparison Value text
place the cursor in box.
the row below
which you want
3 Type the value you want to replace into the Comparison Value text
to insert the row, then click box.
Insert Row. To delete a row 4 To change the value, type a new value into the corresponding
you’ve specified, choose the Replacement Value text box.
first (blank) item from that
row’s operator list. 5 To specify more than five sets of values, use the scroll bar to display
more blank rows.
6 To specify a color for the new value in the corresponding standard
report, click the color button and specify a color.
7 Click OK.
Converting Two-digit Years

When you type a two-digit year or import a data source that contains
two-digit years, BI/Query automatically converts them to four-digit
years. This ensures that your business is unaffected when the century
changes from 1999 to 2000.
If you change the To enable BI/Query to convert two-digit years, you need to specify
date window after the range of dates in your data, then establish whether dates are sliding
typing two-digit
or fixed. The start and end years of sliding dates are incremented by one
years, the new
date window doesn’t apply to each time the current year changes. The start and end years of fixed
the dates you’ve already dates don’t change.
entered.
The type of date you specify applies to all Hummingbird BI products,
so what you specify in one product affects all other products you use.

Consider your organization’s requirements carefully before choosing a
date type.
You use the Date Entry dialog box to specify a start year for your data.
BI/Query automatically calculates an end year that’s 99 years after the
start year. When you type two-digit years in BI/Query, it adds a
century prefix so that the years fall on or between the start year and the
end year displayed. For example, let’s say the start year is 1918, and the
end year is 2017. BI/Query adds the prefix 19 to all two-digit years
greater than or equal to 18; it adds the prefix 20 to all two-digit years
less than or equal to 17. When you type 45 in BI/Query, it’s converted
to 1945; when you type 15, it’s converted to 2015.
When the current year changes (for example, from 1998 to 1999) and
you’ve specified dates as sliding, the start year changes to 1919 and the
end year changes to 2018. (When you’ve specified dates as fixed, the
years remain the same — 1918 and 2017.)
To convert two-digit years

1 Choose Edit>Date Entry.
2 In the Date Entry dialog box, type a start year for the date window.
3 Click Sliding or Fixed.

4 Click OK.

Using Data Values, Prompts, and Variables
Data Values Files 257 Variables 280

Naming and Storing Data Values Files 258 Creating Variables 281
Creating Data Values Results Files 260 Specifying Attributes and Operators 283
In BI/Query 261 Including Functions 284
Using a Text Editor or Spreadsheet Including Variables 285
Program 262
Including Prompts 285
Creating Data Values Query Files 264
Importing Variables from a File 286
Using Data Values Files to Alias Data 266
Prompts 269
Naming and Storing Prompts 270
Creating Single Prompts 270
Group Prompts 271
Creating the Prompts 272
Creating the Title 273
Testing the Prompt 273
Conditional Prompts 274
Creating the Group Prompt 275
Creating the Data Values Query File 276
Testing the Conditional Prompt 277
Importing Prompts 279
Using Data Values,
Prompts, and Variables
When you qualify a query, you can insert one or more data values into
the qualification to retrieve results that correspond only to those values.
(See “Qualifying Queries” on page 293.) BI/Query provides a number
of facilities that use data values as building blocks for complex but
useful queries.
For example, you can use data values files to retrieve specific data values.
These can be query files or results files. Depending on how they’re
named, you can use them to qualify an attribute when you build a
query or insert into a prompt when you submit a query to the database.
You can also use prompts, which request you to insert one or more
values into a qualification when you submit a query. You can combine
BI/Query’s data values and prompting facilities to insert values into one
prompt that are based on values you inserted into another.
And you can use variables to perform user-defined operations in a

query. Variables can determine data values in the database, and they can
perform calculations based on database functions. You can combine
BI/Query’s data values, prompting, and variables facilities by including
prompts in variables.
Data Values Files

Both the administrator and users can make qualifying a query more
efficient by creating data values files. Data values files allow users to
qualify an attribute by selecting from a list of data values stored in the
database. Data values query files retrieve a subset of values from the
database; data values results files display a stored set of values. Data
values results files further reduce the load on the database server because
they eliminate the need to query the database each time users need a list

of values. How these files are named determines which file BI/Query
uses and when they’re used.
When users select from a list of data values stored in the database,
BI/Query queries the database for all the values for the attribute.
However, the administrator can disable access to this default query.
This is recommended when loading all the values in the database uses
large number of values or when those values are simply numbers and
dates. (For more information, see “Securing Access to Data Values” on
page 135. For information on qualifying an attribute with data values,
see “Using Data Values” on page 296.)
Naming and Storing Data Values Files

Data values query and results files have specific uses and require special
naming conventions. When they’re used for a specific prompt, they use
the prompt name. When they’re used in qualifications and prompts, they
use the format data object name.attribute name (such as retailers.cust_city). (In
this case, data object also means actual relationships.) Be sure to use the
case used in the attribute or prompt name.
Data values query and results files are stored in the DataVals folder. If
the administrator-layer and user-layer files of a split data model are
stored in separate folders, each layer has its own DataVals folder that
stores its own files.
The file names you give these files determine the order in which
BI/Query searches for the files in the DataVals folder as well as where
the corresponding data values are available. The following table shows
the order in which BI/Query uses data values files, their names, and
where they’re used.
258 Using Data Values, Prompts, and Variables

Data Values File Descriptive Name Available In
Results file prompt name Prompt dialog

named after the box
corresponding
prompt
Query file prompt name Prompt dialog

named after the box
corresponding
prompt
Results file data object name.attribute name Qualification

named after the tree and
data object and prompt dialog
attribute used in box
the query
Query file data object name.attribute name Qualification

named after the tree and
data object and prompt dialog
attribute used in box
the query
For example, when you’ve inserted a prompt into a qualification and

you click the data values icon to display data values in the qualification
prompt dialog box, BI/Query checks to see if there’s a data values file
with the same name as the prompt. If there is, BI/Query uses it;
otherwise, it uses a data values file named after the data object and
attribute used in the query. A data values file named after a prompt
always takes precedence.
If BI/Query doesn’t find a data values file, and if data values for an
attribute haven’t been disabled, BI/Query runs a default query that
retrieves all the unique values in the database for the attribute and
displays the results in a list.

Creating Data Values Results Files
A data values results file stores a set of data values for an attribute. It
allows you to access a data values list without querying the database
each time you need it. A data values results file can be linked to a
prompt or an attribute so that the corresponding results are available in
a data values list in a qualification tree or in a qualification prompt
dialog box. When you click the data values icon, the data values stored
in the data values results file for an attribute are displayed in a list.
Data values icon displays

Qualification tree
Qualification prompt dialog box
Creating data val- If data values haven’t been disabled for an attribute, you can access all
ues results files is the data values in the database instead of just those in the data values
useful only when
results file. Select more from the data values list, then in the Data Values
the data changes
infrequently. If a file needs to dialog box, click Load All.
be updated often, create a data
values query file instead. (See You can create a data values results file from results you’ve retrieved in
“Creating Data Values Query BI/Query as well as by using a text editor or spreadsheet program.
Files” on page 264.)

In BI/Query
When you create a data values results file in BI/Query, be sure to
eliminate duplicate values from your results. You can select just the
attribute to retrieve all of the values in the database, or you can qualify
the query to retrieve only specific values.
This query returns a list of cities in the state of New York, sorted alphabetically.
To create a data values results file in BI/Query

2 Click its Sort box, then apply any other restrictions you want.
3 Choose Query>Modifiers>Distinct.
4 Submit the query.
6 In the Data Values dialog box, specify a name for the file. (See
“Naming and Storing Data Values Files” on page 258.)

7 Click Save.
Using a Text Editor or Spreadsheet Program

You can use any text editor or spreadsheet program to create a data
values results file that contains a set of customized data values. To do so,
create a data values results file first; it will serve as a template for the
customized data values. This is necessary because BI/Query stores data
values results files in two separate files: the .qrd file, which stores results
in text format, and the .qrr file, which stores additional information that
the application needs to read the text file. Without the .qrr file,
BI/Query can’t open the .qrd file. Once you create these files, you’ll
replace the data values in the .qrd file with the customized data values.
When you type values into the text editor or spreadsheet program, type
them in the order and case you want them to appear in BI/Query,
pressing Enter after each value. For example:
DirectorEnterExecutiveEnterManagerEnter
It’s good practice to test the file; the icon displays the results in the
order you typed them.
To create a data values results file using a text editor


4 Submit the query.
5 In the results window, choose Results> Results Options.
6 Under Separators in the Results Options dialog box, specify <CR>
in the Record text box and <None> in the End of File text box.
7 Click OK.
9 In the Data Values dialog box, specify a name for the file. (See The name you
“Naming and Storing Data Values Files” on page 258.) give the data val-
ues results file
10 Click OK.
must be the same
11 In a text editor or spreadsheet program, type a list of values, pressing as the name you give the data
Enter after each one. values results file template.
12 Save the file using the same path and file name as the .qrd file you
created in BI/Query.
13 To test the file in BI/Query, click the attribute used to create the
original results, click its Qualify box, then click the data values icon
in the qualification tree.

Creating Data Values Query Files
A data values query operates like any other standard query but retrieves
specific data values for an attribute. (You can’t use super queries as data
values query files.)
A data values query file can be linked to a prompt or an attribute so that

the corresponding results are available in a data values list in a
qualification tree or in a qualification prompt dialog box. When you
click the data values icon, then click Data Values, the data values
returned from a data values query for an attribute are displayed in the
Data Values dialog box.
Qualification tree
Qualification prompt
dialog box

If data values haven’t been disabled for an attribute, you can access all
the data values in the database instead of just those returned by the data
values query by clicking Load All.
To retrieve the results you want, you need to qualify the attribute that’s
linked to that data values query file. For example, if a data values query
returns data values for Title, apply the qualification to Title. Be sure to
eliminate duplicate values from your results. You can select just the
attribute to retrieve all of the values in the database, or you can qualify
it to retrieve only specific values.
This query returns a list of staff titles, sorted alphabetically.
To create a data values query file

5 In the Save Query dialog box, click Data Values Queries, then
specify a name for the file. (See “Naming and Storing Data Values
Files” on page 258.)

6 Click Save.
Using Data Values Files to Alias Data

Using BI/Query’s data values facility, the administrator can provide
data aliasing. Data aliasing allows users to select from a list of data values
while BI/Query inserts the corresponding values into the query. Data
aliasing is particularly useful in a data model that provides an attribute
that represents a code or number in more than one data object but
doesn’t provide a descriptive attribute in each one.
To set up data aliasing, you create a data values results file or data values
query file that contains two columns; the data in the first column aliases
the data in the second. Only the data in the second column is displayed
in the list of data values. Instead of selecting a value for a qualification
that may be difficult to understand or remember, such as a staff person’s
ID, users can select a more meaningful value, such as the person’s last
name. While the user selects the name from a list of data values,
BI/Query inserts the corresponding ID into the SQL string.
When a user qualifies the ID# attribute, then clicks the data values icon
in the qualification tree, BI/Query either loads the data values results
file or submits the data values query and displays staff last names as a list.

When the user selects a name from the list, BI/Query inserts the
corresponding ID into the qualification tree and the SQL string.
ID for Peterson
To create a data values file that aliases data

1 In an attribute window, click an attribute that represents the value
to be sent to the database.
2 Click a second attribute that represents the value to be displayed in
the data values list, then click its Sort box.

3 Save the query as a data values query file. (See “Creating Data
Values Query Files” on page 264.)
OR
Submit the query and save the results as a data values results file.
(See “Creating Data Values Results Files” on page 260.)
4 Name the file after the first attribute (for example, Staff.ID #).

Prompts
A prompt is a request by BI/Query to insert a value into a qualification
when you submit a query. You can qualify a query with a prompt so
that each time users submit the query, they’re prompted to specify the
qualification value they want to use. (See “Using a Prompt” on
page 298.) You can also include a prompt in a variable in order to
qualify a variable without inserting a value each time the variable is
used. (See “Including Prompts” on page 285.) And you can qualify a
data object or actual relationship with a prompt in order to restrict
users’ queries to specific information in a table. (See “That Include a
Prompt or Variable” on page 106 and “Securing Access to Rows in a
Column” on page 133.)
For tables that contain a large number of rows, prompts improve query
performance and prevent users from submitting queries that retrieve
more data than they need. For example, regional sales managers may
need sales information only for countries in their region. When they
submit queries against the table containing countries, the queries
prompt them to specify the countries they want.
You can submit queries using single prompts, group prompts, which
are made up of a number of individual prompts, and conditional
prompts, in which the data values returned for one prompt are based on
the value you specify for another.

Naming and Storing Prompts
Single prompts can have any name, although they’re usually named
after the attribute they qualify. (For example, if you create a prompt
that qualifies the City attribute, the prompt is most useful when you
name it City.) Group and conditional prompts have special naming
conventions. (See “Group Prompts” on page 271 and “Conditional
Prompts” on page 274.)
BI/Query stores prompts in a single Prompts file in the Queries folder.

If the administrator-layer and user-layer files of a split data model are
stored in separate folders, each layer has its own Queries folder that
stores its own Prompts files.
The data values that you can insert into a prompt depend on whether
the corresponding data values file is named after the data object and
attribute used in the query or after the prompt. (See “Naming and
Storing Data Values Files” on page 258.)
Creating Single Prompts

A single prompt prompts you for one or more values for an attribute.
To create a single prompt

1 Choose Edit>Prompts.
2 In the Prompts dialog box, click New.

3 In the Edit Prompts dialog box, type a prompt name into the
Prompt ID text box.
4 Type a descriptive phrase into the Prompt String text box.
5 Click OK.
Group Prompts
A group prompt is made up of two or more single prompts. All the
prompts have the same group name and are displayed together in one
or more dialog boxes depending on the number of prompts in the
group. For example, a group prompt can be made up of prompts for
the Country and City attributes so that a query that qualifies those
attributes prompts you to select first a country, then one or more cities.

A group prompt can display up to five prompts in one dialog box. If it
contains more than five prompts, the first dialog box displays the first
five prompts, the second displays the next five, and so on. A query can
contain more than one group prompt.
When queries are qualified with more than one prompt, grouping
them in a dialog box allows users to see all the prompts at once and
reduces the number of steps in the query. It also relates one prompt to
another. (See “Conditional Prompts” on page 274.)
Creating the Prompts

Each prompt in a group prompt begins with a group name and an
exclamation mark. For example, in the prompt Retailer!City, the group
name is Retailer! and the prompt name is City. If you don’t specify an
order for the prompts, they’re executed in alphabetical order — for
example, Retailer!City is run before Retailer!Country. If you want the
prompts to appear in a particular order, specify the order in their
names. For example, to ensure that the country prompt is run before
the city prompt, use the names Retailer!2City and Retailer!1Country.
To create the prompts for a group prompt

1 Create at least two single prompts with a group name. (See
“Creating Single Prompts” on page 270.)

Creating the Title
The dialog box that displays a group prompt displays the default title
Please Enter Qualification Values. You can create your own title for this
dialog box by creating a prompt that begins with the group name
you’re using, two exclamation marks, and Title (for example,
Retailer!!Title). You must use the word Title with a capital T. The
prompt string you type becomes the title.
To create the title for a group prompt

2 In the Prompts dialog box, click Edit.
3 In the Edit Prompt dialog box, type the name of a prompt into the
Prompt ID text box.
4 In the Prompt String text box, type a title for the prompt.
5 Click OK.
Testing the Prompt

Before distributing a group prompt, it’s useful to test it to ensure that it
works properly. When you submit the query, the group prompt dialog
box displays the prompts in the order and with the title you specified.
To test a group prompt

1 In an attribute window, click the attributes you want.
2 For each attribute, click its Qualify box, choose Edit>Prompts,
then specify a prompt.

3 Submit the query.
4 In the group prompt dialog box, specify a value in the first text box.
(Type it or use the data values icon to select a value from a list.)
Data values icon
5 Specify a value in the second text box.

6 Click OK.
Conditional Prompts
Conditional prompts are group prompts in which the data values available
for one prompt are determined by the value specified for another. For
example, a prompt for cities provides only those cities that correspond
to the value you specify for the country prompt. You create a

conditional prompt by creating a group prompt, then creating a data
values query file that retrieves data values based on the value specified
for one of the prompts.
When users select data values from a list instead of typing them into a
prompt, conditional prompts eliminate values they don’t need and
make it easier for users to find the values they do need. Conditional
prompts are also useful in an EIS interface because they provide a
means of drilling down to obtain increasingly detailed information. (See
“EIS Data Model” on page 85.)
Displays only cities in USA
Creating the Group Prompt

Be sure to create a group prompt that prompts you in the order you
want. For example, to ensure that you’re prompted first for a country,
then for a city, name the first prompt Retailer!1Country and the second
prompt Retailer!2City.
To create the group prompt

1 Create a group prompt with a group name. (See “Group Prompts”
on page 271 and “Creating Single Prompts” on page 270.)

Creating the Data Values Query File
Now you create a data values query file that returns unique values for
the attribute that corresponds to the second prompt. Be sure to
eliminate duplicate values from your results.
To create the data values query file

1 In an attribute window, click an attribute that corresponds to the
second prompt.
2 Click its Sort box, then choose Query> Modifiers>Distinct.
3 Qualify the attribute that corresponds to the first prompt with the
first prompt.
4 Apply an operator. (See “Restricting Qualifications with an
Operator” on page 302.)
This query retrieves a list of cities for the country specified for the Retailer!1Country
prompt.
5 Save the query as a data values query file using the name of the
second prompt in the group prompt. (See “Creating Data Values
Query Files” on page 264.)

Testing the Conditional Prompt
Before distributing a conditional prompt, it’s good practice to test it to
ensure that it works properly.
To test a conditional prompt

2 Qualify the attribute that corresponds to the first prompt with the
first prompt.
3 Qualify the attribute that corresponds to the second prompt with
the second prompt.
4 Apply an operator. (See “Restricting Qualifications with an
Operator” on page 302.)
The Country attribute is qualified by the Retailer!1Country prompt, and the City
attribute is qualified by the Retailer!2City prompt.
5 Submit the query.

6 In the group prompt dialog box, type a value into the first text box.
OR
If data values haven’t been disabled for the attribute, click the data
values icon and select a value from the list.

7 Click in the second text box.
8 Click the data values icon that appears, then click Data Values.
Clicking Data Values submits the data values query file (Retailer!2City) and displays
the results in the Data Values dialog box.
9 In the Data Values dialog box, select the value(s) you want.
(Depending on the operator you applied to the qualification, you
can select one or more values.)
10 Click Insert.

11 In the group prompt dialog box, click OK.
Importing Prompts
You can distribute prompts by copying and renaming your Prompts file
(located in the Queries folder); other users can then import the prompts
contained in this file. You can also import prompts stored in someone
else’s Prompts file.
To import prompts
2 In the Prompts dialog box, click Import.
3 In the Select Import File dialog box, select the file that contains the
prompts you want to import, then click Open.
4 In the Import Prompts dialog box, select the prompts you want
under Prompts to Import, then click Import.

5 Click Done.
6 In the Prompts dialog box, click Done.
Variables
A variable (or automatic variable) performs a user-defined operation in a
query. That operation specifies the search conditions for the query and
can contain anything that’s valid in an SQL WHERE clause (attributes,
operators, values in the database, calculations, functions, subqueries, or
stored procedures). Variables take the work out of formulating
potentially complex queries.
When you qualify an attribute with a variable, the operation is

executed when you submit the query. Variables are especially useful for
queries that are run on a regular basis or are scheduled to run at specific
intervals. Variables can carry out a variety of operations. In their
simplest form, they determine values in the database so you don’t have
to specify them in queries. For example, when you need information
about retailers in a particular country, you can use a variable to
determine which states or provinces are included in that country rather
than specify each state or province yourself.

Variables can also perform calculations based on database functions to
work out date, time, and other values. For example, you can use a
variable to retrieve retailer sales that were placed today, before today,
and so on. The variable determines what today’s date is, and BI/Query
returns the corresponding results.
You can include prompts and other variables within a variable. For
example, a variable can prompt you to specify a week and a year. When
you qualify a query with the variable, the results correspond to the
week and year you specified.
Variables are stored in the Prompts file in the Queries folder. If the
administrator-layer and user-layer files of a split data model are stored in
separate folders, each layer has its own Queries folder and its own
Prompts file. You can import variables stored in another user’s Prompts
file. (See “Importing Variables from a File” on page 286.)
Creating Variables
When you submit a query qualified with a variable, the variable is You can test that
executed as a complete expression; it replaces the entire qualification, an expression
returns the results
including the attribute and operator. As a result, the variables you
you want by cre-
create must contain information about what attribute to qualify and ating a calculated attribute
what operator to use. (An exception occurs when the variable is a that uses the same expression.
stored procedure that already contains attribute and operator Use the attribute in a query,
then verify the results. (For
information.) information on creating cal-
culated attributes, see “Creat-
You can create a variable that includes a specific attribute and operator. ing Attributes That Perform
You can then use the variable to qualify that attribute using that Calculations” on page 334.)
operator — even when you’re qualifying a different attribute in the
query. You can also create variables that qualify other attributes using
other operators.
You can also add to a variable any value, calculation, function,

subquery, or stored procedure that’s valid in an SQL WHERE clause.
The syntax for variable expressions depends on the DBMS you’re
using; the examples provided in this chapter are based on ODBC.

To create a variable
1 Choose Edit>Variables.
2 In the Variables dialog box, click New.
3 In the Edit Automatic Variable dialog box, type a name and

description into the Name and Description text boxes.
Attribute placeholder Specific operator Determines today’s date
This variable determines today’s date. You can use it to qualify a query for sales at
the end of a quarter rather than qualify the query with a specific date.

4 Specify the expression you want the variable to perform. (See the
instructions below.)
5 Click OK.
Specifying Attributes and Operators

Specifying an attribute, an operator, or both ensures that BI/Query uses
that attribute or operator in the variable even if your query qualifies a
different attribute or uses a different operator.
(({fn quarter(Âttribute^)} = {fn quarter({fn

curdate()})}) AND
({fn year(Âttribute^)} = {fn year({fn
year(Âttribute^)})}) AND
(Âttribute^ <= {fn curdate()}))
Using the EQUAL (=) operator in this variable ensures that the results are based on dates
within the current quarter, up to and including today’s date. If you specify a different
operator in the qualification tree, BI/Query ignores it.
You can also use placeholders instead of specific attributes and operators.
When you submit a query, BI/Query replaces the placeholders in the
variable expression with the attribute and operator you specified when
you qualified the query. For example, you can qualify a query with a
variable that includes the Âttribute^ and Ôperator^ placeholders.
When you submit the query, Âttribute^ is replaced with the current
attribute, and Ôperator^ replaces itself with the current operator. (The
current attribute and operator are those in the qualification tree).
Using placeholders also allows you to create a variable that calculates

today’s date; you can apply the variable to any date attribute in the data
model. The operator you specify in the qualification determines how
the attribute is compared to today’s date — before (<), after (>), equal
to (=), and so on. No matter what attribute or operator you use in the
qualification, the query returns results based on today’s date. For

example, if you specify the Greater Than (>) operator, the query
returns results for all dates greater than today’s date.
Âttribute^Ôperator^ {fn curdate()}
Placeholders Determines today’s date

This variable can qualify any date attribute, and any operator can be assigned to the
qualification.
To specify an attribute and operator

1 In the Edit Automatic Variable dialog box, select a data object from
the Table/Attributes list.
2 To specify an attribute, select an attribute from the list under
Table/Attributes, then click Insert Selection.
OR
To specify a placeholder for an attribute, with the cursor in the
Expression text box, click Âttribute^.
3 To specify an operator, type it into the expression.
OR
To specify a placeholder for an operator, with the cursor in the
Expression text box, click Ôperator^.
4 Click OK.
Including Functions
Variables often include functions that perform some type of calculation.
Using the DBMS function for the current date, for example, a variable
can determine the date for the beginning of the month to allow you to
find all retailer sales received since that date.
Âttribute^ Ôperator^ {fn curdate()}

- {fn dayofmonth({fn curdate()})}
To include a function in a variable

1 In the Edit Automatic Variable dialog box, click Function.

2 In the Insert Function dialog box, select a function. You can use most
scalar functions
available in your
DBMS even if
they don’t appear in the
Other Functions list. Type the
function into the Expression
text box. (Check your DBMS
documentation for the correct
format.)
A list of built-in SQL functions appears under Functions. For certain DBMS types, a
list of scalar functions appears under Other Functions.
3 Click Insert.
4 To include the value to which you want the function to be applied,
edit the expression.
Including Variables
You can use variables as building blocks for more complex variables.
Âttribute^Ôperator^ <<Today>> - 1
The Today variable determines today’s date and allows you to create a variable that
determines yesterday’s date.
To include a variable in a variable

1 In the Edit Automatic Variable dialog box, with the cursor in the
Expression text box, click Variable.
2 In the Variables dialog box, select a variable, then click Insert
Variable.
Including Prompts
When you need to qualify a variable but you don’t want to restrict it to
a specific value, you can include a prompt so that you can insert a value
each time the variable is used. (For more information on prompts, see
“Prompts” on page 181.)

{fn week(Âttribute^)} Ôperator^
<<weekofyear!1week>>AND
{fn year(Âttribute^)} Ôperator^
<<weekofyear!2year>>
This variable includes the weekofyear! group prompt, which prompts you to specify first
the week you want, then the year. The variable returns results based on the week and
year you specify.
To include a prompt in a variable

1 In the Edit Automatic Variable dialog box, with the cursor in the
Expression text box, click Prompt.
2 In the Prompts dialog box, select a prompt, then click Insert Prompt.
Importing Variables from a File

When you want to use variables created by another user, you can
import them from that user’s Prompts file.
To import variables from a file

1 Choose Edit>Variables.
OR
If you’re qualifying a query, with the cursor in the qualification text
box, click the data values icon, then select Variables from the list.

2 In the Variables dialog box, click Import. When other users
want to use vari-
3 In the Select Import File dialog box, open the Prompts file
ables that you’ve
containing the variables you want.
created, make a
copy of your Prompts file and
rename it to avoid overwrit-
ing other users’ files. Then
distribute your file using the
corporate server, e-mail, or
Intranet.
4 In the Import Variables dialog box, select the variable(s) you want
under Variables to Import, then click Import>>.
5 Click Done.

Building Queries
The Basics 291 Publishing Queries 310

Qualifying Queries 293 Retrieving Queries 312
Using the Qualification Tree 293
The Qualification Text Box 293
The List Icon 294
The Data Values Icon 295
The Operator List 295
The Condition Box 296
Using Data Values 296
Using a Prompt 298
Applying Multiple Qualifications 300
Combining Qualifications 301
Restricting Qualifications with an
Operator 302
Making Comparisons 303
Matching Character Strings 304
Matching Items in a List 305
Finding a Range of Values 306
Finding Unknown Values 306
Applying Your Own Operator 307
Saving Standard Queries 307
Saving Results 309
Building Queries
In order to retrieve information from the database, you need to build
queries (sometimes called ad hoc queries) that specify the data you want.
This chapter describes the typical ways you can build and save queries
and results. For those whose querying environment includes the
BI/Broker Repository, it also describes how you publish queries to the
repository and retrieve them. To take advantage of advanced querying
capabilities, see “Building Advanced Queries” on page 315. To specify
how results should be organized, see “Sorting Results” on page 377
and “Reordering Columns of Results” on page 382. To take advantage
of scheduling capability in the BI/Broker Repository, see “Scheduling
Queries” on page 357.
The Basics
You build queries using the data objects and relationships in a design
window. You specify which attributes you want to retrieve, and you
qualify your query to restrict your results to specific information in the
database. (For information on qualifying queries, see “Qualifying
Queries” on page 293.)
While you can use more than one object in a design window to build a
query, you can’t build a query that uses data objects and actual
relationships in different windows.
You can build a query in one step. Or you can specify the initial
qualifications, submit the query, review the results, then revise the
query until you retrieve exactly the results you want.
Most of the time, you’ll qualify queries with one or more data values or
variables. You can also combine qualifications to avoid ambiguity and
restrict them with an operator. To qualify queries with attributes,
subqueries, and variables, or to reverse a qualification to retrieve the
opposite results, see “Building Advanced Queries” on page 315.

To build a query
1 In a design window, double-click the data object(s) or actual
relationship(s) for which you want to retrieve results.
You don’t need to 2 In the attribute window, click the attributes that represent the
click the attribute information you want to retrieve.
you’re qualifying if
you don’t want to
include it in the results. For
example, if you qualify Coun-
try, you don’t need to click it
if you don’t want to retrieve
data for countries.
3 To place restrictions on the query, click the Qualify box for an

attribute.
4 In the qualification tree, specify a qualification. (See “Using the
Qualification Tree” on page 293.)
5 If there’s more than one relationship between the objects you’re
using, click a relationship to specify the “path” you want to use.
6 To eliminate duplicate rows from your results, choose Query>
Modifiers>Distinct.
292 Building Queries

7 Choose Query>Submit Query.
Qualifying Queries
When you formulate queries, you can qualify the query with one or
more values in order to retrieve results that correspond only to those
values. For example, if you’re interested in sales figures only for France,
you can build a query that qualifies the Country attribute with France.
Qualifying a query restricts results to the data that satisfies the
qualification.
Using the Qualification Tree

The qualification tree identifies the attribute you’re qualifying and
provides the means of qualifying it. It includes the qualification text
box, the list icon, the data values icon, the operator list, and the
condition box.
Data values
icon
Attribute Operator Qualification List
list text box icon
Condition box
The Qualification Text Box

You can enter one or more items into the qualification text box to qualify
an attribute. For example, by qualifying the Country attribute with

France, Germany, and Spain, you can restrict the results to retailers
located in France, Germany, and Spain. You can type the values you
want or select them from a list. Selecting from a list is easier than typing
and avoids potential uncertainty about capitalization and spelling.
If your database is case-sensitive and the Case-sensitive Comparisons

preference is set, you must type a qualification that uses a character in
the case in which it’s stored in the database. If this preference isn’t set,
case isn’t important. If you’re not sure what value to type or how it’s
stored, use the data values icon or choose Edit>Data Values to select
one from a list.
You can enter dates in a variety of formats (such as 1998/1/14,

1.14.1998, or January 14, 1998) as long as BI/Query can
unambiguously determine the dates you enter. When in doubt, use the
default format specified in your Control Panel. (For more information
about specifying date formats, see “For Typing Data” on page 245.)
When you’ve finished entering a qualification in the qualification text

box, click outside the qualification. The qualification appears in the
qualification tree; a list of values entered into a qualification is
represented by the list icon.
Single value List of values
Once you’ve specified a qualification, you can view and modify it by

clicking the qualification value or the list icon.
The List Icon

You can use the list icon beside the qualification text box to add and
modify entries in a list of qualification values, delete all entries, and
view the list you’ve entered. You can display a value in the
qualification text box by clicking the list icon, then choosing the value
from the list. Alternatively, use the arrow keys on your keyboard to

display each value in the qualification text box. (See “Using Data
Values” on page 296.)
List icon
Add a new value to the list
Remove all values from the list
Current list of values
The Data Values Icon

The data values icon appears beside the list icon. It provides an easy
means of inserting one or more specific values (data values), prompts,
or variables into a qualification. Prompts prompt you for one or more
data values, while variables perform a user-defined operation. (See
“Using Data Values” on page 296, “Using a Prompt” on page 298, and
“Qualifying a Query with a Variable” on page 320.)
The Operator List

Once you’ve qualified a query, you can use the operator list in the
qualification tree to specify how to restrict a qualification. For example,
you can apply the Greater Than (>) operator to find all the records that
have a value greater than the qualification you specified. (See
“Restricting Qualifications with an Operator” on page 302.)

Operator list
The Condition Box

The condition box appears above the attribute identified in the
qualification tree. If you specify multiple qualifications in a query, you
can use the condition box to combine them (see “Combining
Qualifications” on page 301) or give them the opposite meaning (see
“Reversing Qualifications” on page 319). You can also remove a
qualification from a query: click the condition box, then press Delete.
Using Data Values

Choosing from a You can qualify an attribute with data values to restrict the results of a
list of data values query to those values. For example, by qualifying the Country attribute
is useful when
you’re not sure
with USA, the results will include only retailers located in the United
how the values are stored in States. By qualifying Country with France, Germany, and Spain, the
the database — that is, how results will include only retailers located in France, Germany, and
they’re spelled and what capi- Spain. You can type the values you want or select them from a list.
talization they use.
The data values icon provides an easy means of entering values into a
qualification. Unless the administrator has disabled data values for an
attribute, clicking the data values icon submits a default query, which

retrieves all the unique values in the database for the attribute. The
values are displayed in the Data Values dialog box, where you can select
the one(s) you want to enter into a qualification. You can also create
data values query files that retrieve specific data values from the
database. (See “Creating Data Values Query Files” on page 264.)
If data values for an attribute haven’t been disabled, clicking the data values icon
displays all the values for the attribute stored in the database.
If you or the administrator have set up a local data values results file for
an attribute, a list of data values is displayed instead of the Data Values
dialog box. (See “Creating Data Values Results Files” on page 260.)
If a local data values results file has been set up for an attribute, clicking the data values
icon displays a list of data values.

If data values haven’t been disabled for an attribute, you can access all
the data values in the database instead of just those provided by the data
values results file by choosing more from the list, then clicking Load All
in the Data Values dialog box.
To qualify an attribute with one or more data values

1 In an attribute window, click the Qualify box for an attribute.
2 With the cursor in the qualification text box, click the data values
icon, then select Data Values from the list.
3 In the Data Values dialog box, select the values you want, then
click Insert.
4 To view the values you’ve entered, click the list icon. (See “The
List Icon” on page 294.)
Using a Prompt
You can qualify an attribute with a prompt so that you’re prompted for
a value when you submit the query. Once you’ve built the query, you
can save it and use it again to retrieve the same results for a different
value. This is particularly useful if you’re creating your own EIS
interface and you want to associate the query with a button to allow
you to zero in on specific information. (See “EIS Data Model” on
page 85 and “Prompts” on page 269.)
To qualify an attribute with a prompt


2 With the cursor in the qualification text box, click the data values When a query
icon, then select Prompts from the list. prompts you for
one or more val-
3 In the Prompts dialog box, select a prompt. (If the prompt you
ues, you can insert
want isn’t listed, you can create it. See “Creating Single Prompts” them, or you can leave the
on page 270.) prompt blank. (Leaving it
blank returns all of the possi-
ble values for the attribute.)
To view the query’s SQL, in
the attribute window, choose
Query>Show Query, then
click Show Prompt Values. If
you specified prompt values,
they’re displayed in the SQL.
If you didn’t, the prompt
qualification is removed from
the WHERE clause to reflect
the actual query that will be
submitted to the DBMS.
4 Click Insert Prompt.

5 In the attribute window, apply an operator. (See “Restricting
Qualifications with an Operator” on page 302.)
6 Submit the query.

7 In the qualification prompt dialog box, specify the value(s) you
want. (For more information, see “The List Icon” on page 294 and
“The Data Values Icon” on page 295.)
8 Click OK.
Applying Multiple Qualifications

When you qualify more than one attribute, or when you qualify the
same attribute more than once, you can specify that the query must
satisfy both qualifications or either one.
To apply multiple qualifications

1 Qualify one or more attributes with one or more qualifications.
Click to change operator
Changing the qualification from and to or finds retailers in either France or Germany.

2 To have a query satisfy both qualifications, leave the word and
between them in the qualification tree.
OR
To have the query satisfy one qualification, click the word and to
change it to or.
Combining Qualifications
When you’ve specified two or more qualifications in a query, you can
combine them so that they take precedence over those that aren’t
combined. For example, the qualification Country = France and
Country = Germany and Credit Limit < 60,000 is ambiguous; it’s
unclear whether its purpose is to produce a) retailers located in France
or Germany, all with a credit limit of under $60,000, or b) retailers
located in Germany with a credit limit of under $60,000 plus retailers
located in France. To avoid ambiguity, you can combine this query to
read: (Country = France or Country = Germany) and Credit Limit <
60,000; the results will consist of all retailers located in France or
Germany, all of whom have a credit limit of under $60,000.
Combining qualifications in this way is the equivalent of using brackets
in a mathematical expression — for example, 2 x (3-1) — to indicate
the part of the expression that should be calculated first.
To combine qualifications
1 In an attribute window, select the condition boxes above the
qualifications you want to combine.

2 Choose Query>Combine.
When a qualifica- 3 To change the condition from and to or, click the word and.
tion is combined,
you can separate
it. Click the con-
dition box above it, then
choose Query>Uncombine.
Restricting Qualifications with an Operator

When you qualify an attribute, BI/Query displays the = operator in the
qualification by default. When BI/Query generates the SQL for the
query, it automatically applies the = operator to single values and IN to
lists, then finds all the records in the database that match the

qualification(s) you specify. For example, by qualifying the Country
attribute with Spain, the results include only retailers located in Spain.
Using the operator list in the qualification tree, you can apply other
operators to restrict a qualification. Keep in mind that the >, >=, <,
and <= operators allow you to insert a single value when you submit
the query; the BETWEEN and NOT BETWEEN operators require
two values (for an upper and lower range); the =, IN, NOT IN, and
<> operators allow you to insert one or more values.
Operator list
Making Comparisons
When you need to compare values to find, for example, those that are
larger or smaller, earlier or later in the alphabet, or equal to a value, you
can specify the value on which you want to base the comparison in the
qualification text box and apply the appropriate comparison operator.
While comparisons are typically applied to numbers, they can also be
applied to characters and dates. With characters and dates, < means
earlier in the alphabet or in chronological order; > means later.

This Qualification Results in This
Credit Limit = 2,000 Credit limits exactly equal to 2,000.
Credit Limit != 2,000 All credit limits except those equal to

2,000.
Credit Limit < 2,000 Credit limits smaller than 2,000.
Credit Limit <= 2,000 Credit limits smaller than or equal to

2,000.
Credit Limit > 2,000 Credit limits larger than 2,000.
Credit Limit >= 2,000 Credit limits larger than or equal to

2,000.
Matching Character Strings

You may not be sure how an item is stored in the database, or you may
want to find records for which there is some kind of pattern. For
example, you may need information about a retailer and aren’t sure of
the spelling of the name but know that it begins with Cars. (Is it
Carson, Carsen, Carsin?) Similarly, you may need a list of retailers
whose postal code is 3011.
You can specify the characters you want to match in the qualification
text box and apply the Begins with, Contains, or Ends with operator.
BI/Query automatically inserts the Like operator and the % symbol in
the appropriate position in the SQL string. (The % symbol is a wildcard
that can represent any number of characters. Its position in the
qualification indicates what part of the character string needn’t match
the qualification.)
When you submit the query, BI/Query looks for all instances of values
that match the qualification you specified. You can also type the %
symbol into the qualification text box to find a match for any string of
characters, regardless of where it falls.

The Does not begin with, Does not contain, and Does not end with operators
function in the same way as their counterparts but allow you to find
items that don’t contain the character string you specify. For example,
you can use them to find retailers whose postal code isn’t 3011.
You can apply these operators to character strings, not numbers or dates.
Retailer name Begins Sweet Indulgence, Sweets to Go.

with Sweet
Retailer name Contains Peppermint Twist, Dulces Irresistbles.

ist
Zip/Postal code Ends F-3011, D-3011, DK-3011.

with 3011
Retailer name does not All retailer names except those

begin with Sweet beginning with Sweet.
Retailer name Does not All retailer names except those

contain ist containing ist.
Zip/Postal code Does not All Zip and postal codes except those
end with 3011 ending with 3011.
Matching Items in a List

When you qualify an attribute with a list, BI/Query automatically
displays the = operator in the qualification tree. When BI/Query
generates the SQL for the query, it applies the IN operator to the list.
The IN operator allows you to find all records that match any one item
in the list. You can also find items that don’t match those in a list.

Country IN France, France, Germany, and Spain.

Germany, Spain
Country NOT IN All countries except France, Germany,

France, Germany, Spain and Spain.
Finding a Range of Values

You can qualify an attribute with a range of values to obtain results
within a particular range. The range is inclusive, retrieving the lower
value and the upper value as well as the values in between. To do so,
enter the values as a qualification list (see “Using Data Values” on
page 296) and apply the BETWEEN operator. You can also find results
that are outside a particular range by applying NOT BETWEEN.
Credit Limit Credit limits between and including

BETWEEN 2,000 and 2,000 and 5,000 (2,000, 2,456, 4,646,
5,000 5,000, and so on).
Credit Limit NOT Credit limits outside this range (100,

BETWEEN 2,000 and 1,400, 5,001, 6,111, and so on).
5,000
Finding Unknown Values

A NULL value occurs when no value has been entered into the
database. It doesn’t represent a zero or a character space but is instead a
placeholder for missing information. Because NULLs don’t match
anything, you can’t retrieve them using standard comparison
qualifications such as Greater Than or Less Than. To include or
exclude rows for which information hasn’t been recorded, apply the IS
NULL or IS NOT NULL operator to an attribute.

Credit Limit IS NULL Credit limits for which there is no value.
Credit Limit IS NOT Credit limits for which there is a value.

NULL
Applying Your Own Operator

In addition to applying the standard SQL operators provided in
BI/Query, you can restrict a qualification using any other operator that
your DBMS supports. (For information about operators your DBMS
supports, see the documentation for your DBMS.)
To apply your own operator

1 In an attribute window, select User defined from the operator list in
the qualification tree.
2 In the Enter Text dialog box, specify an operator.
3 Click OK.
Saving Standard Queries

It’s good practice to save any query that you want to use more than
once so that you don’t have to rebuild it each time. Once a query is
saved, it can be:
• loaded, then submitted to the DBMS

• automated by being linked to a button
• stored (by the administrator) with the data model in the database

You save a standard query when you don’t manipulate the results — for
example, you don’t filter them, obtain a range, or combine two or
more results sets. (When you do any of these things, then save a query,
it’s saved as a super query. Saving a super query saves not only the
standard query or component queries but also the operations that you
applied to the results. See “Creating Super Queries” on page 337.)
This standard query retrieves information about retailer sales without manipulating the
results in any way.
Saving a query in To save standard queries, you must have the Save Queries permission.
a results window You can save a standard query to make it available in BI/Query, and
saves the query
that generated the you can save the corresponding SQL string to make it available to other
results. Saving in any other applications.
window saves the current
query. BI/Query saves queries with the extension .qry and stores them in the
Queries folder by default, but you can also store them elsewhere. Data
values queries are saved in the DataVals folder. (See “Creating Data
Values Query Files” on page 264.) If the administrator-layer and user-
layer files of a split data model are stored in separate folders, each file
has its own Queries and DataVals folders.
To save a standard query

1 Make sure you have the Save Queries permission.
2 Formulate a query. (You can submit the query before saving it, but
don’t manipulate the results.)

4 In the Save Query window, specify a file name.
5 To save the query in a location other than the Queries folder, click
Export and specify the name and location of the file.
6 Click Save.
Saving Results
You can save query results to a file in order to use them again in
BI/Query or to use them in other applications, such as word processors
and spreadsheet programs.
BI/Query saves results as two separate files with the extensions .qrd and
.qrr. The .qrd file contains the results stored in text format so that other
applications can open them. (BI/Query automatically supplies the .qrd
extension when you save results.) The .qrr file stores additional
information that BI/Query needs to open the results file (such as
formats for each column and the SQL used to retrieve the results).
When you load results in BI/Query, you see only the .qrd file. If you
need to delete a results file, delete both the .qrd and .qrr files.
The results are stored on your computer so that you can manipulate
them locally instead of in the database, thereby reducing the demands
on the server.

To save results
1 In the results window, choose Results>Save Results.
OR
To submit results directly to a file, choose Query>Submit Query
— To File.
2 In the Save Query Result to File dialog box, specify the name and
location of the file.
3 Click Save.
Publishing Queries
You may want to make a query available to other users with similar
querying needs. If your corporate querying environment includes
Hummingbird’s BI/Broker and you have the appropriate system
permissions, the BI/Broker Repository provides an excellent way for
people throughout the organization to access your queries. You can
include queries when you publish and secure data models (see “Setting
Up to Publish” on page 216), and you can also publish and secure
queries individually. In addition to making your queries available to
other users, publishing your queries makes it possible to schedule them.
(See “Scheduling Queries” on page 357.)
Although you don’t have to save a query before you can publish it, the
data model on which the query is based must have been published. If it

has not been published, BI/Query requires that you publish it before
you can publish a query based on it. In order to be published, a query
must also be the current query. You must have appropriate system
permissions to publish data models and queries.
When you publish a query, it’s automatically saved locally, in the

Queries folder where the data model is stored. (Data values queries are
stored in the DataVals folder.) Then it’s published to the repository
with the security settings of the data model. Once it’s published, you
can also change its security settings (see “Using the BI/Broker
Repository” on page 137).
To publish a query to the repository

1 In a saved and published data model, create or load a query.
2 Choose Query>Publish Query.
3 In the Publish Query dialog box, specify a name for the query.
4 If you’re publishing a data values query, click the Data Values

Queries check box.
5 Click Publish.

Retrieving Queries
You can retrieve queries that you publish to the repository as well as
queries that other users publish if they have set security to give you
access to them. To retrieve a query, you must first open the data model
on which it is based. (You can open it locally if you have a local copy
of it or you can open it by retrieving it from the repository.)
To retrieve a query
Retrieve is avail- 1 Choose Query>Retrieve.
able from the
2 In the Retrieve Query dialog box, click a query, then click
Query menu only
when you’ve
Retrieve.
opened a data model for
which queries are stored in
the repository.
3 To both retrieve and submit the query, click a query, then click
Submit.

Building Advanced Queries
Qualifying One Attribute with Another 315 Editing an Operation 343

Using a Subquery 316 Correcting Errors 345
Reversing Qualifications 319 Common Errors and Their Solutions 346
Qualifying a Query with a Variable 320 Building Queries with a Circular Path 347
Modifying the SQL 321 With a Correlation 348
Modifying a Query for Selected Results 323 Without a Correlation 352
Creating Dynamic Relationships 324
Using Queries to Perform Calculations 326
Applying Functions to Attributes 327
Specifying Functions 329
Specifying a Group Order 331
Grouping Before Calculating a Function 331
Grouping After Calculating a Function 332
Grouping without Functions 333
Creating Attributes That Perform Calculations 334
Working with Super Queries 337
Creating Super Queries 337
That Filter Results 338
That Combine Results 339
Editing Super Queries 340
Understanding the Super Query Window 340
Editing a Component Query 342
Building Advanced
Queries
You can build queries that perform sophisticated operations in order to
retrieve very specific results. For example, you can qualify an attribute
with another attribute, another query, or a variable that performs a
user-defined operation that works out certain values such as a date or
time for you. You can even reverse qualifications to retrieve the
opposite results. You can also build advanced queries that perform
calculations on your data or queries that execute one or more queries
and manipulate the results by filtering or combining them. And you can
build complex queries with a circular path. Some of these operations
may require more in-depth knowledge of BI/Query, SQL and database
syntax, and the business rules of your organization (such as the period
that corresponds to your fiscal year).
Qualifying One Attribute with Another

BI/Query allows you to build sophisticated queries in which one
attribute qualifies another attribute. For example, a Current Receivable
attribute can be qualified by a Credit Limit attribute to retrieve only
retailers whose current receivables exceed their credit limits. When you
qualify one attribute with another, you must specify the database name
for the second attribute.
To qualify one attribute with another

2 With the cursor in the qualification text box, choose Edit>Insert
DB Name.
3 In the Insert DB Name dialog box, select a data object and
attribute.

This query returns a list of retailers along with their current receivables and credit
limits. The Sort box indicates that the list will be sorted alphabetically by name. The
Current Receivable attribute is qualified by Credit Limit to retrieve only retailers
whose current receivables exceed their credit limits.
4 Click Insert Name.
Using a Subquery
You can access your data in more dynamic ways by qualifying a query
with a nested query statement, or subquery. A subquery returns values
for a single attribute. By qualifying a query with a subquery, you can
create sophisticated queries that provide more direct access to very
specific data.
Let’s say you want to retrieve information about retailers with the
highest credit limit. You can find the value of the highest credit limit
first by issuing a query that includes the Credit Limit attribute with the
316 Building Advanced Queries

MAXIMUM function applied to it. Then copy the value from the
results window to the Clipboard. When you generate a new query,
qualify the Credit Limit attribute by pasting in the value. When you
submit the query, BI/Query returns only the results for retailers with
that credit limit. Because the maximum credit limit can change (a new
retailer with a higher credit limit may be added to the database), you
need to repeat these steps each time you want to retrieve information
based on the highest credit limit.
A subquery provides a more direct way of retrieving the same results

regardless of the actual credit limit value. In the example above, the
subquery contains the Credit Limit attribute with the MAXIMUM
function applied to it. Because a subquery qualifies an attribute in the
query it qualifies, it can include only one attribute. When you build a
query, you insert the subquery into a qualification to obtain results
based on the maximum credit limit. BI/Query submits the subquery
first, then uses the corresponding results to qualify the query. By using
the subquery to qualify the query, you don’t have to determine the
maximum value in the database and transcribe it to your query. In
addition, the query continues to provide the desired results when the
maximum value in the database changes.
To qualify a query with a subquery, you need to create the subquery

first. A subquery can qualify any attribute. It doesn’t have to qualify the
attribute on which it’s based, but it must have the same data type.
To qualify a query with a subquery

1 To create the subquery, in an attribute window, click an attribute.
2 Apply a function or qualification, then choose Query>Save Query.
(See “Saving Standard Queries” on page 307.)

3 To qualify a query with the subquery, in an attribute window, click
the Qualify box for an attribute.
4 With the cursor in the qualification text box, choose Edit>Insert
Subquery.
5 In the Insert Subquery dialog box, select a subquery, then click OK.
6 In the qualification text box, select an operator from the operator

list. (If the subquery is returning a single value, select =. If it’s
returning a list of values, select IN or NOT IN. The Begins with,
Contains, Ends with, Does not begin with, Does not contain, and Does
not end with operators are invalid for subqueries.)

Reversing Qualifications
When you want to exclude certain information from a query, or when
it’s easier to specify the information you don’t want rather than the
information you do (for example, all retailers except those in
Germany), you can qualify the query to have the opposite meaning to
the condition specified.
To reverse a qualification
1 In an attribute window, click the condition box above a When you reverse
qualification. a qualification, the
word not appears
2 Choose Query>Negate Clause. in front of the
condition box. If you change
your mind about the restric-
tion, click the word not to
remove it.

Qualifying a Query with a Variable
You can qualify an attribute with a variable that performs a user-
defined operation when you submit the query. Once you’ve built the
query, you can save it and use it again to retrieve the same results for a
different operation. When you submit the query, BI/Query returns the
data that corresponds to the operation performed by the variable. For
example, you can use a variable to retrieve retailer sales that were
placed today, before today, and so on. The variable determines what
today’s date is, and BI/Query returns the corresponding results.
To qualify a query with a variable

2 With the cursor in the qualification text box, click the data values
icon, then select Variables from the list.
3 In the Variables dialog box, select a variable. (If the variable you
want isn’t listed, you can create it. See “Creating Variables” on
page 281.)

4 Click Insert Variable.
Modifying the SQL

Advanced users who understand SQL and the database can modify the If you click Show
SQL string generated by BI/Query when they formulate a query. (This Prompt Values in
the Query win-
section describes modifying the SQL for standard queries. To modify
dow, the SQL dis-
super queries, see “Editing Super Queries” on page 340.) plays the values you insert
into prompts. If you don’t
You need the Show SQL String preference to display the SQL in the insert values into prompts, the
Query window and the Edit Queries permission to modify the SQL. Show Prompt Values option
You can then modify anything after the SELECT statement. (This displays the SQL without the
qualification or operator.
doesn’t compromise any restrictions placed on you by the DBMS.)

BI/Query must recognize the format of data sent to the DBMS. If it
doesn’t, the results may be returned with missing, misaligned, or
otherwise incorrect columns. This restricts the changes that you can
make to the SQL string. A good general rule is to not change anything
before the WHERE clause. That is, don’t change the attributes you’ve
selected, and don’t delete, add, or change the function you’ve applied
to them. (For example, don’t build a query, edit the SQL string, then
return to the attribute window to change the operator in a
qualification.) Changes you make to the SQL string should be the last
changes you make to a query. If you modify the SQL string incorrectly,
the DBMS may return an error message.
To modify the SQL string

1 Make sure that you have the Edit Queries permission and the Show
SQL String preference.
2 Choose Query>Show Query.
3 In the query window, make the change(s) you want. (When you
specify attributes in the SQL string, use their database names, not
the names in the attribute window.)
4 If BI/Query displays a warning, click OK to overwrite the SQL

string.
OR
Click Cancel to undo your changes.

Modifying a Query for Selected Results
If you want to retrieve more detailed data about specific results you’ve
retrieved, you can do so in ad hoc drill-down mode. In this mode, you
select one or more results cells, then submit a query that returns results
only for those values.
Selecting cells in ad hoc drill-down mode creates one or more in-

clauses in the current query. When you select a single cell, {drilldown}
appears in the qualification tree instead of the contents of the cell.
When you select more than one cell, the list icon appears; you can use
it to view and modify the list of cells you selected. (For information on
using the list icon, see “The List Icon” on page 294.)
To modify a query for selected results

1 In the results window, choose Results>Ad Hoc Drill Down. To cancel ad hoc
drill-down mode,
2 Select the cell(s) on which to base your query.
choose Results>
Ad Hoc Drill
Down or simply display
another window.
The original query returns a list of retailer names, locations, and sales amounts.
3 To retrieve results that match these items, resubmit the current query.

OR
To retrieve different results for these items, modify the current
query, then submit it.
Provides a list of cells selected

in the results window
You don’t have to 4 To work with the same subset of results later, save the new query.
be in ad hoc drill- (See “Working with Super Queries” on page 337.)
down mode to
save a subset of
results. The in-clauses that
determine which subset to
retrieve are saved with the
query.
The query retrieves only the records for retailers with the six largest sales amounts
and includes the dates on which the sales were placed.
Creating Dynamic Relationships

The administrator creates relationships between data objects to allow
users to formulate queries using more than one object. Rather than
creating all possible relationships between data objects, the

administrator typically creates the most important ones. When data
objects don’t have a relationship, or when existing relationships don’t
relate the attributes users need, they can create dynamic relationships.
Dynamic relationships are typically created “on the fly” for temporary
use by advanced users who understand the database and know how to
draw related information from more than one table.
Creating dynamic relationships requires the Dynamic Relationships

permission and the Allow Dynamic Relationships preference. Saving
the relationships requires the Save Data Model permission.
In order to create a dynamic relationship between two tables, you need

to specify its join condition to indicate how the data in one table is
related to data in the second. For example, by joining the Retailer and
Sales tables, where the Retailer Number attribute in one table is “equal
to” the Retailer Number attribute in the other table, a query that
includes both data objects returns data only for retailer numbers that
match. (For more information on join conditions, see “Creating Join
Conditions” on page 104.)
When you create a new relationship, it’s represented by a line joining

the two data objects in the data model. You can create a relationship
icon and name it.
To create a dynamic relationship

1 Make sure that you have the Dynamic Relationships permission
and the Allow Dynamic Relationships preference.
2 Click the two data objects you want to join, then choose Query>
Relationship.
3 In the Choose Relationship dialog box, select <dynamic> from the
relationship list.

Relationship list Operator list
Choosing an Operator
The default = operator is
the most common type of
relationship; it specifies
that the value of an
attribute from one table
equals the value of an
attribute from another.
You may need to consult
your administrator to
ensure that the relation-
ships you create use the
appropriate join conditions
and produce the results
you want.
Data object lists
4 Select an operator from the operator list.

5 Click an attribute in the left-hand list.
6 Click an attribute in the right-hand list, then click Add.
7 Click OK.
8 To create a relationship icon and name it, choose Query>New
Query.
9 In the Save Query dialog box, click Save.
10 Specify a relationship name. (For information on naming
relationships, see “Renaming Objects and Attributes” on page 102.)
Using Queries to Perform Calculations

You can use queries to perform basic calculations such as summing or
averaging results by applying a function to an attribute. You can also
carry out more sophisticated calculations by including an attribute in a
query that performs a user-defined calculation.

Applying Functions to Attributes
Aggregate functions are mathematical operations that allow you to calculate
summary values from a set of values for an attribute. For example, you
can retrieve retailers’ total sales by applying the SUM function to the
Invoice Amount attribute. Different functions are available depending
on the attribute, DBMS, and data type you’re using.
When you apply an aggregate function to an attribute, BI/Query

automatically groups all the other attributes in the query in the order in
which you selected them. (If this order isn’t appropriate to your needs,
you can change it. See “Specifying a Group Order” on page 331.)
Grouping organizes the data into sets and retrieves a summary value for
each set. All selected attributes to which functions haven’t been applied
are grouped to ensure that the results set doesn’t calculate a summary
value for individual members of the group. (To group attributes
without applying functions, see “Grouping without Functions” on
page 333.) The following example shows how grouping works with
aggregate functions.
Suppose the database contains the following data about retailer sales:
Name City Invoice Amount
Sterling Ottawa $3000
Triteck Toronto $1000
Billings Toronto $3000
Saddler Toronto $5000
Triteck Ottawa $2000

If you want to retrieve a list of retailers, cities, and total retailer sales,
you might formulate a query in which you select the Name, City, and
Invoice Amount attributes (in that order) and apply the SUM function
to Invoice Amount. When you submit the query, the DBMS organizes
the data into groups (first by Name, then by City). Each row of results
in a group has identical values except the attribute to which the
function is applied.
The table below shows how the DBMS groups the date. The rows for
Billings, Toronto, represent one group, the row for Saddler, Toronto,
represents another group, and so on.
Name City Invoice Amount
The DBMS then applies the sum to each group. When the results are
displayed, each group is organized alphabetically, numerically, or
chronologically. The table below shows how BI/Query displays the
final results. Groups are organized first alphabetically by name, then
alphabetically by city for retailers with the same name (such as Triteck)
but located in different cities.
Name City SUM Invoice Amount

Name City SUM Invoice Amount
Specifying Functions
You can choose from a wide range of functions to calculate the results
you want.
Apply This Function To Do This
none Leave the Function box blank.
AVERAGE Retrieve the average of all the values of

an attribute or the average of each group.
MAXIMUM Retrieve the maximum value of an

attribute in the results set or by group. (In
character data, this is the last value in the
list; for dates, it’s the most recent date, for
numbers, it’s the highest number.)
MINIMUM Retrieve the minimum value of an

attribute in the results set or by group.
(In character data, this is the first value
in the list; for dates, it’s the earliest date;
for numbers, it’s the lowest number.)
SUM Retrieve the sum of all the values of an

attribute or the sum of each group.
COUNT Retrieve the number of values that

aren’t NULL (missing) values of an
attribute or the number in each group.
AVERAGE DISTINCT Retrieve the average of all the values of

an attribute or the average of each
group, ignoring any duplicates.

Apply This Function To Do This
SUM DISTINCT Retrieve the sum of all the values of an

attribute or the sum of each group,
ignoring any duplicates.
COUNT DISTINCT Retrieve the number of values that

aren’t NULL (missing) values of an
attribute or the number in each group,
ignoring any duplicates.
Calculation Add calculated attributes that perform

user-defined calculations in a query.
(See “Creating Attributes That Perform
Calculations” on page 334.)
To apply a function to an attribute

2 Click the Function box for an attribute, then select a function from
the list.
3 To group the data in a different order than the order in which you
selected the attributes, click the Group box for the remaining
attributes. (The function is applied after the results are grouped.)
This query calculates the average of all retailer sales.

Specifying a Group Order
When you apply a function to an attribute, BI/Query automatically When you group
groups attributes to which you haven’t applied a function in the order attributes, you can
include a column
in which you selected them. If this order isn’t going to give you the
that counts the
groups you want, you can specify your own group order by clicking number of rows in each
the appropriate Group box in the attribute window. For example, if group. Choose Query>
you select the Name, City, and Invoice Amount attributes (in that Modifiers>Count All.
order) and apply the SUM function to Invoice Amount, you can
retrieve the names and cities of retailers along with their total sales,
grouped first by retailer name, then by city.
When you apply a group order, you’re indicating which attributes

should be grouped as well as their group order. When you select more
than one attribute from one or more data objects and group at least
one, the remaining attributes (except those to which you apply a
function) must also be grouped.
Grouping Before Calculating a Function

When you apply a function to an attribute, you can qualify the attribute
in the qualification tree in order to group results before calculating the
function. (See “Qualifying Queries” on page 293.) In this case, a
WHERE clause is created in the SQL for the query. The WHERE
clause eliminates rows before grouping the results. For example, in
order to retrieve retailers’ largest sales, you might include the Retailer
Name and Invoice Amount attributes, qualify Invoice Amount to be
greater than $50,000, and apply the SUM function to it. The SQL for
the query would look like this:
select retailers.cust_name, SUM (sales.ord_amount)

from retailers, sales where ((sales.ord_amount
>50000.00)) and retailers.cust_num=sales.cust_num
group by customer.cust_name;
When you submit this query, BI/Query eliminates the records that
don’t meet the criteria you specified, groups the results, and calculates

the sum for each group. That is, it finds all sales that are greater than
$50,000, groups them by retailer name, then sums them.
Grouping After Calculating a Function

When you apply a function to an attribute, you can qualify the attribute
About the HAVING Clause
with a group qualification in order to group results after calculating the
When you apply a group
qualification, you don’t function. In this case, a HAVING clause is created in the SQL for the
need to include the word query and is applied after grouping. That is, the qualification is applied
HAVING in the Group to the entire query, after all aggregate functions have been calculated
Qualification dialog box
(including any calculated attributes that are treated as aggregates) and
— it’s automatically
inserted before each HAV- the appropriate attributes have been grouped. For example, instead of
ING clause. finding retailers’ largest sales, you can find the largest retailers by
The HAVING clause in a summing all sales by retailer first, then eliminating the sums that don’t
group qualification is meet your criteria. (For information about calculated attributes, see
retained with the current “Creating Attributes That Perform Calculations” on page 334.)
query unless you remove it
from the Group Qualifica- The SQL for the query would look like this:
tion dialog box or choose
Query>New Query.
select retailers.cust_name, SUM (sales.ord_amount)
from retailers, sales where
retailers.cust_num=sales.cust_num group by
retailers.cust_name having SUM ((sales.ord_amount)
>50000.00);
To group results after calculating a function

1 In an attribute window, click the Function box for an attribute,
then select a function from the list.
2 Choose Query>Group Qualification.
3 In the Group Qualification dialog box, under Columns, select the
column to which you want to apply the group qualification.
4 Click Move, then type the qualification into the available text box.

This list displays the Count function,
all columns to which an aggregate
function has been applied, and any
calculated attributes that are
treated as aggregates.
The SUM function for the Invoice Amount attribute is qualified with >50000 to
retrieve a list of total sales greater than $50,000.
5 To include a prompt in the qualification, click Insert Prompt, then

use the Insert Prompt dialog box to specify it. (For more
information about prompts, see “Prompts” on page 269.)
6 To include a variable in the qualification, click Insert Variable, then
use the Insert Variable dialog box to specify it. (For more
information about using variables in queries, see “Qualifying a
Query with a Variable” on page 320.)
7 To include the database name of another attribute to which the
qualification refers, click Insert DB Name, then use the Insert DB
Name dialog box to specify it.
8 Click OK.
Grouping without Functions

Grouping is most often used with functions. But you can group
attributes without applying functions. In this case, grouping is similar to
a Distinct operation. It divides a table into groups and returns one row
for each group. For example, a query in which the Country attribute is
selected retrieves all countries in the Retailers table.

SQL for the Query Results
select retailers.country Canada

from retailers Canada
France
Australia
France
USA
USA
Canada
Australia
If you group by Country, the results are the same as if you selected all
the unique sales, except that the results are sorted numerically.
SQL for the Query Results
select retailers.country Australia

from retailers group by Canada
retailers.country France
USA
Creating Attributes That Perform Calculations

If you’re using a BI/Query allows you to add calculated attributes to a data object. A
Teradata connec- calculated attribute performs a user-defined calculation in a query. The
tion via WinCLI
and you’re not calculation can be based on more than one attribute from more than
using ODBC, you need to one data object in a design window. For example, a data object might
identify the type of data the include Unit Price and Unit Cost attributes that retrieve a product’s
calculated attribute creates.
market price and production cost, respectively. By creating a new
For all other connections, you
can either specify a data type attribute that calculates Unit Price minus Unit Cost, you can determine
or use the default Automatic. the profit made on each product. You can also apply an SQL function
(such as an average) to an attribute in the calculation.
In a combined data model, users can edit or delete any calculated

attribute. In a split data model, users can edit or delete only calculated
attributes that they create, not those the administrator provides.

To create an attribute that performs a calculation
1 In an attribute window, click the attributes you want. You can easily
edit and delete
2 Click the Function box for the attribute below which you want to
calculated
add the calculated attribute, then select Calculation from the list.
attributes. Select
3 In the Edit Computed Attribute dialog box, type a name for the Edit Calculation or Delete
attribute into the Name text box. Calculation from the corre-
sponding Function list.
4 In the Expression text box, specify a calculation. (Type it in or use
the keypad. Add a space between each item.)
Displays the database

name for the attribute
The Profit attribute determines the profit per product by calculating Unit Price minus
Unit Cost.
5 To include an attribute in the expression, select the corresponding

data object from the Table/Attributes list, select an attribute, then
click Insert Attribute.
6 To ensure that the other attributes in the query are grouped when
the calculated attribute is used in a query, click Aggregate. (See
“Applying Functions to Attributes” on page 327.)

7 To include a function in the expression, click Insert Function, then
use the Insert Function dialog box to specify a function.
Choosing a Function
The Insert Function dialog
box displays a list of built-
in SQL functions. For cer-
tain DBMSs, a list of scalar
functions appears under
Other Functions. (A scalar
function takes a predefined
number of parameters —
usually one or two — and
produces a value for each
result in turn. Aggregate
functions are often used
with a group by clause; sca-
lar functions aren’t.)
You can use most scalar

functions available in your
DBMS even if they don’t
appear under Other Func-
tions. Type the function
into the Expression text
box. (Check your DBMS
documentation for the
correct format.)
The Average Profit attribute calculates the average profit made on each product.
8 To specify a data type for the calculated attribute and whether it’s
numeric or character, click Data Type, then use the Choose Data
Type dialog box to specify the information.

9 In the Edit Computed Attribute dialog box, click OK.
Working with Super Queries

A super query is an advanced type of query that executes one or more
standard queries and automatically manipulates the corresponding
results. For example, a super query either returns a single set of results,
then filters it by sorting the results or calculating a range, or it returns
multiple results sets and combines them. A super query that combines
results gives you the flexibility to perform join operations that may not
be specified in a design window. A super query also allows you to
combine results from different databases and place two or more related
results sets (for example, retailer sales for 1997 and retailer sales for
1998) in one report. (For information on combining results, see
“Combining Results” on page 383.)
Creating super queries takes the work out of manipulating the results of
a query each time you want to perform the same operations on them.
Once a super query has been saved, it can be:
• loaded, then submitted to the DBMS

• edited by changing the operations it performs, the component
queries, or both
• automated by being linked to a button
• stored (by the administrator) with the data model in the database
If your data access environment includes BI/Broker and you have the
appropriate system permissions, administrators can publish super queries
to the repository to make them available to users. (You don’t need to
save super queries first, but it’s good practice.) To save a query as
a data values
query file, or to
save its SQL string
Creating Super Queries as a text file for use in another
application, save it as a stan-
You can create super queries that filter results or combine two or more dard query, not a super query.
results sets. To create a super query, you submit one or more standard (See “Saving Standard Que-
queries, manipulate the results, then save the queries in the super query ries” on page 307.)

or results window. This saves the standard queries as well as the
operations applied to the results. When you save a super query that
combines results, BI/Query saves the component queries along with
the operation you applied to combine the results.
To save super queries, you must have the Save Queries permission.
Super queries are saved with the extension .qry and stored in the
Queries folder by default, but you can also store them elsewhere.
That Filter Results

A super query that filters results can sort the results (for example,
alphabetically by retailer name) or narrow the range (for example,
eliminating all retailers whose sales don’t fall within a particular range).
This super query retrieves information about retailer sales and narrows the range to
sales between $25,000 and $50,000.
To create a super query that filters results

1 Formulate a query.
2 In a design or attribute window, choose Query>Submit Query.
3 Filter the results. (See “Sorting Results” on page 377 and
“Narrowing the Range of Results” on page 380.)
4 In the results window, choose Query>Save Query.
5 In the Save Query dialog box, specify a file name.

6 Click Save.
That Combine Results

A super query combines results by appending the rows of one results set
to another or by joining one column to another. (For details on the
advantages of combining results, see “Combining Results” on page 383.)
This super query appends the rows of one results set to another.
To create a super query that combines results

1 Formulate the two queries whose results you want to combine.
2 In a design or attribute window, choose Query>Submit Query for
each one.
3 Combine their results. (See “Combining Results” on page 383.)

4 In the results window that displays the combined results or in the
super query window, choose Query>Save Query.
5 In the Save Query dialog box, specify a name and location for the file.
6 Click Save.
Editing Super Queries

To open the super You can edit a super query to change the results it retrieves. You can
query window, in change each component query (each query that makes up the super
the super query’s
results window,
query) and each operation performed on the results it returns. For
choose Query>Show Query. example, you can add an attribute to a component query, then change
If a super query isn’t loaded, a sort operation to use the new attribute. (For information about
choose Query>Load Query; building and saving super queries, see “Creating Super Queries” on
in the Load Query dialog box,
select a super query, then page 337.) Editing super queries starts in the super query window.
click Load.
Understanding the Super Query Window

The super query window is divided into two panes separated by a
splitter bar, which you can use to resize the panes.

Operation
Component queries
Splitter bar
Message pane
The top pane displays the structure of a super query using a tree list.
Icons
Each component query and each operation is included in the tree and is Query
represented by an icon. The operations performed on a component
Append
query’s results appear above the component query in the tree. For
example, if the results of a component query are reordered, then sorted, Join
the tree list shows three branches — first the component query, then Range
the reorder operation and the sort operation above it.
Reorder
If a join or append operation is performed on two of the component Sort
queries, it’s shown in the window above the queries and their
associated operations. Any operation that appears above a join or
append operation is applied to the results of the join or append.
When you’re
8 working with
7 complex super
3 queries, you can
2
1 see where a join or append
6 occurs by collapsing the tree
5 structure, then expanding the
4
branches one by one.
How the Retailer Accounts super query works

1 Retrieves the results of the Invoice Amount query. 2 Filters the results by applying a
range. 3 Sorts by Retailer #. 4 Retrieves the results of the Retailer Receivables query.
5 Reorders the columns. 6 Sorts by Retailer #. 7 Joins the results from step 3 with the
results from step 6. 8 Reorders the columns to produce the final super query.

The bottom pane of the super query window (called the message pane)
displays information about the selected item in the super query. When
you select a component query, the message pane displays the query’s
SQL string. When you select an operation, the message pane shows
information about what the operation does to the query results. And if
there’s an error in the super query, the message pane displays
information about why the error occurred and how to correct it.
Editing a Component Query

You edit a component query by copying it from the super query
Editing Super Queries
window into the data model. The component query then becomes the
When you edit super que-
ries, follow these guidelines. current query, allowing you to open the attribute windows you want
to use and make your changes. When you’ve finished editing the
• Start with the innermost
query and work up query, you paste it back into the super query window. (It’s not
through the tree. This necessary to submit the component query before you paste it.) For
makes it easier to example, if a component query contains a date attribute in a Sales data
correct any errors.
object, you may want to add a qualification to the attribute. You copy
• Save your work the component query into the data model, then open Sales and apply
regularly.
the qualification. When you paste the component query back into the
• Don’t edit a super query
by modifying the SQL
super query window, BI/Query replaces the old component query
string — your changes with the new one.
won’t be checked for
errors. If any errors occur as a result of making the changes, you need to
correct them before you can save and submit the super query. (See
“Correcting Errors” on page 345.)
To edit a component query

1 If a super query isn’t loaded, choose Query>Load Query. In the
Load Query dialog box, select a super query, then click Load.
OR
In the super query’s results window, choose Query>Show Query.
2 In the super query window, right-click a component query, then
choose Copy Query to Model.

You can submit
and save super
queries by right-
clicking the top
pane of the super query win-
dow, then choosing the
appropriate option.
3 Minimize the query window for the component query.

4 In the design window(s), make your changes to the component
query.
5 Display the super query window. If you can’t find
the super query
6 Right-click the component query you’ve edited, then choose Paste
window, choose
Query from Model.
Window>More
Windows, then use the Select
Window dialog box to open
the window.
7 Correct any errors. (See “Correcting Errors” on page 345.)

8 Save the super query. (See “Creating Super Queries” on page 337.)
Editing an Operation
You can change how an operation manipulates query results by editing
the operation. You edit an operation starting in the super query
window. When you select the operation you want to edit, BI/Query
opens the appropriate dialog box, where you can make your changes.
The dialog box you use is the same one you used to create the
operation. (The Join Conditions dialog box is slightly different — you

can’t change the results sets that are joined.) When you click OK,
BI/Query replaces the old operation with the new one.
For example, if a range operation limits the results of a component

query to sales between $25,000 and $50,000, you can change the range
and the attribute the range is applied to. When you select the range
operation in the super query window, BI/Query opens the Range
Filter dialog box, where you can make your changes. When you click
OK, BI/Query replaces the old range operation with the new one.
You can’t edit an If any errors occur as a result of your changes, you need to correct them
append opera- before you can save or submit the super query. (See “Correcting
tion. Also, you
Errors” on page 345.)
can’t delete an
operation from a super query.
Operations are described in more detail elsewhere in this guide, as
outlined in the table below.
For This Operation See This
Join “Joining One Column to Another” on

page 386.
Range “Narrowing the Range of Results” on

page 380.
Reorder “Reordering Columns of Results” on

page 382.
Sort “After Results Are Returned” on page 382.
To edit an operation
1 If a super query isn’t loaded, choose Query>Load Query. In the
Load Query dialog box, select a super query, then click Load.
OR
In a super query’s results window, choose Query>Show Query.
2 In the super query window, right-click an operation, then choose
Edit Operation.

3 In the dialog box that appears, edit the operation. (The type of
operation you’re editing determines which dialog box appears.)
4 Click OK.
Correcting Errors
Each time you edit a super query, BI/Query checks for errors. You
can’t save or submit a super query that contains errors — you need to
correct the errors first. When you edit a super query, you may
introduce an error because the parts of a super query are
interdependent. For example, removing an attribute from a component
query when that attribute is used in a sort operation results in an error
in the sort.
Errors occur on operations, but you can correct them by editing either
the operation or its associated component query. For example, you can

correct the error described above by editing the component query to
include the missing attribute or editing the sort operation to sort on a
different attribute.
Most errors occur because an attribute used in an operation is missing

from the component query on which the operation is performed.
Error icon When an error occurs, BI/Query displays an error icon beside the
corresponding operation. When you click the operation, the message
pane in the super query window provides information about why the
error occurred and how to correct it. After you’ve corrected the error,
test the super query by submitting it.
To correct an error
1 In the super query window, click the operation causing the error.
2 Read the information in the message pane.

3 Edit the component query or operation. (If you’re editing more
than one operation, start with the operation immediately above its
corresponding query and work up through the tree.)
4 Save the super query. (See “Creating Super Queries” on page 337.)
5 To test the super query, right-click the top pane of the super query
window, then choose Submit Query.
Common Errors and Their Solutions

The table below lists some common errors and their solutions.

Type of Error Reason and Solution
Append: Column n doesn’t match The attributes in the results

you’re appending don’t match
for one of the following reasons:
• you selected the attributes in
the first query in a different
order than the attributes in the
second
• an attribute used in one query
is missing from another query
Edit the queries to reselect the
attributes in a consistent order.
Reorder Error: Missing Column An attribute in the operation is

Range Error: Missing Column missing for one of the following
Sort Error: Missing Column reasons:
• the attribute is missing from
the component query
• you hid the column with a
reorder operation
Do one of the following:
• edit the query to add the
missing attribute
• edit the reorder operation to
restore the hidden attribute
• edit the operation to use a
different attribute
Building Queries with a Circular Path

When the data model you’re using contains two or more data objects
whose relationships form a circular path, you can build queries that use
all the data objects and all the relationships in that path. For example, if
the data model contains the Employees and Departments data objects,

and they’re connected by the Work In and Managed By relationships,
you can build queries that use both data objects and both relationships.
Because each data object in a circular path has two relationships,

BI/Query prompts you to specify whether you want to create a
correlation (also called an alias). The choice you make determines how
join conditions are applied in your query and the extent to which your
results are restricted. A query that uses a correlation allows you to ask
two questions of the same data object and is usually less restrictive than
a query that doesn’t use a correlation.
Queries with a circular path are typically built by advanced users who
understand how to use join conditions in order to retrieve the
information they need.
With a Correlation
When administra- When you build a query with a correlation, BI/Query creates a
tors design a data temporary copy of the data object. This allows you to ask two different
model, they can
questions of the same object.
create permanent
copies of a data object using
You begin by selecting the relationships joining the data objects you
correlation names. In some
cases, this allows users to want to include in your query. The last relationship you select
avoid building circular que- determines how the circular query is formed. The data objects
ries. (See “Specifying Correla- connected to that relationship are the ones you’re presented with when
tion Names” on page 109.)
you’re prompted to create a correlation. And that relationship is applied
to the data object you create a correlation for.
For example, if you select the Managed By relationship last and create a
correlation for Employees, BI/Query creates a second, temporary copy
of Employees called Empo__Manag. (To name the correlation,
BI/Query uses the first five characters of the data object’s name, two
underscores, then the first five letters of the relationship you selected
last.) The result is two copies of Employees: one connected to
Departments through the Work In relationship, the other, temporary
copy connected to Departments through Managed By.

This is what you see in the Behind the scenes, BI/Query creates
design window. temporary copy of Employees and connects it to
Departments using the Managed By relationship.
When you double-click the original data object in the design window,
you’re prompted to specify which attribute window you want to use
— the one for the original data object or the one for its correlation.
You can use one attribute window to ask one question, then the other
attribute window to ask the second question.
For example, suppose you want to use the data objects illustrated above
to find out which employees work for managers who make over
$60,000. You need a correlation because you’re asking for two kinds of
information from the Employees data object — the names of the
employees and who is a manager making over $60,000. You’d use the
Employees data object to find out the names of the employees, and
you’d use its correlation to find out who is a manager making over
$60,000. (You use the correlation for the second question because it’s
the one that uses the join condition in the Managed By relationship.)
When you submit the query, the DBMS processes it in two stages.
Behind the scenes, the DBMS first obtains a preliminary results set
(names of all employees and the departments they work in) by joining
each row in Employees with each row in Departments, then applying
the join conditions for Work In.
Departments X Employees
---------------------------------------------------------------------------------- = Results 1
Work In

The DBMS then applies the join condition for Managed By to the
preliminary results set and Emplo__Manag (the copy of Employees) to
retrieve the final results (employees who work for managers making
over $60,000).
Results 1 X Emplo__Manag
------------------------------------------------------------------------------ = Results Final
Managed By
This is the SQL that this query generates.
select
Employees.LastName,
from
Departments,
Employees,
Employees Emplo__Manag
where
(
(
Emplo__Manag.Salary > 60000.0000
)
)
and
Departments.DepartmentID = Employees.DepartmentID
and
Departments.Manager = Emplo__Manag.EmployeeID ;
To build a query with a circular path that uses a correlation

Because circular 1 Decide which data object you want to create a correlation for and
queries are com- which relationship to use for that correlation.
plex, it’s good
2 Click the relationships joining the data objects you want to include.
practice to start by
building one that returns a
(Make sure that the last relationship you click is the one you want
small subset of data. This to use for the correlation.)
allows you to test the design 3 In the Circular Query Option dialog box, click the data object you
of the query before you sub- want to create a correlation for.
mit it (and possibly retrieve a
large number of rows).

4 Click OK.
5 In the design window, double-click the data object you created the
correlation for.
Double-click Employees to open the attribute windows for Employees and for its
correlation.
6 In the Open Attribute Windows dialog box, select the attribute

window(s) you want to open.
Choosing Employees opens the attribute window for the original Employees data
object. Choosing Emplo__Manag opens the attribute window for its correlation.

7 Click OK.
8 In the attribute window(s), click the attributes you want to include
in the query, then close the window(s).
9 Click any other attributes you want to use from the other data
objects in the circular path.
10 To maintain all the join conditions in the query, choose Query>
Modifiers>Trim Relationships to deselect it.
Without a Correlation
Unlike a query with a correlation, BI/Query doesn’t create a
temporary copy of a data object in the circular path. This allows you to
ask one question using all the data objects and all the join conditions in
the circular path. The results are usually more restricted because the
rows returned from the database must meet all the join conditions in
the circular path.
In a circular query without a correlation, the DBMS returns only the rows that meet the
join conditions in both the Work In and Managed By relationships.
Building a query without a correlation is similar to building a query

with a correlation except that the order in which you select the
relationships isn’t important. When BI/Query prompts you to specify
whether or not to create a correlation, you choose not to create one.
For example, suppose you want to use the data objects illustrated above
to find out which employees make over $60,000 and manage the

department they work in. You need a circular query, but you don’t
need a correlation because you’re using each data object only once.
When you submit the query, the DBMS processes it in two stages.
Behind the scenes, the DBMS first obtains a preliminary results set
(names of all employees who make over $60,000 and the departments
they work in) by applying the join condition for Work In to
Departments and Employees.
Departments X Employees
---------------------------------------------------------------------------------- = Results 1
Work In
The DBMS then applies the join condition for Managed By to the
preliminary results set to obtain the final results (employees who make
over $60,000 and manage the department they work in).
Results 1
------------------------------------- = Results Final
Managed By
This is the SQL that this query generates.
select
Employees.LastName,
from
Departments,
Employees
where
(
(
Employees.Salary > 60000.0000
)
)
and
Departments.DepartmentID = Employees.DepartmentID
and
Departments.Manager = Employees.EmployeeID ;
To build a query with a circular path that doesn’t use a correlation

1 Click the data objects and relationships you want to include in the
query.
2 In the Circular Query Option dialog box, click No Correlation.

3 Click OK.
4 In the design window, double-click the data objects in the circular
path.
5 In the attribute window(s), click the attributes you want to include
in the query, then close the attribute windows.

Scheduling Queries
Naming and Prioritizing a Job 357

Specifying When to Run a Job 358
Scheduling Once-only Jobs 358
Scheduling Recurring Jobs 359
Scheduling Jobs Based on Events 362
Advanced Scheduling 364
Specifying Job Actions 365
Actions for Running Queries and Refreshing
Reports 366
Distribution and Notification Actions 367
E-mail 367
Print (for Reports) 368
Broadcast Message 369
FTP 369
Publish 370
Push 370
Run Command on Server Action 371
Trigger Event Action 371
Notifying Yourself 373
Scheduling Queries
If your querying environment includes BI/Broker and you have
appropriate system permissions, you can schedule queries (and reports)
that have been published in the BI/Broker Repository. Scheduling
makes it possible to run queries when you are not present and even
when your desktop machine is not turned on. Scheduling automates
querying and makes it possible to manage the flow of job requests to
the database. You can schedule queries to run at specific times or after
specific events have occurred and you can decide where the output
should go and who should be notified when jobs complete. (It’s also
possible to schedule the refreshing of reports; see “Using Scheduling”
on page 282 of the BI/Query Reports user’s guide.)
Naming and Prioritizing a Job

You begin by providing the scheduler with a name for the job and its If you have the
priority. To assist anyone who may later view or change the job, you’ll appropriate sys-
tem permissions,
also want to include a description of it. If you are changing a job that
you can schedule
isn’t your own, you can also add comments to explain your changes. queries and reports other than
You enter all of this information on the Info page of the job scheduler. your own by first retrieving
The page also displays errors and other system messages concerning the the query or report from the
repository, then scheduling it.
scheduled job.
Once you’ve named and prioritized the job, you can schedule the time
or times for it to run.
To name and prioritize a job

1 With a published query open, choose File>Schedule>Query.
2 On the Info page of the Schedule Job dialog box, type the name of
the query (or report) into the Job Name text box.

3 Select a priority from the Priority list.
4 Type a description of the job into the Description text box.
5 If you’re changing someone else’s job, add an explanation of the
change into the Administrator Comments text box.
6 Click OK.
Specifying When to Run a Job

You can choose whether to schedule a job to run once only or on a
recurring basis. You can also choose to schedule a job based on date
and time (once only on January 16, 2001, at 4:05 p.m.; every Monday
morning at 3:00 a.m.), schedule it to be triggered by an event
(immediately after the annual regional sales report refreshes), or a
combination of both (on Tuesdays after the weekly backup). The
scheduling choices you make are reflected in a status line at the bottom
of the When page.
Scheduling Once-only Jobs

You can schedule a job to run only once. For instance, you can
schedule a Regional Sales Summary query to be refreshed during the
358 Scheduling Queries

night in time for tomorrow’s sales meeting by setting a once-only date
and time.
To specify date and time for a once-only job

1 In the Schedule Job dialog box, click the When tab.
2 On the When page, under Frequency, click Once.
3 Under Once, enter a date and time. (You can click the calendar
icon, then click the date you want.)
4 To also have the job run after an event has taken place, click
Advanced, select an event, then click OK. (See “Advanced
Scheduling” on page 364.)
Scheduling Recurring Jobs

You can schedule jobs to run more than once. For instance, if the
Regional Sales Summary results proved useful at the sales meeting, you
might schedule the query to run before each regularly scheduled
weekly sales meeting.
You can set recurring dates in multiples of hours, days, weeks, and
months. By choosing monthly intervals, you can also schedule
recurring jobs to run quarterly (every three months) and annually
(every twelve months).

By choosing Hourly, you can set a start and stop time for jobs that run
more than once in a day. For instance, you can schedule a query to run
every hour between 9:00 a.m. and 5:00 p.m. only.
You may want to run a job more frequently than daily but less often
than weekly. By choosing Daily, you can set it to run every so many
days—for instance, every three days.

By choosing Weekly, you can run it on specific days of the week, for
instance, on Monday, Wednesday, and Friday.
If you use Monthly, you can choose the day of the month when the
job is to run based on a calendar date (for instance, the 1st of the
month) or based on a day and week (for instance, on Tuesday in the
first week of the month).

To specify date and time for a recurring job
2 On the When page, under Frequency, click Hourly, Daily,
Weekly, or Monthly.
3 Under Hourly, Daily, Weekly, or Monthly, enter an interval
between jobs and specify a starting time.
4 If you choose an Hourly frequency, you can specify an end time.
Click End, then specify a time.
5 If you choose a Weekly frequency, select one or more days of the
week on which to run the job.
6 If you choose a Monthly frequency, you can run the job based on
day of month. Or you can run it based on week of month and day
of week.
7 If you also want the job to run after an event has taken place, click
Advanced, select an event, then click OK. (See “Advanced
Scheduling” on page 364.
Scheduling Jobs Based on Events

You may want to schedule a job to run after another process completes.
You could schedule the job for a date and time after the process is
expected to be complete, but what if the process doesn’t complete or
takes longer than you anticipated? Your job will still run at the time
you specified.
Instead of scheduling by date and time, you can specify that the job be
triggered by an event. You provide a short natural language description
of what must happen before your job runs. For instance, you could
type in an “annual regional sales query completed” event or an “after
weekly backup” event.
To specify an event
2 Under Frequency, click Event-based.
3 Under Events, select the event(s) that will trigger running the job.
OR

Click the new event button, then in the Events list, enter a
descriptive name for a new event and click to select it.
4 To also run the job at a specific date and time, click Advanced,
select the date and time, then click OK. (See “Advanced
Scheduling” on page 364.)
Once you’ve created an event, it appears in the event list in the

Schedule Job dialog box, where you can select it for future jobs as well
as for the current one.

The scheduler holds the job you’ve scheduled until it recognizes that
the event you’ve specified has taken place. In order for the scheduler to
recognize this, an event trigger must be fired. (See “Trigger Event
Action” on page 371.)
Advanced Scheduling
When combin- You don’t have to choose between scheduling by date and time and
ing events and scheduling by event. Instead, you can combine them.
dates to start a
job, take into For instance, suppose that management receives an annual regional sales
account how the scheduler
understands events. For report that is refreshed each year on March 1. For a meeting on April 4,
instance, you want a query to you want to provide several managers with results from a query that
run after daily backup on drills down into the same information used in that annual report. The
December 1. On November
query results will only make sense to the managers in the context of the
27, you schedule both the
event, “After daily backup,” latest annual report, but you want the query to take advantage of a
and the date, December 1. database update that will occur at the end of March. In other words,
Daily backup occurs on you want to be sure the annual report was refreshed before running the
November 28th. The sched-
query, and you want the query to run after the March 31 update.
uler recognizes that it is now
“After daily backup”. Then it
You schedule the query to run both on April 3 and on the Annual
waits for December 1. The
report runs as soon as it is Regional Sales Report Completed event. The query won’t run until
December 1, without waiting April 3, so the results will be current. But if for any reason the annual
for the daily backup to occur report hasn’t been refreshed, the query will be held. If it runs, you’ll
on December 1.
know the report was refreshed as well.
To schedule by both date and time and by event

2 On the When page, in the Frequency section, click one of the date
and time frequencies or the Event-based frequency.
3 Specify the frequency as required.
4 Click Advanced.
5 If you set the date and time on the When page, set the event in the
Advanced Settings dialog box. If you set the event on the When
page, set the date and time in the Advanced Settings dialog box.

6 Click OK.
Specifying Job Actions

When you schedule a query (or report), you want the scheduler to run
the query (or refresh the report). You also may want the scheduler to
distribute the results or refreshed reports to a variety of places, notify
various users of the job’s completion, or both. With the appropriate
system permissions, you can choose from a variety of ways to notify and
distribute.
And you may want to make it possible for the completion of the job to
cause other jobs to run. If you have the appropriate system permissions,
you can supply and remove the means of triggering such events. You
may have permissions that allow you to include all these actions:
running the query or refreshing the report, distributing the results,
notifying users, and serving as a trigger for events that run other jobs.

Actions for Running Queries and Refreshing Reports
The Run Query action is included automatically when you schedule a
query, and the Refresh Report action is included automatically when
you schedule a report. They appear on the Actions page of the
Schedule Job dialog box and can’t be deleted.
The Publish Query Results action also appears automatically on the

Actions page when you schedule a query, so that query results will be
published to the BI/Broker Repository. (You can delete this action.
Keep in mind, however, that the results must go somewhere. You can
specify where results are to be placed using one of the disposition actions.)
You and the users you choose can then retrieve query results (and
refreshed reports) from the repository.
To retrieve results
1 In BI/Query, choose File>Schedule>Retrieve Results.
OR
In BI/Query Reports, choose File>Retrieve.
2 In the Retrieve dialog box, select a results set or report.
3 Click Retrieve.
4 To retrieve reports, in the Retrieve Data dialog box, specify
whether you want to refresh the data in the report.

5 Click OK.
Distribution and Notification Actions

A distribution action delivers the output of a scheduled job. A
notification action provides notice that the job has been completed.
Some actions can do both. If you have the appropriate system
permissions, you can select distribution and notification actions from
the Add Action menu on the Actions page of the scheduler.
E-mail
You select an e-mail action from the Add Action menu when you want
to send e-mail notification of the completion of the scheduled job,
when you want to provide the output of the scheduled job as an e-mail
attachment, or both. A button in the E-mail dialog box displays the
users and groups that can receive e-mail so that you can select the
recipients you want.

Print (for Reports)
You select print when you want to print a report after it has been
refreshed. You can select the printer, what pages you want printed, and
the number of copies to print.

Broadcast Message
You select Broadcast Message when you want to notify others through
the system-wide message broadcaster that displays messages to
recipients logged in to BI/Broker. The Broadcast Message action uses
this broadcaster to notify users when a job has completed. As with the
e-mail notifier, a button in the Broadcast Message dialog box displays
the users and groups that can receive broadcast messages so you can
select the recipients you want. The broadcaster displays messages only;
this action can’t be used to distribute the results themselves.
FTP
You use the FTP action when you want to deliver results using the
TCP/IP file transfer protocol, FTP. The FTP action prompts you for
the server address where you want the results file to be located. This
action doesn’t notify users, but you can provide the information they
need to FTP the results using an e-mail or broadcast message.

Publish
The Publish action publishes query results to the BI/Broker
Repository. One Publish action is included automatically when you
schedule a query. If you want to publish the results set under more than
one name or set security for the results, you can replace it or add others.
Push
Push technology allows pages of content (usually in HTML format) to
be delivered via predefined channels to users who subscribe to those
channels. If this action is available, your BI/Broker administrator has set
up a Pointcast or Microsoft Active Channel server.
You use the push action to select the channels to which to deliver a
notifier. You can pick the appropriate channel(s) from a list and add a
message. Push messages allow hypertext links to the job results. You
can incorporate the time of completion and the name of the document
in the message.

Run Command on Server Action
Use the Run Command on Server action to start an application from
the BI/Broker server before running your job. For example, if your
organization has a program to run backups called Backup.exe, you can
include an action to run Backup.exe before your scheduled job runs.
Selecting Run Command on Server opens the Run on Server dialog
box, where you specify the program.
Trigger Event Action

When you schedule a job based on date and time, the event that makes
the job run is the occurrence of the date and time you specified. The
scheduler keeps track of the date and time, and when the current date
and time match those you’ve chosen, it starts the job.
You can also schedule jobs based on other kinds of events, such as the
completion of another scheduled job or the completion of an activity
by another application.
The scheduler also tracks these software events, but only if you’ve
specified what events it should track. You name them in the scheduler

(see “Scheduling Jobs Based on Events” on page 362), but you also
have to ensure that something triggers the event you named. That is,
you have to provide the means by which the scheduler is made aware
that the named event has happened.
If the event requires an application other than BI/Broker, you must add
a command line in that application that executes BI/Broker’s FireEvent
utility. The FireEvent utility passes the event name to the scheduler
when the event has completed, signaling to the scheduler to start the
scheduled job. The syntax for the command line is shown below. (You
must include all parameters.)
FireEvent [UserName] [Password][EventName]
You can also set up the jobs you schedule to serve as the events that
trigger other jobs to run. For instance, you might want to schedule a
Sales Query and a Summary Report that’s refreshed after the Sales
Query is run:
• When you schedule the Sales Query, you add a Trigger Event
action on the Actions page and give the action a name such as
“After Sales Query Runs” so that you can easily identify it as the
one you want when you schedule the Summary Report.
• When you schedule the Summary Report, on the When page, you
choose “After Sales Query Runs” as the event that causes the
summary report to refresh (see “Specifying When to Run a Job” on
page 358).
It’s equally effective to schedule the Summary Report to refresh first,

even though you want it to be triggered by the completion of the Sales
Query. In that case, when you schedule the Summary Report, you
enter the words “After Sales Query Runs” as an Event on the When
page. Then, when you schedule the Sales Query, you add a Trigger
Events action on the Actions page and select “After Sales Query Runs”
from the list of events in the Trigger Events dialog box.

Just remember: If you add an event trigger on the Actions page when
you schedule a job, you can use that job as a trigger for other jobs. If
you choose an event on the When page when you schedule a job, the
job will be triggered when that event occurs.
Notifying Yourself
In addition to notifying others or distributing results to them, you may
want to receive your own notification when a job is complete or when
an error occurs. You can choose to receive such messages by e-mail or
from the BI/Broker message broadcaster.
To specify job actions

1 In the Schedule Job dialog box, click the Actions tab.
2 On the Actions page, click Add Action.

3 Specify how you want to distribute results and/or notify users by
selecting the appropriate action(s), then providing information as
prompted. Repeat for each distribution or notification action you
want.
4 To run another application from the server before running the job,
select Run Command on Server, then enter the application name.
5 To have the completion of this job to trigger other jobs, select
Trigger Event, then enter a name for the Event.
6 To be notified when the job completes, under When the Job
Finishes, select either Send Me an E-mail or Notify Me with a
Broadcast Message.
7 To be notified when an error has occurred, under When an Error
Occurs, select either Send Me an E-mail or Notify Me with a Broadcast
Message.
8 To schedule another job, click Apply.
9 When you’re finished scheduling jobs, click OK.

Working with Results
Sorting Results 377

In the Attribute Window 378
In the Sort Order Dialog Box 379
Narrowing the Range of Results 380
Reordering Columns of Results 382
Combining Results 383
Appending One Results Set to Another 384
Joining One Column to Another 386
Understanding Which Columns to Join 389
Performing Calculations 390
Working with Results
Whether you generate a report from the results of a query or export
them for use in another application, you’ll want to organize the data in
a meaningful way to give it the impact you want.
You can sort results alphabetically, numerically, or chronologically —

or in reverse order. You can narrow them down to include only rows
within a certain range, combine more than one results set into one, and
specify the order in which columns of results should appear. You can
even hide columns of results if you decide you don’t need them. And
you can perform basic calculations on results to determine maximum,
minimum, sum, and average values.
Sorting Results
When you submit a query, the rows of results are displayed in the order
the DBMS returns them unless you specify a sort order. Specifying a
sort order arranges rows alphabetically (A, B, C), numerically (1, 2, 3),
or chronologically (January 1, May 4, September 6) — or in the reverse
order — and specifies the order in which columns are sorted. You can
specify a sort order before or after you submit a query.
These results aren’t sorted. These results are sorted numerically by

credit limit, then, for retailers with the
same credit limit, alphabetically by name.

Before You Submit a Query
When you build a query, you can specify how rows of results should be
sorted by indicating which attributes you want to sort as well as their
sort order. When you submit the query, the DBMS sorts the rows
accordingly. You can specify a sort order for a query in the attribute
window or using the Sort Order dialog box.
In the Attribute Window

The most direct way to sort results is to use the Sort box for an attribute
in the order you want to sort it. The number that appears in the box
indicates the sort order. When you submit the query, the DBMS
arranges rows alphabetically, numerically, or chronologically. This
arranges rows in ascending order. To sort results in reverse (descending)
order, use the Sort Order dialog box.
To specify a sort order in the attribute window

2 Click the Sort box for each attribute in the order you want to sort it.
The number 1 in the Sort box for Credit Limit indicates that it will be sorted first; the
number 2 in the Sort box for Name indicates that it will be sorted second.
378 Working with Results

In the Sort Order Dialog Box
When you want to sort attributes from more than one attribute
window, or when you want to sort results in reverse alphabetical,
numerical, or chronological order, use the Sort Order dialog box.
To specify a sort order in the Sort Order dialog box

2 Choose Query>Sort Order. For a fast way of
displaying the Sort
3 In the Sort Order dialog box, click a column under Selected
Order dialog box
Columns, then click Move. in the attribute
window, double-click the
Sort box for an attribute.
Sorting results first in reverse (descending) numerical order by credit limit, then
alphabetically by retailer name.
4 To specify a sort order for a column, click it, then click First, Last,
Up, or Down.
5 To specify reverse order, click a column, then click Descending.
6 Click OK.
After Results Are Returned

If you don’t specify how results should be sorted before submitting a
query, you can do so after results are returned.
To specify a sort order after results are returned

1 In a results window, choose Results>Filter Results>Sort.

2 In the Sort Order dialog box, click a column under Selected
Columns, then click Move.
Sorting results alphabetically by name.
3 To specify a sort order for a column, click it, then click First, Last,
Up, or Down.
4 To specify reverse order, click a column, then click Descending.
5 Click OK.
Narrowing the Range of Results

You can narrow To help you analyze your data, you can narrow down the results in a
down results when results set. Specifying a range for results includes only the rows within
you build a query
that range. For example, you can specify retailer credit limits valued
by qualifying an
attribute using the between $200,000 and $600,000, sales received between June 30 and
BETWEEN function. If you December 31, and salespeople’s names between the letters A and S.
qualify a character field, use You can also specify rows outside a range.
the case in which the value is
stored in the database.

These results have no range applied. These results are for retailers with credit
limits between $200,000 and $600,000.
To narrow the range of results

1 In a results window, choose Results>Filter Results>Range. You can locate a
specific item in a
2 In the Range Filter dialog box, click a column, then type a range results set using
into the Minimum and/or Maximum text boxes. (For character BI/Query’s Find
data, type the values using the correct case.) feature. In a results window,
choose Results>Find. Type
the item you’re looking for,
specify any additional options,
then click Find.
3 To obtain results outside a range, click Not in range.

4 Click OK.

Reordering Columns of Results
When the results of a query are returned, columns are displayed in the
order in which you selected the corresponding attributes in the
attribute window. You can change that order before you submit a
query or after you’ve obtained the results.
Before You Submit a Query

Before you submit a query, you can specify the order in which columns
of results will appear.
To reorder columns before submitting a query

1 In an attribute window, choose Query>Column Order.
If many columns 2 In the Column Order dialog box, click a column under Ordered
are displayed Columns, then click First, Last, Up, or Down.
under Ordered
Columns, start by
clicking Unorder All to move
all the columns under Unor-
dered Columns. Click each
column, then click Move to
move it to Ordered Columns
in the order you want.
3 Click OK.
After Results Are Returned

Once results are returned, you can change the order of the columns. At
the same time, you can temporarily hide any columns you don’t need
in the results set (for example, to exclude them from a report).

To reorder columns after results are returned
1 In a results window, choose Results>Reorder Columns. You can hide a
column right in a
2 In the Column Order dialog box, click a column under Visible
results window.
Columns, then click First, Last, Up, or Down. Select the col-
umn, then choose Results>
Hide Column. (To display
hidden columns, choose
Results>Reorder Columns.)
3 To temporarily hide a column, click it, then click Move.

4 Click OK.
Combining Results
If a query is so complex that it requires two or more separate queries,
you can combine two results sets into one. This enables you to save
database processing time or create the equivalent of an outer join if
your DBMS doesn’t support it. You can either append the rows of one
results set to another or join columns of results sets.
Once you’ve combined results sets, you can create a super query, then
submit it to retrieve the combined results. You can also link the super
query to a button to perform these operations automatically. (For more
information on super queries, see “Creating Super Queries” on page 337.)

Appending One Results Set to Another
You can append the rows of one results set to another — even if the
data is derived from two different tables. For example, if one set of
results is for retailer sales for 1997 and another is for retailer sales for
1998, you can append one set to the other to include sales for both
years in the same report.
The data types of the columns in the first results set must match the
corresponding columns in the second results set. For example, if the
first results set contains two columns, and their data types are character
and numeric, respectively, the first two columns of the second results set
must also be character and numeric.
The two results sets can have a different number of columns as long as
the extra columns appear at the end of one set. (To exclude the extra
columns, you can hide them using Results>Hide Columns.) If the two
results sets contain columns with the same data type but in a different
order, reorder them using Results>Reorder Columns.
Query Results 1
Name aSales
Abicon Inc. $12,000
Textal Ltd. $113,000
Unisystems $10,145
Ziptech $6,430
Query Results 2
Name aSales State
Bainstream Inc. $10,000 New York
Campus Corp. $2,000 California

Query Results 2
MonoLitho $2,100 Ohio
Textronics $60,000 Illinois
Appended Results
Name aSales State
Abicon Inc. $12,000
Textal Ltd. $113,000
Unisystems $10,145
Ziptech $6,430
Bainstream Inc. $10,000 New York
Campus Corp. $2,000 California
MonoLitho $2,100 Ohio
Textronics $60,000 Illinois
To append rows from one results set to another

1 Retrieve or open the results sets you want to combine.
2 Select the columns you want to combine, then choose Results>
Combine Results>Append Rows.
3 In the Append Rows dialog box, specify the results sets you want.
Appending rows from the second results set to the first. If the results sets have
different column names (for example, Retailer Name and Ret.Name), BI/Query uses
the name of the first set.

4 Specify the second results set in the Second Results Set text box.
5 Click OK.
Joining One Column to Another

BI/Query supports join operations that allow users to retrieve and
manipulate data from more than one table. Typically, the administrator
specifies join operations between data objects to allow users to retrieve
related data from more than one table. (See “Relationships Tie
An equijoin includes only rows
that have an exact match in the
Information Together” on page 21.) Users can perform the same
columns that are joined. operation themselves by retrieving the data they want from the
appropriate tables, then joining the results sets. You may want to join
columns of results when:
• the design window doesn’t provide joins for the attributes you need
to join
A left outer join includes all
rows from the left results set • the design window doesn’t include permission to create
and those that match from relationships between tables
the right.
• the database doesn’t support outer joins
• you want to combine results from more than one database
• after looking at the data you’ve retrieved, you see that you want to
join certain columns, but you don’t want to resubmit the
component queries (particularly if they took a long time to process
A right outer join includes
and you want to save time)
all rows from the right results
set and those that match
If the design window provides the joins you need and you want to reuse
from the left.
a set of joined results, consider creating and saving a standard query that
retrieves the results rather than saving the combined results sets as a
super query. Because the DBMS handles only one query, it may be able
to optimize the join operation more efficiently than BI/Query.
An outer join may even include When you join results sets, you need to specify which columns should
all rows from both results sets,
even if they don’t match. be joined and how. That’s because you’re creating a relationship
between the two tables. With the exception of columns containing
float and money data types, the connecting columns must have the
same data type.

By default, BI/Query joins the columns you specify and includes only
the rows that have an exact match. In SQL terminology, this is an
equijoin. (BI/Query actually performs a type of equijoin called a natural
join, displaying the columns on which you join only once in the
combined results set instead of twice.) In the example below, data
about sales and payments have been retrieved from different tables. An
equijoin allows you to display only those sales for which payment has
been received.
You can also join results and have BI/Query include all rows from a
results set even if they don’t match. In SQL terminology, this is an outer
join. The example below shows that applying an outer join allows you
to display all sales, regardless of whether payment has been received.
You can also apply a left or right outer join, as illustrated in the
diagrams on page 386.
Query Results 1 BI/Query sup-

ports ANSI
Sales # Sales Amount SQL/92 syntax
for left and right
101 $15,000 outer joins for certain data-
bases and connectivities. (For
102 $52,303
more information, see the
213 $995 online Help.)
331 $2,561
511 $8,000
514 $2,303
818 $612
Query Results 2
Sales # Sales Received
101 $15,000
102 $52,303

Query Results 2
331 $2,561
818 $612
Equijoin on Order #
Sales # Sales Amount Amount Received
101 $15,000 $15,000
102 $52,303 $52,303
331 $2,561 $2,561
818 $612 $612
Outer Join on Order #
Sales # Sales Amount Amount Received
101 $15,000 $15,000
102 $52,303 $52,303
213 $995
331 $2,561 $2,561
511 $8,000
514 $2,303
818 $612 $612
To join columns from one results set to another

1 Retrieve or open the results sets you want to join.
2 Choose Results>Combine Results>Join Columns.
3 In the Join Columns dialog box, specify the first results set in the
Left Results Set text box.
4 Specify the second results set in the Right Results Set text box.

The columns you join must have
the same data type
5 Choose the columns you want to join from the lists of columns.
6 To include all rows from one or both results sets, click Include All
Left Rows, Include All Right Rows, or both. (For more information,
see “Understanding Which Columns to Join” on page 389.)
7 Click OK.
Understanding Which Columns to Join

You can join on up to four columns. This is especially useful when the
primary key consists of two or more fields. By default, BI/Query applies
an equijoin, including only the rows in both results sets that have an
exact match in the joined columns. The columns you join appear once
in the combined results set. You can specify a different join using the
Include All Left Rows and Include All Right Rows check boxes.

To Include This Do This
Only rows that have an exact Leave Include All Left Rows and
match (equijoin). Include All Right Rows unchecked.
All rows from the left results set Click Include All Left Rows.
and those that match from the
right (left outer join).
All rows from the right results Click Include All Right Rows.
set and those that match from
the left (right outer join).
All rows from both results sets, Click Include All Left Rows and
even if they don’t match. Include All Right Rows.
Performing Calculations
You can perform basic calculations in a results window to determine
maximum, minimum, sum, and average values for a set of results. For
example, you can calculate the maximum and minimum values for all
attributes in the query as well as the sum and average values for each
numeric attribute.
,To perform basic calculations on a results set

1 In a results window, choose Results>Filter Results>Compute.

Updating Records in the Database
Setting Up BI/Query 393

Setting Key Fields 393
Assigning the Update Database Permission 394
Removing the Update Permission for
Attributes 394
Granting Database Permissions 395
Adding, Modifying, and Deleting Records 395
Adding Records from Another Application 397
Preparing the Text File 398
Specifying Results Options 398
Importing the File into BI/Query 399
Applying Updates to the Database 400
Correcting Errors 400
Updating Records in
the Database
Administrators can use BI/Query Admin and authorized users can use
BI/Query Update to add, modify, and delete records in the corporate
database. BI/Query is designed primarily for maintaining tables, not for
large-scale data entry or updating more than one table at a time.
However, when you have a large number of records stored in another
application, you can use BI/Query to add them to the database.
BI/Query is designed to update records when:
• they’re missing data or need to be corrected

• you’re updating a single table
• only one person is updating a table at a time
• you want to populate an empty table
• you want to add records to the database that are stored in another
application such as Microsoft Excel
Setting Up BI/Query
Before users can use BI/Query to update records in the database, the
administrator must set key fields in the data model, and users must be
granted certain database permissions. If users attempt to apply an update
before the data model and database are set up, BI/Query displays an
alert. For example, if a key field isn’t set, a BI/Query error message
appears; if the appropriate database permission hasn’t been granted, a
database-specific error message appears.
Setting Key Fields

The administrator must set at least one attribute in a data object or
actual relationship to be the key field to allow the corresponding table to

be updated. A key field should be assigned to a primary field in the
table — in other words, a field whose values are unique. This allows
BI/Query to determine which row in the database to update. A table
can have more than one key field. Users can’t update key fields.
To set a key field

1 In BI/Query Admin, choose Layout>Design Mode.
2 Double-click a data object or actual relationship.
3 In the attribute window, click the Key toggle for an attribute.
Assigning the Update Database Permission

To allow authorized users to use BI/Query to make changes to the
data, the administrator needs to assign the Update Database permission.
To assign the Update Database permission

1 In BI/Query Admin, choose Edit>Permissions.
2 In the Permissions dialog box, assign the Update Database
permission.
3 Click OK.
Removing the Update Permission for Attributes

BI/Query assigns update permission by attribute. It’s automatically set
to Update for all attributes in the data model, but the administrator can
remove it to prevent users from updating a specific attribute. (In this
case, users can double-click this attribute in an update window, but
394 Updating Records in the Database

they can’t modify it. Users can, however, update this attribute when it
occurs in new rows.)
To remove the update permission for an attribute

1 In BI/Query Admin, choose Layout>Design Mode.
2 Double-click a data object or actual relationship.
3 In the attribute window, click the Update toggle from the attribute
to remove the check mark.
Granting Database Permissions

The database administrator needs to grant certain database permissions
(select, update, insert, and delete) to allow authorized users to update
specific tables or, depending on the DBMS, specific columns in a table.
Adding, Modifying, and Deleting Records You don’t have to

Once BI/Query has been set up to allow updating and you’ve been retrieve a results
set in order to add
granted the appropriate permissions, you can use BI/Query to add, records to the
modify, and delete records in the database. If a results file stores data database. You can click a data
that you want to add to the database, open the file in BI/Query. If object, then choose Results>
Open for Insert to display an
there are records in the database that you want to modify or delete,
empty update window.
submit a query to retrieve them. The query can include attributes from
only one data object and must include all key fields. (To find out
whether an attribute is a key field, click the question mark beside it in
the attribute window.) To add records stored in another application,
see “Adding Records from Another Application” on page 397.

When you update records, the rows you selected to update are
displayed in the update window in Spreadsheet view. Spreadsheet view
displays multiple records in a format similar to a results window. It’s
useful when you’re updating the same data for more than one record or
when you need to compare records when making changes.
Spreadsheet view displays multiple records.
If BI/Query With results displayed in Spreadsheet view, you can display an

displays an error individual record by double-clicking its row number. Form view displays
message that you
one record at a time and is useful when you want to make changes in a
can’t update more
than one table, you may have more focused update environment and navigate through the records
selected a data object that’s you’ve retrieved.
been merged. In this case,
retrieve results for attributes in
one table at a time.
Form view displays one record at a time.
The view in which you work depends on the nature of the data and the
types of changes you want to make. A key appears beside or above a
key field to indicate that the field is locked and can’t be modified. Any
values you change are displayed in italics, and update indicators identify
whether you want to add, modify, or delete a record. The changes you

make are stored in memory on your computer until you apply them to
the database. (See “Applying Updates to the Database” on page 400.)
To add, modify, or delete records

1 Retrieve the records you want to work with. (Use only one data BI/Query doesn’t
object and include all key fields.) Select the record(s) you want to lock rows that are
update, then choose Results>Update. being updated.
This means that
OR more than one user can make
To update records without retrieving results, click the data object changes to the same records at
you want to update, then choose Results>Open for Insert. one time. To avoid overwrit-
ing another user’s changes,
2 To work in Form view instead of the default Spreadsheet view, make sure that only one per-
double-click the row number of a record. son updates a table at a time.
3 To add a record, choose Results>Insert Row, click in a cell, then
type the information you want.
4 To modify a record, click in a cell, make the change, then click
outside the cell.
5 To delete a record, select it, then choose Results>Delete Row.
Adding Records from Another Application

When records are stored in an application that doesn’t allow you to
update the database, you can import the records into BI/Query, then
add them to the database. For example, you may have created a “batch”
of new records that you want to add to an existing table. Or you may
want to populate a new table that you’ve created in the database. (For
information about creating tables, see “Creating Tables in the
You can import data as a text file and paste data from the Clipboard. Be
sure you’re set up properly. (See “Setting Up BI/Query” on page 393.)
You add records from another application in three basic steps:
• Prepare the data and save it in a text file. (See “Preparing the Text
File” on page 398.)
• Specify results options in BI/Query to match the text file. (See
“Specifying Results Options” on page 398.)

• Import the file into BI/Query. (See “Importing the File into
BI/Query” on page 399.)
Preparing the Text File

To add records from another application, you first prepare the text file.
To prepare the text file

You can easily
create a Microsoft 1 Store the data in a flat text file (usually tab-delimited).
Word file that
contains data to be
2 Don’t include column headings.
imported into BI/Query. 3 Make sure that the columns are in the same order as those in the
Type each value, followed by update window. (To view the order, double-click the data object
a <TAB> character. At the that corresponds to the table you’re updating, select all the
end of each record, press attributes, and submit a query. In the results window, choose
Enter. Don’t press Enter after Results>Update.)
the last record. Save the file as
a DOS text file. If you have 4 Include the key field and make sure that its values are unique. (For
trouble importing a Microsoft example, if the key field is Retailer #, its new values must not
Excel file into BI/Query duplicate existing values in the table you’re updating.)
(Excel doesn’t maintain car-
5 Include all columns flagged as not NULL for the table you’re updating.
riage returns), open the file in
Word and save it as a DOS 6 If you’re very careful, you can include null values. Be sure to
text file. include the exact number of tab characters.
OR
Don’t allow null values. For non-character fields such as integers,
money, and dates, replace nulls with “dummy” values. (You can
clean them up after you’ve inserted the file.) For character fields,
replace nulls with periods to reduce the chance of data becoming
misaligned. (You can use a spreadsheet application such as
Microsoft Excel to correctly insert placeholder values.) Once the
data is in BI/Query, open an update window, delete the contents of
the cells, and do the update. The cell contents become null.
BI/Query doesn’t allow you to insert blank character values (‘s’).
7 Make sure there are no blank lines or spaces at the end of the file.
Specifying Results Options

Before you import the text file into BI/Query, or before you copy the
contents of the Clipboard, you must ensure that BI/Query’s default

results options match the field, record, and end-of-file separators used
in the text file. Because you’re importing a text file, the separators
typically match BI/Query’s default options — Field = <TAB>,
Record = <CR>, and End of File = <None>. If the file uses any other
separators, you must specify them. The only options that should be
specified are the separators.
To specify results options

1 In BI/Query, choose Edit>Preferences.
2 In the Preferences dialog box, click Results Options.
3 In the Results Options dialog box, specify the file separators you want.
4 Click OK.
5 In the Preferences dialog box, click OK.
Importing the File into BI/Query

When you import data from a file, the data is inserted into an update You can also
window. An update indicator appears beside each row to mark it to be import data using
the Clipboard. In
added to the database. the source appli-
cation, copy the data to the
To import a file into BI/Query Clipboard. In BI/Query, click
the data object whose table
1 In BI/Query Admin or BI/Query Update, click the data object
you’re updating and choose
whose table you’re updating. Results> Open for Insert.
2 Choose Results>Insert from File, then use the Insert from File Then paste the contents of the
dialog box to specify a text file. Clipboard into the window.

Applying Updates to the Database
To cancel making The changes you make to records in BI/Query are stored in memory
a change in the on your computer. You can apply them to the database as you make
update window,
click the update
them or all at once at the end of a BI/Query session.
indicator for that row to
remove the indicator.
After all the updates are applied, the update indicators become
unavailable. If you try to close the update window before applying the
updates, BI/Query prompts you to either complete the update, cancel
closing the window, or close the window and discard all the updates.
To apply an update to the database

1 In BI/Query Admin or BI/Query Update, connect to the DBMS.
2 In an update window, choose Results>Do Update.
Correcting Errors
If an error occurs while a record is being updated in the database, the
update to that record and the remaining records are lost. Errors may
occur, for example, when data separators or data types are incorrect in
records you’ve imported into BI/Query from another application. You
can correct errors easily.
To correct an error
1 To correct an error in the data separators, check the BI/Query
results options and make sure that the separators you’ve specified
match the separators used in the text file.
2 To correct an error in data types, identify the fields with
mismatched data types by highlighting the first cell in the update
window, then using the arrow keys to move from cell to cell. If the
data type in a cell is invalid, BI/Query prompts you to enclose it
within brace brackets ({}). Do so, or correct the data type. (Keep in
mind that while BI/Query may accept this data type, the DBMS
may not.)
3 When you’ve finished correcting the error, apply the update again.

BI/Query and Other Applications

Automating Tasks
Using Buttons 405 Visual Basic Reference Materials 422

Creating Buttons 406
That Submit Queries 408
That Generate Reports and HyperCubes 409
That Display Design Windows 410
That Execute Scripts 410
That Export Results 411
That Create Tables in the Database 412
Using SQL Scripts 414
Using OLE Automation 416
Using Application Scripts with BI/Query 416
Using Visual Basic to Control BI/Query
Objects 418
Objects 418
Methods 419
Properties 419
Sample Code 419
Application Object 419
Loading a Data Model 420
Submitting a Query 420
Retrieving Results 421
Shutting Down 421
Automating Tasks
You can automate both routine and complex activities in BI/Query so
that you don’t have to do them yourself each time. For example, you
can create a button that submits a query, generates a report from the
results, and prints the report for a weekly staff meeting. You can also
integrate other applications to add customized features to BI/Query
and extend its capabilities — such as retrieving data using BI/Query,
analyzing it in Microsoft Excel, and sending a weekly report to a
colleague in another city over a network.
BI/Query provides several mechanisms for automating tasks. You can

create buttons that automatically carry out routine activities. You can
also create text files of SQL commands and send those files as SQL
scripts to the DBMS for execution. And you can take advantage of
OLE Automation to execute scripts that allow you to run BI/Query in
combination with other applications like Microsoft Excel.
Using Buttons
Buttons (sometimes called executive buttons) store a sequence of actions
The Benefits of Buttons
that is carried out automatically when you click them; they’re a quick
With a single click of a
and easy means of automating activities you carry out frequently. button, you can:
Buttons are ideal for executives and other decision makers who have
• submit standard and
limited knowledge of the database and who want quick answers to super queries and
standard questions. Buttons also provide non-technical users with easy queries you schedule to
access to their data. Administrators can include buttons in design run at a particular time
windows to take these needs into account. With the appropriate • generate reports and
HyperCubes
permissions, users can also create their own buttons.
• send results to files,
You can create buttons that automatically submit queries; generate other applications, and
reports and HyperCubes; display design windows; run scripts; and send database tables
results to applications, files, and database tables. • run application scripts

• display design windows

Creating Buttons
If the Edit Data Model and Save Data Model permissions have been
assigned, you can create buttons in design windows and save them with
the data model. In a split data model, buttons created by the
administrator are stored in the administrator layer; buttons created by
users are stored in the user layer. Users can’t edit or delete buttons
created by the administrator. Before creating a button, you need to
create the query or automated process it will run or the design window
it will display.
If your corporate query environment includes Hummingbird’s

BI/Broker and you have the appropriate system permissions, you can
allow or restrict access to buttons you create. (See “Using the
BI/Broker Repository” on page 137.)
Buttons can display text, icons, and pictures. You can create your own
text and use graphics stored in files; you can also use text and graphics
created in other applications and copied from the Clipboard. (This
allows you to use graphics in formats BI/Query doesn’t normally
support.) You can edit, resize, copy, move, and delete buttons.
Autosizing is turned on automatically so that buttons fit the text or
graphics they display.
BMP format is a Icons are graphics with a specific dimension (32 pixels by 32 pixels). An
good choice for icon file usually has the extension .ico. If you’re using a monochrome
creating graphics
icon, you can assign a color to it. Pictures are stored in BMP, GIF, or
files for use in
BI/Query. BMP format stores WMF format. Graphics imported from the Clipboard are metafiles (the
graphics with the lowest reso- most common format for graphics used by applications like Corel
lution and is available using DRAW) or bitmaps (created in a paint program).
any paint program. Keep in
mind, however, that graphics
To create a button
can add substantially to the
size of the data model. 1 Make sure you have the Edit Data Model and Save Data Model
permissions.
2 Create the query or automated process you want the button to run
or the design window you want it to display.
3 Display the design window in which you want the button to
appear.
406 Automating Tasks

4 In Design Mode, choose Layout>Create Button.
5 In the Create Button dialog box, type a name into the Name text
box that will identify the button if you assign access privileges to it.
Specify the
appearance of
the button
Specify the
actions it
automates
Specify where
to place the
results
Link the button

to the current
query
6 To create a button that displays text, click Edit Text, then use the A fast way to copy
Text Style dialog box to type the text and specify the options you text from the
want. Clipboard is to
click Edit Text,
OR then copy the text into the
To copy text from the Clipboard, click From Clipboard. Click Edit text box in the Text Style dia-
Text, then use the Text Style dialog box to specify the options you log box.
want.
7 To create a button that displays an icon, click Icon. Click Select
Icon, then use the Select Icon dialog box to specify an icon. (If the
icon you want isn’t displayed, click Open File and use the Open
Icon File dialog box to specify one.) Click OK.
OR
To copy an icon from the Clipboard, click Icon, then From
Clipboard.
8 To create a button that displays a picture, click Picture. Click Select
Picture, then use the Open Picture dialog box to specify a picture.
OR
To copy a picture from the Clipboard, click Picture, then From
Clipboard.

9 To add a border, click Border.
10 Click OK.
That Submit Queries
In order to be able When you link a button to a standard query, clicking the button
to link buttons to submits the query and displays the results in the results window. The
queries, the que-
one step of submitting a predefined query replaces the several steps
ries must be stored
in the Queries folder with the required to submit the equivalent ad hoc query. If a query contains a
data model. prompt, you can enter a different value into the prompt each time you
click the button so that the same query returns different results based on
the value you enter.
You can also link a button to a super query that submits multiple
queries, then combines, filters, or reorders the results. Build the ad hoc
queries, manipulate them to produce the results you want, save the
resulting query, then link that super query to a button.
To create a button that submits a query

To submit any ad 1 Create the query you want the button to generate.
hoc query with-
2 Under Linkage in the Create Button dialog box, select Query from
out creating a new
the list on the left.
button each time,
link the button to the current 3 Select a query from the list on the right.
query (<Current Query>)
4 Under Output, click Application, File, or DB Table.
instead of to a specific query.
5 Click OK.

That Generate Reports and HyperCubes
If you create the same reports frequently, you can use buttons to
automate the process. You can link buttons to reports in BI/Query
Reports and BI/Analyze and to HyperCubes in BI/CubeCreator.
Clicking the button submits the query and creates the report or
HyperCube. If the query contains a prompt, you can insert whatever
value(s) you want into the query each time you click the button.
To create a button that generates a report or HyperCube

1 Create the report or HyperCube you want the button to generate.
2 Under Linkage in the Create Button dialog box, select BI/Query
Report, BI/Analyze, or BI/CubeCreator from the list on the left.
3 Select a report or HyperCube from the list on the right.
OR
Click Browse, then use the Browse dialog box to specify a file.
4 If you choose BI/Query Report, make sure that Refresh is selected.
5 Click OK.

That Display Design Windows
You can link a design window to a button so that clicking the button
displays the window. That window can display data objects and
relationships for submitting ad hoc queries and reports, display buttons
for submitting “canned” queries and reports, or provide information
about the data model. You can link buttons to a series of design
windows containing buttons to create an Executive Information
System interface. (See “EIS Data Model” on page 85.)
To create a button that displays a design window

1 Create the design window you want the button to display.
2 Under Linkage in the Create Button dialog box, select Window
from the list on the left.
3 Select a window from the list on the right.
4 Under Output, make sure that Window is selected.
5 Click OK.
That Execute Scripts

A script is a set of commands that controls the actions of one or more
applications. A script can submit a query, send the results to an Excel
worksheet, and launch a macro that calculates a 12-month running

total. This feature is supported by OLE Automation. (For further
information, see “Using OLE Automation” on page 416.)
You can link a button to a script so that clicking the button carries out
the activities specified in the script.
To create a button that executes a script

1 Create the script that you want the button to execute.
2 Under Linkage in the Create Button dialog box, select Script from
3 Select a script from the list on the right.
4 Click Browse, then use the Select Application dialog box to specify
the application that you want to act as the OLE Automation
controller (such as Microsoft Visual Basic or Excel).
5 Type any required parameters (document name, application or
executable file name, or World Wide Web address) into the
available text box.
6 In the Create Button dialog box, click OK.
That Export Results

BI/Query provides a number of options for exporting results using
buttons. For example, you can link a button to a query that exports
results to other applications using Microsoft’s DDE facility, and a series
of menu commands. Clicking the button copies the results to the
Clipboard, checks whether the receiving application is already running,
and, if it isn’t, starts it up. Depending on the export mechanism you’re
using, BI/Query calls the menu commands in the receiving application
or sends the DDE commands to the application.
You can also link a button to a query that saves the results as a text file.
If you’re writing a report about this quarter’s sales in Microsoft Word,
you can then open the text file in Word and copy the information into
your report.
To create a button that exports results

1 Create the results set that you want the button to export.

3 To export results to another application, click Application under
Output.
OR
To export results as a file, click File, then specify a file name in the
Filename text box.
4 Click Results Options, then use the Results Options dialog box to
specify the options you want. (For more information, see
“Specifying Results Options” on page 435.)
OR
Click Export Options, then use the Export Options dialog box to
specify the options you want. (For more information, see
“Specifying Export Options” on page 437.)
That Create Tables in the Database

If you have the Submit to Table, Edit Model, and Save Model
permissions and you’ve been granted permission to create tables in the
database, you can create a button that submits a query, sends the results
to a new table in the database, and creates the corresponding data object
in the active design window. You can then use the new table to
formulate future queries. For example, if you submit a query that
accesses several tables, uses multiple joins, and retrieves many rows of
results, you can store the results in the table, then query the table for
faster access to the data and to reduce the load on the database server.

This facility is particularly useful if you’re analyzing data that doesn’t
change regularly.
If you have the Dynamic Relationships permission and Allow Dynamic

Relationships preference, you can create a dynamic relationship to link
the new data object to the other data objects and relationships in the
window. If you also have the Submit to Named Table permission, you
can name the table and the corresponding data object. This instructs
BI/Query to drop and re-create the table with the current results each
time you click the button; otherwise, BI/Query creates a new table
each time and allows you to name only the corresponding data object.
To create a button that saves results to the database

1 Make sure you have the Submit to Table, Edit Model, and Save
Model permissions and that you’ve been granted permission to
create tables in the database.
2 Create the results set that you want the button to save.
4 Select a query from the list on the right.
5 Under Output, click DB Table, then type a name for the new data
object in the DB Table text box.
OR
Leave the text box blank so that you’re prompted for a name each
time you click the button.

Using SQL Scripts
You can use an If you know SQL, you can automate certain tasks using SQL scripts. An
SQL script to send
SQL scripts is a set of SQL commands saved in a text file that you send
an EXEC state-
ment to the data- to the DBMS for execution. It’s a one-way transmission of SQL; it
base to call a procedure stored doesn’t contain SQL that returns data. SQL scripts can contain multiple
in the DBMS — for example, SQL statements, such as insert, update, and modify.
to update data. First store the
procedure in the DBMS if it’s Administrators can use SQL scripts to create tables in the database for
not already there. In
use in a data model. (See “Using an SQL Script” on page 118.) They
BI/Query, you need the
Allow Non-select SQL per- can also use SQL scripts to grant database permissions, drop tables (such
mission. Display the Query as tables that users have defined), and move tables to a different
window, type the EXEC database. Authorized users can use SQL scripts to add and update tables
statement, then submit the
query. You can automate this and data in the database.
activity by saving the query
and linking it to a button. Sending SQL scripts to the DBMS has several advantages over
executing the corresponding commands yourself. If you’re not familiar
with tools other than BI/Query for connecting to the DBMS, you can
create the required commands in the more familiar environment of a
text editor instead of typing them in a TCP connection to a UNIX
server or using your front-end DBMS tool. You can also work off-line
instead of being connected to the DBMS. In addition, SQL scripts
allow you to include additional syntax that isn’t provided in BI/Query,
and for operations that BI/Query does provide, it allows you to fine-
tune the SQL to meet your exact needs.
Before sending an SQL script to the DBMS, make sure that you have
the Send SQL Scripts permission in BI/Query and that you’ve been
granted the appropriate database permissions. Sending SQL scripts
doesn’t compromise any restrictions placed on users by the DBMS, but
it does override BI/Query restrictions, such as the Allow Non-select
SQL permission. When you send the script, BI/Query displays the
commands as they’re sent to the host computer, and each command is
executed as it reaches the DBMS. BI/Query monitors for status codes
(success or error) but doesn’t retrieve data.
Two sample scripts are shown below. Keep in mind that they’re
written for a particular DBMS and connection type; your connectivity

may have different requirements. For example, some connectivities
require single quotation marks around each piece of data; others require
double quotation marks. Some require a semicolon after each
statement; others require a carriage return. Before creating an SQL
script, check the documentation for your DBMS and connection type.
create table employee (name char(30), title

char(50), salary number(10,2), date_started date,
department char(30));
This script creates the table, creates the columns, and specifies their data types.
insert into employee values ('Brennan, Sharon',

'Legal Secretary', 23000.00, '10-Jan-86', 'Legal')
This scripts inserts data into the columns of the new table.
To create and send an SQL script to the DBMS

1 In any text editor, type the commands in the format statement 1;
<CR> <CR> statement 2; <CR> <CR>.
2 Insert a blank line between each statement. (This allows BI/Query
to send each statement separately and the DBMS to process it.)
3 Save the file in text format.
4 In BI/Query, connect to the DBMS, then choose Host>Send SQL
Script.
5 In the Open Script File dialog box, select a script file.

6 Click Open.
Using OLE Automation

Automation is one of the features of OLE (Object Linking and Embedding,
Microsoft’s object-based technology for sharing information and
services across applications). OLE Automation allows an application to
take advantage of services (functionality) provided by other OLE-
enabled applications. These services can vary widely from application to
application, but they’re provided through a standard object interface.
OLE Automation requires two components: automation objects and

automation controllers. Automation objects are “programmable”
components of an application, such as the queries and results sets in
BI/Query. Automation controllers are development tools or applications
that allow users and third-party developers to write scripts and create
applications that drive automation objects; Microsoft Visual Basic,
Visual Basic for Applications, and Visual C++ are all automation
controllers. Using an automation controller like Visual Basic, for
example, you can control automation objects in BI/Query in order to
open a data model or design window and submit a query.
Using Application Scripts with BI/Query

The scripts, applications, and Excel macros that can automate processes
in BI/Query are called application scripts. Application scripts allow you
to perform a wide variety of tasks in BI/Query and integrate other
applications with it. A script can submit a query, send the results to an
Excel worksheet, and run a macro that calculates a 12-month running
total. A script can even launch your Web browser so you can download
competitors’ product information and prepare a competitive analysis.

create table employee
insert into employee

values
(‘Brennan, Sharon’, ‘L
Secretary’, 23000.00,
You can create an application script that runs your Web browser and lets you visit
Hummingbird’s Web site (http://www.hummingbird.com) for information on BI/Query and
other business intelligence products.
You can run an application script in an automation controller like Administrators

Visual Basic and have it launch BI/Query and perform the activities it who develop
application scripts
controls. You can also run an application script in BI/Query by linking to be used with
it to a button; clicking the button activates the application script. (See BI/Query should test them to
“That Execute Scripts” on page 410.) When you link a button to an ensure that they work prop-
application script, you can have a controller click a button to launch erly before they distribute the
scripts to users.
another controller. In addition, the application that is launched must
close the current data model before trying to open a new one.
To Do This Specify This
Run Excel and open the Sales2 spreadsheet, excel sales2

which contains a Visual Basic script that starts
up an automation session.
Open the Microsoft Word document report.doc. report.doc
Run Word Perfect and open the document wp maysales.wp

maysales.wp.

Using Visual Basic to Control BI/Query Objects
This section provides basic guidelines for experienced Visual Basic
developers who are writing application scripts for use with BI/Query.
(For a comprehensive list of BI/Query objects, methods, and
properties, see BI/Query’s online Help. For other sources, see “Visual
Basic Reference Materials” on page 422.)
Objects
BI/Query supports a rich set of automation objects. These objects are
arranged in a hierarchy of one parent object and several child objects;
the child objects are accessed through the parent object. In BI/Query,
the parent object is the Application object; the child objects are
DataModel, Window, Query, Prompt, Button, and ResultSet. Child objects
that occur in lists or groups are also called collections and are accessed
using their plural names. For example, to select the Sales Summary
query, the Visual Basic code would include a line that selects the
Queries collection from a list of queries:
Set Query = DataModel.Queries(“Sales Summary”)
Application Parent
object
DataModel Window
Child
objects
Window Query Prompt
Collections
Button ResultSet
Some objects are available only under certain conditions. For example,
the ResultSet object is accessible only from a results window. In
addition, results windows aren’t referred to by their BI/Query name
(such as Query Results 1.1) but rather by the corresponding query

name. For example, the name of the results set for the Sales Summary
query is Sales Summary.
Two characteristics of objects, called methods and properties, allow you to

manipulate and find out information about them.
Methods
Methods are actions that an object can perform. You use methods in
Visual Basic to cause objects to do things you want them to do.
Examples of methods in BI/Query are open (a data model), connect (to
the DBMS), submit (a query), and help (display online Help).
Properties
Properties are characteristics of an object that control its appearance and
behavior. You set and retrieve the values of properties for objects in
Visual Basic to change how they behave. Examples of properties in
BI/Query are cell (sets or retrieves the value of a cell in a results set) and
prompts (returns the list of prompts for a data model).
Sample Code
This section provides some sample Visual Basic code that describes the You can’t use
minimum steps required to use OLE Automation with BI/Query. For BI/Query to edit
application scripts.
simplicity, the code contains no error checking.
Instead, you need
to use a tool like Microsoft
Visual Basic, a Microsoft
Application Object Office application like Excel
or Word, or any programma-
To use BI/Query as an OLE Automation server, you need to first ble tool that supports OLE
create a BI/Query application object. The following code uses a Automation.

Dimension statement to create the BI/Query Application object, then
sets its value to BI/Query User.
Dim
as Object
' Create an application object by running the

specified application
Set gql = CreateObject("GQLUser.Application")
Loading a Data Model

Other than a few rudimentary operations, you can’t do anything with
BI/Query until you load a data model. The following code creates the
Sales DataModel object and opens the Sales.gql data model. The dot
notation provides access to a property or method. In the code below,
DataModel is a property of Application.
Dim Sales DataModel as Object
' Open a data model and create a data model

object
gql.Open("sales.gql")
Set Sales DataModel = gql.DataModel
Submitting a Query
Now that the Sales data model is open, you can work with it — for
example, to submit a query. The following code creates the Sales
Summary Query object, opens the Sales Summary query, and submits it.
Because the Sales Summary Query object is a collection, the query is
selected from a list of queries (DataModel.Queries).
Dim Sales Summary Query as Object
' Execute the "Sales Summary" query

Set Sales Summary Query = Sales DataModel.Queries
("Sales Summary")
Sales Summary Query.Submit

Retrieving Results
When the query completes, you can perform a calculation on the
results. The code below accesses the Sales ResultSet object associated
with the Sales Summary results window. The Sales ResultSet object is
accessed through the Window object. Because the Window object is a
collection, the Sales Summary window is selected from a list of possible
windows (Sales DataModel.Windows). Note how the dot notation
accesses each object in turn. Once you’ve created all the necessary
objects, it would be possible, for example, to write one line of code
that replaces several:
Set Sales ResultSet = gql.DataModel.Windows

(“Sales Summary”).ResultSet
Dim Sales ResultSet as Object
' Result windows have the same name as the query

that created them
Set Sales ResultSet = Sales DataModel.Windows

("Sales Summary").ResultSet
' Read the number of rows

rowCount = Sales ResultSet.RowCount
' Calculate the total of the Sales Amounts column

(column 2)
total = 0
For i = 1 to rowCount
amount = ResultSet.Cell(i, 2)
total = total + Sales ResultSet.Cell(i,2)
Next i
Shutting Down
When you’re finished using BI/Query, you can shut it down.
' Shut GQL down
gql.Quit

Visual Basic Reference Materials
A comprehensive list of BI/Query objects, methods, and properties is
available in BI/Query’s online Help. Additional information on Visual
Basic is available in any of the documentation accompanying OLE-
enabled Microsoft applications such as Access, Excel, and Project. For
example, sources available with Excel include:
• the Microsoft Excel Visual Basic User’s Guide

• Microsoft Excel online Help (includes examples and demos)
• the Visual Basic Reference, available either as an online reference file
with Excel or in print form in book and software stores and from
Microsoft Press
• Microsoft Excel Visual Basic Step by Step, a tutorial that you can order
by calling 615-793-5090 or 800-MS-PRESS; CompuServe
members can order through the Microsoft Press Electronic Book
Store by typing GO MSP

Importing and Exporting Information
Importing Information 425 Using the First Command only on Startup 441
Using the Clipboard 425 Issuing Two Commands to Obtain the
Effect of Three 441
Using Ornaments 426
Exporting Three Queries and Combining
Updating the Database 426
Them in One Worksheet 442
Using OLE 426
Sending Current Results to Excel 443
Creating Linked Objects 427
Running a Macro That Calculates a
Creating Embedded Objects 429 12-month Moving Total 444
Editing Linked Objects 430 Using Mail 445
Editing Embedded Objects 430
Exporting Information 431
Queries 431
Results 432
Using the Clipboard 433
To a File 433
To an Application 434
Preparing Results for Export 435
Specifying Results Options 435
Specifying Export Options 437
Exporting to Excel using DDE 438
Common DDE Commands 438
Setting Export Options for Excel 439
Using Two Commands 440
Importing and
Exporting Information
BI/Query makes it easy to share information with other applications.
You can import text and graphics to enhance the appearance and
usefulness of design windows, and you can import records stored in
other applications to update the database. BI/Query’s OLE support
allows you to create linked and embedded objects in design windows.
You can save BI/Query query and results files for use in other
applications and export results using DDE or menu commands.
Electronic mail allows administrators to distribute queries and results;
users can also share BI/Query files that they’ve created.
Importing Information
If you’ve created text or graphics in another application, BI/Query
provides a number of mechanisms for importing them into design
windows. For example, you can import graphics to represent buttons,
ornaments, and data objects; you can use imported text to create titles,
notes, and instructions. Whatever mechanism you use — whether it’s
using the Clipboard, importing from files, or using OLE — the objects
are imported as ornaments that you can move and resize like any other
BI/Query ornaments. You can also use text imported into BI/Query
to update records in the database, either by importing a text file or by
pasting data you’ve copied from another application.
Using the Clipboard

A simple way to import text and graphics from other applications is to
use the Clipboard. This method is also useful when you’re importing
graphical formats that BI/Query doesn’t support directly.

To import text and graphics using the Clipboard
1 In the source application, copy the text or graphic to the Clipboard.
2 In BI/Query, display a design window.
3 In Design Mode, choose Edit>Paste.
Using Ornaments
You can create ornaments to display icons and pictures created in other
applications. Windows icons are found in .exe, .dll, and .ico files. Any
.wmf, .gif, or .bmp file contains graphical files. Windows 95 and
Windows NT also support enhanced metafiles (.emf). (See also
“Creating Ornaments” on page 198.)
Updating the Database

When records are stored in an application that doesn’t allow you to
update the database, such as Microsoft Word, you can import the
records into BI/Query, then add them to the database. This is useful
when you’ve created a “batch” of records that you want to add to a
table or when you want to populate a new table. You can either import
a text file or paste data that you’ve copied from another application.
(See “Adding Records from Another Application” on page 397.)
Using OLE
More about OLE BI/Query supports Windows’ OLE protocol, which is a standard for
To find out more about exchanging information between applications. It allows you to import
OLE, see the user docu-
information (called OLE objects) from other applications into BI/Query
mentation for any
Microsoft application, design windows without leaving BI/Query. If those applications
such as Word. To find out support in-place editing, you can also edit objects from within BI/Query.
what OLE features an
application supports (such BI/Query is an OLE container, allowing it to import OLE objects from
as in-place editing and other applications. (BI/Query isn’t an OLE server, so it can’t create
drag-and-drop linking),
see its user documentation. OLE objects.) To create a linked or embedded object, the application
in which it was created (the source application) must be an OLE server.
426 Importing and Exporting Information

Both BI/Query and the source application must be installed on your
computer, and your computer must have enough RAM to
accommodate the size of the object.
There are two types of OLE objects: linked and embedded. A linked OLE doesn’t sup-
object is stored in the source document; the data model stores the port multiple-
page objects. If
location of the document and displays a representation of the object. If you import text
you add a linked object more than once to a data model, you can into BI/Query, import only
update it once in the source document, and the changes are made to one page at a time.
every instance of the object. Linking doesn’t add appreciably to the file
size of the data model. When the administrator distributes the data
model, he or she needs to ensure that users have read access to the
source documents for linked objects.
An embedded object, on the other hand, is stored in the data model.

While embedding objects increases the file size of the data model, it
keeps the data model self-contained so it’s easy to copy and distribute.
If any objects are meant to be edited, the administrator needs to ensure
that users have the source application(s).
OLE objects are imported as BI/Query ornaments; you can move and To save space in a
resize them. Saving the data model saves OLE objects with it. OLE design window,
you can import
objects can be an entire file or, if you’re importing from Microsoft
OLE objects as
Word or Excel, a portion of a file. (For example, you can import a icons. In the Paste Special or
selected portion of a worksheet from Excel.) OLE objects can also be Import Object window, click
displayed as icons. OLE objects can take the form of graphics, text, Display As Icon.
sound, and even video. For example, the administrator can import a
video clip into an introductory design window that explains the
purpose of the data model.
Creating Linked Objects

You can create a linked object in a design window by dragging it from
the source application, copying it from the Clipboard, or inserting it.
To create a linked object

1 In BI/Query, display a design window.

How you grab an 2 Open the source file, then select an object or a portion of an object.
object differs from Hold down the Ctrl and Shift keys and drag the object into the
one application to design window.
another. For
example, in Microsoft Excel,
OR
move the mouse over the Open the source file. Select an object or a portion of an object,
edge of the selected work- then choose Edit>Copy. In Design Mode in BI/Query, position
sheet until it becomes a the cursor where you want the object to appear, then choose Edit>
pointer. (Keep in mind that Paste Special. In the Paste Special dialog box, click Paste Link.
not all applications support Click OK.
drag-and-drop linking.)
OR
In BI/Query, position the cursor where you want the object to
appear. Choose Edit>Insert Object. In the Insert Object dialog
box, click Create from File, then specify the path and file name.
Click Link. Click OK.

Creating Embedded Objects
You can create an embedded object in a design window by dragging it
from the source application, copying it using the Clipboard, or
inserting it.
To create an embedded object

1 Display a design window.
2 Open the source file. Select an object, then drag it into the design
window. (To copy the object, hold down the Ctrl key, then drag.)
OR
Open the source file. Select an object, then choose Edit>Copy. In
Design Mode in BI/Query, position the cursor where you want the
object to appear, then choose Edit>Paste Special. In the Paste
Special dialog box, click Paste. Click OK.
OR
In BI/Query, position the cursor where you want the new object
to appear, then choose Edit>Insert Object. In the Insert Object
dialog box, click Create from File, then specify the path and file
name. Click OK. (To create a new object, make sure Create New
is selected, then select an object type. Create the object, then click
in BI/Query. (You don’t need to save the object first.)

Editing Linked Objects
Edit>Linked When you’ve created a linked object, you can edit the object in its
Object changes to source application or in BI/Query (in-place). When you edit the file in
reflect the object
you select. When its source application, then save it, the changes are applied to the object
you select an Excel work- the next time you open the data model. For example, if you’ve added
sheet, it becomes Edit> an Excel worksheet that’s updated every month, whenever the monthly
Linked Worksheet Object;
figures are changed in Excel, they’re made the next time you open the
when you select a picture, it
becomes Edit>Linked data model.
Picture Object, and so on.
If the source application in which a linked object was created is
installed on your computer, you can edit the object in BI/Query.
To edit a linked object

1 Display a design window.
2 In Design Mode, double-click the object.
OR
Click the object, then choose Edit>Linked Object>Edit.
3 Make the changes you want, save them, then exit the application.
Editing Embedded Objects

If the source application you used to create an embedded object is
installed on your computer, you can edit the object in BI/Query (in-
place). When the source application starts up, its menus combine with

BI/Query’s. (The File and Window menus are BI/Query’s; the others
are those of the source application.) If the source application isn’t
installed on your computer, the source application opens separately
from BI/Query, and the object in BI/Query is shaded to show it’s
currently being edited elsewhere.
To edit an embedded object

1 Display the design window that contains the object.
2 In Design Mode, double-click the object. Make the changes you
want, then click in the window to exit the source application. (You
don’t need to save the object first.)
OR
Click the object, then choose Edit>Object>Edit. Make the changes
you want, save them, then click in the design window to exit the
source application.
OR
Click the object, then choose Edit>Object>Open. Make the
changes you want, save them, then choose File>Update to update
the object in GQL.
Exporting Information
You can extend the usefulness of your BI/Query information by
exporting it to other applications to produce powerful worksheets,
reports, and other documents. You can export the underlying SQL for
standard queries, and you can export results. And using electronic mail,
the administrator can distribute BI/Query files, and users can share
them with other users.
Queries
If you have the Save Queries permission, you can save standard queries
for use by other applications by saving the corresponding SQL string as
a text file. You can then include the SQL in reports, use it in stored
procedures in the database, and so on. When you export a query in the

results window, BI/Query saves the query that generated that results
set. In any other window, BI/Query saves the current query.
To export the SQL for a query

1 Make sure you have the Save Queries permission.
3 Select a query, then click Export SQL Only.
4 In the Save Query dialog box, click Export, then specify the name
and location of the file.
5 Click OK.
Results
Query results aren’t just useful in BI/Query — they’re also valuable
when they’re exported to other applications, where they can be
manipulated in other ways. BI/Query exports results files as text files
that can be used by any application. Columns are delimited by your
choice of character. For example, you can augment a quarterly or year-
end report prepared in Microsoft Word by including actual data that
you’ve retrieved from a query. Similarly, you can transfer results to a
worksheet in Microsoft Excel and analyze the data.

You can export results using the following mechanisms:
• Copy results to the Clipboard and paste them into another

application. (See “Using the Clipboard” on page 433.)
• Save results to a file and open the file in another application. (See
“To a File” on page 433.)
• Create a button that exports results to another application using
Microsoft’s Dynamic Data Exchange (DDE) facility or using menu
commands in that application. (See the table on page 434.)
Using the Clipboard

An easy way to export results is using the Clipboard.
To export results using the Clipboard

1 In a results window, select the results you want.
2 Choose Edit>Copy.
3 In the target application, paste the contents of the Clipboard.
To a File
You can make results available to other applications by exporting the
results to a text file. Before exporting results, be sure that they’re
properly set up. (See “Specifying Results Options” on page 435 and
“Specifying Export Options” on page 437.) You can also create a
button that automatically saves the results of a query to a file. (See
“That Export Results” on page 411.)
To save results to a file

1 In the results window, choose Results>Save Results.
OR
To submit the results directly to a file, choose Query>Submit
Query — To File.
2 Specify the name and location of the file.
3 Open the results file in the target application.

To an Application
Results can be exported directly to another application using one of
two mechanisms — menu commands or DDE. When you export
results, BI/Query copies the results to the Clipboard, checks whether
the receiving application is already running, and if not, starts it up.
Depending on the export mechanism you’re using, BI/Query then calls
the appropriate menu commands in the receiving application or sends
the DDE commands to the receiving application. Before exporting
results, be sure that they’re properly set up. (See “Specifying Results
Options” on page 435 and “Specifying Export Options” on page 437.)
Exporting results using these export mechanisms is available using

buttons. (See “That Export Results” on page 411.)
To Do This Use This
Export results by specifying the menu Menu Commands

commands to be executed in the receiving
application. For example, you can instruct
Microsoft Excel to execute Edit>Paste to paste
the contents of the Clipboard into a document.
Include arguments in your commands that DDE

instruct the receiving application to carry out
more specific tasks than simply using menu
commands — for example, to open a particular
worksheet and run a macro. (See also
“Exporting to Excel using DDE” on page 438.)
To export results to an application

1 Under Commands in the Export Options dialog box, click an
export mechanism (DDE or Menu Item).
2 In the available text box, type the commands to be executed in the
receiving application.

Preparing Results for Export
Before you export results, you need to ensure that they’re properly set
up. There are three things to consider:
• display format — how numbers, characters, and dates are

represented (for example, Microsoft Excel doesn’t accept some date
formats allowed in BI/Query, like YY/MM/DD; see “Specifying
Data Formats” on page 245)
• results options — settings required by the receiving application
• export options — the receiving application, the export mechanism,
and the commands to be executed
Specifying Results Options

When you save results to files and export them to other applications,
you need to specify the results options required by the receiving
application. For example, a worksheet application may require double
quotation marks around textual data. (If you’re not sure what the
receiving application requires, check its documentation.)
You can specify results options in the following ways:
• as part of preferences — applies the options only to new results sets

and new buttons
• for a particular results set — specify them after retrieving results,
with the results window active
• when you create a button — overrides the options specified as
preferences
To specify results options

1 To specify default results options, choose Edit>Preferences. In the
Preferences dialog box, click Results Options.
OR
To specify results options for a particular results set, choose
Results>Results Options.
OR

To specify results options when you’re creating a button to
automate exporting results or save them to a file, in the Create
Button dialog box, click Results Options.
2 In the Results Options dialog box, specify the option(s) you want.
(These options are described in the table below.)
3 Under Separators, specify the separator(s) you want in the Field,

Record, and End of File text boxes. (Select them from the lists or
type any valid ASCII characters, such as ^D for Control-D (ASCII
004), <LF> for a line feed, <CR> for a carriage return, and
<TAB> for a tab character. For more information, see the table
below.)
4 Click OK.
This Option Does This
Save Query Includes the name of the query that generated the
Name results. This is useful when you’re exporting to
applications that use worksheet macros to perform
certain operations depending on which query
generated the data.
Save Column Includes results column headings in a block of

Headings results that’s saved or copied.

This Option Does This
Save Prompts Includes information about the prompts used in the

query — for each prompt, the number of prompts
followed by a record separator, the prompt ID
followed by a field separator, the number of values
used in the prompt followed by a field separator,
and the actual prompt values separated by field
separators.
Text in Quotes Inserts double quotation marks around textual data.
Transpose For results saved to a file, transposes rows and

A D
columns so that the data is stored by columns rather
than rows (for example, the first row of results A B C B E
becomes the first column of data); not available D E F C F
when you create buttons.
Original Transposed
Field A character or sequence of characters that separates
Record each value in a row (normally a tab character),
End of File separates each row of data (normally a carriage
return), and indicates the end of the file (normally
no character).
Specifying Export Options

When you export results to other applications, you need to specify the
application to which the results will be exported, the export mechanism
you’re using, and the commands to be executed in the receiving
application. You can specify export options as a preference or when
you create a button. Specifying export options as a preference applies
the options only to new buttons. Export options saved with a button
allow you to automate exporting results; these options override the
options specified as preferences.
1 To specify default export options, choose Edit>Preferences. In the

Preferences dialog box, click Export Options.
OR
To specify export options when you’re creating a button, in the
Create Button dialog box, click Export Options.

To determine the 2 In the Export Options dialog box, select the application to which
requirements of you’re exporting from the Application list. (If it isn’t in the list,
the receiving select User Defined, then specify the file.)
application, see its
user documentation. You may
also need the help of your
administrator to find out
whether an application sup-
ports DDE and what service
name to use.
3 If the executable for the application isn’t in your path, type the path
into the Execute Command Line text box.
4 If you’re exporting using DDE, type the name that the application
registers with the DDE server into the Service Name text box.
5 Under Commands, click DDE or Menu Item.
6 Type the commands to be executed in the receiving application.
(The menu command mechanism requires the format “menu
command|command”.)
7 Click OK.
Exporting to Excel using DDE

This section provides more information about exporting to Excel using
DDE as well as a number of examples. DDE (Dynamic Data Exchange) is
a form of inter-application communication in Windows and OS/2 that
allows applications to exchange information and commands.
Common DDE Commands

Here are some common command sequences used to send results to
Microsoft Excel using DDE. Some of them are used in the examples

that follow. (See “Exporting to Excel using DDE” on page 438.) For
other commands, see your Excel user documentation.
To Do This Use This Command
Open Excel, open a new [paste()]

worksheet, and paste the
contents of the Clipboard
Open a new worksheet with [new()]|[paste()]

Excel already running and
paste the results
Open the test.xls worksheet [open(“c:\msoffice\excel\test.xls”)]

(if Excel isn’t already [paste()]
running) and paste the results
Open the test.xlm macro [open(“c:\msoffice\excel\test.xlm”)]

sheet, then run a macro on [run(“test.xlm!macro1”)]
that sheet
Open the test.xls worksheet, [open(“c:\msoffice\excel\test.xls”)]

open the test.xlm!macro1 |[run(“test.xlm!macro1”)]
macro sheet, and run a macro
Open the test.xlm! macro [run(“test.xlm!macro1”)]

sheet, then run the macro1
macro on that sheet (where
the macro sheet is in the
BI/Query data model folder
or the macro is on the global
macro sheet)
Setting Export Options for Excel

When you set export options for Excel, the default command —
[Paste()] — appears automatically in the Commands text box. When
you export your results, BI/Query starts up Excel if it isn’t already
running, then instructs it to paste the contents of the Clipboard (the
query results) into a worksheet.

To set export options
2 In the Export Options dialog box, specify Microsoft Excel in the
Application text box.
3 Under Commands, click DDE.

4 If the executable for the application isn’t in your path, type the path
into the Execute Command Line text box — for example,
c:\msoffice\excel\excel.exe.
5 In the Service Name text box, supply the name that Excel registers
with the DDE server (Excel).
6 Click OK.
Using Two Commands

Instead of using the default [Paste()] command in the Commands text
box, you can substitute up to two commands — for example, to open a
specific worksheet and paste results. If you’re content with a generic
worksheet, you can open a macro sheet, run a macro on that sheet,
then save it using another name. Unless a macro is on the global macro
sheet, you must first open its macro sheet.

To Do This Type This into the Commands Text Box
Open a worksheet [open(“c:\msoffice\excel\test.xls”)][paste()]

and paste results
Open a macro sheet, [open(“c:\msoffice\excel\test.xlm”)][run

then run a macro on (“test.xlm!macro1”)]
that sheet
Using the First Command only on Startup

If the first of two commands is to be executed only once (such as
opening a specific worksheet on startup), use the | (pipe) symbol
between the two commands: [open(.........)]|[run(.............)]. Be sure
to also use the pipe symbol to prevent Excel from opening a worksheet
that is already open or pasting results into an open worksheet and
overwriting the contents. The first command is sent only if the
application isn’t already running and BI/Query must start it up; the
second command is always sent, even when the application is already
running. Specify all arguments for each command. The pipe symbol is
not necessary if it’s logical for both commands to run each time you
export results. (The pipe symbol has a different purpose here than when
you export results using menu commands.)
Issuing Two Commands to Obtain the Effect of Three

When you open a specific worksheet and run a macro, you’re doing
three things — opening a specific worksheet, opening a specific macro
sheet, and running a macro. You can carry out these three commands
using two in order to use the DDE export mechanism. The two
commands would look like this:
[open(“c:\msoffice\excel\test.xls”)]|[run
(“test.xlm!macro1”)]

To issue two commands to obtain the effect of three
1 Attach Excel’s auto_open function to your worksheet so that your
macro sheet opens whenever the worksheet opens. Do this by
opening the worksheet, then choosing Formula>Define Name.
Specify a name such as Auto_open, then use the following syntax in
the Refers To text box: =test.xlm!open_macro.
2 Place the macro on the global macro sheet (global.xlm). This sheet
is opened automatically with Excel and doesn’t require a command.
Using it cancels opening a default worksheet, but that function can
be included in the macro if needed. The disadvantage to this
approach is potentially developing a global macro sheet containing a
lot of specific macros that aren’t useful in a global sense.
3 Place the macro sheet in your path or in the subdirectory of the data
model you’re using. This is somewhat unorthodox, but the effect is
the same as placing the macros on the global macro sheet, and it has
the advantage of grouping the macros in a separate sheet.
Exporting Three Queries and Combining Them in One Worksheet

You can easily combine the results of more than one query in an Excel
worksheet. This is useful when you’re using data from different tables
or when you’re using a super query.
To combine three results sets

1 Create three buttons in BI/Query, then link each one to a query.
Link each button to a macro that positions the cursor in Excel, then
pastes the results to the appropriate spot on the default worksheet.
Click each button in turn. Don’t close Excel until all three buttons
have sent their results; otherwise, you’ll create three separate
worksheets. For example, set up the buttons with these macros:
This Button Executes This Macro
Button A [open(“c:\msoffice\excel\test.xlm”)]
[run(“test.xlm!macro1”)]
Button B [run(“test.xlm!macro2”)]
Button C [run(“test.xlm!macro3”)]

If the macro sheet is in the BI/Query data model folder, or if the
macros are on the global macro sheet (see “Issuing Two Commands
to Obtain the Effect of Three” on page 441), you can accomplish
the same result using the following macros:
Button A [run(“test.xlm!macro1”)]
2 Create a button that selects the current query, then exports the
results using the default paste to Excel. This method reduces the
number of buttons but requires you to load each query in
BI/Query before running it. You must also reposition the cursor in
Excel each time so that the next set of results does not overlap.
3 Paste to a specific worksheet. Open the macro sheet by following
one of the instructions in “Issuing Two Commands to Obtain the
Effect of Three” on page 441. Then use the following macros:
Button A [open(“c:\msoffice\excel\test.xls”)]
[run(“test.xlm!macro1”)]
Sending Current Results to Excel

You can create a button that exports the results of the current query to
Microsoft Excel using DDE. Using a button saves time when you
export data regularly to Excel. Clicking the button in this example
selects the results displayed in the results window, copies them to the
Clipboard, runs Excel, opens a new worksheet, and pastes the results.

If your Excel worksheet always uses the same format, set up a template
worksheet. Specify an export command that opens the template and
pastes the results, such as [open(“c:\msoffice\excel\template.xls”)][paste()].
Once the results are copied, save the template with another name.
To send current results to Excel

2 Under Appearance, specify the name of the button, such as Send
Current Query to Excel.
3 Under Linkage, select Current Query.
4 Under Output, click Application.
5 Click Export Options and specify the application to which the
results should be exported (Microsoft Excel) using DDE.
Running a Macro That Calculates a 12-month Moving Total

You can create a button that exports the results of a query to Microsoft
Excel using DDE, opens a worksheet, and runs a macro that calculates a
12-month moving total.

To run a macro that calculates a 12-month moving total
1 In Excel, create the macro.
2 In BI/Query, in Design Mode, choose Edit>Create Button.
3 Under Appearance, specify the name of the button, such as Send
Current Query to Excel or Create 12-month Moving Total.
4 Under Linkage, select Current Query.
5 Under Output, click Application.
6 Click the Export Options button and specify the application to
which the results should be exported (Microsoft Excel) using DDE.
Using Mail
If you’re running an electronic-mail application on your computer, you Administrators
can export BI/Query files as enclosures with your mail messages. Mail may find it more
useful to use mail
provides an easy way for administrators to distribute new and revised to distribute revi-
queries and results to users. And at sites where users can create their sions to a data model rather
own queries and results, they can easily share them with other users. than an initial distribution.
Revisions usually include only
a small number of files.

You can use any mail system that supports Microsoft’s Messaging API
(MAPI), such as Microsoft Mail.
You can retrieve When you send mail from BI/Query, the application starts up your
BI/Query files mail client. (For information on using your mail client, see the
using mail. Run
your mail client corresponding documentation.) If you build a query before starting up
and retrieve the files into the mail, BI/Query automatically encloses the corresponding .qry file in
appropriate folders. (For your message — regardless of which window you’re working in. If you
query files, this is the Queries
retrieve a results set, then start up mail, the corresponding .qrd and .qry
folder. For results, this is the
folder where BI/Query is files are enclosed only if the results window is the active window. To
stored; be sure to retrieve automatically enclose a results set, display the results window before
both .qrd and .qrr files.) To use running mail. If you don’t want to include the current query or results
retrieved files, close the data
set in a mail message, remove the file from the enclosure.
model if it’s open, reopen it,
then open the files.
To send mail from BI/Query
1 Choose File>Send.
2 Specify a recipient and subject and enclose any additional files.
3 Send the message.

Index 1
A ad hoc
drill-down mode, 323–324
access to data, 131–150 queries. See queries
attributes, hiding, 132–133 Ad Hoc Drill Down command, 323
BI/Broker Repository, using, 137–141 adding
controlling annotations, 205–206
by item, 139–140 attributes, 235–237, 330, 334–336
by user and group, 141 calculated, 146
data model permissions, 142–143 buttons, 95
data values colors, 251–252
disabling, 135–136, 258 data to tables, 194
See also data values database information, 149–150
inheritance, 138 metadata, 81–82, 179–190
qualifying tables, 133–135, 157 OLE objects, 426–431
tables in database, 131–136, 149–150 ornaments, 95, 198–200
users and groups, 137–141 qualifications. See qualifying
Access to DB Values command, 136 records to database, 393–400
actions, 365–374 errors, 400
Broadcast Message, 369 from another application, 397–399, 426
distributing, 367–370 rows of results, 384–386
E-mail, 367 See also creating
FTP, 369 administrator layer, 25, 126, 145, 233–234
notifying, 367–370 distributing, 211–212, 219–228, 234
yourself, 373–374 files, 25, 40, 126, 211–212, 223, 233–234
Print, 368 finding, 42–43
Publish Query Results, 366 moving user layer contents to, 233–234
Publish, 370 passwords, 123–124
Push, 370 reestablishing path to, 42–43
Run Command on Server, 371 aggregate functions, 327–333, 335, 336
Run Query, 366–367 alarms, 251–252
Trigger Event, 371–373 aliasing
actual relationships, 22, 100, 101–102 data objects. See correlation names
attributes, key, 393–394, 396 data, 266–269
copying, 95 aligning objects, 171–172
correlation names, 95 Allow Dynamic Relationships permission, 147
creating, 101–102 Allow Dynamic Relationships preference, 147, 325
design windows, using multiple, 95 Allow Non-select SQL permission, 121, 145, 414
join conditions, 104–107 altering. See editing
naming, 101–104 Annotate command, 206
qualifying, 133–135, 157, 237–238, 269 annotating online help, 205–206
queries, 291 Append Rows command, 384, 385
updating, 235–238 appending rows of results, 384–386
Index 447
applications connections to DBMS, 64, 149, 155–156
exporting to. See exporting querying, 357
importing from. See importing automation
objects, 418, 419 controllers, 411, 416, 417
scripts. See scripts objects, 416, 418–419
attaching. See linking scripts. See scripts
attributes, 20–21, 99–100 autosizing ornaments, 199, 406
actual relationships with, 22 AVERAGE DISTINCT function, 329
adding, 146, 235–237, 330, 334–336 AVERAGE function, 329
calculated, 146, 237–238, 330, 333, 334–336 average value for results, 390
calculations on, 326–337, 390
comments, 190–198
creating, 99, 116–117, 330, 334–336 B
data formats, 245–253
data objects with, 20–21 batch processing. See scheduling queries
data types, 235–237 BI/Analyze, 13, 79
data values, 135–136 BI/Broker Repository, 31, 39, 68, 215–219, 310, 357,
disabling, 135–136 366, 370
displaying, 295–298 publishing
database name, displaying, 194 data models, 137, 215–219
deleting, 132, 133, 235–238, 238–240 queries, 310–311
descriptions, 190–198 retrieving
functions, applying, 326–336 data models, 39–40
grouping, 327–328, 331–334 queries, 312
hiding, 132–133, 192, 237 setting security, 137–141
in variables, 280 BI/Broker, 12, 39, 131, 310, 357, 369, 371, 372
indexing, 78 BI/Query Admin, 12, 13
joining objects, 104–107 BI/Query Reports, 13
key, 393–394, 396 BI/Query Update, 12, 13
names BI/Query User, 12, 13
displaying, 194 BI/Query, 12
specifying, 96, 104 exiting, 421
null values, allowing, 235–237 overview, 5, 12–13, 17–33
ordering, 99–100, 382–383 starting, 37–39
sorting, 378–380 suggesting enhancements, 10
updating, 394 using on the Web, 32
automatic variables. See variables BI/Web, 12
automating Personal Portfolio, 32, 39
activities, 405–422 bitmap files, 199, 406
macros, 416 BMP format, 406
OLE, 405, 411, 416–422
scripts, 405, 410–411, 414–416
448 Index
borders Check Design command, 125
buttons, 408 checking design of data models, 124–125
ornaments, 200 child objects, 418–419
boxes, using, 175 circular queries, 347–354
Broadcast message action, 369 no correlations, 352–354
buffers, using, 153–155 with correlations, 348–352
buttons, 23, 405, 405–406, 436 Clear command, 133
adding, 95 Clipboard
aligning, 171–172 exporting to, 411, 433, 433
borders, 408 importing from, 198, 200, 397, 407, 425–426
colors, specifying, 176, 201–205 collection, 97, 117
copying, 95 Color Objects in Active Window command, 203
creating, 406, 413 colors, using, 170, 176, 201–204, 251–252
deleting, 95, 406 Column Order command, 382
editing, 95, 406 columns in results
graphical, 176, 406 hiding, 132–133, 382–383, 384
iconic, 406 joining, 386–390
moving, 95 ordering, 382–383, 384
queries, linking to, 408–410 sorting, 379
scripts, running, 410–411, 417 viewing hidden, 383
split data models with, 41, 95, 406 Combine Columns command, 384
tables, creating, 412–413 Combine command, 302
textual, 173–174 Combine Results command, 385, 388
windows, linking to, 18, 410 combined data models, 24, 27–28, 41, 127, 145
distributing, 214–215, 219–228
editing, 234
C files, 223
passwords, 123–124
calculated attributes, 146, 330, 333, 334–336 saving, 125–126, 127
updating, 237–238 combining
calculations qualifications, 296, 301–302
in variables, 280 results, 339, 383–390
on results, 390, 421 comments for attributes, 190–198
with attributes, 146, 326–337 Compare Table dialog box, 236
with queries, 326–336 comparing
canceling data model to database, 235–238
ad hoc drill-down mode, 323 queries to data model, 238–240
queries, 146, 160–161 comparison operators, 303–304
scheduled jobs, 164 compiling help files, 206
Case-sensitive Comparisons preference, 294 Compute command, 390
catalog table, using, 190, 192–198 Computed Attributes permission, 121, 146
characters, special, 250–251 computed strings, 251–252
Index 449
condition box, 302, 319 data models to
conditional prompts, 270, 274–279 diskettes, 220
conditions, applying. See qualifying file server, 214, 219–220
Connect Automatically preference, 62, 155 data objects, 95, 108–110
Connect command, 69 OLE objects, 427–429
Connect Objects command, 101, 102 ornaments, 95
Connect per Query preference, 149 relationships, 95
Connect per Window permission, 65 user layer to administrator layer, 233–234
connecting correcting errors, super queries, 345–347
lines between data objects, 100–102 correlation names, 95, 109, 109–110, 348
per window, 64–67 Count All command, 331
to DBMS, 47–69, 148–149, 153–156 COUNT DISTINCT function, 330
automatically, 62–64, 149, 155–156 COUNT function, 329, 333
creating connection files, 48–50, 148 Create Button command, 407, 440
default connection files, 48, 69, 217 Create DB Script command, 119
disconnecting after query processed, 155–156 Create DB Tables command, 117, 193
Ingres/Net, 153 Create Ornament command, 199
middleware, 47 creating
multiple databases, 64–67 actual relationships, 101–102
passwords, 148 annotations, 205–206
row buffering, 153–155 attributes, 99, 116–117, 330, 334–336
SQL*Net, 153 descriptions, 190–198
TCP/IP connections, 52–61 buttons, 406, 413
testing, 51 circular queries. See circular queries
connection files, 47, 48–69 colors, 204
assigning to design windows, 64–67 connection files, 48–51, 148
creating, 48–52 correlation names, 109, 109–110
distributing, 52 data models, 93–127
TCP/IP, 52–61 See also designing data models
testing, 51–52 data objects, 96–100, 115, 116–117, 150, 157, 412–
Connections command, 49, 51, 61, 69, 116 413
Contents command, 8, 10, 206 data values
Control Panel settings, 245, 245–247 query files, 264–266, 276
conventions in this guide, 7 results files, 261–263
converting design windows, 95–96, 167–176
data objects and relationships, 101–102 embedded
two-digit years, 252–253 objects, 429
Copy command, 433 relationships, 101
Copy Query to Model command, 342 help files, 206
copying join conditions, 104–107
buttons, 95 lines in design windows, 173
Clipboard, using, 425–426, 433 linked objects, 427
450 Index
metadata, 179–190 combined, 24, 27–28, 41, 127, 145, 234
nested queries, 317–318 See also combined data models
ornaments, 198–200, 425–426 comparing with queries, 238–239
prompts, 270, 272–273, 275 creating, 93–127
queries. See queries data objects, 20–21
relationships, 100–102, 147, 324–326 designing. See designing data models
results files, 196–198 distributing, 211–228, 234, 427
split data models, 126–127 BI/Broker Repository, using, 215–219
subqueries, 317–318 combined, 214–215
tables in database, 114–120, 150, 157, 192–194, 229, database, using, 221–230
230, 412–413 diskettes, using, 220
variables, 281–286 file server, using, 219–220
creator 97, 117 mail, using, 220–221
creator name, 97, 117, 187, 229–230 split, 211–212
Custom Checks permission, 148 editing, 19, 41, 145, 233–234, 235–240
customer support, 9–10 files, 25, 26, 40–42, 211–215, 233–234
ID, 223, 224, 226, 228
join conditions, 237–238
D loading from database, 41–42, 224, 229, 420
opening, 32, 40–41, 62, 63, 93–94
data ornaments. See ornaments
about data. See metadata 179 overview, 18–28
access. See access to data passwords, 123–124
adding to tables, 194 permissions, 121–122
aliasing, 266–269 preferences, 122–123
dictionary, using, 190, 192–197 publishing, 31–32, 215–219
entering, 245–248 refreshing, 132, 235–240
formats, 245–253 relationships, 21–22
colors, 251–252 retrieving from repository, 32, 39–40
dates, 245–247, 247, 250 saving, 32, 125–127
default, 245 securing, 32
numbers, 245–247, 249 sharing, 31–32
strings, 250 split, 24, 25–27, 40, 145, 233–234
groups, 327–328, 331–334, 336 See also split data models
in multiple databases, 64–67 storing, 31–33
organizing in database, 79–81 table access, 131–136
substituting values, 251–252 testing, 227
types, 235–237 updating, 132, 235–240
updating in database, 145, 149–150 user access, 131–150
data models, 18–28, 93–127 version, 224, 228
buttons. See buttons windows. See design windows
checking design, 124–125 Data Object tool, 116
Index 451
Data Object Relationship command, 102 query files, 136, 156, 257–259, 264–266
data objects, 20–21 creating, 264–266, 276
alias names, 109, 109–110 lookup table, using, 77
aligning, 171–172 naming, 258–259
attributes, 20–21, 99–100 prompts with, 258–259, 276
adding, 116–117 results files, 136, 156, 257–263
key, 393–394, 396 creating, 260–263
ordering, 99–100 naming, 258–259
colors, specifying, 176, 201–205 prompts with, 258–259
connecting, 21–22, 100–107, 324–326 spreadsheet, using to create, 262–263
converting to actual relationships, 101–102 text editor, using to create, 262–263
copying, 95, 108–110 database
correlation names, 95, 109, 109–110 adding records to, 393
creating, 96–100, 115, 116–117, 150, 157, 412–413 from another application, 397–399, 426
design windows, using multiple, 21, 95 catalog table, using, 190, 192–197
iconic, 200–201 connecting to, 47–69, 148–149, 153–156
join conditions, 104–107 creating tables in, 114–120, 150, 157, 192–194, 229,
merging, 111–114 230, 412–413
names, 194 data
displaying, 101 access, 131–136
specifying, 96, 108, 109, 150, 413 dictionary, using, 190, 192–197
qualifying, 133–135, 157, 237–238, 269 organizing, 79–81
queries, 291 data models, loading, 41–42, 224, 229, 230
ranking, 158–160 DB2, 158
refreshing, 132, 235–238 deleting records from, 393–397, 400
relationships between, 21–22, 100–107, 147, 324–326 denormalizing tables, 78
updating, 235–238 designing, 77–81
data types, 334 distributing data models from, 221–230
invalid, 400 editing, 149–150
Data Values command, 294 indexing attributes, 78
Data Values folder, 211, 214, 229, 258 load
Data Values Results command, 197, 198, 261, 263 data models, 41–42, 224, 229, 420
data values, 29–30, 135–136, 257–269 managing, 146, 153–164
access, 135–136, 258 tables, 96–100
aliasing data, 266–269 lookup tables, 77
displaying, 295–298 managing load on, 146
files, 223, 257–269 modifying records in, 393–397, 400
icon, 295–298 names, 194
in variables, 280 Oracle, 158–160
prompts, using with, 258–259, 276 populating tables, 194
qualifying attributes with, 29–30, 156, 257, 294, 295, ranking tables, 158–160
296–298 resources used for query, 158
452 Index
specifying, 97, 117 settings, 122–123
summary information, storing, 79 text styles, 245
Teradata, 158 defining. See creating
updating, 112, 145, 149–150, 194, 393–400 Delete Row command, 397
See also DBMSs deleting
Database Management Systems. See DBMSs attributes, 132, 133, 235–238, 238–240
database name, 187 buttons, 95, 406
DataVals folder, 25–26 calculated attributes, 334
Date Entry command, 253 characters in a string, 250
dates database information, 145, 149–150
calculating in variables, 281, 282 ornaments, 95, 198
entering, 294 qualifications on attributes, 294, 296
fixed, 252–253 records from database, 393–397, 400
formats, 245–247, 250 scheduled jobs, 164
scheduling, 358–362 denormalizing tables in database, 78
sliding, 252–253 denying access to data, 138
DBMSs descriptions for attributes, 190–198
connecting, 47–69, 148–149, 153–156 Design Mode, 19–20
automatically, 62–64, 149, 155–156 design windows, 18–19, 95–96
creating connection files, 48–51, 148 aligning objects, 171–172
default connection files, 48, 69 assigning connection files, 64–67
middleware, 47 boxes, 175
multiple databases, 64–67 buttons. See buttons
passwords, 148 colors, specifying, 170, 176, 201–204
TCP/IP connections, 52–61 creating, 95–96
testing connections, 51 data objects, 21
disconnecting after query processed, 155–156 designing, 167–176
Ingres/Net, 153 displaying, 410
Oracle, 158–160 graphics, 176
permissions, 142, 395 lines, adding, 173
row buffering, 153–155 mastheads, 172
SQL scripts, naming, 94, 95
sending, 148, 414–416 ornaments. See ornaments
SQL*Net, 153 tables, loading, 96–100
Teradata, 158, 334 white space, 174–175
DDE, 411, 433, 434, 438–445 designing
commands, 438–439 data models, 75–76, 96, 97, 100, 167–176
exporting to Excel, 438–445 accessing user, 75–76
default checking design, 124–125
colors, 201–203 data access, 131–150
connections, 48, 69 database, 77–81
data format, 245, 248 detached queries, 161
Index 453
dictionary, data, 190, 192–198 E
disabling access to data. See access to data
disconnecting after query processed, 155–156 Edit command (for OLE), 431
diskettes, distributing data models using, 220 Edit command, 430
displaying Edit Data Model permission, 95, 115, 121, 145
data object names, 101 edit mask, 251–252
data values, 295–298 Edit menu. See specific commands
data, 245, 248–252 Edit Operation command, 344
database names, 194 Edit Queries permission, 121, 133, 145, 321, 322
design windows, 410 editing
hidden columns, 382–383 application scripts, 419
relationship buttons, 41, 95, 406
icons, 101 calculated attributes, 334
names, 101 combined data models, 234
scheduled jobs, 162–164 data formats, 248–252
Distinct command, 261, 263, 265, 276 data models, 19, 145, 233–234, 235–240
distributing database, 149–150
connection files, 52 embedded objects, 430
data models, 31–33, 211–228, 234, 427 join conditions, 237–238
BI/Broker Repository, using, 215–219 linked objects, 430
combined, 214–215 logon scripts, 57–58
database, using, 221–230 online help, 205–207
file server, using, 219–220 ornaments, 41, 95, 198
mail, using, 220–221 qualifications. See qualifying
split, 211–212 queries, 145–146, 158, 238–240, 321–323
queries, 31–33 records in database, 393–397, 400
BI/Broker Repository, using, 310–312 split data models, 233–234
reports, 31–33 SQL string, 145–146, 158, 321–322
scheduled job output, 367–370 super queries
TCP/IP settings, 60–61 component queries, 340, 342–343
Do Update command, 400 operations, 340, 343–345
documentation conventions, 7 TCP/IP settings, 58–60
downloading from database, 41–42, 229, 230, 420 electronic documents, 8–9
drawing toolbar, 94 e-mail
duplicate information, suppressing, 330 action, 367
Dynamic Data Exchange, 411 address, Hummingbird, 10, 11, 14
Dynamic Link Library (DLL) files, 148 embedded
Dynamic Relationships permission, 121, 325 objects, 199, 426
dynamic relationships, 110, 147, 324–326 creating, 429
editing, 430
relationships, 22, 100, 101
creating, 101
454 Index
join conditions, 104–107 results, 136, 156, 257–263
Enforce Connect per Query permission, 64, 65, 149, 155 Dynamic Link Library (DLL), 148
enhancements, suggesting, 10 exporting to, 411–412, 433, 435–437
equal joins, 105, 387–390 formats, 199, 406
errors graphics, 199, 406
connecting, 51 icons, 199, 200, 406, 426
editing super queries, 345–347 importing
updating database, 400 results, 397
Estimate Resources command, 158 importing, 426
events, scheduling based on, 362–365, 371 results, 426
Excel, 23, 405, 411, 416–418 mailing, 220–221, 445–446
exporting to, 411, 438–445 names, 258–259
importing from, 398, 427 online help, 206, 207
exception reporting, 251–252 passwords, 123–124, 148
EXEC statements, sending to database, 414 Prompts, 279, 281
executive buttons. See buttons prompts, 270
exiting BI/Query, 421 queries, 223, 310, 431–432
exporting, 431–446 reports, 223, 446
buttons, using, 433, 436 results, 190, 196–198, 309–310, 411, 433
Clipboard, using, 433 separators, 398
DDE, using, 434, 438–445 server, using, 219–220
mailing files, 445–446 storing centrally, 31–33
queries, 431–432, 445–446 TCP/IP settings, 60–61
reports, 446 Fill Color tool, 203
results, 309–310, 411–412, 412–413, 432–438, 445– Filter Results command, 379, 381, 390
446 filtering results, 338–339
format, 435–437 finding
to Excel, 438–445 administrator layer, 42–43
expressions. See variables errors in data model design, 124–125
FireEvent utility, 372
fixed dates, 252–253
F fixing. See updating
Form view, 396–397
fields. See attributes Format command, 248
File menu. See specific commands formats
file transfer protocol, 369 data, 245–253
files colors, 251–252
administrator layer, 223 default, 245
data models, 25, 26, 211–215, 233–234 substituting values, 251–252
distributing, 211–230 dates, 245–247, 250, 294
data values, 223 graphics, 406
query, 136, 156, 257–259, 264–266, 276 numbers, 245–247, 249
Index 455
formats (continued) grouping
results, 435, 435–437 attributes, 327–328, 331–334, 336
strings, 251–252 prompts, 270, 271–279
See also designing groups, 137–141
formulating. See creating
four-digit years, converting to, 252–253
FTP action, 369 H
functions, 327–334
aggregate, 327–337 HAVING clause, 332–333
AVERAGE DISTINCT, 329 help
AVERAGE, 329 compiler, 206
COUNT DISTINCT, 330 obtaining technical support, 9–10
COUNT, 329, 333 online, 8, 205–207
group order, 327–328, 331, 332, 336 Help menu. See specific commands
in variables, 280 heterogeneous connections. See connecting to multiple da-
MAXIMUM, 329 tabases
MINIMUM, 329 Hide Column command, 383, 384
none, 329 hiding
qualifying attributes, 331–333 attributes, 132–133, 192, 237
scalar, 336 columns
SUM DISTINCT, 330 in tables, 132–133
SUM, 79, 327, 328, 329, 331 of results, 382–383, 384
hierarchical prompts, 270, 271–279
homogeneous connections. See connecting to multiple da-
G tabases
How to use Help command, 8
GQLMETA table, 223, 228, 229, 229–230 Hummingbird
GQLMnnnn table, 223 BI/Analyze, 13, 79
GQLQnnnn table, 223 BI/Broker, 12
GQLRnnnn table, 223 BI/Query, 12
GQLVnnnn table, 223 BI/Web, 12
granting access to data, 138 e-mail address, 10, 11, 14
graphics, 199, 406 Professional Services, 11
buttons with, 176, 406 Sales, 14
design windows with, 176 technical support, 9–10
formats, 406 Trace Utility, 10
importing, 425–426 Web site, 10, 11, 14
ornaments with, 198–200, 425–426 HyperCubes, 79
Grid Settings command, 171
grid, aligning objects, 171–172
Group Qualification command, 332
group qualification, 332–333
456 Index
I J
icons, 199, 200, 406, 426 job actions. See actions
buttons with, 406 jobs. See scheduling
data objects with, 200–201 Join Columns command, 387, 388
importing, 425–426 Join Conditions command, 105
ornaments with, 198–200, 407 join conditions, 104–107, 325
relationships with, 101 creating, 104–107
importing, 425–431 prompts, including, 106–107
attribute descriptions, 190, 197–198 updating, 237–238
Clipboard, using, 198, 425–426, 428, 429 variables, including, 106–107
data values, 262 joining columns of results, 386–390
results, 262–263
files, 397, 426
graphics, 425–431 K
icons, 425–426
OLE objects, 426–431 key attributes, 393–394, 396
ornaments, 425–426 kinked lines, creating, 100
prompts, 279–280
results from another application, 262–263, 397, 426
text, 397, 425–431 L
variables, 286–287
video, 427 Layout menu. See specific commands
indexing attributes, 78 layout palette, 94
information access. See access to data layout. See designing
inheritance, 138–139 leaving
conflict, 139 BI/Query, 422
denying, 138 prompts empty, 299
granting, 138 Line Color tool, 203
Insert Attribute command, 99, 190 Line tool, 173
Insert DB Name command, 315 lines
Insert from File command, 399 adding, in design windows, 173
Insert Object command, 428, 429 kinked, 100
Insert Subquery command, 318 Linked Object command, 430
inserting. See adding linked objects, 199, 426–428
invalid data creating, 427–428
entry, 248 editing, 430
types, 400 linking
buttons to
applications, 411
design windows, 410
queries, 408–410
Index 457
linking (continued) M
buttons to (continued)
scripts, 410–411, 417 macros. See scripts
tables in database, 412–413 mailing files, 220–221, 445–446
data objects, 100–102, 324–326 MAPI, 220–221, 445–446
data values to mastheads, using, 172
attributes, 258–259 Maximum Rows Retrieved permission, 146
prompts, 258–259, 276 MAXIMUM function, 329
objects using OLE, 426–428 Maximum Query Time permission, 146, 161
creating, 427–428 Maximum Rows Retrieved permission, 161
editing, 430 maximum value for results, 390
queries to buttons, 23 menu commands. See specific commands
reports to buttons, 23 Merge Joins command, 113
scripts to buttons, 23 Merge Object command, 113
windows to buttons, 18 merging data objects, 111–114
list icon, qualification tree, 294 message pane, super query window, 342
load Metadata Source command, 186, 187
data models from database, 41–42, 420 metadata
database, managing, 146 adding
tables from database, 96–100 to data model, 81–82, 179–190
Load Metadata command, 189 to database, 181–183
Load Query command, 340, 342, 344 as display names, 180–181
Load Tables command, 97 as tool tips, 180–181
loading loading into data model, 180, 188–190
attribute descriptions, 190 queries, 180, 183–185
comments, 190 process, 185
data models from database, 224, 229 structure, 183–185
tables from database, 224, 230 templates, 180, 186–188
lock icon, 41 source, 180
Log window, 236–238, 239–240 specifying, 186–188
logon scripts, 52–61 tables
editing, 57–58 creating, 181–182
examples, 54–55 loading, 182
prompt/reply pairs, 55–57 populating, 182–183
reply tags, 54–55 metafiles, 199, 406
static strings, 55 methods for objects, 419
logos, using, 172 middleware connections, 47
lookup tables, 77 MINIMUM function, 329
minimum value for results, 390
model ID, 223, 224, 226, 228
Modifiers command, 261, 263, 265
modifying. See editing
458 Index
More Windows command, 343 numbers
moving entering, 245–247
buttons, 95 formats, 245–247, 249
ornaments, 95
user layer to administrator layer, 233–234
multiple prompts, 270, 271–279 O
Object command, 431
N Object Qualifier command, 134
objects
Name in Database command, 110, 194 automation. See automation objects
name of OLE, 199, 426–431
actual relationships, 101 See also data objects, buttons, ornaments, and
attributes, 96, 104, 194 relationships
simplify, 98–99 OLE, 199, 426–431
correlation, 95, 109, 109–110 automation, 405, 411, 416–422
creator, 229–230 editing scripts, 419
data model files, 25 sample code, 419–422
data objects, 96, 101, 104, 108, 109, 150, 194, 413 Visual Basic, using, 418–422
simplify, 98–99 objects, 199, 426–431
data values files, 258–259 creating, 426–431
design windows, 94, 95 editing, 430–431
prompts, 270, 272, 273 once-only scheduled jobs, 358–359
queries, 196 online
relationships, 101, 104 electronic documents, 8–9
results files, 197 help, 8, 205–207
scheduled jobs, 357–358 technical support, 10
tables in database, 150, 194, 413 tool tips, 8
natural joins, 387–390 Open command (for OLE), 431
Negate Clause command, 319 Open for Insert command, 395, 397
negating qualifications, 319 opening
nested queries, 316–318 data models, 32, 40–41, 62, 63, 93–94
network queries, 32
connections. See connecting to DBMS operating permissions. See permissions
load. See load operating preferences. See preferences
New command, 94 operator list, 295, 302–307
New Query command, 326, 332 operators, 295, 302–307, 318
new. See creating comparisons, making, 303–304
none function, 329 in variables, 280
normalized tables in database, 78 matching
null values, 235–237, 306–307, 330 character strings, 304–305
items in list, 305–306
Index 459
operators (continued) Paste command, 198, 426
null values, 306–307 Paste Query from Model command, 343
range of values, 306 Paste Special command, 428, 429
user-defined, 307 Path to Admin Layer permission, 43
options, for exporting results, 436 pausing scheduled jobs, 164
Oracle database, 158–160 Permissions command, 121, 124, 142
order of permissions, 121–122, 142–143, 217, 225
attributes, 99–100, 378–380 Allow Non-select SQL, 121, 145, 414
columns in assigning, 142–144
results, 382–383, 384 BI/Broker, 142, 310, 311
prompts, 272 Computed Attributes, 121, 146
results, 377–380 Connect per Window, 65
organizing. See designing Custom Checks, 148
ornaments, 23 DBMS, 142, 395
adding, 95, 198–200 Dynamic Relationships, 121, 147, 325
aligning, 171–172 Edit Data Model, 95, 121, 145
autosizing, 199, 406 Edit Queries, 121, 133, 145, 321, 322
borders, 200 Enforce Connect per Query, 63, 65, 149
colors, specifying, 176, 201 Maximum Query Time, 146, 161
copying, 95 Maximum Rows Retrieved, 146, 161
creating, 198–200, 425 Path to Admin layer, 43
deleting, 95, 198 publishing, 138
editing, 95, 198 Save Data Model, 95, 121
graphical, 198–200, 425 Save Passwords, 148
iconic, 198–200 Save Queries, 121, 147, 308, 338, 432
importing, 425 Save Split Data Model, 126, 127, 145
moving, 95 Send SQL Scripts, 121, 148
OLE objects. See OLE Set Administrator Password, 124
split data models with, 41, 95, 198 Submit to Named Table, 121, 150, 157, 413
text, 173–174, 198–200, 425 Submit to Table, 115, 150, 412
outer joins, 105, 387–390 Update Database, 121, 149, 394
Personal Portfolio, 39
pictures
P ornaments with, 200, 407
See also graphics
package, 216 placeholders, in variables, 283–284
pages, OLE objects, 427 populating tables in database, 194
palette, layout, 94 predefined queries. See buttons
parent objects, 418, 419 Preferences command, 122, 124, 144, 202, 203, 247, 435
passwords preferences, 122–123, 144
data models, 123–124 Allow Dynamic Relationships, 147, 325
DBMS, 148 Case-sensitive Comparisons, 294
460 Index
Connect Automatically, 62, 155 single, 270, 270–271
Connect per Query, 149 testing, 273, 277–279
Query Time before Prompt, 146 titles, 273
Rows Buffered, 153 using, 298–300
Rows Retrieved before Prompt, 146 Properties command, 173
Show Relationship Names, 101, 103 properties of objects, 419
Show Relationships, 101, 103 Properties tool, 173
Show SQL String, 145, 321, 322 Publish action, 370
prefix for tables, 229–230 Publish command, 218
Print action, for reports, 368 Publish Query command, 311
prioritizing scheduled jobs, 357–358 publishing
problems data models, 31–32, 137, 138, 215–219
connecting, 51 user layers, 216
reporting, 10 queries, 31–32, 310–311
updating database, 400 super queries, 337
procedures, in variables, 280 Push action, 370
product support, 9–10
Professional Services, Hummingbird, 11
programmable applications. See scripts Q
prompt/reply pairs, logon scripts, 55–57
Prompts command, 270, 273, 279 qualification text box, 293–294
Prompts file, 281 qualification tree, 293–296, 331–332
prompts, 30, 269–280 condition box, 296, 302, 319
conditional, 270, 274–279 data values icon, 295–298
creating, 270, 272–273, 275 list icon, 294
data values, using with, 258–259, 276 operator list, 295, 302–307
drill-down, 270, 271–279 qualification text box, 293–294
files, 270 qualifying
group, 270, 271–279 actual relationships, 133–135, 157, 269
hierarchical, 270, 271–279 attributes, 29–30, 293–307, 331–333
importing, 279–280 ad hoc drill-down mode, 323–324
in variables, 281 combining qualifications, 296, 301–302
join conditions with, 106–107 comparisons, making, 303–304
leaving empty, 299 deleting, 296
linking queries to, 408 editing qualifications, 321–323
multiple, 270, 271–279 grouping, 327–337
names, 270, 272, 273 lookup tables, 77
qualifying matching character strings, 304–305
actual relationships, 269 matching items in list, 305–306
attributes, 269, 298–300, 333 negate clause, 296, 319–320
data objects, 269 null values, 306–307
objects, 133–135 operators, 295, 302–307, 318
Index 461
qualifying (continued) prompts. See prompts
attributes (continued) publishing, 31–32, 310–311
qualification tree, 293–296 qualifying. See qualifying
range of values, 306 refreshing, 238–240
reversing qualifications, 296, 319–320 relationships, 22
separating combined qualifications, 302 retrieving from repository, 32, 312
updating, 238–240 row limit, 146, 160–161
with an attribute, 315–316, 333 saving, 147, 307–309, 337–340, 431–432
with data values, 29–30, 77, 156, 257–269, 295, scheduling, 33, 146–147, 161–162, 357–374
296–298 securing, 32
with multiple qualifications, 300 sharing, 31–32
with prompts, 30, 258–259, 269–279, 298–300, sort order, 378–379
333 SQL. See SQL
with subqueries, 316–318 standard, 386, 431
with values, 293–294, 296–298 storing, 31–33
with variables, 31, 280, 286 submitting, 408–413, 420
data objects, 133–135, 157, 237–238, 269 buttons, using, 408–413
results, 323–324 to applications, 432–445
tables, 133–135, 157 to files, 310
with variables, 320–321 to tables, 115, 150, 157, 412–413
Queries folder, 25–26, 211, 214, 229, 270, 308, 338 to windows, 410
queries, 28–30, 291–312 subqueries, 316–318
attribute descriptions, 191–196 super, 264, 337–347, 383, 386, 408
attributes, qualify. See qualifying creating, 337–340
buttons, linking to. See buttons editing, 340–347
calculations with, 326–337 time limit, 146, 160–161
canceling, 146, 160–161 updating, 238–240
circular, 347–354 variables, 320–321
no correlations, 352–354 variables. See variables
with correlations, 348–352 Query menu. See specific commands
comparing with data model, 238–239 Query Time before Prompt preference, 146
connecting to DBMS, 63–64, 149, 155–156 quitting BI/Query, 421
creating, 21, 191–196, 291–312
database resources required, 158
distributing, using BI/Broker Repository, 310–312 R
editing, 145–146, 158, 238–240, 321–323
exporting, 431–432, 445–446 Range command, 381
files, 223, 310 range, results in, 306, 380–381
mailing, 445–446 Rank Data Objects command, 160
nested queries, 316–318 ranking data objects, 158–160
opening, 32 records
per window, 64–67 adding to database, 393–399
462 Index
from another application, 397, 426 See also BI/Query Reports user’s guide
deleting from database, 393–397, 400 repository. See BI/Broker Repository
displaying individually, 396–397 resources needed for queries, 158
modifying in database, 393–400 restarting scheduled jobs, 164
See also rows restricting
recurring scheduled jobs, 359–362 data access. See access to data
reducing network load. See load queries. See qualifying attributes
refresh results, 347–354
data models, 132, 235–240 results
queries, 238–240 calculations on, 390, 421
Refresh Queries command, 238 columns
Refresh Report action, 366 hiding, 382–383, 384
Refresh Tables command, 236 joining, 386–390
Relational Database Management Systems. See DBMSs order, 382–383, 384
relations. See tables in database combining, 339, 383–390
Relationship command, 325 data formats, 245–252
relationships, 21–22 data values. See data values
actual, 22 exporting, 309–310, 411–412, 432–446
aligning, 171–172 files, 190, 196–198, 309–310
attributes associated with, 22 filtering, 338–339
colors, specifying, 201, 204 Form view, displaying in, 396–397
copying, 95 format, 435
creating, 100–102, 147, 324–326 grouping, 332–333
dynamic, 110, 147, 324–326 importing, 397, 426
embedded, 22 mailing, 445–446
icons, displaying, 101 publishing, 370
join conditions, 104–107 qualifying, 323–324
names See also qualifying
displaying, 101 range, specifying, 306, 380–381
specifying, 101 resources required, 158
queries, 291 restricting, 347–354
saving, 325 See also qualifying
Reorder Attributes command, 100 retrieving, 366–367
Reorder Columns command, 382, 383 See also queries
reply tags, logon scripts, 54–55 rows, appending 384–386
Report menu. See specific commands saving, 309–310, 433
reporting problems, 10 sending
reports, 31 buttons, using, 408–413
exporting, 446 to applications, 432–445
mailing, 445–446 to files, 310
scheduling, 365, 366, 368 to tables, 115, 150, 157, 412–413
storing, 31–33 to windows, 410
Index 463
results (continued) Save to Database command, 227
sorting, 377–380 saving
Spreadsheet view, displaying in, 397 combined data models, 127
updating database with, 393, 395–400 data models, 32, 125–127
values, substituting, 251–252 in database, 221–230
Results menu. See specific commands on diskettes, 220
Results Options command, 198, 263, 435 on file server, 219–220
Results Options dialog box, 398–399 passwords, 148
Retrieve command, 39, 312 queries, 32, 147, 307–309, 337–340, 431–432
Retrieve Results command, 366 relationships, 325
retrieving results, 309–310, 433
data models from repository, 32, 39–40, 138 SQL string, 431–432
information from the database. See queries summary information in database, 79
queries from repository, 32, 312 tables in database, 229
results, 366–367 scalar functions, 336
See also load Schedule Query command, 357
reversing qualifications, 296, 319–320 scheduling
revising. See editing actions, 365–374
rows event-based, 362–365
buffering, 153 jobs
See also results canceling, 164
Rows Buffered preference, 153 deleting, 164
Rows Retrieved before Prompt preference, 146 displaying, 162–164
rules, adding, 173 naming, 357–358
Run Command on Server action, 371 once-only, 358–359
Run Query action, 366 pausing, 164
running BI/Query, 37–43 prioritizing, 357–358
recurring, 359–362
restarting, 164
S queries, 33, 146–147, 161–164, 357–374
reports, 365, 366, 368
sans serif type, 173 scripts, 116, 118, 405, 410–411, 414–416
Save As command, 42 buttons, linked to, 417
Save command, 127 OLE Automation, 411, 416–422
Save Data Model permissions, 95, 121 editing, 419
Save Data Model permission, 115 sample code, 419–422
Save Passwords permission, 148 Visual Basic, 418–422
Save Queries permission, 121, 147, 308, 338, 432 SQL, 116, 118–120, 405, 414–416
Save Query command, 195, 265, 308, 317, 338, 340, 432 sending to DBMS, 148, 415
Save Results command, 310, 433 See also logon scripts
Save Split Data Model permission, 126, 127, 145 Search for Help On command, 8
Save To Database permission, 222
464 Index
securing Show SQL String preference, 145
data models, 32, 90 single prompts, 270, 270–271
queries, 32 sliding dates, 252–253
security Sort command, 379
setting, 137–141 Sort Order command, 379
Select Table Icon command, 200 sorting results, 377–380
selecting. See qualifying attributes split data models, 24, 25–27, 40, 126–127, 145, 233–234
Send command, 446 administrator layer, 25, 42–43, 223
Send SQL Script command, 120, 415 buttons, 41, 95, 406
Send SQL Scripts permission, 121, 148 creating, 126–127
sending distributing, 211–212, 219–228, 234
data models using mail, 220–221 editing, 233–234
queries files, 25, 126, 211–212, 233–234
BI/Broker Repository, using, 161–164 ornaments, 41, 95, 198
buttons using, 408–413 passwords, 123–124
to applications, 432–445 reestablishing path between layers, 42–43
to files, 310 saving, 125–127
to tables, 115, 150, 157, 412–413 user layer, 25, 26–27
to windows, 410 splitter bar, super query window, 340
SQL Spreadsheet view, 397
scripts to DBMS, 118, 148, 415 spreadsheets, data values results files, 262–263
string to DBMS, 148 SQL
See also exporting HAVING clause, 332–333
separating operators. See operators
columns in reports, 384 scripts, 116, 118–120, 148, 405, 414–416
qualifications, 302 sending to DBMS, 415
separators, 398 string, 230
for exporting results, 436 editing, 145–146, 158, 321–322
serif type, 173 saving, 431–432
server submitting, 148
distributing data models, 211, 219–220 WHERE clause, 331–332
See also database standard queries, 386, 431
Set Administrator Password permission, 124 saving, 307–309
Set Object Color command, 204 starting
Set Security command, 139, 140, 141, 218 DBMS, 53–57
setting security, on data models, 90 BI/Query, 37–43
sharing static strings, logon scripts, 55
data models, 31–32 stopping. See canceling
queries, 31–32 storing files centrally, 31–33
Show Query command, 299, 322, 340, 342, 344 strings
Show Relationship Names preference, 101, 103 computed, 251–252
Show Relationships preference, 101, 103 SQL. See SQL
Index 465
strings (continued) T
See also data
structuring. See also designing tables in database
Submit Query — To File command, 310, 433 catalog table, using, 190, 192–196
Submit Query — To Table command, 115 columns, hiding, 132–133
Submit Query command, 338, 339, 352, 354 comparing to data model, 235–238
Submit to Named Table permission, 121, 150, 157, 413 creating, 114–120, 150, 157, 192–194, 229, 230, 412–
Submit to Table permission, 115, 150, 412 413
submitting data dictionary, using, 190, 192–196
queries, 408–413, 420 denormalizing, 78
buttons, using, 408–413 GQLMETA, 223, 228, 229, 229–230
to applications, 432–445 GQLMnnnn, 223
to files, 310 GQLQnnnn, 223
to tables, 115, 150, 157, 412–413 GQLRnnnn, 223
to windows, 410 GQLVnnnn, 223
See also sending indexing attributes, 78
subqueries, 316–318 loading, 96–100, 224, 230
in variables, 280 lookup, 77
See also queries names
substituting values, 251–252 displaying, 194
SUM DISTINCT function, 330 specifying, 150, 413
SUM function, 79, 327, 328, 329, 331 organizing data, 79–81
summary information permissions, 225
storing in database, 79 populating, 194
See also aggregate functions prefix, 229–230
summing results, 390 qualifying, 133–135, 157
super queries, 105, 264, 337–338, 383, 386, 408 ranking, 158–160
creating, 337–340 refreshing, 132, 235–240
combining results, 339–340 representing, 20–21, 22
filtering results, 338–339 resources required, 158
editing, 340–347 restricting queries, 133–135, 157
component queries, 342–343 saving, 229
correcting errors, 345–347 sending results to, 115, 150, 157, 412–413
operations, 343–345 updating, 112, 149–150, 194, 393–400
publishing to repository, 337 user access, 131–150
saving, 337–340 TCP/IP, 369
super query window, 340–342 connections, logon scripts, 52–61
See also queries settings
suppressing duplicate information, 330 distributing, 60–61
system permissions. See permissions, BI/Broker editing, 58–60
technical support, 9–10
using the Trace Utility, 10
466 Index
Telnet sessions, TCP/IP connections, 52–57 U
Teradata database, 158, 334
testing Uncombine command, 302
connections, 51–52 Update command, 397, 398
data model, 227 Update Database permission, 121, 149, 394
prompts, 273, 277–279 Update window, 397, 399, 400
text updating
appearance, specifying, 173–174 attributes, 394
buttons, 173–174 data models, 132, 235–240
editor database, 145, 149–150, 393–400
attribute descriptions, 190, 197–198 join conditions, 237–238
data values results files, 262–263 queries, 238–240
files, adding records from, 397, 426 tables in database, 112, 194
importing, 425–426 user
ornaments with,200, 407 data access. See access to data
ornaments, 173–174, 198–200 passwords, 123–124, 148
time requirements, 75–76
calculating in variables, 281 user layer, 25, 26–27, 126, 145, 233–234
including in distributing, 211–212, 219–228, 234
results, 250 files, 25, 26, 40, 126, 211–212, 233–234
limit for queries, 146, 160–161 moving to administrator layer, 233–234
required to return results, 158 passwords, 123–124
scheduling, 358–362 user-defined
titles in attributes, 146, 334–336
design windows, 172 calculations, 330
prompts, 273 operators, 307
tool tips, 8 users, 137–141
Trace Utility, 10
Tracing Enabled command, 10
transferring user layer to administrator layer, 233–234 V
tree list, super query window, 341
Trigger Event action, 371–373 values. See data values
triggers, 251–252, 371–373 Variables command, 282, 286
Trim Relationships command, 352 variables, 31, 280–287
troubleshooting calculating
problems, 10 dates, 281
connections, 51–52 time, 281
tuple. See records containing
two-digit years, converting, 252–253 attributes, 283–284
typefaces, about, 173–174 functions, 284–285
operators, 283–284
placeholders, 283–284
Index 467
variables (continued) accessing using scripts, 411
containing (continued) Hummingbird’s, 10, 11, 14
prompts, 285–286
variables, 281, 285
creating, 281–286 Y
importing, 286–287
qualifying attributes, 280–286 Year-2000 compliance, 252–253
verifying data model design, 124–125
version number of data model, 224, 228
video, importing, 427
View Jobs command, 162
viewing. See displaying
visible. See hiding
Visual Basic, 23, 405
scripts, 411, 416, 418–422
exiting BI/Query, 421
loading data model, 420
methods, 419
objects, 418–419
properties, 419
retrieving results, 421
submitting queries, 420
Visual C++, 416
W
WHERE clause, 331–332
displaying prompt values, 299
in variables, 31, 280
white space, using, 174–175
wildcard in qualifications, 304
WinCLI connections, 334
Window menu. See specific commands
Windows command, 95
windows, appearance in this guide, 7
See also design windows
Word Perfect, using, 417
word processors. See applications
Word, 417, 427
importing records from, 397–399, 426
World Wide Web sites
468 Index

Bi Query

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Bi Query

Diunggah oleh

Hak Cipta:

Format Tersedia

BI/Query

Hummingbird BI/Web 12 Installing BI/Query 37

Hummingbird BI/Query 12 Starting BI/Query 37

Hummingbird BI/Analyze 13 Retrieving a Published Data Model 39

Connecting 68 Creating Design Windows 95

Using a Default Connection 69 Loading Tables from the Database 96

Using a Specific Connection 69 Simplifying Display Names 98

Dates 247 Qualifying Queries 293

Invalid Entries 248 Using the Qualification Tree 293

For Displaying Data 248 Using Data Values 296

Formatting Numbers 249 Using a Prompt 298

Formatting Dates 250 Applying Multiple Qualifications 300

Inserting and Deleting Characters 250 Combining Qualifications 301

Substituting Values 251 Restricting Qualifications with an

Using Queries to Perform Before You Submit a Query 378

Section 4: BI/Query and Other

Automating Tasks 405

Importing and Exporting Information 425

Connecting to the DBMS 47

About This Guide 5

For administrators, BI/Query provides the flexibility to tailor

For business users, BI/Query provides an easy-to-use, visual way to

About This Guide

Certain information applies to both administrators and users because

NEW USERS ALL USERS ADMINISTRATORS

Updating Records in the Database Maintaining a Data Model

The guide provides conceptual and background information on the

This Is Used for This

folder Directory, subdirectory, and folder.

italics New terms, file names, and information that you

Providing useful hints and suggestions.

You can access online Help in a number of ways.

Display contents Choose Help>Contents.

Locate specific information Choose Help>Search for Help On,

Get Help about using Help Choose Help>How to use Help.

Outside North America

Before we can investigate your problem, we need certain information

Troubleshooting Problems using the Trace Utility

To run the trace utility

Hummingbird offers standard training to help users and administrators

Contacting Professional Services

Voice +1-613-548-4355 ext. 1700

The Business Intelligence Product Line

BI/Broker includes the following key components, which are fully

BI/Broker Admin Allows the administrator to manage the

BI/Broker Provides the central storehouse of data

User and Group Allows the administrator to provide user,

Scheduler Schedules queries and reports and distributes

BI/Query Admin An all-in-one solution for the administrator.

BI/Query User The user’s query application. It provides an

BI/Query Update An extended version of BI/Query User. It

BI/Query Reports A reporting tool installed with BI/Query. It

IT staff customize the data access environment to meet people’s business

Whatever the mix, BI/Query’s visual interface provides people with a

Design Windows Provide a Design Environment

Design windows provide a means of organizing information so that

Working in Design Mode

Drawing toolbar Application toolbar

Data Objects Represent Tables in the Database

Attributes specify the information to Conditions restrict results

While the administrator can provide data objects in any design

Relationships Tie Information Together

The place relationship (represented by the diamond-shaped icon) allows users to