Hi, in my experience, data dictionaries were what I built when I was working with ADABAS (Software AG) or DB2 (IBM) -- data base systems in which the data dictionary was maintained and defined for the database system by someone called a DBA -- or data base administrator.
If we had a bunch of ad-hoc reports with the data in VSAM files and SAS data sets and sequential files, then I sometimes I had to map my columns or variables in those files to their corresponding matches in the data dictionary or, sometimes (most likely) there was no mapping -- which is why I was using them for ad-hoc access. If I worked in a shop where I had DB2, then there was one data dictionary for DB2. If I also had Oracle, then we might have a separate data dictionary for Oracle.
Every once in a while, somebody would rumble about have a corporate wide data dictionary and identifying all the data sources and we used to do HIPO charts or CASE charts to map the disparate data sources into one monster data dictionary -- but over time, as things changed, the last thing that changed was the documentation for the various systems.
I believe that in the strictest sense of the usage, a data dictionary is tied to a specific data base and each data base has its own way of using the data dictionary.
In some senses, the metadata that you are defining for your tables in the BI Platform represents the kind of "metadata" data dictionary that your boss wants to have.The big advantage of using Data Integration Studio or otherwise defining your tables and files in the metadata is that you can have disparate data sources, such as DB2 and Oracle and flat files all being used in your BI system and you essentially define that kind of metadata (about whether the columns are character or numeric, what format they should have, what transformations those columns need to undergo all in one place) for every data source you have.
In addition, the Metadata server contains information about user access and restrictions for each table, for columns within tables and even for rows within tables. When you define information maps, you are able to provide your users with a "friendlier" view of the data. Let's imagine that you have a list of orders that have an order number. Each item is provided by a vendor. It's inefficient to keep the vendor name and address in the order file. But, there may be somebody who is dealing with returned items, where they need to access both the item number of the returned item AND the vendor name and vendor address who provided the item. Should that person need to know about doing an SQL join of the returned items with the order file and the vendor file in order to get data in the right structure they want??? Probably not. You can build an information map for the person handling returns so the join is transparent to them -- they could open the information map in Excel or in Word and then the fact that a join is taking place is defined in the information map.
What I'm trying to say is that I think the SAS Metadata server is like having a super-charged data dictionary. For information on how to document your metadata or print out information from the metadata repository (which is what I think you're asking for), you should consult the Platform Administration documentation. Since everything in the BI Platform is stored in the metadata repository, that should be the first place you look. SAS Data Integration Studio does have a way to do impact analysis, again, the DI Studio documentation can be useful to you.
cynthia
