Skip Headers
Oracle® Life Sciences Data Hub Application Developer's Guide
Release 2.1.4

Part Number E18306-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

11 Defining Business Areas for Visualizations

This section contains information on the following topics:

Figure 11-1 Process of Creating a Business Area Definition and Instance

Business Area creation process
Description of "Figure 11-1 Process of Creating a Business Area Definition and Instance"

About Visualizations

The Oracle Life Sciences Data Hub (Oracle LSH) is integrated with visualization tools, to allow nontechnical users to quickly create onscreen graphical and tabular displays and interactive dashboards of Oracle LSH data. Any Oracle LSH data can be made available for this purpose—freshly loaded source data or merged and transformed data.

You make data available to the visualization tool by defining one or more Business Areas in Oracle LSH. You define Table Descriptors in a Business Area and map them to Table instances. The visualization tool can read data contained in the Table instances to which the Table Descriptors are mapped. An Oracle LSH Business Area corresponds to a Discoverer Business Area or an Oracle Business Intelligence Enterprise Edition (OBIEE) Repository and a particular visualization can see data through a single Business Area. Your company may support other visualization tools and an Oracle LSH Business Area of that type may correspond to an element in those visualization tools.

You can also define Joins between the Table Descriptors and Hierarchies (drill-down structures) of Columns in the same Table Descriptor or in joined Table Descriptors. Joins and Hierarchies help determine how visualizations can compare and organize data; see "Defining Joins" and "Defining Business Area Hierarchies".

When you launch a Visualization tool from a Business Area or from the Visualizations subtab of the Reports tab, you can choose to see non-current and blinded data, if you have the appropriate privileges, through the Launch Settings screen. If you open OBIEE directly (not from within Oracle LSH) you can view only current and not blinded data regardless of your privileges.

Visualizations cannot be used to make any changes to data.

Oracle LSH Data Security for Visualization Tools

Security access to data available to visualizations is determined by Oracle LSH security access to Business Area instances within Oracle LSH.

Business Area instances use standard Oracle LSH security. To have security access to a Business Area, a user must belong to a user group assigned to the Business Area instance (either explicitly or by inheritance through the Work Area) and have at least View privileges on Business Area instances of the relevant subtype.

See "Discoverer Plus Security""OBIEE Security". Your company may also support other visualization tools. Follow your company's instructions on their security access.

Reports on Business Area Definitions and Instances From the Actions drop-down list, you can generate reports that provide information on a Business Area definition or instance; see Chapter 15, "System Reports" for information.

Creating a Business Area

When you create a Business Area in a Work Area, you are actually creating an instance of a Business Area definition.

To create a new Business Area instance:

  1. In a Work Area, select Business Area from the Add drop-down list.

  2. Click Go.

    The system displays the Create Business Area screen.

  3. Choose one of the following options:

    • Create a new Business Area definition and instance. Choose this option if no Business Area definition exists that can meet your needs, either as it is or with some modification.

    • Create an instance from an existing Business Area definition. Choose this option if a Business Area definition already exists that meets your needs.

      If you can adapt an existing Business Area definition to make it fit your needs, first copy it into the current Application Area, then choose this option and select the copied definition. See "Finding an Appropriate Definition" and "Reusing Existing Definitions" for further information.

  4. Depending on your choice, follow one of the following sets of instructions:

Creating an Instance of an Existing Business Area Definition

If you use an existing Business Area as a definition source, its Table Descriptors, Joins and Hierarchies (if any) are already defined. See "Creating an Instance of an Existing Definition" for instructions.

After you have created the Business Area instance, you must map the Table Descriptors to Table instances; see "Mapping Table Descriptors to Table Instances" for instructions.

Creating a New Business Area Definition and Instance

When you select Create a new Business Area definition and instance in the Create Business Area screen, additional fields appear.

  1. Enter values in the following fields:

  2. In the Classification section, select the following for both the definition and the instance:

  3. Click Apply to save your work and continue defining the Business Area.

    The system opens the Properties screen for the new Business Area instance.

  4. Define the Business Area details. For information and instructions see:

  5. Click Check In. The system checks in Version 1 of both the Business Area definition and instance.

  6. Install the Business Area instance (see Chapter 12, "Using, Installing, and Cloning Work Areas").

  7. Validate both the definition and the instance according to your company's policies.

Using the Business Area Properties Screen

This section contains the following topics:

See also Figure 11-1, "Process of Creating a Business Area Definition and Instance".

