SAS9

Entender la jerarquía de la ordenación multinivel con PROC SORT

Simon 6 vistas

Uno de los primeros comandos que se aprenden en la programación SAS© es el PROC SORT. Aunque su uso parece trivial para una sola variable, los resultados a veces pueden confundir a los usuarios cuando se trata de aplicar una ordenación con tres o más criterios.

Una confusión frecuente surge cuando se intenta ordenar una tabla según una lógica compleja, por ejemplo: por ciudad (ascendente), luego por deuda (descendente), y finalmente por número de cuenta (ascendente). Al inspeccionar el resultado, a menudo sucede que la última variable (el número de cuenta) parece estar completamente desordenada.

¿Es un error de código? ¿Un bug de SAS©? No, es simplemente una mala interpretación de la lógica jerárquica de la ordenación.

Entender la jerarquía de la ordenación multinivel con PROC SORT -

El principio del "Tie-Breaker" (Desempate)

Para entender por qué su tercera variable no parece estar ordenada, debe visualizar la ordenación como una serie de filtros o muñecas rusas.

Cuando envía la siguiente instrucción:

Note :
PROC SORT data=ma_table;
BY town DESCENDING debt accountnumber;
RUN;

SAS© no intenta ordenar todas las columnas de forma independiente. Aplica una jerarquía estricta:

  1. Nivel 1 (Town): SAS© ordena primero todo el conjunto de datos por ciudad.

  2. Nivel 2 (Debt): La ordenación por deuda se activa solo dentro de los grupos donde la ciudad es idéntica. Es un criterio de desempate.

  3. Nivel 3 (AccountNumber): Esta ordenación solo se vuelve visible y efectiva solo si los dos primeros criterios (Ciudad Y Deuda) son estrictamente idénticos para varias observaciones.

La ilusión del desorden

El problema de percepción proviene del hecho de que, en muchos conjuntos de datos reales, la combinación de las dos primeras variables suele ser única.

Imagine una fila donde la ciudad es "París" y la deuda es "500". Si no hay ninguna otra fila con exactamente "París" y "500", la ordenación por número de cuenta nunca tiene la oportunidad de aplicarse. Por lo tanto, el número de cuenta aparecerá en la posición determinada únicamente por los dos primeros criterios. Si mira la columna accountnumber de arriba a abajo sin tener en cuenta las demás, parecerá aleatoria.

Un ejemplo concreto

Tomemos un caso específico para ilustrar este funcionamiento. Supongamos que tenemos varias observaciones, pero que la ordenación por número de cuenta solo es efectiva para un subgrupo específico:

  • Grupo A (Town='Apex', Debt=50.00): Una sola fila. El número de cuenta se muestra tal cual.

  • Grupo B (Town='Apex', Debt=37.95): Existen tres filas con estos valores exactos.

  • Grupo C (Town='Boston', Debt=100.00): Una sola fila.

En este escenario, la ordenación del número de cuenta (tercera variable) solo será visible para el Grupo B. Si los números de cuenta para este grupo son 3131, 5108 y 9923, aparecerán en este orden ascendente.

Sin embargo, si compara visualmente el número de cuenta del Grupo A con el del Grupo B, no habrá ninguna lógica de ordenación aparente entre ellos, ya que la jerarquía superior (la Deuda) ha prevalecido.

Si su tercera variable de ordenación parece desordenada, revise sus datos. Es muy probable que tenga muy pocos duplicados en la combinación de las dos primeras variables.

La ordenación funciona correctamente, pero su efecto está "oculto" por la alta cardinalidad de los criterios anteriores. La ordenación por la variable n solo es útil para desempatar los empates de las variables 1 a n-1.