דיון: בניית עולם בעזרת link universe : בעד ונגד

שלום,
תוכלו בקשה להגיד מה בעד ונגד בניית עולם BO בעזרת link universe
תודה רבה

בוריס

העיקרון העיקרי ב-Linked universe הוא שאתה משתמש במבנה בסיס שטוב לשימוש במספר עולמות שונים ,למשל מנויים /לקוחות בחברת סלולר או מבנה גיאוגרפי/ סניפים בבנקים.

הרעיון הוא שאת השינויים אתה עושה במקום אחד ומפיץ אותם באמצעות ה-Linked universe לשאר העולמות.

אם יש לך מבנה משותף או אפילו סוג מסויים של אובייקטים/פילטרים שאתה רוצה שיופיע בכל עולם ואתה רוצה לשמור על % תחזוקה נמוך אזי יש בידך פתרון די נוח למימוש.

צד שני – ה- Linked universe לא מאפשר לך לבצע עריכה בעולם היעד בו הוא מוטבע,זאת אפשרות להפוך אותו לעריך אבל אז אתה מאבד את היתרון של שימוש במבנה המקור.

דבר נוסף – אם עולם הבסיס מכיל Aggregate awareness ו – Contexts תצטרך לבנות אותם מחדש בעולמות היעד ויהיו מימושים שלא תוכל ליישם אם ה- Aggregate awareness של עולם המקור צריך לדבר עם טבלאות נוספות בעולמות היעד.

מינוס נוסף – Linked universe ידועים כבעלי פוטנציאל גדול יותר לבאגים (נושא שאחוזי התקרית שלו הם נמוכים ביותר אךיחד עם זאת אפשריים )
בהגירה בין סביבות מצריכים יותר בדיקות,כמו כן יש להם בנוסף את הפרמטרים שלהם שיש להתאים בדיזיינר ובקבצי ה-prm.

מנסיוני האישי - יישמתי מס' פעמים פתרון מסוג זה בבנקים,חברות סלולר ותקשורת והוא בסה"כ יציב וטוב למדי.

והנה לך עוד השוואה מבית היוצר של SAP :

Symptom

What are the Best Practices for Linking Universes? I am trying to solve this formatting issue on the forum...



Environment

BusinessObjects Enterprise XIR2, XIR3.1

Cause

Linking Universes:

Within a universe it is possible to dynamically link to another universe.

When you link two universes, the primary active universe that is open has the role of derived universe and the universe that will be attached to it is referred to as the core universe.

Changes that are made in the attached core universe are automatically propagated to the derived universes.

The core universe can only be edited at its source and not in the derived universe.



Why Link?

If you have a number of universes and each contains the same set of objects it enables the reuse of objects.

Or you can opt for using the Include to copy all classes/objects and structure to a new universe. (Include becomes part of the new universe and is not dynamic)



Advantages of Linking:

Structure is created once and reused

Class and objects created once and reused

Maintenance on CORE only

Derived universes automatically updated

Disadvantages of Linking:

Only applicable to exported universes. (Not able to hide core universe in CMS)

Contexts must be recreated

Lovu2019s must be recreated

Connection must be to the same data source

One level of linking allowed

Why Include?



Advantages of Including:

Quick method of copying one universe into another

Maintain one universe rather than a number of smaller ones

Disadvantages of Including:

Only applicable to exported universes

Contexts must be recreated

No dynamic change if core universe is updated

Linking Requirements:

The core universe and derived universe use the same connection, data account, or Database and the same RDBMS.

Using the same connection for both the core and the derived universe makes managing the universes easier, but this can be changed at any time.



The core and derived universes must be in the same repository and the same domain.

The core universe and derived universe use the same data account, or database, and the same RDBMS. Using the same connection for both the core and the derived universe.

The core universe was exported and re-imported at least once. The derived universe does not need to have been exported before creating a link.

Exported derived universes are located in the same universe domain as the core universe.

You are authorized to link the given universe.

You cannot link to a universe that uses stored procedures.

You can use only one level of linking. You cannot create derived universes from a universe which is itself derived.

All classes and objects are unique in both the core universe and the derived universes. If not conflicts will occur.

Once the links are created there is very limited ability to move classes and dimensions.

The two universe structures must allow joins to be created between a table in one universe to a table in the other universe. If not, then Cartesian products can result when a query is run with objects from both structures.

Only the table schema, classes and objects of the core universe are available in the derived universe. Contexts and Access Restrictions must be re-detected or re-added in the derived universe.

Lists of values associated with a core universe are not saved when you export a derived universe with the core universe structures.

When multiple links are added the order of the links will appear reversed in the Class/Object Panel. For example, if universe A is first linked and then universe B the result will display in the class/objects panel as universe B then universe A.

Note: When you link universes, you can relocate the core universe within the same repository with out breaking the link. This allows you to export the core universe to a different repository folder, while keeping the links with derived universes valid.



The linking process must be completed by creating joins between the core tables and the derived universe tables. Delete all current contexts and re-detect the contexts for the new structure.

Note: You can not edit any structure, class, or object from the linked universe (core universe), within the derived universe.



Editing the Derived Universe:



Create joins between the core and derived universe structures. Creating joins ensures that Cartesian products are not returned for objects included in a query from both structures.

Remove existing contexts.

Detect aliases.

Detect contexts.

Hide or Create new objects as required.

Note: For information on hiding a component, refer to the section showing or hiding classes, objects and conditions Universe Designer Guide on page 308.