How Linking Works

 < Day Day Up > 



The linking works through the repository, so a key requirement for linked universes is that they use a Secure Connection. Recall from earlier chapters that there are three possible connection types:

  1. Personal connections that individual users may create, whose definitions are stored in a local pdac.ssi file.

  2. Shared connections that are shared via work group folders on a LAN server, whose definitions reside in sdac.ssi.

  3. Secure connections that either supervisors or designers create and whose definitions reside in the BusinessObjects repository.

The kernel and derived universes must exist within the same universe domain. The kernel universe must have been exported to the repository at least once. This establishes a UNIVERSE_ID that then gets used in the link. You add the link within the derived universe. When you define a link, all the classes, objects, and joins get displayed within the derived universe; they appear gray to differentiate them from other items that you may add directly within the derived universe. The link is one-way and not bidirectional. When you export the derived universe to the repository, Designer updates the UNV_RELATIONS repository table to say the link exists. Table 14-1 shows that the Kernel universe with UNIVERSE_ID=19 is linked to a Derived universe with UNIVERSE_ID=20.

Table 14-1: Universe Links Are Defined in the Repository Tables

UNIVERSE_ID

UNI_FILENAME

BASIC_UNV_ID

DERIV_UNV_ID

13

DebitCre

  

15

Orders

  

16

T_BEACH

  

17

AcctRec

  

12

Sales

  

11

HumanRes

  

14

TestFash

  

18

DrinkDET

  

19

Kernel

19

20

20

Derived

  

Be aware that linking does not save disk space in the repository. For each object, you will have two rows of data in the repository tables, each with a unique UNIVERSE_ID. The derived_universe.unv will be somewhat smaller than if you did not link, but not by much. As an example, the size of my small kernel universe is 16K (46 objects, four tables) and the derived universe that contains only one additional table and two new objects is 11K. These sample files are exceedingly small. In a real-world implementation, universe.unv files get to be several megabytes. When a user accesses a derived universe, both the kernel universe and the derived universe get imported to the client PC, work group server, or WebIntelligence (WebI) midtier. (Refer to Figure 5-6 for an overview of how the universe gets imported.) If users have to wait patiently for two large universe.unv files to be imported (the kernel plus the derived universe), it is not user friendly. File size is more of a problem for companies trying to build a kernel universe with all the information in the data warehouse (Figure 14-2), as these universe.unv files are larger than files used in the other two approaches. To minimize this problem, universe designers can 1) move to scheduled modifications so that universe definitions change on a periodic (weekly or biweekly) basis or 2) push the universe.unv file to a work group directory for full-client installations or the WebI midtier; do not wait for the modified derived_universe .unv and kernel_universe.unv file to be downloaded during user login.

Note 

The size of the universe.unv file will be larger on a designer’s PC than on a user’s PC or WebI midtier, as it contains structure information from the data dictionary of the data source. To get the user size of the universe.unv file, export the universe to the repository, delete your local copy, and reimport the universe.

If you are working with an existing universe or trying to combine two kernel universes into one bigger derived one, there are a few more caveats. First, class names must be unique. If the kernel universe contains a duplicate name as the derived universe, then Designer will rename this class upon linking. For example, if Country exists in both the derived universe and the kernel universe, it becomes renamed Country2 in the derived universe. The object names within each class remain the same. The physical table, however, is another story. The table COUNTRY already existed within the derived universe structure. Upon linking, the table name remains the same, but unfortunately, the link table now takes priority and COUNTRY will appear dimmed. This will pose a problem only if you later decide you want to remove the link; you can’t easily do this, as your existing Country class still needs the original COUNTRY table.



 < Day Day Up > 



Business Objects(c) The Complete Reference
Cisco Field Manual: Catalyst Switch Configuration
ISBN: 72262656
EAN: 2147483647
Year: 2005
Pages: 206

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net