We can move the objects from Development folder to Production folder in Informatica by using any of the two methods.Before making any changes to the Production folder make sure you take the back up of all the objects.
Export and import
Export the mappings that you want to move from the DEV folder and save those as XML in some folder.
Take the back up of the Production mappings before replacing
Import these XML into Production Folder
Save the mappings
But when you are doing these we need to check the below things
1.We need to check the Replace check box in case the source or target is already present in the folder
2. For other reusable transformations such as source shortcuts, target shortcuts or any other transformations (Sequence Generator, Lookup etc) choose Reuse (not replace)
3. On Global copy options, in conflict resolution wizard, select (or mark) Retain Sequence Generator, Normalizer or XML key current values.
Direct Migration :
IF the Development and Production are in separate repositories then go to the Repository Manager and then connect to the development Repository.Then go to the Production repository and open that too.Then you can drag and drop all the folders from Dev to Production.
Note:
Problem might come when we export and import objects separately i.e. mapping, workflow etc. The big problems is shortcuts. In this case
1.Open Development folder from Repository Manger
2.Select only the workflows related to the mapping from the repository manager and export only the workflow XML. This will take all the associated objects (mappings, sessions, etc.) with the workflows.
3.Import from this single file into your Prod Environment.
This will import and export everything regarding a mapping.
1. Objective:
To filter duplicate records in a source, solution described below uses a lookup transformation with
dynamic cache enabled. System generated port NewLookupRow is used to identify new records.
2. Source definitions:
Source is EMP table as shown in figure 1. This can be a flat file source also depending on the
requirement.
Figure 1: Relational source EMP (Oracle)
3. Target definitions:
Target is copy of source i.e. another table with same structure as of source. All distinct records found
in source table will be inserted into target table EMP_TARGET. All duplicate records will be discarded.
4. Mapping:
Figure 2 shows the mapping designed to filter duplicate records in source.
Figure 2: Mapping logic
4.1 Transformations used
LK_target
Lookup transformation with dynamic cache properties enabled is used to identify if the incoming
record already exists in target. If yes then value of NewLookupRow port will be 0. If incoming record is
Lookup condition is EMPNO=IN_EMPNO. This condition depends on the key to identify duplicate
records. In my example I am just looking for duplicate empno. Dynamic Lookup Cache property for
this lookup transformation is enabled.
FL_new_rows
This filter passes only new rows to the target. Filter condition is NewLookupRow = 1.
We get the unique records in Target table.
To filter duplicate records in a source, solution described below uses a lookup transformation with
dynamic cache enabled. System generated port NewLookupRow is used to identify new records.
2. Source definitions:
Source is EMP table as shown in figure 1. This can be a flat file source also depending on the
requirement.
Figure 1: Relational source EMP (Oracle)
3. Target definitions:
Target is copy of source i.e. another table with same structure as of source. All distinct records found
in source table will be inserted into target table EMP_TARGET. All duplicate records will be discarded.
4. Mapping:
Figure 2 shows the mapping designed to filter duplicate records in source.
Figure 2: Mapping logic
4.1 Transformations used
LK_target
Lookup transformation with dynamic cache properties enabled is used to identify if the incoming
record already exists in target. If yes then value of NewLookupRow port will be 0. If incoming record is
Lookup condition is EMPNO=IN_EMPNO. This condition depends on the key to identify duplicate
records. In my example I am just looking for duplicate empno. Dynamic Lookup Cache property for
this lookup transformation is enabled.
FL_new_rows
This filter passes only new rows to the target. Filter condition is NewLookupRow = 1.
We get the unique records in Target table.
We know
that fact table is a collection of many facts and measures having multiple keys
joined with one or more dimension tables. Facts contain both numeric and
additive fields. But factless fact table are different from all these.
A factless
fact table is fact table that does not contain fact. They contain
only dimensional keys and it captures events that happen only at information
level but not included in the calculations level. just an information about an
event that happen over a period.
A
factless fact table captures the many-to-many relationships between dimensions,
but contains no numeric or textual facts. They are often used to record events
or coverage information. Common examples of factless fact tables include:
- Identifying product promotion events (to determine promoted products that didn’t sell)
- Tracking student attendance or registration events
- Tracking insurance-related accident events
- Identifying building, facility, and equipment schedules for a hospital or university
Factless
fact tables are used for tracking a process or collecting stats. They are
called so because, the fact table does not have aggregate table numeric values
or information. There are two types of factless fact tables: those
that describe events, and those that describe conditions. Both may play
important roles in your dimensional models.
Factless fact tables for events:
The first type of factless fact table is a table that records an event. Many event-tracking tables in dimensional data warehouses turn out to be factless. Sometimes there seem to be no facts associated with an important business process. Events or activities occur that you wish to track, but you find no measurements. In situations like this, build a standard transaction-grained fact table that contains no facts.
Factless fact tables for events:
The first type of factless fact table is a table that records an event. Many event-tracking tables in dimensional data warehouses turn out to be factless. Sometimes there seem to be no facts associated with an important business process. Events or activities occur that you wish to track, but you find no measurements. In situations like this, build a standard transaction-grained fact table that contains no facts.
For eg.
The
above fact is used to capture the leave taken by an employee. Whenever an
employee takes leave a record is created with the dimensions. Using the fact
FACT_LEAVE we can answer many questions like
- Number of leaves taken by an employee
- The type of leave an employee takes
- Details of the employee who took leave
Factless
fact tables for conditions
Factless fact tables are also used to model conditions or other important relationships among dimensions. In these cases, there are no clear transactions or events. It is used to support negative analysis report. For example a Store that did not sell a product for a given period. To produce such report, you need to have a fact table to capture all the possible combinations. You can then figure out what is missing.
Factless fact tables are also used to model conditions or other important relationships among dimensions. In these cases, there are no clear transactions or events. It is used to support negative analysis report. For example a Store that did not sell a product for a given period. To produce such report, you need to have a fact table to capture all the possible combinations. You can then figure out what is missing.
For eg:
fact_promo gives the information about the products which have promotions but
still did not sell
This fact
answers the below questions:
- To find out products that have promotions.
- To find out products that have promotion that sell.
- The list of products that have promotion but did not sell.
This
kind of factless fact table is used to track conditions, coverage or
eligibility. In Kimball terminology, it is called a “coverage table.”
A
commit interval is the interval at which the server commits data to relational
targets during a session.
Three types of Commit Intervals:
Target based commit.
Source based commit.
User defined Commit.
If you use in Transaction control Transformation that time the commit type is automatically convert to User defined commit.
Default commit interval is Target.
(a)
Target based commit
1. Server commits data based on the no
of target rows and the key constraints on the target table. The commit
point also depends on the buffer block size and the commit interval.
2. During a session, the server
continues to fill the writer buffer, after it reaches the commit interval.
When the buffer block is full, the Informatica server issues a commit
command. As a result, the amount of data committed at the commit point
generally exceeds the commit interval.
3. The server commits data to each
target based on primary –foreign key constraints.
(b)
Source based commit
1. Server commits data based on the
number of source rows. The commit point is the commit interval you
configure in the session properties.
2. During a session, the server commits
data to the target based on the number of rows from an active source in a
single pipeline. The rows are referred to as source rows.
3. A pipeline consists of a source
qualifier and all the transformations and targets that receive data from
source qualifier.
4. Although the Filter, Router and
Update Strategy transformations are active transformations, the server
does not use them as active sources in a source based commit session.
5. When a server runs a session, it
identifies the active source for each pipeline in the mapping. The server
generates a commit row from the active source at every commit interval.
6. When each target in the pipeline
receives the commit rows the server performs the commit.