See "Modifying Business Areas" for information on modifying Business Areas.

If you are working in a Work Area, you see the properties of both the Business Area instance and the Business Area definition it references. If you are working directly on the definition in an Application Area or Domain, you see only the properties of the definition.

Instance Properties

You can see the following instance properties:

Name You can click Update and modify the name. See "Naming Objects" for further information.

Description You can click Update and modify the description. See "Creating and Using Object Descriptions" for further information.

Definition This field specifies the Business Area definition to which this Business Area instance points. For further information, see "Definition Source".

You can upgrade to a new version of the same definition. See "Upgrading to a Different Definition Version from an Instance".

Validation Status This field displays the current validation status of the Business Area instance. If you have the necessary privileges, you can change the validation status by selecting Validation Supporting Information from the Actions drop-down list. See "Validating Objects and Outputs" for further information.

Status This field displays the installable status of the Business Area: Installable or Non Installable. See Appendix B, "Installation Requirements for Each Object Type".

Version This field displays the current version number of the Business Area instance.

Version Label This field displays the version label, if any, for the current Business Area instance version.

For further information on object versions, see "Understanding Object Versions and Checkin/Checkout".

Definition Properties

Checked Out Status This field displays the status of the definition: either Checked Out or Checked In. You must check out the definition to modify Table Descriptors, Joins, and Business Area Hierarchies. However, you can change Table Descriptor mappings without checking out the definition. See "Understanding Object Versions and Checkin/Checkout" for further information.

Latest Version If set to Yes, this Business Area instance is pointing to the latest version of the Business Area definition. If set to No, this Business Area instance is pointing to an older version of the Business Area definition.

Checked Out By This field displays the username of the person who has the Business Area definition checked out. See "Understanding Object Versions and Checkin/Checkout" for further information.

Version Label This field displays the version label, if any, for this definition version.

Business Area / Adapter Type This field displays the name of the Business Area adapter.

Validation Status This field displays the current validation status of the Business Area definition. If you are working directly in the definition in an Application Area or Domain and you have the necessary privileges, you can change the validation status by selecting Validation Supporting Information from the Actions drop-down list. If you are working in an instance of the Business Area in a Work Area, and you want to change the validation status of the definition, you must go to the definition. See "Validating Objects and Outputs" for further information.

Status This field displays the installable status of the Business Area: Installable or Non Installable. See Appendix B, "Installation Requirements for Each Object Type".

Business Area Attributes

This section of the Business Area screen displays attributes for the type of Business Area you have created. See "Setting Business Area Attributes and Parameters" for more information.

Buttons

From a Business Area instance in a Work Area, you can use the following buttons:

Install Click Install to install the Business Area instance, including mapped Table instances in the same Work Area; see "Installing Business Area Instances". For a list of reasons a Business Area instance may not be installable, see Appendix B, "Installation Requirements for Each Object Type".

Launch Visualization Click Launch Visualization to go to the Launch Visualization screen; see "Launching Visualizations". You can see the Launch Visualization button only after you have installed the Business Area. See "Installing Business Area Instances".

Update Click Update to modify the Business Area instance properties. See "Modifying Business Area Instance Properties".

Check In/Out and Uncheck Click these buttons to check out, check in, or uncheck the Business Area definition. Different buttons are displayed in the Business Area Definition Properties section depending on the Checked Out Status and whether or not you are the person who has the definition checked out. If someone else has checked out the definition, you cannot check it in or uncheck it. The username of the person who has checked it out is displayed. See "Understanding Object Versions and Checkin/Checkout".

Defining Table Descriptors

You make data available to visualizations by mapping the Table instances that contain the data to Table Descriptors in a Business Area. Any one visualization can access data through one and only one Business Area. The more Table Descriptors you include in a Business Area, the more data is accessible to a single visualization.

Business Areas have source Table Descriptors only. They can read data but they cannot write data to Tables instances.

If you do not want data from a particular Table instance Column available to visualizations, remove the Column from the Table Descriptor that is mapped to that Table instance.

You can map Business Area Table Descriptors to Table instances in any Work Area.

If the Table instances to which you want to map a Business Area's Table Descriptors already exist, the simplest way to add and map Table Descriptors to the Business Area is to use the Table Descriptors from Existing Table Instances job from the Actions drop-down list. See "Creating Table Descriptors from Table Instances and Simultaneously Mapping Them" for further information.

Note:

