A Better Perspective of SASHELP Views

Transcription

1 Paper PO11 A Better Perspective of SASHELP Views John R. Gerlach, Independent Consultant; Hamilton, NJ Abstract SASHELP views provide a means to access all kinds of information about a SAS session. In fact, since their inclusion into SAS Version 6, these views, which utilize Dictionary tables, have become a very important aspect of any serious SAS application. And, not surprisingly, Version 9.0 greatly expands the collection of these meta-data, putting SAS on par with relational database environments. Unfortunately, this powerful font of dynamic information is not well understood nor often used, and even less appreciated. Perhaps if the views were conveyed in a relational context, rather than as discrete entities, the user might understand them better. Specifically, to address the question: How are SASHELP views related to each other and, even, to Dictionary tables? Not just as queries and data objects, but as relational entities. However, this approach requires the use of meta-data about meta-data. This paper explains SAS code that shows how to develop relational schemas about these views with the intent to attain a much better perspective of SASHELP views. Introduction SASHELP views are stored queries that access Dictionary tables, which are read-only objects that store dynamic information about a SAS session. These views are part of the SAS System and are stored in the SASHELP data library. Also, these same views can be used like any native query, unlike dictionary tables that are used only with PROC SQL. Since their introduction in Version 6, SASHELP views have become an important tool for SAS analysts who develop applications. Much of the information found in these data objects would be very difficult to obtain otherwise. Thus, it behooves the SAS professional to master this aspect of the SAS System. Before the advent of SASHELP views, it was possible to obtain meta-data by extracting pertinent information, for example, from the CONTENTS procedure. This older technique could be used to obtain the names of data sets in a data (e.g., WORK) library, as well as other useful information, such as: the name, data type, and length of variables, using the following code. proc contents data=work._all_ noprint out=meta(keep=memname name); To learn about SASHELP views, let s employ similar code, this time accessing only the views stored in the SASHELP data library, as follows. proc contents data=sashelp._all_ noprint out=views memtype=view; This time the result contains the names of all the views in the SASHELP library, along with their respective column names and other pertinent variables. A partial list follows. MEMNAME NAME TYPE LENGTH < Etc. > MLVIEW mldesc MLVIEW mlname 2 41 VCATALG alias 2 8 VCATALG created 1 8 VCATALG libname 2 8 VCATALG memname 2 32 VCATALG memtype 2 8

2 : : : : : : : : : : VTABLE reqvector 2 24 VTABLE reuse 2 3 VTABLE typemem 2 8 VTITLE number 1 8 VTITLE text VTITLE type 2 1 VVIEW engine 2 8 VVIEW libname 2 8 VVIEW memname 2 32 VVIEW memtype 2 8 Thus, it s easy to obtain the names of SASHELP views, as well as lots of other information. That s a good start to understanding these data objects; however, it would be nice to know the following: What is the relationship between two or more SASHELP views? What is the relationship between two or more SASHELP views and two or more Dictionary tables? These two questions pose an interesting problem in data processing, that is, to obtain meta-data about objects that represent meta-data. The desired report is in essence a relational schema about these objects. Keep in mind that these data objects do not contain data. Rather, these objects contain information about data; nonetheless, we need to process the data as if they were data sets. The desired report shows the collection of variables listed along with the other columns indicating the views, such that an asterisk indicates that the variable exists in the respective view, and a dash indicates otherwise. Below is an abstract of what the report would look like, which serves as a relational schema. NAME VIEW1 VIEW2 VIEW3 <Etc.> Var1 - * * Var2 * * - Var3 * * - : : : : Varn * - * For example, the following report shows the relationship between the SASHELP views: VTABLE, VSTABLE, and VSTABVW. Besides listing all the variable names found in the several views, it becomes readily apparent how these views are related. In fact, except for the variables LIBNAME and MEMNAME, these particular views have little in common. Despite their limited similar traits, certainly, one s understanding of these views is enhanced. NAME vtable vstable vstabvw bufsize * compress * crdate * datarep * delobs * encrypt * indxtype * libname * * * memlabel * memname * * * memtype * * modate * nobs *

