| Oracle® Life Sciences Data Hub Implementation Guide Release 2.1.4 Part Number E18308-01 |
|
|
View PDF |
| Oracle® Life Sciences Data Hub Implementation Guide Release 2.1.4 Part Number E18308-01 |
|
|
View PDF |
This section includes information on the following topics:
The Oracle Life Sciences Data Hub (Oracle LSH) provides three nested containers with which you can create an organizational structure that reflects your business and clinical organization. The containers are Domains, Application Areas, and Work Areas. Within these three containers you define and store meta-data objects to create your Oracle LSH applications. Through Work Areas you install applications to the database to interact with data.
You must design a logically organized set of these containers Your design should include:
Any number of Oracle LSH Domains, each with a specific purpose and each containing a library of validated, reusable object definitions and/or one or more logically related child Domains and/or Application Areas. See "Domains" for further information.
Any number of Application Areas, each contained in a logically related Domain and each having a specific purpose; for example, to generate a particular set of reports and/or to contain all the data for a single study or project. See "Application Areas" for further information.
One primary Work Area in each Application Area for use in application development. You may decide to let individual Definers have their own Work Areas in addition, but in the primary Work Area you install all the objects required for the application together. You clone this primary Work Area to create a test environment, and clone the validated test Work Area to create a production environment. See "Work Areas" for further information.
Both the security and classification systems make use of this organizational structure. Objects can inherit both their security User Group assignments and their classifications from their parent container. Therefore you can control security access to object definitions and instances by setting up inheritance and assigning user groups to Domains, Application Areas, and Work Areas. You can follow a similar procedure to setup classification for object definitions and instances. You can exclude a particular object at any level from the security access or classification, but if you design a logical structure that works for both security and classification, your Oracle LSH implementation will be much simpler to set up and to use. You should design all three systems at the same time. See Chapter 4, "Designing a Security System" and Chapter 5, "Designing a Classification System for Searching and Browsing".
Domains, Application Areas and Work Areas are themselves objects that you must define. You can add Domains, Application Areas, and Work Areas at any time. The instructions for creating Domains, Application Areas, and Work Areas are contained in the Oracle Life Sciences Data Hub Application Developer's Guide.
Notes:
Oracle LSH can display a maximum of 200 rows at a time by default, so if you define more than 200 Domains within a Domain, or Application Areas within a Domain, or Work Areas within an Application Area, or objects within either an Application Area or Work Area, you get an error. Therefore Oracle recommends that you design your organizational structure to avoid this problem. Alternatively, it is possible to reset an Oracle Applications profile to display more than 200 rows at a time; however this affects all your Oracle Applications.Also, keep container and Program names short if you are using an integrated development environment (IDE) such as SAS. Oracle LSH identifies objects in the IDE by their full pathname and the maximum length allowed for the full pathname is 256 characters. For further information see "Naming Objects" in the Oracle Life Sciences Data Hub Application Developer's Guide.
The relationship among the containers is described in the following sections and shown in Figure 3-1, "Oracle LSH Organizational Structure" below. The libraries in both Domains and Application Areas are shown with dotted lines because a Library is not a container that must be defined. A library simply consists of all the object definitions contained directly in either the Domain or the Application Area.
The Domain container inside the Domain container is shown in a different type of dotted line because you can choose to have no child Domains or up to nine (9) levels of nested Domains. See "Domains" for further information.
Figure 3-1 Oracle LSH Organizational Structure
For ideas on how to use this structure, see "Examples of Organization Design".
Many of the concepts used in this chapter were introduced in Chapter 1, "Overview". Appendix B, "Object Ownership" shows the container relationships among Domains, Application Areas, Work Areas, and all types of object definitions and instances.
A Domain is the top-level container in Oracle LSH. Domains have two purposes, and any one Domain can be used for one or both of these purposes:
Organizer. A Domain can contain child Domains and/or Application Areas. You can use a Domain to organize these other containers—child Domains and Application Areas—into logical groups. For example, you might create a Domain for a particular drug project and one Application Area within it for each clinical trial in the project. Alternatively you could create a Domain for a project, create a child Domain within the project Domain for each trial in the project, and create an Application Area for each report set. See "Examples of Organization Design" for other examples.
Library. A Domain can contain a library of object definitions. See "Domain Libraries".
Even if the Domain's only purpose is to store library definitions, you may want to include an Application Area containing a Work Area in order to install and test the definitions within the Domain before promoting them to the Domain library.
You can define any number of Domains and any number of Application Areas within a Domain.
Nested Domains Whether or not you can define Domains within Domains, and if so, how many levels of Domains, depends on your setting for the Domain Nest Value profile; see "Setting Profile Values" in the Oracle Life Sciences Data Hub System Administrator's Guide for further information. The allowed values range from zero (no nested Domains; a single level of Domains that can contain Application Areas and object definitions only) and nine (9 levels of nested Domains). The default value is two (2).
The Domain Nest Value setting does not affect the number of Domains you can define at the same level within a parent Domain. You can define any number of sibling Domains at a given level.
In the Oracle LSH user interface, you can browse and search for objects in only one Domain at a time.
Note:
When you load Oracle Clinical Global library definitions into Oracle LSH, the system automatically creates a Domain in Oracle LSH for Oracle Clinical Global Library objects and an Application Area for each Oracle Clinical Global Library Domain loaded into Oracle LSH. Each Application Area has the same name as the Oracle Clinical Domain whose Global library it contains. The Oracle LSH Tables, Variables, and Parameters created from the Oracle Clinical Question Sets, Questions, and DVGs become the library of that Domain.Domain Libraries A library is not a defined object; object definitions belong to a Domain's library when they are stored directly in the Domain. Therefore you cannot have more than one library in a Domain.
Domains are intended to store only tested, validated, production-quality object definitions. Some Domains may contain production-quality objects that are suitable for reuse in many applications. Other Domains may contain object definitions currently used in production for a particular trial or project. Oracle LSH does not enforce this usage in any way; you must develop a validation policy to determine which object definitions are eligible for inclusion in a library and, if you choose, set up Oracle LSH security so that only a few people can move definitions into a Domain library and modify them there. For an example, see "Project 123 Domain User Group".
Maintaining object definitions in a Domain library is not required. When a Definer creates an object in a Work Area, Oracle LSH automatically stores the definition in the Application Area that contains the Work Area. You can simply leave all object definitions in their Application Area library and still allow users with the necessary privileges to create instances of them in any Work Area or copy the definitions into any other Application Area library.
However, storing validated object definitions in a particular Domain library facilitates reusing these definitions by making it clear that these are intended for reuse. You can develop standard operating procedures requiring Definers to search first in Domain Libraries to find an existing definition that serves their purpose before searching in Application Area Libraries or creating a new definition. Reusing valid object definitions reduces your definition workload and ensures the consistency and quality of object definitions (see "Reusing Object Definitions").
In general, if a Domain contains logically related Application Areas, it makes sense to use that Domain library for storing validated object definitions that have been developed or adapted specifically for that logical group of applications. If you have developed definitions that are suitable for use in many projects, trials, or applications, such as Enrollment or Demography Tables, Programs or Report Sets, you may want to create a Domain specifically for the purpose of maintaining a central library of standard reusable definitions, and call it the Standards Domain, for example.
You can make it easier to find object definitions in a library by labeling them with a classification. See Chapter 5, "Designing a Classification System for Searching and Browsing".
This section contains information on the standard and alternative usage of Application Areas.
Standard Usage of Application Areas
An Application Area is designed to contain a single business application that you want to validate, release, and maintain as a unit. For example, an Application Area's business purpose might be to manage a single study, including all the programs for transforming and reporting data in that study. Or an Application Area might be used to generate a set of projectwide reports, or to merge data for all studies in a project. An Application Area supports a business application in two ways:
Library. An Application Area library contains the object definitions—Tables, Load Sets, Programs, Workflows, Report Sets, Data Marts, Business Areas and their component parts—created (or copied and modified) specifically to accomplish the business purpose of the Application Area. When you create a new object in a Work Area, Oracle LSH automatically creates the new object definition in the library of the owning Application Area. You can validate these definitions and move them to the Domain library if that is your policy. As in a Domain, the library is not a separate container but a collection of object definitions stored directly in the Application Area.
Work Area Container. An Application Area contains all the Work Areas necessary to develop, test, and put into production all the object instances necessary to accomplish the business purpose of the Application Area over time. A Work Area may contain instances of object definitions that are stored in any Domain or Application Area library.
For further information on Work Areas, see "Using Work Areas".
Alternative Usage of Application Areas or Child Domains
You can create Application Areas or child Domains whose sole purpose is to store library definitions. For example, in a Domain whose sole purpose is to store standard definitions, you could create Application Areas to store different categories of definitions to make the definitions easier to find by browsing. For example, you could create one Application Area for Demography-related Tables, Load Sets, Programs, Report Sets, and Workflows, and another Application Area for Adverse Events-related definitions.
The user interface separates objects within a library by object type, so there is no need to use Application Areas or child Domains to do that. You can use classification to label definitions by categories such as Demography and Adverse Events, but you can use definitions' classifications only during searching, not browsing.
A Work Area is designed to maintain a specific, installable, executable version of a particular life cycle stage of the whole business application supported by the Application Area. That is, a Work Area is intended to contain all the object instances required for the Application Area's business application. These may be instances of object definitions contained in the parent Application Area's library, in a Domain library, or even in another Application Area's library (though this is not recommended). See "Using Work Areas".
Work Areas are the link between the LSH definitional subsystem, which consists solely of meta-data, and the actual database schemas that comprise the data repository. Definitional objects' tables, views, and packages are instantiated in the database by installing a Work Area; see "Installing Work Areas". All data loading, storage and manipulation in Oracle LSH are done through installed Work Areas.
When a Definer creates a new object in a Work Area, he or she can either create an instance of an existing definition or create a new definition and instance at the same time. In this case, Oracle LSH simultaneously creates the new definition in the containing Application Area and an instance of it in the Work Area.
Work Areas have a special operation called cloning that allows you to duplicate a Work Area and all its object instances and install them to a new set of schemas for the next stage in the application's life cycle. Use this functionality to create separate development, test, and production environments. See "Cloning Work Areas".
The life cycle stages are represented in Work Areas' Usage Intent attribute, whose allowed values are the same as object validation statuses (except Retired): Development, Quality Control, and Production. Oracle LSH enforces certain rules based on the Work Area's Usage Intent value, its validation status, and the validation status of all its object instances. For a detailed explanation of how to use Work Areas for different application life cycle stages, see "Work Area Usage Intent and Validation Status".
After a Work Area is installed, you can populate its underlying database schema with data in two basic ways:
To load data from an external system, define, install, and run a Load Set (see "Loading Data") in the Work Area.
To operate on data already stored in Oracle LSH, define a Program in the Work Area and map each of its source Table Descriptors to a Table instance in any Work Area in Oracle LSH (see "Operating on Data"). Then install and run the Program.
Therefore it is not necessary to load data into the same Work Area where it will be processed. You can load a set of data to one Work Area and read it from a Program in any Work Area afterward. Figure 3-2 represents data flow options graphically.
When you install a Work Area for the first time, the system creates a new set of database schemas (called an Oracle LSH Schema). The installation process also instantiates object definitions in the database through the Work Area's defined object instances. There are three installation modes:
Full installation drops and replaces all objects. Any data already loaded into the schema is lost. It may be useful during development and testing to replace all objects and delete data that may be corrupted.
Upgrade installation changes only objects whose version numbers have incremented since the previous installation, and preserves data by upgrading Tables instead of dropping and replacing. You can explicitly omit objects from an upgrade installation. Upgrade is the only installation mode allowed in Work Areas with a Usage Intent of Production.
Partial installation enables multiple Definers to work in the same Work Area. Partial installation includes only objects that are not explicitly omitted and whose version number has incremented since the previous installation. The person who runs the installation can choose whether to upgrade or drop and replace Tables.
Newly created objects are automatically excluded from installation until their Omitted flag is explicitly unchecked. When a Definer is ready to install and test an object, he or she unchecks the flag. The object is included in the next Work Area installation, which may be started by the same Definer or someone else with the necessary privileges.
For further information, see "Using, Installing, and Cloning Work Areas" in the Oracle Life Sciences Data Hub Application Developer's Guide.
You can use the cloning operation together with the Usage Intent Work Area attribute and object validation statuses (Development, Quality Control, Production, and Retired) to create clean, controlled, distinct environments for application development, testing, and production. See "Work Area Usage Intent and Validation Status".
The cloning operation is similar to the copy operation except that it is possible to clone a Work Area onto an existing Work Area, so that the clone overwrites the existing Work Area. For example, if you already have a Quality Control usage intent Work Area, and several objects fail quality control testing, you can fix the objects in the Development Work Area and then clone the whole Development Work Area onto the QC Work Area, creating a new version of the QC Work Area.
When you clone a Work Area, you add the same label to the source and target Work Area. The label is proof that the two Work Areas are identical. In addition, all the object instances in the Work Area are duplicated exactly in the target Work Area. Their validation statuses remain the same.
This section contains information on the standard and alternative ways to use Work Areas.
Work Areas are designed to contain the entire application required for the business purpose of the Application Area, at a particular stage of its development. Oracle LSH uses an attribute (Usage Intent) and an operation (cloning) unique to Work Areas, to support controlled, validated passage from one life cycle stage to another: Development, Quality Control, and Production.
When you set up an organizational structure, you create one Work Area for each Application Area. Its Usage Intent and validation status are both set to Development. In standard usage, your team creates and tests objects in the development Work Area. When the objects in the Development Work Area are ready for formal testing, you clone the Work Area and all its object instances to create a duplicate Work Area with a Usage Intent of Quality Control (QC). You then install the QC Work Area, load fresh data, and test. When all objects are tested and validated, you can clone the Quality Control Work Area to create a duplicate Work Area with a Usage Intent of Production.
For details, see "Work Area Usage Intent and Validation Status".
Alternative Usage of Work Areas
Oracle LSH was designed to allow multiple Definers to work in a single Work Area that contains an entire logical application, using the Partial installation mode to install their own work.
However, it is possible to use different Work Areas for different portions of the business application. For example, you can create a separate Work Area for each Definer. If you create multiple Work Areas for different portions of the application, we recommend that you also maintain a primary Work Area to contain the entire application to validate and clone as a whole. Definers can then develop new object instances and definitions in their own Work Areas and move the instances into the main Work Area when they are ready.
This approach has the following advantages:
You can develop and validate different parts of the business application at different times. For example, if the business purpose of the Application Area is to analyze all the data for a particular study, you might need to develop and validate adverse events reports before efficacy reports for the study.
Definers can install their Work Area at any time, never having to wait for another Definer's partial installation to complete. However, installation should not be a lengthy process. This issue is primarily of concern for large groups of Definers working on the same business application.
Note:
You can remove the individual Definers' Work Areas after you have copied their object instances into the main Work Area. Unused object instances are eliminated, making more space available. However, object instances do not require very much space.You can remove only Work Areas whose Usage Intent is Development, or Work Areas whose Usage Intent is Quality Control or Production but which do not contain any installed objects.
The approach has the following disadvantages:
When Definers move objects from one Work Area to another they may need to remap Table instances to executables. If they copy and paste mapped executable instances and Table instance together, Oracle LSH maintains the mapping.
Because only one executable can write to any given Table instance, normally target mappings would be in the Definer's Work Area and Oracle LSH would maintain the mapping if the Definer moves the two object instances together. However, source Tables would often not be located in an individual Definer's Work Area, so the Definer would need to remap to source Table instances and test the new mappings. Also, if a Definer copies the object instances instead of moving them, he or she must redo all the mapping.
Definers should retest object instances after pasting them to the main Work Area.
If Definers have used the same name for the same type of object instance in two separate Work Areas, one of them must be renamed when they are pasted into the same Work Area. Oracle LSH renames them automatically by appending an underscore and the number one (_1), or the next higher number, to the name.
Following are several examples of ways to organize Domains, child Domains, Application Areas and libraries. You can use a combination of these approaches or design your own approach.
Examples 1 and 2 are alternative ways to organize data handling for a project that contains multiple studies and for which you need to report on each study separately as well as the project as a whole. The main advantage of Example 2: Project Domain with Reporting on Pooled Data is that you can report on the same data snapshot for all studies and for the project. The main advantage of Example 1: Project Domain with Reporting on Separately Stored Study Data is that you do not need a separate container for unblinded data at the end of the trial, saving space in the database.
Note:
You could follow the same procedures without using child Domains. The child Domains serve to organize the Application Areas, making it easier to browse.Alternatively, you can keep each study's data separate throughout the process except to report on the project as a whole. Within each project Domain, create the following child Domains:
A Domain for Each Study. Load data for each study in the project into an Application Area in its own Domain. Create a Load Set from the source tables or data sets. Oracle LSH stores the Load Set definition in the Application Area library.
If you collect data for different studies using slightly different formats, define a Program to copy raw data into Table instances with a standard data type and length for the project. Create an instance of the Program for each study, mapping its source table descriptors to the appropriate raw data table instances.
Create Report Sets and run each of them on the standardized study data. If necessary, create a different version of the Report Sets for each study.
When you are ready to unblind study data, run the Report Sets in Unblind mode or unblind each Table instance.
A Domain for Projectwide Data and Reports. Define a Program to copy data from the standardized table instances for each study into a single set of table instances for the project.
Run the Report Sets for the project as whole. If necessary, create a new version of each Report Set for the projectwide data.
When all studies are unblinded, run the Report Sets in unblinded mode or unblind each Table instance and then run the Report Sets.
In this example, you create a Domain for every project. In this Domain, you load the data from all of the project's studies into Oracle LSH, transform data to a standard format for the project, merge the standard data from all studies into a single set of table instances for the project, and report on the merged, standardized data.
Within each project Domain, you create the following child Domains:
Load and Transform Data. Load data for each study in the project into its own Application Area. Create a Load Set from the source tables or data sets. Oracle LSH stores the Load Set definition in the Application Area library.
If you collect data for different studies using slightly different formats, define a Program to copy raw data into Table instances with a standard data type and length for the project. Create an instance of the Program for each study, mapping its source table descriptors to the appropriate raw data table instances.
Merge and Report Data. Define a Program to copy data from the standardized table instances for a study into a single set of table instances for the project, adding a column for Study ID to each table if it is not already there.
Create Report Sets and run each of them on the pooled standardized data. Use Parameters to specify which study to report on and create a different Execution Setup for each study. By accepting all values for the Study ID Parameter you can create a Report Set on the project as a whole.
You can create data snapshots and run each Report Set for each study and the project as a whole on the same data snapshot.
Unblind and Report Data. If you need to unblind data for each study at a different time, create another Domain to hold the unblinded data. Define a Program to copy data with a particular study ID from the Merge and Pool Data Domain to the Report Unblinded Data Domain. To unblind a study, run this Program setting the Study ID Parameter to the correct value for the study, and run it in Unblind mode.
As each study becomes ready for unblinding, repeat the procedure. You can run the same or different report sets on the unblinded study data for each study and, when all studies in the project are unblinded, run the same Report Sets on projectwide data.
The companywide Domain holds Application Areas for companywide reports such as a list of all investigators updated monthly for submission to the FDA, and patient enrollment charts.
Use standard definitions of Tables, Programs, Data Marts, and so on to make it easier to reuse definitions and reduce the amount of work required for validation. Put standard definitions in a Domain only when you have thoroughly tested and validated them so that they are approved for reuse.
You may want to use CDISC data formats for standard Table definitions and create Programs that read from and write to those tables, for example.
You can use child Domains to organize definitions by type. For example, create a child Demography Domain to store demography-related Tables, Programs, Report Sets, and Data Marts. Create an Adverse Events Domain and an Efficacy Domain, and so on.
Note:
You can create these definitions as needed in other Domains and move them to the standard definition Domain when they are ready, or you can create Application Areas and Work Areas inside these Domains for the purpose of creating and testing standard definitions.When you define and run a Load Set for the Oracle Clinical Global Library, the adapter automatically creates an Oracle LSH Domain into which it puts Oracle LSH Variables, lists of values, and Tables that it converts from user-defined Oracle Clinical Questions, DVGs, and Question Groups. For further information, see "Defining Load Sets" in the Oracle Life Sciences Data Hub Application Developer's Guide.
In combination with any of the other examples, you can create one or more Domains to use for cross-project analysis. For example, you could create one Domain for one group of projects, and another Domain for a different set of projects.
Develop standard definitions for use in all studies, validate them, and put them in one or more Domains of standard definitions. Create a Study Template Domain with at least one Application Area and copy into it the standard definitions that you know need to be modified for each study. Create a Work Area in the Application Area that contains instances of the definitions in the Study Domain and also instances of definitions in the Standard Domain that do not need modification. In the Work Area, map all executables to Table instances as necessary.
When you begin a new study, copy the entire Study Template Domain, including its Application Areas Work Areas. The object instances in the copied Work Area point to the correct definitions, either in the copied Application Area or in the original Domain. All mappings remain intact.
Through the instances in the copied Work Area, modify the definitions in the Application Area as necessary for the new study.
This model works with Example 1: Project Domain with Reporting on Separately Stored Study Data. You could work out a similar process for the entire Domain, or for the Domain in Example 2: Project Domain with Reporting on Pooled Data.
As you design an organizational structure for your company, take the following points into consideration:
Security System Users are allowed to perform an operation on an object when they:
belong to a User Group that is assigned to that object, either directly or indirectly by inheritance
are assigned to a Role within the User Group that allows the requested operation on the requested object subtype
Objects inherit the User Group assignments of their containing objects, unless the User Group is explicitly unassigned from a particular object. If you assign a User Group to a Domain, that User Group also has access to everyDomain and Application Area in the Domain and every object definition in every Domain and Application Area, including every Work Area, and every object instance in every Work Area. However, users can perform only the operations defined by their Role(s) in the User Group.
You can unassign a User Group from an object at any level, in which case any objects it contains are also no longer assigned that User Group.
Outputs—reports, report sets, data marts, and visualizations—inherit their User Group assignments from the object instance that generates them (Programs, Report Sets, Data Marts, and Business Areas, respectively). Object instances inherit their User Group assignments from their containing Work Area. Therefore you can grant Consumers (end users) access to outputs by assigning them to a User Group that is assigned to the Production Work Area of the appropriate Application Area.
See Chapter 4, "Designing a Security System" for further information.
Classification System Classifications are used to label objects and outputs so that they are more easily found both by browsing the user interface and by advanced searches.
Objects can inherit the classifications of their container objects. Therefore, if you set up Domains and Application Areas in the same logical pattern you need for classification, you can effectively assign classifications to all the objects within a Domain or Application Area simply by assigning the classifications to the Domain or Application Area.
For example, if a Domain supports all of Project A and its Application Areas each support one study within Project A, you can assign an appropriate classification to each Application Area, such as Project A/Study 01 or Project A/Study 02. Then all Reports and other outputs produced from within each Application Area are automatically labeled as Project A/Study 01 or Project A/Study 02, and users can search for them in that context.
User Interface In the Oracle LSH user interface you can view only one top-level Domain at a time, with all the Domains and Application Areas it contains. To browse object definitions and Work Areas in other Domains, you must change Domains. Similarly, if you are viewing outputs, you can browse the outputs of only one Domain at a time.
You can search for objects across all Domains.
Business Areas Business Areas are the bridge between the Oracle LSH database and data visualization tools such as Oracle Business Intelligence Enterprise Edition and Oracle Discoverer Plus. A Business Area contains Table Descriptors that are mapped to Table instances. A data visualization can include only data mapped to a single Business Area.
When you create a Business Area, you can map to all Table instances in the Work Area at once if you choose to, simplifying Business Area definition. You can also map Business Area Table Descriptors to Table instances in other Work Areas, and/or to selected Table instances in the same Work Area. Therefore your data visualizations are not restricted to data contained in a single Work Area.
This section lists the basic design decisions you must make, with information on restrictions, if any. To work on your design, it may be helpful to sketch a diagram similar to those in the section "Examples of Organization Design".
You must make the following decisions about Domains:
Decide the number and purpose of each Domain.
Decide whether or not the Domain will contain a library of object definitions. If it will, decide the purpose of the library.
Decide whether or not the Domain will contain child Domains and if so, whether the child Domains will contain their own child Domains (and so on up to a total of 9 levels of Domain). If there will be child Domains, decide the purpose of each one.
Decide whether or not the Domain will contain Application Areas (see "Application Areas").
Even if the Domain's only purpose is to store library definitions, you may want to include an Application Area containing a Work Area in order to install and test the definitions within the Domain before promoting them to the Domain library.
If the Domain will include a library, you should also plan:
validation requirements for objects in the library, including a minimum validation status and what supporting information is required, if any (see Chapter 6, "Validating Objects and Outputs")
security requirements for objects in the library, including one or more roles with privileges allowing moving object definitions into the library and modifying them there (for an example, see "Project 123 Domain User Group").
You can define any number of Domains, and each Domain can contain a library of object definitions of any validation status and/or any number of Application Areas. The number of levels of child Domains allowed is determined by your setting of the Domain Nest Value profile; see "Nested Domains" and "Setting the Maximum Number of Nested Domains" in the Oracle Life Sciences Data Hub System Administrator's Guide for further information.
Considerations Take the following into consideration:
Domains are an important part of the security and classification systems; read Chapter 4, "Designing a Security System" and Chapter 5, "Designing a Classification System for Searching and Browsing" before you reach a decision on Domain usage.
You can browse objects in only one Domain at a time in the Oracle LSH user interface. However, you can search for objects in any Domain at any time.
You must decide the number and purpose of Application Areas in each Domain.
You can define any number of Application Areas in a Domain.
Considerations The business purpose of each Application Areas contained in a Domain should be a part of the business purpose of the Domain.
For example, if the purpose of the Domain is to contain all the data for a drug project, the purpose of each Application Area might be to contain all the data for a particular study that is part of that project.
If the purpose of the Domain is to contain standard Report Sets, the purpose of each Application Area might be to contain a particular Report Set.
See also "Alternative Usage of Application Areas or Child Domains".
For normal usage, you need to create one Work Area in each Application Area.
Considerations In standard Application Area usage, as time goes on you will clone this Work Area to create a Quality Control Work Area, and then clone the QC Work Area to create a Production Work Area.
It is possible to use an Application Area for object definition storage without a Work Area. However, even if you are using the Application Area for definition storage, you may want a Work Area to install and test the definitions. See "Alternative Usage of Work Areas".
|
 Copyright © 2006, 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
