Using the INFOMAPS LIBNAME Engine
SAS Customer Intelligence Studio uses an information map to access the data used in designing campaigns. On many sites, this is the only way the information map is ever used – which is a shame. SAS provides an INFOMAPS libname engine which enables ordinary SAS code to read data using the information map. However, some care is needed to avoid such code being inefficient.
libname mymaps infomaps '/Shared Data/Campaign Managament/ Information Maps';
This statement assigns an INFOMAPS library. It’s an unusual sort of library, in that the aggregate storage location it points to is a metadata folder – information maps themselves being metadata objects. Each information map within the folder can be treated, for most purposes, as if it were a data set e.g. when using Proc DATASETS or Proc CONTENTS. An information map is sometimes described informally as a “posh view”.
There are dictionary tables specific to information maps, called INFOMAPS, DATAITEMS and FILTERS. The DATAITEMS table can be useful, for example, in a situation – which can easily arise when an information map is large – where one has forgotten which information map folder a particular data item is in. For example, suppose we have mislaid the postcode data item in an information map called BobInfoMap, which is in an assigned INFOMAPS library:
proc sql; dataitemname, path from dictionary.dataitems where upcase (memname)='BOPINFOMAP' and upcase (dataitemname) like '%POST%'; quit;
The PATH column will give the name of the information map folder which contains each data item that has POST in its name.
The FILTERS table is important, or at any rate the filters listed in it are important. Querying the FILTERS dictionary table will show what filters are available.
proc sql; select filtername, description from dictionary.filters where upcase(memname)='BOBINFOMAP'; quit;
In this case the output shows that a single filter has been defined for the specified information map:
This filter has been defined in Information Map Studio:
It can now be used in conjunction with the FILTER data set option, which is available when reading data from an information map. For example:
proc sql; select count (*) from mymaps.BobInfoMap (filter='Oldies_Filter'); quit
This is a great deal more efficient than the naïve:
proc sql; select count (*) from mymaps.BobInfoMap where age > 70; quit;
The point is that such a WHERE clause (or a WHERE data set option) could not be handled within the information map. This query would result in all the data being passed from the information map to SAS, with SAS then applying the WHERE clause for itself. By contrast, a filter can be applied by the information map, with only the selected records being passed into SAS. The catch, of course, is that all the filters you are likely to need must already have been defined in the information map.
A related issue is that, in most cases, sorting and BY-group processing cannot be handled within the information map. This kind of thing has to be done once the data has been read into SAS.
NB Defining a filter as above does not mean that the filter will necessarily be applied when using the information map in CI Studio. If you have a filter that you do in fact want to always apply – for example, to prevent invalid data from reaching CI Studio – you can set it up as a pre-filter. To do this in Information Map Studio, define the filter in the usual way, and then edit the properties of the information map itself. The “General Prefilters” tab here will allow you to select, from among all the filters defined, which ones are always to be applied as pre-filters.