Create an Oracle Module

Introduction:

An Oracle Module contains all the objects associated with a specific schema on a particular instance. The objects that are created here are deployed as tables, views, sequences, package procedures, etc.

Aim:

Create an Oracle Module and associate it with it's physical schema.

Requirements:

Access to an OWB Project.

Procedure:

• Log in to OWB.
• On the main screen, open a project: Expand Project Name.
• -Databases-
• -Oracle-
• Right-click Oracle
• -Create Oracle Module-
• Welcome:
• [Next]
• Name: Usually the name of the schema.
• Module status:
• This COULD be used as developer information. However, it is no more than a metadata label and doesn't form part of any greater configuration management infrastructure. I usually leave this as-is regardless of its actual status.
• Identify the module type:
• The primary difference between 'Data Source' and 'Warehouse Target' is that you can deploy object to the latter but not the former. This sounds like a simple choice; if it is a read-only external system, use 'Data Source', right? Well not always. You may, for example, wish to deploy a view or procedure used in a trigger to an Oracle source - handy if the source can't readily identify change records - though you will need a VERY understanding source system DBA. It is probably best to define all Oracle modules as targets at this stage. After all, you don't HAVE to deploy to a target but you can give yourself the option of doing so one day if necessary.
• Description:
• This is used to let the users know where their data is coming from / going to and should be geared to that.
• [Next]
• Connection Information:
• This screen describes where you get the descriptions of objects (tables, etc) that will be used in the data warehouse. If you use Designer, you can define a connection to its repository. If you are creating objects directly in a schema and want to pull their definitions into OBW from there, you can define a link to this schema. Regardless of whether I am using Designer or not, I prefer to always use the 'Oracle Data Dictionary' option. Anything that I develop in Designer is deployed to the schema and imported from there into OWB. That gives me the choice of not using Designer for some objects, if I want. Of course, if you are designing and delopying different objects in different ways, you need a very good Configuration Management infrastructure to handle it all. What do you mean - you don't have one of those!
• Oracle Data Dictionary
• Datadase Link: If you already have a link defined for this target, choose that, otherwise: -New DB Link-
• New Database Link:
• DB Link Name: I usually use something like; [schema name]_SRC.[SID] or [schema name]_TGT.[SID].
• NOTE: If you don't append '.[SID]', or at least '.[something]', Oracle will append the Global Database Name to the DB Link an this component can be very long. This can cause problems when using debug. Why? Because the links are deployed surrounded by double-quotes - e.g. "link name" - and, if the length of this is greater than 30 characters, it throws and error. It's best to have short-name DB Links.
  
• Host Name:
• Host Name: lisa
• Port Number: 1521
• Oracle Service Name: The instance name
• User Name: The schema name
• Password: *********
• [Create and Test]
• Testing... successful
• [OK]
  
• [Next]
• Location:
• This screen describes the location where the objects will be deployed to. Often, this points to the same location as the Connection Information location, i.e. the target contains objects sourced from Designer, other places and this module, and object definitions can be passed freely between them.
• Deployment location: If you want to use one that's already defined, pick this from the drop-down, otherwise: [New...]
• New Location Dialog:
• Name: I usually use [schema name]_TGT
• Description: This is a developer's message.
• Version: The database version.
• [OK]
• [Next]
• [Finish]