Select File Multiuser History. Select the version of interest, and then choose Actions View Repository. Select File, then select Copy As to save that version to a new name.

A-26 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition Rolling Back to Previous Versions The multiuser development environment stores backup copies of RPDs at appropriate checkpoints. Each time a potentially destructive operation is performed, a new backup is stored in the master directory. It has the name of the RPD, and the extension is a three-digit incrementing integer. Individual developers can also make copies of their RPD files at any time during development. In the developers sandbox, the original version of a checked-out project is stored with the name originalrpd_name.rpd. This version is automatically used if the developer discards changes. You can also view and roll back to an older version by following these steps: 1. Open the Administration Tool, but not a repository.

2. Select File Multiuser History.

3. Select the version of interest, and then choose Actions View Repository.

4. Select File, then select Copy As to save that version to a new name.

5. Use the older version to replace the latest version, or replace the master repository with the older version. Example This example explains how to copy an older version to replace the latest version. Assume you are at version 1000 and want to roll back to version 900. In this situation, you have three files: repository.900, repository.1000, and repository.rpd, the current version. To perform the roll back, make a copy of repository.900 and rename it to repository.1001. This lets you keep repository.1000 in your version history. Then, copy repository.900 to repository.rpd. B MUD Case Study: Eden Corporation B-1 B MUD Case Study: Eden Corporation This appendix describes a fictional case study that shows how the multiuser development environment might be used for a particular business case. This appendix contains the following topics: ■ About the Eden Corporation Fictional Case Study ■ Phase I - Initiating Multiuser Development MUD ■ Phase II - Branching, Fixing, and Patching ■ Phase III - Independent Semantic Model Development About the Eden Corporation Fictional Case Study Eden Corporation a fictional company recently purchased Oracle Business Intelligence. They have two divisions that are licensed and plan to use the product. Because of this, the company has two separate initiatives: ■ Initiative S: The Sales Division wants to use Oracle Business Intelligence for dashboarding and analysis of revenue versus plan. They want to deploy an initial phase to production quickly to meet an immediate need. Then, they want to roll out more functionality in Phases II and III. Initiative S is large enough that they will have two developers working on it. ■ Initiative H: The Human Resources Division HR needs to do dashboarding and analysis of HR data. Initiative H is a smaller initiative, so it will have only one developer. They plan to deliver their application to production between Initiative S Phases II and III. Note that the Sales developers and the HR developers are not allowed to see each others data or metadata. The metadata administrator is the only person who has security privileges for all the metadata. As in all organizations, there will also be a steady stream of urgent requests and occasional bugs from production. The developers will need to deliver fixes for these within days, even though the longer-term initiatives S and H are in development at the same time. About the Technical Team Roles and Responsibilities Eden Corporation has staffed the team as follows: ■ Adam Straight - MUD Administrator ■ Sally Andre - Developer for Sales Division, Revenue project ■ Scott Baker - Developer for Sales Division, Quota project B-2 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition ■ Helen Rowe - Developer for HR Division About the Eden Corporation Development Phases Eden Corporation plans to deploy RPDs to production based on the following timeline: 1. January - Sales Phase I projects Revenue and Quota 2. February - Sales Phase II add project Target, extend projects Revenue and Quota 3. March - HR one project used 4. April - Sales Phase III extend all three projects About the Eden Corporation Topology Eden Corporation plans to use the following systems for their multiuser development environment: ■ MUD Administrator - NT computer with a share ■ Sally Andre - NT computer for Administration Tool client, and Linux computer to run the Oracle Business Intelligence stack ■ Scott Baker - high-powered NT computer ■ Helen Rowe - either of the above ■ Test - Linux computer ■ Production - Clustered Linux computers About the Repository Architecture Because of Eden Corporations business structure and initiatives, they need to have two independent semantic models in their repository: one for Sales and one for HR. Each of these models can have multiple projects. Planning the Repository Structure Eden Corporation knows that it is important to plan the structure of their repository file so that it will be able to support the multiuser development needs of their organization. They assigned owners to major objects, so the developers know who to go to when conflicts arise, and which objects they should not modify on their own. Tip: When hosting multiple independent semantic models, be sure to itemize the names of top-level objects to prevent duplicate names. Table B–1 and Table B–2 show the high-level repository objects in main.rpd for both Initiative S and Initiative H, mapped to projects and owners. Note that Adam is the overall owner of both Initiative S and Initiative H. Table B–1 Initiative S Repository Objects Mapped to Projects and Owners Object Type Object Owner ProjRevenue ProjQuota ProjTarget physical database Sample App Data Sally Yes Yes Yes business model Sales Sally na na na logical fact table 1 F10 Billed Rev Sally Yes Yes No logical fact table 2 F30 Facts Targets Scott No No Yes logical fact table 3 F50 Facts Quotas Scott No Yes No logical dimension various Sally Yes Yes Yes MUD Case Study: Eden Corporation B-3 Phase I - Initiating Multiuser Development MUD In the first phase, both Sally Andre and Scott Baker will develop in parallel. Sally will create the starter content, which Adam Straight will divide into projects. He will then create the MUD directory so that Sally and Scott can check out and perform their development. After unit testing, they merge and publish their changes, and then Adam migrates the repository to the test environment. After a bug fix cycle, Adam promotes the repository to production. The following sections describe Phase I development: ■ Starting Initiative S ■ Setting Up MUD Projects ■ First Developer Checks Out ■ Second Developer Checks Out ■ First Developer Checks In ■ Second Developer Checks In ■ MUD Administrator Test Migration Activities ■ Phase I Testing subject area 1 Sales Quota Scott No Yes No subject area 2 Sales Revenue Sally Yes No No subject area 3 Sales Target Scott No No Yes variable S_Last_Load Sally Yes Yes Yes initialization block S_Last_Load Sally Yes Yes Yes application role 1 Sales Management Sally Yes Yes Yes application role 2 Sales Rep Sally Yes Yes Yes Table B–2 Initiative H Repository Objects Mapped to Projects and Owners Object Type Object Owner ProjHR physical database Human Resources Data Helen Yes business model HR Helen na logical fact table 1 Payroll Facts Helen Yes logical fact table 2 Medical Ins Facts Helen Yes logical dimension various Helen Yes subject area 1 HR Payroll Helen Yes subject area 2 HR Medical Helen Yes variable H_Last_Load Helen Yes initialization block H_Last_Load Helen Yes application role 1 HR Management Helen Yes application role 2 HR Rep Helen Yes Table B–1 Cont. Initiative S Repository Objects Mapped to Projects and Owners Object Type Object Owner ProjRevenue ProjQuota ProjTarget B-4 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition ■ Phase I Migration to Production ■ Phase I Summary Starting Initiative S Sally Andre starts off Initiative S from an empty RPD. Because it is easier to divide the repository into MUD projects if you define some logical stars and subject areas first, she begins by developing the physical model needed for Phase I. She includes connection pool details for her own local test data sources. Tip: The physical model should include the physical tables, the best practice of aliasing all the physical tables to give them meaningful names, and joins. Figure B–1 shows the physical model for Initiative S. Figure B–1 Initiative S Physical Model Sally drags the Physical layer to the Business Model and Mapping layer to create some starter content. She removes unneeded tables, and ensures that the star joins are correct. She also ensures that all the physical tables that will be needed during development have mappings from the starter logical tables, so that they will be included in the projects when they are checked out. For Sally, these steps create two logical fact tables, F10 Revenue and F50 Quotas, that can act as the basis for the projects. Sally also needs to have some subject areas to map to the projects in the business model. She could drag the entire business model, but a convenient way to accomplish this is to instead right-click the business model and select Create Subject Areas for Logical Stars and Snowflakes . This feature creates a subject area from each logical fact table. MUD Case Study: Eden Corporation B-5 Sally does not need to be concerned about the contents of the subject areas yet. All that matters is that each subject area maps to the logical fact table for the same project. However, she does name the subject areas based on the plan agreed to in the governance meeting: Sales Quota and Sales Revenue. Sally now has enough content for the MUD administrator to create the first two projects based on the Revenue and Quota fact tables. To review, Sally has made sure that she meets the following criteria at a minimum: 1. At least one logical fact table according to the governance plan, to anchor the projects. The columns of the logical fact tables need not be complete or even properly named, but they do need to be complete enough to map all the physical content. 2. Enough logical dimensions so that the repository will pass the consistency check. 3. Physical content that maps to one or more logical fact tables, so they will be included in projects. 4. The subject areas needed according to the governance plan. Setting Up MUD Projects The MUD administrator for Eden Corporation, Adam Straight, now handles the next few steps to create the projects and get them ready for checkout. First, he creates the MUD directory, RPD_main, where the master RPD will be stored. This master RPD contains the superset of content for the developers. The users will check their projects out of the master, and merge them back in when they want to share their changes. Sally copies her started RPD to the master folder so that Adam can create the first two projects, ProjRevenue and ProjQuota. First, Adam opens the master RPD in the Administration Tool and selects Manage Projects . Then, in the Project Manager, he selects Action New Project. Adam names the project ProjRevenue and proceeds to pick the logical fact tables at the center of the project. The top object in the list expands to show the logical fact tables, but he has a choice of seeing them grouped by the Business Model to which they belong, or by Subject Area. Figure B–2 shows the different ways Adam can view the logical fact tables. Figure B–2 Project Dialog with Facts Grouped by Business Model and Subject Area Adam decides to group facts by Business Model for convenience, although he could have used the Subject Area grouping to select the same fact table. He adds the fact table, plus the default application roles and subject areas specified for this project. B-6 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition Because there are no custom-defined application roles, users, variables, or initialization blocks yet, he cannot yet add them to the project. Adam repeats this process for ProjQuota, the second project. Tip: Note that some of the explicit objects are the same in both projects, because both projects share application roles. Similarly, many of the implicit project objects are shared, particularly dimension tables in both the logical and physical models. Keep in mind that projects are a convenience for creating small subsets that are easy to work with; they are not for security. It is critical in your governance process that the owner of each top-level object is assigned and documented for the whole team, because this enables developers to avoid conflicts. Adam included the logical fact table F10 Bill Rev in the project, even though it is owned by Sally Andre, not by Scott Baker, the owner of this project. He did this because Scott needs to create a measure that derives from measures in both fact tables Sales percent of quota. Again, the point is to provide the user with the subset of content they need to implement their requirements, not just the objects they own. Adam saves the master RPD to the shared drive, RPD_Main, as sales.rpd. It is now ready for users to check out projects and begin working in parallel. First Developer Checks Out Now, the two developers will set up their Administration Tool clients for the master repository, check out their projects, and begin working. Sally starts by setting up her Administration Tool client to use the master repository. To do this, she selects Tools Options , and then selects the Multiuser tab. There, she sets up the pointer to the master repository directory. She also enters her full name, which will be useful in logs and locks. Now, she can check out her project and begin working on it. Meanwhile, in the Master Repository directory, two new files have been created: sales.000 and sales.mhl. Figure B–3 shows the new files. Figure B–3 Two New Files in the Master Repository Directory The sales.000 file is an automatic backup created for sales.rpd when Sally checked it out. This file can be used to roll back if problems occur. The sales.mhl file tracks her checkout status and parameters, including project, computer, and user. Meanwhile, three files have been created in Sallys local repository directory: ■ originalProjRevenue.rpd: This file is the project subset RPD at the time of checkout. It will be used later as the original in the three-way merge process, and also if Sally discards her changes. ■ ProjRevenue.rpd: This file contains only the self-consistent subset project ProjRevenue. This is the file that is open for editing. ■ ProjRevenue.rpd.Log: This file is the log file for this editing session in the Administration Tool. You can view its contents in the Administration Tool using File Multiuser History . Figure B–4 shows the three files in the local repository directory. MUD Case Study: Eden Corporation B-7 Figure B–4 Three New Files in the Local Repository Directory Now, Sally begins to work on the model for her application. She does not need to change her connection pool settings because she used her own test data source connection pool details when she created the starter content. Sally starts by opening her fact table and deleting the unused keys based on the modeling best practice. Then, she adds SUM aggregation rules to three measures, Discnt_Value, Revenue, and Units. She also changes the name of Discnt_Value to Discount Amount, Units to Units Sold, and Revenue to Sales Revenue. Sally also needs to add a new column to the D10 Product table, an upper-case version of the Prod_Dsc column called PRODUCT DESCRIPTION. It uses the following expression: UpperSales.D10 Product Dynamic Table.Prod_Dsc. She also adds dimension hierarchies, creates a variable called Constant One, and initializes it to the value 1. She uses it to create a new measure, Constant One. Sally starts her sandbox Oracle Business Intelligence stack so that she can add application roles, and then test her repository using Answers. She follows these steps to start her components in the right order and to configure her system environment:

1. Start the database containing the RCU schema, using its standard controls.