Set the SAS Library Name of the source Table Descriptor to $REPINIT if you want to enable queries from the OBIEE repository's Repository Init Block to access Table instances mapped to this Table Descriptor. These queries fetch data from the Oracle LSH Table instances at user-defined refresh intervals to initialize Repository Variables.

If you do not set the SAS Library Name to $REPINIT, OBIEE cannot access the mapped Table instances and the automatic, periodic OBIEE repository queries will fail.

For additional information about Table Descriptors see the following sections:

Defining Joins

You can define a Join between two Table Descriptors to allow a visualization to query and display data from two Table instances as if they were one unified table.

You must define Table Descriptors before you can define Joins between them. You can create Joins between two and only two Table Descriptors.

You can define a Join between Table Descriptor A and Table Descriptor B, another Join between Table Descriptors B and C, and another between Table Descriptors C and D, for example. Furthermore, in this same example you can create a join between Table Descriptors D and A.

However, if you create a Join between Table Descriptor A and Table Descriptor B, you cannot create a Join between the same Table Descriptors with their positions reversed (Table Descriptor B and Table Descriptor A).

Joined Columns For each Join, you must specify at least one pair of equivalent Columns, one Column from each Table Descriptor, that are equivalent in terms of their data content; for example, Table A's Patient Column and Table B's Pat Column, both of which contain the patient ID. The joined Columns must be of the same data type.

Note:

For Business Areas of type OBIEE, joins work only if Table instances have a Primary Key constraint.

Also, OBIEE Business Areas support only one-to-many relationships; for example, if you want to create a join between an employee table and a department table, you must add the department table to the Join first, because a department can have multiple employees in it, but an employee can belong to only one department.

If you specify more than one pair of equivalent Columns, the system sees rows in the two Table instances as being the same only if they have the same value in both Columns. For example, if you create a Column Join between Table A's Investigator Column and Table B's Inv Column, both of which contained an investigator ID, as well as the Patient/Pat join, the visualization query would see rows as being the same in the two Table instances only if they shared the same investigator ID as well as the same Patient ID.

Note:

Although some visualization tools allow the use of other operators to join columns, Oracle LSH always applies the "equal to" (=) operator.

Inner and Outer Joins By default, an Oracle LSH Join is an inner join. That is, only rows where the joined Columns share the same value are evaluated for the query. Rows that exist in either Table instance that do not have an equivalent row in the other Table instance are not included in the visualization.

You have the option to create an outer join. In an outer join, the visualization query evaluates all the rows in the Table instance you define as Table A plus all the rows in Table B where each joined Column has the same value as a row in Table A.

Defining a Join at the Table Level

