[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
Re: st: SAS
"David Elliott" <email@example.com>
Re: st: SAS
Tue, 4 Dec 2007 09:58:24 -0400
I work in a department that does analysis on health data from a number
of different sources - pure administrative data from physician,
dentist and pharmacist claims; hospital discharge abstract data;
survey data; vital statistics and numerous other data sources
associated with special programs (diabetes, perinatal, cancer...).
Many of these are built on RDBMS platforms, usually Oracle.
Traditionally, we have used a frontend like Cognos Impromptu to
generate and execute the SQL needed to extract information, or have
used other tools, including Stata's -odbc- commands to execute remote
SAS Enterprise offers an ETL (Extract Transform Load) process to do
the initial dataload and can then be scripted to do periodic updates.
The loaded data is partially denormalized and optimized for query
processing. (Data structures may be quite different between the
system optimized (heavily normalized) for transactional processing
versus those optimized for queries) There is also the potential to
create metadata for all tables and fields in the data repository,
critically important when you have a diverse range of data sources
(and a regrettable turnover in data analysts). This is a whole
different cat than desktop SAS, although the average desktop user may
not notice a great deal of difference while working with base SAS
modules. For those of us concerned with the "back-office" components,
they give a great deal of control, including security, that is very
important in our environment.
Having said all this, I still plan to use Stata for rapid prototyping
of new routines. I can quite often work out the logic and get results
in Stata in a couple of hours and then hand it over one of our SAS
programmers to duplicate in a couple of weeks ;-)
* For searches and help try: