Repository tables

In BusinessObjects 6.5 Repository have 57 tables.


Security Domain tables 25


1. OBJ_M_ACTOR
2. OBJ_M_USRATTR
3. OBJ_M_DOCCST
4. OBJ_M_GENPAR
5. OBJ_M_MAGICID
6. OBJ_M_RESLINK
7. OBJ_M_UNIVCST
8. OBJ_M_UNIVSLC
9. OBJ_M_ACTORDOC
10. OBJ_M_DOCUMENTS
11. OBJ_M_UNIVERSES
12. OBJ_M_ACTORLINK
13. OBJ_M_TIMESTAMP
14.OBJ_M_UNIVDBCST
15.OBJ_M_CONNECTION
16.DS_USER_LIST
17.OBJ_M_REPOSITORY
18.OBJ_M_CATEG
19.OBJ_M_CONNECTDATA
20.OBJ_M_OBJSLICE
21.OBJ_M_RESERVATION
22.DS_PENDING_JOB
23.OBJ_M_DOCCATEG
24.OBJ_M_DOCAT
25.OBJ_M_DOCATVAR


Document Domain have 1 tables

1.OBJ_X_DOCUMENTS

Universe Domain have 31 tables

1. UNV_JOIN
2. UNV_AUDIT
3. UNV_CLASS
4. UNV_RELATIONS
5. UNV_DIM_OBJ
6. UNV_OBJECT
7. UNV_OBJ_TAB
8. UNV_TAB_OBJ
9. UNV_CONTEXT
10. UNV_CTX_JOIN
11. UNV_TAB_PROP
12. UNV_JOIN_DATA
13. UNV_PROP_DATA
14. UNV_PROPERTY
15. UNV_UNIVERSE
16. UNV_CLASS_DATA
17. UNV_DIMENSION
18. UNV_PROP_TAB
19. UNV_OBJECT_DATA
20. UNV_CONTEXT_DATA
21. UNV_JOINCONTENT
22. UNV_UNIVERSE_DATA
23. UNV_OBJCONTENT
24. UNV_TABLE
25. UNV_TABLE_DATA
26. UNV_OBJECT_KEY
27. UNV_JOIN_OBJECT
28. UNV_COLUMNS
29. UNV_COLUMN_DATA
30. UNV_OBJ_COLUMN
31. UNV_X_UNIVERSES

Read more »

The Repository

The Default Repository Structure

The default Business Objects repository consists of three domains:

· Security Domain – Stores users, passwords, permissions, and connection information.
· Universe Domain– Stores universe structure (classes and objects)
· Document Domain– Stores documents and universe lists of values

There are several drawbacks to using the default repository structure provided by Business Objects:

· Universe lists of values and all document types share the same repository domain
· All three repository domains share the same database account
· There is no way to place two universes or documents with the same name in the repository for testing purposes

The Custom Repository

For the reasons listed in the previous section and for ease of maintenance, organization, and disaster recovery purposes, consider creating a custom repository with multiple domains.

The diagram below is a graphical representation of a sample new repository layout:

In the example, each Universe domain is in a separate schema with a separate default tablespace to eliminate the risk that an error will cascade and corrupt the entire repository. Universe domain schemas must also contain a Document domain. This Document domain is used to store custom lists of values.

There are four additional Document domains in four separate schemas with their own default tablespaces. These are used to store various types of documents.

The purpose of each repository domain is explained in detail below:

· BusinessObjects Security – This is the default security domain. For more information see above.
· Universe – This is the default universe domain. It is not currently being used in the example to store universes.
· Document – This is the default document domain. It is not currently being used in the example to store documents or lists of values.
· Production_Universe – Used to store Production universes.

· ProdLOV_DoNotUse – Used to store Production universe lists of values. It is named ‘_DoNotUse’ to discourage use for purposes other than the storage of universe lists of values. No user group has access to the domain and surprisingly enough, this does not prevent designers from being able to export custom lists of values nor does it prevent users from being able to import them.
· Test_Universe – Used to store Test universes or universes being staged from Test to Production. An additional Dev_Universe domain could be added.
· TestLOV_DoNotUse – Used to store Test universe lists of values. See above for a detailed explanation of the naming convention ‘_DoNotUse’. An additional DevLOV_DoNotUse could be added.
· Corporate Documents – Used to store Corporate Documents
· Secure_Documents – Used to store and separately secure documents accessed by selected customers (You many have as many document domains as necessary to secure or organize Business Objects reports).
· BO_User_Documents – Used to store documents mailed from one user to another via the Business Objects repository. It is possible for users to send documents using other domains they are allowed to access but since domains appear alphabetically and since users rarely notice the domain dropdown on the send to user screen, user-to-user documents will likely remain confined to this area.

· Scheduler_DoNotUse – Used to store documents being distributed by the Broadcast Agent. A second Broadcast Agent has been set up for Corporate Documents published on a schedule that uses the ‘Corporate_Documents’ document domain. See above for a detailed explanation of the naming convention ‘_DoNotUse’
The table below can be used to record pertinent database information pertinent to the repository. The sample is designed for Oracle

Read more »