3 : : : : : : : : npage * nvar * obslen * pcompress * protect * reqvector * reuse * typemem * As expressed earlier, the creation of the report above is not as easy as one might think. The problem is that you must collect meta-data on views that represent meta-data about a SAS session. Actually, the problem is solved handily, but only because of a simple idea that facilitates the acquisition of the meta-data. The Problem & Solution How do you obtain meta-data from a SASHELP view or a Dictionary table with the intent to produce a relational schema, as shown above? Think about it. What happens when you use Dictionary tables or SASHELP views? Well, depending on the data object (e.g., VTABLE) and the WHERE clause, you might get a lot of information about your SAS session. But, ironically, you re not really interested in such information. The objective is to get the meta-data about those data objects in order to produce a report that shows the relationships between these objects, such as: VTABLE, VTABLE, and VSTABVW. To illustrate this point, consider the following SQL step. from dictionary.tables; Depending on the installation of SAS (and version), you will get a data set that contains a lot of information about the session; but not the meta-data, specifically, the names of the columns, such as: LIBNAME, MEMNAME, etc., found in the TABLES Dictionary table. The column names are needed to determine the relationships between the several data objects. But, how do you get them? Since Dictionary tables are accessible only via the SQL procedure, let s consider using the INOBS=0 option, as follows. Consequently, you get a data set that contains zero observations and the appropriate variables. But, it generates a warning message indicating that the statement terminated early. proc sql inobs=0; from dictionary.tables; An alternative solution is to use the OBS option of the OPTIONS statement prior to the SQL step, as follows. from dictionary.tables; Once the meta data is obtained, the next step is to use the CONTENTS (the old method) or the SQL procedure, to generate a data set that contains the meta data. Keep in mind that the data set META_DATA contains zero observations. Also, keep in mind that the OBS options must be reset to MAX. Consider the following code employing the old technique.

4 proc contents data=meta_data out=meta_data noprint; And, the more modern code using SQL. Another Schema select name from dictionary.columns where libname eq WORK and memname eq META_DATA ; To increase our understanding of how Dictionary tables and SASHELP views are related, the following code utilizes TABLES and MEMBERS Dictionary tables, along with the VTABLE and VSTABLE views. Notice that the OPTIONS statement is used before and after the SQL step. Why? Because we re interested only in the meta-data; we don t want the code to rummage through the SAS session looking for instances of the meta-data. Rather, we wish to discern only the relationships between the sources of meta-data (e.g., MEMBERS and VSTABLE). In other words, at this point, we want data sets that contain zero observations and n-variables. create table tables as from dictionary.tables; create table members as from dictionary.members; create table vtable as from sashelp.vtable; create table vstable as from sashelp.vstable; However, after obtaining the meta data, the CONTENTS procedure, for example, can be used to process the four output empty data sets, thereby creating new data sets that contain an observation for each variable; thus the OBS option needs to be reset to MAX. Consequently, the new data sets can be merged via a Data step in order to produce the target data set, that is, the relational schema. Consider the following utility macro that generates the data sets that contain the column names, using the SQL procedure rather than use the CONTENTS procedure. The single input argument of the macro is the full name of a Dictionary table or a SASHELP view, and the output table is the name of that table or view. The macro contains two SQL statements: one that creates an empty data set from the query using the Dictionary table or SASHELP view, and the other statement creates the non-empty data set that contains one observation per variable found in the empty data set. %macro metadata(item); proc sql noprint; create table %scan(&item.,2) as from &item.;