To define an Oracle LSH Join:

  1. From the Joins subtab on the Properties screen of the Business Area, click Add. The system displays the Join for Business Area screen.

  2. Enter a name for the Join.

  3. Enter a description for the Join (optional).

  4. Click the Search icon to the right of the Table A field.

  5. Click Go to see a list of all the Table Descriptors you have defined for the Business Area. Alternatively, enter the exact name of the Table Descriptor you want, or use special characters if you are unsure of the name (see "Searching" in the Oracle Life Sciences Data Hub User's Guide for instructions).

    The system displays one or more Table Descriptors.

  6. Click the Quick Select icon to select the Table Descriptor you want.

    Note:

    In an outer join, the system evaluates all the rows of the Table instance you map to the Table Descriptor you define as Table A; see "Inner and Outer Joins".
  7. If you want to define an outer join, select Yes in the Table A Outer Join field.

  8. Click the Search icon to the right of the Table B field.

  9. Click Go to see a list of all the Table Descriptors you have defined for the Business Area. Alternatively, enter the exact name of the Table Descriptor you want, or use special characters if you are unsure of the name (see "Searching" in the Oracle Life Sciences Data Hub User's Guide for instructions).

    The system displays one or more Table Descriptors.

  10. Click the Quick Select icon to select the Table Descriptor you want.

  11. Click Apply. See "Defining a Join at the Column Level".

Defining a Join at the Column Level

To define which two Columns are joined, do the following:

  1. Define the Table Descriptors in the Join; see "Defining a Join at the Table Level".

  2. In the Join properties screen, click Update. The system displays an Add Join Column button.

  3. Click Add Join Column. The system displays a drop-down list under each Table Descriptor included in the Join.

  4. For the Table Descriptor on the left, select the Column you want to define as part of the Column Join from the drop-down list.

  5. For the Table Descriptor on the right, select the Column you want to define as part of the Column Join from the drop-down list.

    Note:

    The two Columns must have the same data type.
  6. Click Apply. The system saves your work.

    Click Return to go back to the main Business Area screen.

Defining Business Area Hierarchies

Visualization tools allow drilling down into more and more detailed data or up into more and more general data. To allow this functionality for visualizations of Oracle LSH data, you must define Business Area Hierarchies.

Business Area Hierarchies define hierarchical relations among Table Columns to organize data in a meaningful way, from general to specific, so that data values at the lower levels aggregate into the data values at higher levels.

For example, you could define a Hierarchy for the Columns Study, Patient, Visit, Test, in that order, from the most general to the most specific. The system uses the Hierarchy and the data values for each row to interpret the data values in the Columns hierarchically: all tests belong to a visit; all visits are associated with a patient, and all patients are part of a study.

If Table Descriptors are defined as joined, you can create a Business Area Hierarchy that includes Columns from both Table Descriptors. For example, you could create a Business Area Hierarchy for the Columns Investigator Name, Patient, and Gender where the Investigator Name is in the Sites Table and the Patient and Gender Columns are in the Demography Table.

When you define a Business Area Hierarchy, you assign each Column an order number. The Column with order number one is the top, or most general, level of the Business Area Hierarchy, and each subsequently numbered Column is the next lower Hierarchy level. Sequential Columns must be contained either in the same Table Descriptor or in joined Table Descriptors.

Grouping Columns You can include two or more Columns in the same Business Area Hierarchy level by using the Group With Previous flag. For example, you could define the following Business Area Hierarchy:

Example 11-1 Business Area Hierarchy Column Grouping

Order number Column Group With Previous?
1 Investigator ID
2 Investigator Name Yes
3 Patient
4 Gender

The example above shows a three-level hierarchy. Investigator ID and Investigator Name are both in the top level, which makes sense because they are alternate values for the same type of information. Patient is the middle level and Gender is the bottom level. In a visualization, users can drill down from the investigator by either name or ID, or view them both, to all patients for whom a particular investigator is responsible, to an investigator's male patients or the same investigator's female patients.

To define a Business Area Hierarchy:

  1. From the Business Area Hierarchies subtab on the Properties screen of the Business Area, click Add. The system displays the Create Business Area Hierarchies screen.

  2. Enter a name for the Business Area Hierarchy (required).

  3. Enter a description for the Business Area Hierarchy (optional).

  4. Click Apply. The system displays the Properties screen of the new hierarchy.

  5. Click Update. The system adds the Add Another Row button.

  6. Click Add Another Row.

  7. Click the Search icon in the Table column. The system opens a Search and Select screen.

  8. Click Go to see a list of all the Table Descriptors you have defined for the Business Area. Alternatively, enter the exact name of the Table Descriptor you want, or use special characters if you are unsure of the name (see "Searching" in the Oracle Life Sciences Data Hub User's Guide for instructions).

    The system displays one or more Table Descriptors.

  9. Click the Quick Select icon to select the Table Descriptor that is mapped to the Table instance you want to include in the Hierarchy.

  10. Click the Search icon in the Column Name column. The system opens a Search and Select screen.

  11. Click Go to see a list of all the Columns in the Table Descriptor. Alternatively, enter the exact name of the Column you want, or use special characters if you are unsure of the name (see "Searching" in the Oracle Life Sciences Data Hub User's Guide for instructions).

    The system displays one or more Columns.

  12. Click the Quick Select icon to select the Column you want to include in the Hierarchy.

  13. Repeat Steps 6-12.

    This time the system displays only the Table Descriptor you selected in Step 9 and any other Table Descriptors that are part of a Join that includes the Table Descriptor you selected.

    In addition, beginning with the second row, you can choose to group the Column with the previous one at the same level of the Hierarchy; see "Grouping Columns".

  14. When you have added all the rows you want in the Hierarchy, click Apply. the system saves your changes.

    Click Return to go back to the Business Area Properties screen.

Understanding Business Area Source Code

In the context of an Oracle LSH Business Area, the Source Code object is used to store files required for integration with an external visualization tool. This is different from the way Source Code is used in Oracle LSH Programs where the Oracle LSH Source Code object contains actual program source code.

For information on OBIEE Business Area Source Code see "About OBIEE Business Areas".

Setting Business Area Attributes and Parameters

Some types of Business Areas, including third-party types not covered by this documentation, may have attributes and Parameters. When you create a Business Area of those types, attributes or Parameters required for the visualization tool may appear on the Business Area Properties page.

OBIEE Business Areas have one attribute; see "Defining Oracle Business Intelligence Business Areas".

Defining Oracle Discoverer Plus Business Areas

For information on using Oracle Discoverer Plus to create visualizations, see Oracle Discoverer Plus documentation, including online help.

This section contains the following:

See also:

Integration with Oracle Discoverer Plus

When you install an Oracle Discoverer Business Area instance, the system generates an End User Layer (EUL) in Oracle Discoverer Plus for its Oracle LSH Work Area and an Oracle Discoverer Plus Business Area for each Oracle LSH Business Area. Within an Oracle Discoverer Plus Business Area, the system generates a Folder for each Oracle LSH Table Descriptor, an Item for each Table Descriptor Column, and a Join for each Join defined in Oracle LSH.

Discoverer Plus Security

When you launch a visualization, Oracle LSH sends your security information to Oracle Discoverer Plus. Oracle LSH creates a user account in Oracle Discoverer Plus with all the necessary grants and permissions to create visualizations based on that particular Business Area instance. To use Discoverer Plus with Oracle LSH, you must have an Oracle LSH user account.

Defining Oracle Business Intelligence Business Areas

This section contains the following:

For information on using the OBIEE Administration Tool and Presentation Services to create visualizations—Answers and Dashboards—see the Oracle Business Intelligence documentation, including online help.

About OBIEE Business Areas

When you install an OBIEE Business Area for the first time the system generates an Oracle BI repository (.rpd) file—which is required for creating and displaying Subject Areas, Answers, and Dashboards in Oracle BI Presentation Services—and deploys it to the BI Server. This allows you to rapidly deploy a visualization of LSH data through OBIEE Answers without learning or using the OBIEE Administration tool. Oracle LSH stores the .rpd file in the OBIEE Business Area Source Code definition.

The system deploys the .rpd files from all the OBIEE Business Areas that share the same OBIEE Service Location Name onto that Oracle BI Server and merges them into a single .rpd file as each Business Area is installed. When a Business Area is installed to the BI Server, the system stops that BI Service in order to merge the Business Area's .rpd file onto the deployed .rpd file. It then restarts the BI Service.

Customizing the RPD File Using OBIEE Administration Tool Oracle LSH takes advantage of only a small number of the features that OBIEE has to offer. If you are experienced with OBIEE you may wish to make changes to the Business Area's default .rpd file using the OBIEE Administration Tool and upload the resultant .rpd to replace the system-generated .rpd in the Business Area in Oracle LSH.

In order to ensure that subsequent installations of the Business Area do not overwrite those customizations, the system tracks the origin of the .rpd file. When Oracle LSH creates a .rpd file during installation, it populates the File Reference Name with the value System. When a user uploads a customized .rpd file the system populates the File Reference Name with the value Uploaded.

Each time you install the Business Area, the system checks if the current .rpd file was generated by the system or manually uploaded to the Business Area. If the file was generated by Oracle LSH and not manually uploaded and the Table Descriptor, Join, or Hierarchy definitions have changed, then the system generates a new .rpd file and stores this as a new version of that Source Code.

If the current .rpd file was uploaded, the system does not override it with a new file even if you have made changes in Oracle LSH. You must make corresponding changes—adding, deleting, or modifying tables, joins, and hierarchies—in the Administration Tool and reupload the file.

Defining an OBIEE Business Area

Oracle recommends developing an OBIEE Business Area in the following order:

  1. Create the Business Area; see "Creating a Business Area". Special information for OBIEE Business Areas:

    • Name. The Business Area name is displayed in OBIEE Answers as the Subject Area. The name must be unique among Business Areas using the same service location. If it is not unique, when you install the Business Area you receive an error message with the location of the previously installed Business Area with the same name.

      Note:

      Do not change the name of a previously installed Business Area. This will cause problems with the .rpd file.
    • OBIEE Service Location Name. Select the value for the computer with the Presentation Services Server you want this Business Area to use, if more than one is available in your company.

  2. Add Table Descriptors and map them to the Table instances that contain the data you want to make available in OBIEE; see "Defining Table Descriptors".

    Note:

    To enable the OBIEE repository to query the source Table instances that the Oracle LSH OBIEE Business Area uses, set the SAS Library Name of the mapped Table Descriptor to $REPINIT. See "Defining Table Descriptors".
  3. If you want to add joins and hierarchies in Oracle LSH, do so now; see "Defining Joins" and "Defining Business Area Hierarchies". See "About OBIEE Business Areas".

    Note:

    Do not explicitly create a Source Code definition. The Source Code is automatically created when you install the Business Area. Its name is determined by the value of the Details attribute in the Deploy service defined for the service location you selected.
  4. Install the Business Area to create the initial .rpd file. Install it again if you make changes in Oracle LSH before working in the OBIEE Administration Tool. The system generates a new .rpd file with your changes.

    Note:

    You can stop at this point. Customization in the OBIEE Administration Tool is optional.
  5. Click Launch IDE to open the OBIEE Administration Tool. Log in as administrator using the password set by your company. Work on the .rpd file in this tool, using the OBIEE user documentation.

    Note:

    When multiple Business Areas use the same service location, the .rpd files are merged in the deployed .rpd file in the Administration Tool. Only one person can modify the .rpd file at a time.
  6. Upload the .rpd file to the Business Area:

    1. In the Source Code tab, click the link to the Source Code definition.

    2. Click Browse.... The .rpd file is generally stored on the C drive, in the CdrWork folder. The full path of the repository file looks like this:

      C:\CdrWork\LSH_database_username\OBIEE_BA_Domain_name\OBIEE_BA_Application_Area_name\OBIEE_BA_Work_Area_name\OBIEE_BA_name\OBIEE_BA_version_number\
      

      Note:

      Oracle LSH supports uploading zipped .rpd files. However, you must give the .zip file exactly the same name as the .rpd file; for example, test.zip must contain test.rpd.
    3. Click Apply.

  7. Install the Business Area. The system creates a new version of the Source Code definition that contains the newly uploaded file and deploys the file to the Oracle BI Server.

    Note:

    If an .rpd file does not appear in the Source Code tab after installation, check the Jobs subtab. If the Execution Status is Pending Logon or Obtain Service, there is a problem with the Distributed Processing (DP) Server on the BI Server computer.
  8. Continue to work in the OBIEE Administration Tool until you are finished.

    • If you make structural changes in the OBIEE Administration Tool—changes to tables, joins, or hierarchies—you must make the same changes in Oracle LSH so that the .rpd file is always synchronized with the Business Area definition. Otherwise you will not be able to use the new structures in OBIEE. For example, if you add a column to a table in OBIEE but do not add the column in the Business Area Table Descriptor and map it to a column in its Table instance, you will not be able to see the data in the column in OBIEE.

      Reinstall the Business Area for the changes to take effect. The installation process instantiates the structural changes in the database. If the current .rpd file was uploaded, the system does not overwrite it.

Visualizing Business Area Data using OBIEE Answers

You can access OBIEE data visualizations in two ways:

  • In Oracle LSH, go to the Visualizations subtab of the Reports tab; locate the Business Area under its classification hierarchy; click the View icon in the Actions column for the Business Area; and click Launch Visualization.

    The system launches the Oracle Business Intelligence Presentation Services interface. Navigate to the Subject Area with the same name as the Business Area and follow instructions in the OBIEE user documentation to create Answers and Dashboards.

  • Outside Oracle LSH, go to the URL of the computer corresponding to the Service Location Name. The system launches the Oracle Business Intelligence Presentation Services interface. Navigate to the Subject Area with the same name as the Business Area and follow instructions in the OBIEE user documentation to create Answers and Dashboards.

OBIEE Security

Security access to OBIEE visualizations is determined by users' security privileges on the Business Area on which the visualization is based.

When you launch the OBIEE Administration Tool or an OBIEE visualization from within Oracle LSH , you can see noncurrent and blinded Oracle LSH data if you have the required privileges.

If you access an OBIEE visualization outside of Oracle LSH, through the URL of the OBIEE Presentation Services, you cannot see blinded or noncurrent data regardless of your privileges.

Installing and Setting Up Oracle Business Intelligence Administration Tool

To use the Oracle Business Intelligence Administration Tool, you must do the following on your local PC:

  • Get the CD-ROM that contains the Oracle LSH files cdrconfig.xml and cdrclient.exe from your system administrator and insert it into your PC. InstallShield automatically runs setup.exe to load cdrconfig.xml and cdrclient.exe to a location you specify on your local computer.

  • Install Oracle BI Client Tools on your PC in the location specified by your system administrator. The location must match the directory path specified in cdrconfig.xml.

  • Ensure that cdrconfig.xml has the correct directory path for the Oracle BI Administration tool.

  • Set up connectivity with the Oracle LSH database (details below).

Set Up Database Connectivity

To access Oracle LSH data in the Administration Tool on your PC, you must set up connectivity between the Oracle LSH database and your PC. You can use a system ODBC DSN or the Oracle Call Interface (OCI10g):

  • Set Up Database Connectivity Using a System DSN

    1. Create a valid Oracle driver-based System Data Source Name (DSN) on your PC that points to the LSH database.

    2. Consult Microsoft Windows online help for instructions on creating the System DSN.

    3. Use the Test Connection button to test the connection.

  • Set Up Database Connectivity Using OCI 11g

    1. Create an entry in your PC's tnsnames.ora file with the name and connection details for the LSH database server.

    2. Create an entry in your PC's tnsnames.ora file with the name and connection details for the LSH database server.

    3. Test the connection by trying to connect to the Oracle LSH database using sqlplus as apps. For example:

      sqlplus apps/apps_password@lsh_database_name
      

Launching Visualizations

This section contains the following topics:

Creating a Visualization

To create a Visualization from a Business Area instance:

  1. Click Launch. Oracle LSH opens the Launch Visualization screen.

  2. The Launch Visualization screen displays details about the Business Area instance, and launch settings—data currency, and data blinding-related settings—for data that becomes available to Oracle Discoverer or OBIEE. To edit these settings, click Launch Settings. Oracle LSH opens the Launch Settings screen. See "Setting Data Currency and Blinding Values".

  3. After making your selections in the Launch Settings screen, click Launch on the Launch Visualization screen. Oracle LSH opens Oracle Discoverer Plus or the OBIEE Administration Tool.

    Note:

    The first time you launch an Oracle Discoverer Visualization, a java applet is downloaded to your PC.

    When you launch an Oracle Discoverer Visualization, you may see a Discoverer login window. You do not need to do anything. Oracle LSH takes care of the login.

    When you launch the OBIEE Administration Tool, you have to log in with an Oracle LSH username and password.

  4. In Discoverer, you must select a Workbook. If you choose to create a new Workbook you see the Business Area and its tables displayed.

Setting Data Currency and Blinding Values

This section contains the following topics:

You can determine the blinding status and currency of the data you see by clicking the Launch Settings button and selecting a value for Blind Break and Shared Snapshot Label.

Setting the Blind Break Value

This setting is relevant only when one or more source Table instances either currently or formerly contained blinded data. Special privileges are required to view real data that is either currently blinded or was formerly blinded. You must have these special privileges on all such Tables, in order to see real data in any of them.

Note:

You must have Read Data privileges in order to see any data at all.

The following choices are available depending both on the state of the data and on your security privileges:

  • Not Applicable. If none of the data has ever been blinded, the only option available is Not Applicable. No special privileges are required.

  • Dummy. This is the only option available to you if you do not have blinding-related privileges for blinded Tables. You can also see this option if you have blinding-related privileges. In that case, you can select this option to work with dummy (not real) data in Oracle Business Intelligence Enterprise Edition or Oracle Discoverer.

  • Real (Blind Break). If any of the data is currently blinded, and you have the required privileges, you can select this option to view real data in Oracle Business Intelligence Enterprise Edition or Oracle Discoverer, according to your company's policies. The table(s) containing the blinded data remain blinded after you run the visualization.

  • Real (Unblinded). If a blinded Table instance has now been unblinded, you can see real data for the Table instance, provided you have the required privileges. If there are more than one such Table instances, you need the required privileges for all of them to be able to use this option.

Setting the Shared Snapshot Value

If all the relevant Table instances share one or more snapshot labels, those snapshot labels appear in this drop-down list and you can select one.

In addition, you normally have the option to view the current data.

You can apply snapshot labels in the Work Area; see "Adding, Removing, or Moving a Snapshot Label".

For more information on what snapshots are, see "Data Snapshots".

Installing Business Area Instances

You can install a Business Area instance directly from its Properties screen, using the Install button, or in its Work Area (see "Installing a Work Area and Its Objects").

When you install a Business Area instance using the Install button on its Properties screen:

Log File To see the log file for the installation, you must go to the Work Area Installation screen, as follows:

  1. Click the Applications tab. The main Application Development screen opens.

  2. Click the name of the Work Area you are working in. The Work Area screen opens.

  3. From the Actions drop-down list, select Installation History.

  4. Click Go. The system displays the Installation History screen with the log files in chronological order.

  5. Click the View Log link for the most recent installation attempt or for the date and time that you ran the install process. The system displays the log file.

For information on installation and on reading the log file, see "Installing a Work Area and Its Objects".

Modifying Business Areas

This section contains the following topics:

If you have the necessary privileges, you can modify a Business Area either through an instance of it in a Work Area or directly in the definition in its Domain or Application Area. In most cases it makes sense to work through an instance in a Work Area for the following reasons:

However, if you need to change properties of the definition, you must work directly in the definition in its Domain or Work Area.

Whether you work in an instance or directly in the definition, when you check in the new version of the definition you have the opportunity to upgrade instances of the original definition to the new version; see "Upgrading Object Instances to a New Definition Version".

Modifying Business Area Instance Properties

On the Business Area instance's Properties screen, click Update to enter changes. Oracle LSH creates a new version of the instance you are working on and applies your changes to it when you click Apply. Click Cancel to discard your changes and the new version.

You can modify some properties through the Actions drop-down list; see "Using the Actions Drop-Down List" for further information.

Note:

You must reinstall the Business Area for the changes to take effect.

You can modify the following:

Name See "Naming Objects" for further information.

Description See "Creating and Using Object Descriptions" for further information.

Definition Source This field applies to the instance only. It specifies the Business Area definition to which this Business Area instance points. It generally does not make sense to change the source definition for the following reasons:

  • Changing the definition may result in a new set of Table Descriptors, Joins, and Business Area Hierarchies.

  • Any new Table Descriptors are not mapped.

  • The Business Area's status changes to Non Installable.

If you want to change to a new version of the same definition, use the Upgrade Instance option from the Actions drop-down list.

Modifying Business Area Definition Properties

You can go to a Business Area definition's Properties screen in one of the following ways:

  • From the Business Area's Properties screen: Click the hyperlink of the Business Area definition that appears in the Definition field. See "Definition".

  • From the Domain or Application Area where you created the definition: Click Manage Definitions to view all the definitions in that Domain or Application Area. Click the definition name.

Once on the Business Area definition screen, click Update to enter changes. Oracle LSH creates a new version of the definition. You can change the following properties:

Name See "Naming Objects" for further information.

Description See "Creating and Using Object Descriptions" for further information.

You can modify some properties through the Actions drop-down list; see "Using the Actions Drop-Down List" for further information.

Modifying Table Descriptors

Table Descriptors belong to the Business Area definition, but Table Descriptor mappings belong to the Business Area instance. You must check out the definition to add, remove, or update Table Descriptors, but not to map, unmap, or remap Table Descriptors.

You can remove the existing Table Descriptors and add different ones. See "Creating a Business Area" for information about the function of Table Descriptors in a Business Area.

Oracle LSH enforces the following rules:

  • You cannot remove a Table Descriptor if any Join or Hierarchy references it.

  • You cannot change a Table Descriptor's source Table definition to a different Table definition if any Join or Hierarchy references the Table descriptor.

  • You cannot remove a Column from a Table Descriptor if any Join or Hierarchy references it.

You can change the Table Descriptor mappings, which are part of the Business Area instance, not the definition; see "Mapping Table Descriptors to Table Instances".

Note:

Oracle LSH does not prevent all changes that might cause your Business Area to not function properly. For example, you are allowed to change the underlying Variable of a Column even if the Column is part of a Join. However, if you select a Variable that has a different data type, the Join may no longer work.

Modifying Joins

Joins belong to the Business Area definition.You must check out the definition to add, remove, and modify Joins. See "Defining Joins" for information about Joins.

Modifying Business Area Hierarchies

Business Area Hierarchies belong to the Business Area definition. You must check out the definition to add, delete, and modify Business Area Hierarchies. See "Defining Business Area Hierarchies" for information about Business Area Hierarchies.

To change the order of the hierarchy columns, click Reorder. See "Reordering and Renumbering Objects".

Modifying Business Area Source Code

Business Area Source Code belongs to the Business Area definition. You must check out the definition to make any changes to the Source Code instance, for example, editing and uploading an OBIEE repository file for OBIEE Business Areas. See "About OBIEE Business Areas" for more information on OBIEE Business Area Source Code.