SQL> create table staff_teams (
  2  staff_id number,
  3  team_members varchar2(255));

Table created.

which contained a field, TEAM_MEMBERS, which contained a comma-delimited list of team members who reported to a particular staff ID.

SQL> insert into staff_teams values (1,'Mark,Sonia,Jon,Pete');

1 row created.

SQL> insert into staff_teams values (2,'Andrew,Julian,Keith,Mick,Dave');

1 row created.

SQL> commit;

Commit complete.

SQL> select * from staff_teams;

  STAFF_ID TEAM_MEMBERS
---------- ------------------------------
         1 Mark,Sonia,Jon,Pete
         2 Andrew,Julian,Keith,Mick,Dave

2 rows selected.

What the client wanted to do was to process this delimited list of team members into separate team member records in a target table called STAFF_MEMBER_BREAKDOWN, like this:

SQL> create table staff_member_breakdown (
  2  staff_id number,
  3  team_member_name varchar2(20));

Table created.

getting a result that looked like this:

SQL> select * from staff_member_breakdown;

  STAFF_ID TEAM_MEMBER_NAME
---------- --------------------
         1 Mark
         1 Sonia
         1 Jon
         1 Pete
         2 Andrew
         2 Julian
         2 Keith
         2 Mick
         2 Dave

9 rows selected.

Now to me, this looked like the classic use of a table function - a special kind of Oracle function that generates a table of data as its output. Table functions are particularly useful for ETL work as they can optionally take a REF CURSOR as input, meaning that you can pass the results of a SELECT statement to it as input, it then processes it and spits out another table of data as output. In our case, we would use a SELECT statement to select against the STAFF_TEAMS table, pass the results on to a table function which would parse the comma delimited list of people, then pass out as output a table of staff IDs and individual team members.

OWB10gR1 supports table functions as mapping operators, although the support is fairly basic in this version. You actually have to define the table function, and any supporting TYPEs, outside of OWB and then reference them within the mapping. So, the first thing to do then is to define a record type, then a table type based on this record type, for my function to use as it's output datatype.

SQL> create or replace type staff_member_breakdown_record is object
  2  ( staff_id number,
  3    team_member_name varchar2(20));
  4  /

Type created.

SQL> create or replace type staff_member_breakdown_table
  2  is table of staff_member_breakdown_record;
  3  /

Type created.

Now, I need to define a little package that will just hold a REF CURSOR type that I'll use in the function.

SQL> create or replace package refcur_pkg
  2  as
  3  type staff_teams_cur_type is ref cursor;
  4  end refcur_pkg;
  5  /

Package created.

Now I can create the table function to do the parsing. Note the use of the DBMS_UTILITY.COMMA_TO_TABLE function - thanks to Prasad from work for pointing this one out.

(

UPDATE 20.10.05

SQL> create or replace function parse_teams 
  2   (staff_teams_cur refcur_pkg.staff_teams_cur_type)
  3  return staff_member_breakdown_table
  4  pipelined
  5  is
  6  c_string   VARCHAR2(250);
  7  cnt        BINARY_INTEGER;
  8  my_table   dbms_utility.uncl_array;
  9  v_staff_id   NUMBER;
 10  v_team_members  VARCHAR2(255);
 11  
 12  begin
 13  
 14    loop
 15    
 16    fetch staff_teams_cur into v_staff_id, v_team_members;
 17    exit when staff_teams_cur%notfound;
 18    
 19      dbms_utility.comma_to_table(v_team_members, cnt, my_table);
 20  
 21   for i in 1 .. my_table.count loop
 22  
 23   if my_table(i) is not null then
 24  
 25    pipe row (staff_member_breakdown_record(
 26     to_number(v_staff_id), my_table(i)));
 27  
 28   end if;
 29    
 30      end loop; 
 31    end loop;
 32  end parse_teams;
 33  /

Function created.

Now, to test it out, I can just run a SELECT statement against the source table and pipe the results through the table function.

SQL> select * from table(parse_teams(cursor(select * from staff_teams)));

  STAFF_ID TEAM_MEMBER_NAME
---------- --------------------
         1 Mark
         1 Sonia
         1 Jon
         1 Pete
         2 Andrew
         2 Julian
         2 Keith
         2 Mick
         2 Dave

9 rows selected.

Good stuff. The next step is to create an OWB target module, import in the two tables (but not the function we've just created), then create a mapping. Drop on the source and target tables, and then a table function operator from the mapping toolbox. Right-click on the table function's INGRP1 group ...

and then make sure REF CURSOR is specified as the input parameter.

Next, drag the INOUTGRP1 group from the source table to the INGRP1 input group for the table function, and then define the two output attributes which you then map to the corresponding target table columns.

Finally, right-click on the table function, select Operator Properties, and enter the name of the table function

Next, deploy the mapping as normal using the Deployment Manager, and then execute the package to run the mapping. If you've done it all correctly, you should get something like this:

Then, just to double-check:

SQL> select * from staff_member_breakdown;

  STAFF_ID TEAM_MEMBER_NAME
---------- --------------------
         1 Mark
         1 Sonia
         1 Jon
         1 Pete
         2 Andrew
         2 Julian
         2 Keith
         2 Mick
         2 Dave

9 rows selected.

So there you go. We've used a table function to parse some comma delimited strings, and embedded it in an OWB mapping to make it a bit more manageable. OWB "Paris" will make the handling of table functions a bit easier, as you'll be able to define them within the tool itself rather than using TOAD or SQL*Plus.