The CORR Procedure
- Overview
- Getting Started
-
Syntax
-
DetailsPearson Product-Moment CorrelationSpearman Rank-Order CorrelationKendall’s Tau-b Correlation CoefficientHoeffding Dependence CoefficientPartial CorrelationFisher’s z TransformationPolychoric CorrelationPolyserial CorrelationCronbach’s Coefficient AlphaConfidence and Prediction EllipsesMissing ValuesIn-Database ComputationOutput TablesOutput Data SetsODS Table NamesODS Graphics
-
ExamplesComputing Four Measures of AssociationComputing Correlations between Two Sets of VariablesAnalysis Using Fisher’s z TransformationApplications of Fisher’s z TransformationComputing Polyserial CorrelationsComputing Cronbach’s Coefficient AlphaSaving Correlations in an Output Data SetCreating Scatter PlotsComputing Partial Correlations
- References
The CORR procedure can use in-database computation to compute univariate statistics and the SSCP matrix if the DATA= input data set is stored as a table in a database management system (DBMS). When the CORR procedure performs in-database computation for the DATA= data set, the procedure generates an SQL query that computes summary tables of univariate statistics and the SSCP matrix. The query is passed to the DBMS and executed in-database. The results of the query are then passed back to the SAS System and transmitted to PROC CORR. The CORR procedure then uses these summary tables to perform the remaining tasks (such as producing the correlation and covariance matrices) in the usual way (out of the database).
In-database computation can provide the advantages of faster processing and reduced data transfer between the database and SAS software. For information about in-database computation, see the section “In-Database Procedures” in SAS/ACCESS for Relational Databases: Reference Instead of transferring the entire data set over the network between the database and SAS software, the in-database method transfers only the summary tables. This can substantially reduce processing time when the dimensions of the summary tables (in terms of rows and columns) are much smaller than the dimensions of the entire database table (in terms of individual observations). Additionally, in-database summarization uses efficient parallel processing, which can also provide performance advantages.
By default, PROC CORR uses in-database computation when possible. If in-database computation is used, the EXCLNPWGT option is activated to exclude observations with nonpositive weights. The ID statement requires row-level access and therefore cannot be used in-database. In addition, the HOEFFDING, KENDALL, SPEARMAN, OUTH=, OUTK=, OUTS=, and PLOTS= options also require row-level access and cannot be used in-database.
In-database computation is controlled by the SQLGENERATION option, which you can specify in either a LIBNAME statement or an OPTIONS statement. See the section “In-Database Procedures” in SAS/ACCESS for Relational Databases: Reference for details about the SQLGENERATION option and other options that affect in-database computation. There are no CORR procedure options that control in-database computation.
The order of observations is not inherently defined for DBMS tables. The following options relate to the order of observations and therefore should not be specified for PROC CORR in-database computation:
-
If you specify the FIRSTOBS= or OBS= data set option, PROC CORR does not perform in-database computation.
-
If you specify the NOTSORTED option in the BY statement, PROC CORR in-database computation ignores it and uses the default ASCENDING order for BY variables.
Note: In-database computing in the CORR procedure requires installation of the SAS Analytics Accelerator.