5 create table %scan(&item.,2) as select name from dictionary.columns where libname eq 'WORK' and memname eq "%upcase(%scan(&item.,2))"; %mend metadata; %metadata(dictionary.members) %metadata(sashelp.vtable) After executing the %metadata macro twice, observe the SASLOG below. Notice that the data set MEMBERS and VTABLE contains zero observations, initially. Then, it contains six and twenty-one observations, respectively, denoting the number of variables in each data set. NOTE: Table WORK.MEMBERS created, with 0 rows and 6 columns. NOTE: Table WORK.MEMBERS created, with 6 rows and 1 columns. NOTE: PROCEDURE SQL used: real time cpu time NOTE: Table WORK.VTABLE created, with 0 rows and 21 columns. NOTE: Table WORK.VTABLE created, with 21 rows and 1 columns. NOTE: PROCEDURE SQL used: real time cpu time Notice that the second query inside the %metadata macro always uses the COLUMNS Dictionary table, which is the method used to obtain the meta-data on the empty data set, specifically the column names. Rather than use the COLUMNS Dictionary table, the CONTENTS procedure could have been used to achieve the same objective, as follows. proc contents data=vtable out=vtable(keep=name) noprint; proc contents data=vstable out=vstable(keep=name) noprint; Assume that the %metadata macro was executed on the Dictionary tables called TABLES and MEMBERS, and on the SASHELP views VTABLE and VSTABLE. The result would be four like-named data set each containing their respective variable (column) names. Let s merge these data set using the IN= data set option. The merge process gives us the union of all variables in the several data sets and the IN= data set option creates numeric flag variables that signify whether the variable exists in the respective data set. The result is a data set that contains the relational schema, as shown below. data rep; merge tables(in=d1) members(in=d2) vtable(in=d3) vstable(in=d4); by name; if d1 then tables = '*'; if d2 then members = '*'; if d3 then vtable = '*'; if d4 then vstable = '*';

6 COLUMN TABLES MEMBERS VTABLE VSTABLE bufsize * * compress * * crdate * * datarep * * delobs * * encrypt * * engine * index * indxtype * * libname * * * * memlabel * * memname * * * * memtype * * * modate * * nobs * * npage * * nvar * * obslen * * path * pcompress * * protect * * reqvector * * reuse * * typemem * * From the schema above, we notice that the Dictionary table TABLES and the SASHELP view VTABLE contain the same information. Notice also that the VSTABLE view contains only two columns: the library reference (LIBNAME) and the member name (MEMNAME). Generating a Full Relational Schema How do all the SASHELP views relate to each other? That is, how do you create a schema of all SASHELP views? Well, first we need to identify them and determine how many there are. Using the TABLES Dictionary table, the following SQL step easily identifies all SASHELP views and stores them in macro variables. This same information can be obtained by using the VIEWS Dictionary table, too. proc sql noprint; select left(put(count(memname),2.)) into :nviews from dictionary.tables where libname eq SASHELP and memtype eq VIEW ; select memname into :view1 :view&nviews. from dictionary.tables where libname eq SASHELP and memtype eq VIEW ; Once the macro variables (&nviews, &view1, ) exist, then the following macro, %viewmap, processes each view, and afterwards, merges the collection of data sets containing the meta-data producing a single data set that represents the schema. Try it. It works. %macro viewmap; %do i = 1 %to &nviews.; create table &&view&i.. as from sashelp.&&view&i..;

7 proc contents data=&&view&i.. out=&&view&i.(keep=name) noprint; %end; data rep; merge %do i = 1 %to &nviews.; &&view&i..(in=d&i.) %end; ; by name; %do i = 1 %to &nviews.; if d&i. then &&view&i.. = '*'; else &&view&i.. = '-'; %end; %mend viewmap; Conclusion This exercise affords a great opportunity to develop a better understanding of SASHELP views and Dictionary tables by understanding how these meta-data are related to each other. Author Information John R. Gerlach Independent Consultant Hamilton, NJ SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks or SAS Institute Inc. in the USA and other countries. indicates USA registration.