Cloud words con R. Trabajar con la API del Europe PMC con R

Hace años ya tuvimos nubes de palabras en el blog y ya era hora de ir actualizando algunas cosas. Y además quería aprovechar y presentaros un paquete de R que nos permite consultar la API del Europe PMC. Para quien no sepa que es el Europe PMC podemos decir que es un un buscador de documentos y artículos científicos (que ahora todo el mundo molón llama papers) y que tiene una API desde la que podemos acceder desde R mediante el paquete europepmc.

Obtener datos de la API de Europe PMC con R

El primer paso para trabajar con la librería de R europepmc sería obtener el número de artículos publicados con el topic “Autism” en su descripción, para ello podemos hacer:

#install.packages("europepmc")
library(dplyr)
library(ggplot2)
library(europepmc)

autismo <- epmc_hits_trend("Autism", period = 2000:2019, synonym = TRUE)
autismo
ggplot(autismo, aes(year,  query_hits)) + 
  geom_line() +
  xlab("Año de Publicación") + 
  ylab("Articulos publicados sobre Autismo")

La función del paquete de R europepmc epmc_hits_trend obtiene de un periodo dado el número de artículos y el número de artículos de un determinado tópico. Como vemos se está incrementando casi exponencialmente el número de artículos dedicados al Autismo en los últimos años, no es una tendencia particular, se está incrementando el número de papers (asco de término pero que tiene que aparecer para las búsquedas), estamos ante la “burbuja de los papers” ya que da mas notoriedad hacer mucho que hacer bien, ya se lo leerá una inteligencia artificial, en fin que me disperso. Pero la función que puede resultarnos más interesante es epmc_search que crea un data frame con las búsquedas de los artículos con su ISBN, fechas de referencia, autores,… nos va a servir para obtener unas nubes de palabras sobre los escritos acerca del autismo Seguir leyendo Cloud words con R. Trabajar con la API del Europe PMC con R

Gráficos de calendarios con series temporales

Cuando se realizan gráficos de series temporales se emplean gráficos de líneas donde el eje X contiene la fecha y el eje Y contiene el valor a representar. Hoy quiero traer al blog otra forma de representar series temporales, los gráficos de calendario y su realización con R. Para ilustrar el ejemplo vamos a emplear las cotizaciones históricas del índice bursatil IBEX35:

require(quantmod)
require(ggplot2)
require(reshape2)
require(dplyr)
library(lubridate)

# Obtenemos las cotizaciones del IBEX 35 desde 2010
getSymbols('^IBEX', from = '2010-01-01')

# data frame de trabajo
df<-data.frame(date=index(IBEX),IBEX)

Mediante quantmod extraemos las cotizaciones del IBEX desde 2010 y creamos un data frame de trabajo que llamamos df. Vamos a realizar dos tipos de gráficos, un mapa de calor por años, meses, semanas y días y un calendario de un año puntual.

Calendario como mapa de calor por

Este es un gráfico basado en un trabajo anterior (¡de 2012!) y es una forma imaginativa de representar el cierre del IBEX 35 desde 2010 en una sola imagen. El primer paso será crear las variables a representar en el mapa de calor, el mes, el día de la semana y la semana dentro del mes:

df <- df %>% mutate(año=year(date),
                    mes=factor(month(date),levels=(1:12),
                               labels = c("ENE","FEB","MAR","ABR","MAY","JUN","JUL",
                                              "AGO","SEP","OCT","NOV","DIC"),ordered = T),
                    dia=factor(wday(date)-1,levels=rev(1:7),
                          labels=rev(c("L","M","X","J","V","S","D"))),
                    semanames=ceiling(day(date) / 7))

Ahora sólo queda representar el gráfico mediante ggplot2 donde los paneles de facet_grid serán los años en eje X y los meses en eje Y:

# Realizamos el calendario
calendario1<- ggplot(df, aes(semanames, dia, fill = IBEX.Adjusted)) + 
  geom_tile(colour = "white") + facet_grid(año~mes) + 
  scale_fill_gradient(low = "red", high = "darkgreen", na.value = "black") +  
  labs(title="Cierre histórico del IBEX", x ="Semana del mes", y = "")
calendario1

Un gráfico que me gusta bastante y una original forma de representar series temporales muy largas, no he usado paletas de colores pero imagino que los resultados mejorarán, podéis aportar esas mejoras en los comentarios.

Calendario con openair y calendarPlot

Si deseamos representar un calendario de un año concreto tenemos la función calendarPlot de openair (que me ha costado instalar en Ubuntu) que no puede ser más sencilla:

library(openair)
calendarPlot(df, pollutant = "IBEX.Adjusted", year = 2019, cols = "Greens")

Este último calendario no lo he usado pero la sintaxis es muy sencilla y el resultado queda bastante bien. Ahora vosotros mismos podéis juzgar si hay o no hay rally de fin de año.

El análisis de supervivencia para segmentar el churn

El análisis de supervivencia es uno de los olvidados por el Machine Learning y la nueva forma de ver el oficio. A la regresión logística si la damos algo de recorrido porque aparece en scikit-learn (con sus cositas), sin embargo, el análisis de supervivencia no tiene ese cartel porque en el momento que trabajas con un gran número de variables estos modelos “empiezan a echar chispas”.  Sin embargo ofrecen una serie de gráficos y resultados que más allá de la estimación nos describen problemas y pueden servirnos para segmentar poblaciones en base a la duración hasta la ocurrencia de un evento.

El modelo de supervivencia tiene como variable fundamental el tiempo hasta que ocurre un evento y como este tiempo se modifica en base a unas variables explicativas, mas allá de una tasa nos puede permitir identificar segmentos y poblaciones con comportamientos distintos. El ejemplo que quiero mostraros es el paradigma de todo lo que estoy contando, identificar segmentos de clientes que abandonan mi compañía de telecomunicaciones, mas allá de priorizar clientes en base a su probabilidad de anulación tratamos de identificar características que hacen que mi cliente dure más o menos en la compañía.

El ejemplo que vamos a usar está sacado de este:

https://github.com/zangell44/survival-analysis-lifeline-basics/blob/master/customer_churn.ipynb

Tenéis la descripción de las variables, la más importante es tenure, tiempo en meses hasta que se produce el evento y churn que es el evento, la cancelación de la línea, el resto de variables son propias de la línea. En nuestro caso vamos a trabajar con R porque me parecen interesantes los objetos que generan algunas funciones. Leemos los datos y realizamos una pequeña transformación sobre la variable respuesta:

datos <- read.csv('https://raw.githubusercontent.com/treselle-systems/customer_churn_analysis/master/WA_Fn-UseC_-Telco-Customer-Churn.csv')

datos$Churn <- as.integer(ifelse(datos$Churn=="Yes",1,0))

Las librerías de R que vamos a usar son survival y survminer Seguir leyendo El análisis de supervivencia para segmentar el churn

Me rindo, es necesario trabajar en Agile

Imagen de previsualización de YouTube

“Agile sounds good” y representa todo eso que critico. Tenía compuesta y preparada una canción que versiona el “Me cago en el amor” de Tonino Carotone, “Me cago en el Agile” se llamaba. ¿Por qué este cambio de opinión tan radical?  Porque no se trabaja de forma horizontal, se trabaja de forma vertical y cada uno hace la guerra por su cuenta. Me voy a mi terreno Agile Analytics

Echamos y vendemos humo. Empecemos: arquitectos, ingenieros, científicos de datos,  analistas de negocio, diseñadores,…  y al final nos olvidamos que estamos ahí para ganar € o hacer ganar a nuestra organización €, €€€€€€ no estamos para conectar nodos edge, ingestar data lakes con millones de registros que nadie usa, diseñar algoritmos, crear contenedores, APIs, visualizaciones espectaculares, mapas interactivos, inteligencias artificiales, etecé, etecé. ¿Objetivo final del proyecto? ¿Cuántos € retorna? Bueno pues ha sido necesario de crear una parafernalia con pizarras y posit para que no nos desviemos de esos objetivos y que en último término sean capaces de medir cuantos € supone cada proyecto. Si todos los implicados en un proyecto trabajaran de forma conjunta, ¿serían necesarias estas figuras? No, pero como eso no pasa, no es que sea necesario, es que se torna imprescindible trabajar en Agile.

Me gustaría plantear una visión distinta de las personas y los roles dentro de un proyecto analítico:

  • Jefe de proyecto (project manager sounds better). Esto ni Agile, ni cascadas, hace falta alguien que se las lleve y que reparta, no queda más remedio. Es muy importante su rol en la documentación y entregables de resultados.
  • Científico, ingeniero o arquitecto de soluciones. Al final son los que trabajan tutelados por un jefe de proyecto.
  • Sponsor de negocio. Este es el que plantea el caso de negocio,  el que pone en marcha toda la maquinaria para plantear un proyecto.
  • Usuario de negocio. Persona que en último término va a usar las herramientas que estén desarrollando y el que tiene un problema que la analítica puede resolver. La línea entre sponsor y usuario es fina.
  • Product Owner (la prefiero en english). Esta figura es la clave porque es la verdadera figura horizontal a las anteriores, rol multidisciplinar tiene que entender el lenguaje de todas las personas implicadas y velar por la correcta administración del proyecto, el que se traga la correcta documentación e imputación de las tareas, que si el resto lo hiciera bien no sería necesario. Junto con el jefe de proyecto cuida del cumplimiento de los objetivos a corto plazo.
  • Scrum máster. Es la persona encargada de que todo lo anterior se lleve a cabo y para ello dispone de una serie de ceremonias y de ritos ridículos pero que sin ellos todas las figuras anteriormente citadas harían lo que les viene en gana. Tiene una tarea de interlocución a más alto nivel en la organización muy importante ya que en el caso de producirse retrasos, problemas o impedimentos en el desarrollo de los proyectos debe ser capaz de eliminar esos problemas. También mide junto con negocio y dirección cual es el impacto económico de los proyectos llevados a cabo.

Esta es mi visión de un proyecto en Agile Analytics y alguno llevo encima (con cierto éxito).  No entro en las ceremonias, que tienen su pena y su gloria también pero obligan a que todos los elementos participantes de un proyecto se reúnan, se escriban actas y se gestionen tareas. Si alguien quiere hablaré sobre ellas.

Ahora bien, hace 20 años yo trabajaba sentado con Ana (de Negocio), tenía 2 pcs porque con uno ejecutaba Business Object y si no me salía la cucaracha con el otro realizaba los análisis con Access/Excel. Vale que vendíamos politonos, paquetes de SMS y móviles de concha pero no era necesaria toda esta parafernalia y éramos 2. Podemos opinar sobre la complejidad de los problemas de negocio actuales, la información disponible o el entorno competitivo son argumentos para trabajar de este modo, pero en mi opinión el problema está en la lejanía y la especialización.  Al final no salían las cosas, así que algunos listos han vestido de metodología (que poco me gusta esta palabra) el sentido común y han dado una solución a este problema y con un halo marketiniano muy molón que llamamos Agile. A todo esto la mayor beneficiada ha sido 3M que en 2018 estaba en máximos de cotización, creo que ahora está cayendo un poco quizá haya vuelto el sentido común, no creo, hasta yo me he rendido.

Obteniendo los parámetros de mi modelo GAM

Vimos como los modelos GAM iban más allá del GLM porque en el momento de obtener los parámetros asociados al modelo de un factor nos proponían, en vez de una función lineal una función de suavizado no paramétrica para aquellos factores susceptibles de transformar en variables numéricas ordinales con un sentido determinado. Se trabajó con un modelo de riesgo con una sola variable como era la edad y al sumarizar el modelo no era posible obtener los parámetros en la salida. En último término nuestra intención con este tipo de modelos es obtener esos parámetros para transformarlos en relatividades. Qué sentido tiene obtener un buen modelo para Negocio si su resultado no se puede expresar en términos de incrementos o descuentos, en términos de relatividades.

La entrada del blog que ahora os propongo nos permite extraer los parámetros de cualquier modelo GLM o GAM a partir de la función predict y una de las opciones más olvidadas por todos nosotros:

predict(modelo, newdata = datos,  type = "terms")

con type = “terms” lo que obtenemos en el momento de realizar la predicción son los parámetros del modelo que aplicamos, no es el resultado de la predicción.

Obteniendo las relatividades de nuestro modelo GAM

Partimos del ejemplo que estamos manejando en la serie de entradas:

library(dplyr)

varib <- c(edad = 2L, sexo = 1L, zona = 1L, clase_moto = 1L, antveh = 2L,
           bonus = 1L, exposicion = 8L, nsin = 4L, impsin = 8L)

varib.classes <- c("integer", rep("factor", 3), "integer",
                   "factor", "numeric", rep("integer", 2))

con <- url("https://staff.math.su.se/esbj/GLMbook/mccase.txt")
moto <- read.fwf(con, widths = varib, header = FALSE,
                 col.names = names(varib),
                 colClasses = varib.classes,
                 na.strings = NULL, comment.char = "")


library(mgcv)

moto$edad_numero <- as.numeric(moto$edad)

gam.1 <- gam(nsin ~ s(edad_numero,bs="cr",k=3) + zona, data=filter(moto,exposicion>0), 
             offset = log(exposicion), family = poisson(link='log'))
summary(gam.1)

Ejecutad este código y obtendréis un modelo GAM con la zona por la que circula el riesgo y una función de suavizado de la edad del asegurado. A la hora de sumarizar el modelo para la edad, la variable suavizada, no vemos parámetros solo una función, si queremos obtener parámetros solo aparece la zona, ¿cómo puedo obtener las relatividades que me arroja este modelo? Empleando predict como se indicó con anterioridad:

terminos <- data.frame(exp(predict(gam.1, newdata = moto, type = "terms")))
names(terminos) <- c("rela_zona","rela_edad") 
terminos <- cbind.data.frame(terminos,select(moto,zona,edad))

Se crea el data.frame terminos que tiene el exponencial del parámetro asociado a ese registro para los factores participantes en el modelo. Cabe señalar que predict no respeta el orden de las variables en el modelo, primero pone las variables que no están suavizadas y después las suavizadas. Después de obtener los parámetros registro a registro lo que hacemos es añadir al data frame los factores de los que deseamos obtener las relatividades y como os podéis imaginar la tabla de relatividades finalmente es el resultado de seleccionar los distintos elementos:

rela_zona <- distinct(select(terminos,zona,rela_zona))
rela_edad <- distinct(select(terminos,edad,rela_edad))

Ya sabéis, no subestiméis a predict...
 

Modelos GAM con R. Dejando satisfechos a los equipos de negocio

Los modelos GAM (Generalized Additive Model) son el conjuntos de modelos que tenemos los estadísticos, actuarios, data scientist o como nos denominen en el momento que leas esto para dejar a nuestros equipos de negocio contentos con los resultados de nuestro modelo GLM. No voy a entrar en los aspectos teóricos de este tipo de modelos, hay documentación como esta que os puede ayudar. Por qué se quedan contentos los equipos de negocio, porque nos ayudan a dar sentido a los modelos. Retomemos un ejemplo que vimos en otra entrada del blog: https://analisisydecision.es/los-parametros-del-modelo-glm-como-relatividades-como-recargos-o-descuentos/ en esta entrada presentamos como el resultado de un modelo GLM se transforma en una relatividad, en un mecanismo para ofrecer recargos y descuentos.

Si desarrollamos un modelo GLM en último término podríamos enseñar este gráfico al responsable comercial:

Parece evidente que a mayor edad mayor proporción de siniestros, además, a partir de los 40 – 45 puede considerarse que las relatividades no varían. Se aprecian tendencias, pero no tiene sentido de negocio aplicar directamente los resultados de las estimaciones, no podemos aplicar esas relatividades obtenidas, es necesario realizar un suavizado y seguramente nos veríamos tentados, una vez hecho el modelo, de aplicar unos suavizados posteriores a la obtención de los parámetros. Podríamos hacer:

#g2 es el gráfico anterior obtenido en https://analisisydecision.es/los-parametros-del-modelo-glm-como-relatividades-como-recargos-o-descuentos/

spline_edad_factor < - smooth.spline(relatividades$rela,w=relatividades$exp,spar=0.65)
g2 + geom_line(aes(y=spline_edad_factor$y *5000), group=1, color="green",size=1.5)

Con smoot.spline hacemos una función de suavizado para nuestras relatividades, el nivel del suavizado lo controlamos con el parámetro spar que va desde 0 (sin suavizado) a 1 (función lineal). El caso es que el resultado de ese suavizado ya podría tener un mayor sentido de negocio y tendríamos más contentos a nuestro equipo comercial, pero... lo estamos haciendo a posteriori, eso no es una estimación, es echar balones fuera. Bien, qué os parece si tenemos un mecanismo para hacer una función previa a la estimación, pues este mecanismo se denomina modelo GAM y la librería de R que vamos a emplear para aproximarnos a ellos es mgcv. Vamos a replicar el modelo más básico con la edad del conductor. Seguir leyendo Modelos GAM con R. Dejando satisfechos a los equipos de negocio

Los parámetros del modelo GLM como relatividades, como recargos o descuentos

Los modelos GLM son muy empleados en el ámbito actuarial para la obtención de modelos de riesgo, estos modelos de riesgo son los elementos fundamentales en el cálculo de tarifas y qué es una tarifa, imaginad el precio del seguro de vuestra vivienda, bueno pues es un cálculo en el que partiendo de un precio base se van añadiendo recargos y descuentos en función del tipo de riesgo que se quiera asegurar (recargos y descuentos en función de los metros cuadrados, de la ubicación de la vivienda de las calidades de construcción….). Esta es una visión muy simplista porque al final se tienen múltiples garantías y es necesaria la combinación de garantías, pero se puede entender de ese modo, un precio base al que recargamos o descontamos precio. Estos recargos y descuentos se denominan frecuentemente relatividades y hoy quiero acercaros a la obtención de esas relatividades y como un modelo GLM se transforma en el precio de un seguro.

En la línea habitual del blog vamos a ilustrar con un ejemplo usando unos datos muy conocidos para el trabajo con GLM y modelos de cálculo de tarifas. El primer paso es cargar el conjunto de datos en nuestra sesión de R:

library(dplyr)

varib <- c(edad = 2L, sexo = 1L, zona = 1L, clase_moto = 1L, antveh = 2L,
           bonus = 1L, exposicion = 8L, nsin = 4L, impsin = 8L)

varib.classes <- c("integer", rep("factor", 3), "integer",
                   "factor", "numeric", rep("integer", 2))

con <- url("https://staff.math.su.se/esbj/GLMbook/mccase.txt")
moto <- read.fwf(con, widths = varib, header = FALSE,
                 col.names = names(varib),
                 colClasses = varib.classes,
                 na.strings = NULL, comment.char = "")

Los datos empleados pertenecen a una cartera de motocicletas, disponemos del número de siniestros (variable nsin), el importe de los siniestros (impsin), la exposición al riesgo de ese registro y una serie de factores que creemos pueden influir en la estimación del número de siniestros o del importe de los siniestros como son la edad, la zona, el nivel de bonificación,… Vamos a partir del modelo más sencillo, un modelo de frecuencia siniestral en base a un factor edad. Si realizamos con R un GLM clásico haríamos:

moto$edad_factor <- case_when(
  as.numeric(moto$edad) <=18 ~ 18, as.numeric(moto$edad) >=60 ~ 60,
  TRUE ~ as.numeric(moto$edad))

moto$edad_factor <- as.factor(moto$edad_factor)

glm.1 <- glm(nsin ~ edad_factor+offset(log(exposicion)), data=filter(moto,exposicion>0),
             family=poisson())
summary(glm.1)

Hemos creado un factor edad que va desde los 18 años hasta los 60, realizamos una regresión de poisson para estimar el número de siniestros, como al final lo que deseamos es crear una proporción de siniestros de la forma nsin/exposición (frecuencia siniestral) lo que hacemos es poner el nsin como variable dependiente y la exposición como variable offset, la única variable regresora es la edad en formato factor, con este modelo obtendremos un estimador para cada nivel del factor. Es un modelo aditivo de la forma log(Y) = B0 + Edad18*B1 + Edad19*B2 + … + log(exp) + Error pero si realizamos el exponencial de los parámetros obtenidos con el modelo tendremos E[Y/exp] = B’0 * Edad18*B’1 * Edad19*B`2 * … Es decir, el valor esperado para la frecuencia siniestral es función de unos parámetros que recargan o descuentan esa frecuencia esperada. Esos B’ que son el resultado de exp(B) es lo que denominamos relatividades. Esto es muy utilizado para la realización de modelos de riesgo en el cálculo de tarifas.

Obtención de las relatividades

Reiterando, el exponencial del parámetro obtenido con la formulación del modelo es lo que denominamos relatividad y esa relatividad multiplicada por un término independiente nos daría como resultado la estimación de la proporción de siniestros, la estimación de la frecuencia siniestral para cada nivel del factor. También es relevante estudiar y comprender como R presenta esos parámetros, si hacemos el exponencial de los parámetros del modelo glm.1 que hemos hecho tenemos:

data.frame(exp(glm.1$coefficients))
              exp.glm.1.coefficients.
(Intercept)                0.02986346
edad_factor19              0.48892314
edad_factor20              0.95974062
edad_factor21              0.73651804
….

¿Qué está pasando con la edad 18? Del término independiente pasa directamente a la edad 19 y de ahí hasta la edad 60, una estimación para cada nivel del factor a excepción del nivel 18. Bien, R considera al primer nivel del factor el nivel base, si lo vemos en forma de estimador un factor toma valor 1 si la observación está en ese nivel del factor y toma 0 si no lo está, pues si todos los estimadores presentes en el modelo toman el valor 0 el modelo estima que la proporción de siniestros en la edad 18 es de 0.02986, R no muestra ese estimador porque directamente no es necesario calcularlo, la edad 18 tiene una frecuencia siniestral del 3% Seguir leyendo Los parámetros del modelo GLM como relatividades, como recargos o descuentos

Abierto el plazo para la matrícula en el Máster en Big Data y Data Science de la UNED

Si estáis buscando formación dentro del ecosistema de Big Data y Ciencia de Datos os recomiendo este máster de la UNED:

https://www.masterbigdataonline.com/index.php/en-el-blog/185-master-en-big-data-y-data-science-de-la-uned-matricula-abierta

No sólo lo recomiendo por contenido y por el modo de impartir ese contenido. Recomiendo que os matriculéis en el módulo de seguros. Saludos.

De SQL Server a Python Pandas dataframe

Nueva duda que me han planteado, cómo pasar la extracción de una consulta en BBDD SQL server a un dataframe de pandas. Es sencillo, pero siempre tenemos que tener configurado el origen de datos ODBC, doy por sentado que esa tarea ya está hecha. El paquete que vamos a usar es pip install pyodbc y el ejemplo de uso es el siguiente:

import pyodbc 
import pandas as pd

conexion = pyodbc.connect('Driver={ODBC Driver SQL Server};'
                      'Server=SERVIDOR;'
                      'Trusted_Connection=yes;')

frase = "SELECT * from tabla where campo=1"
consulta= pd.read_sql_query(frase, conexion)
consulta.head()

Creamos una conexión al origen ODBC, os recomiendo que directamente vayáis a ODBC Data Sources y miréis la definición y vamos a tener una frase que será nuestra consulta, también es aconsejable que esa consulta la probéis previamente en SQL Server para asegurar su correcto funcionamiento. En pandas empleamos read_sql_query( consulta , conexión ) y ya disponemos de un data frame directamente de la extracción de SQL Server y podemos hacer con él el data management que necesitemos con pandas.

Parámetros en nuestra consulta SQL Server desde R. Truco R

Me han preguntado hoy como parametrizar una consulta de Sql Server desde R y la verdad es que es algo que me parecía muy sencillo y no me había planteado compartirlo. En mi caso suelo emplear la librería RODBC para acceder a Sql Server porque realizo las consultas vía ODBC, por este motivo lo primero debéis tener es configurado el origen de datos ODBC e instalada la librería RODBC en R. Para acceder vía R a los datos de Sql Server lo primero es crear la conexión a la BBDD:

conexion <- odbcConnect("ORIGEN_ODBC")

Ya estamos en disposición de realizar nuestras consultas sobre la BBDD de SQL Server, en R debemos ejecutar siempre:

objeto_r <- sqlQuery(conexion,"")

Con sqlQuery realizamos la consulta tal cual la realizaríamos en Sql Server y obtendremos el objeto en R o directamente puede salirnos en la consola. Recomiendo siempre cerrar las conexiones ODBC, R nos lo irá recordando de todas formas:

odbcCloseAll()

Con odbccloseAll cerramos todas las conexiones ODBC. Y si deseamos añadir parámetros a nuestra consulta desde R sólo tenemos que recordar que en sqlQuery metemos un texto por ello podremos hacer:

fecha <- '2019-08-01' 
conexion <- odbcConnect("ORIGEN_ODBC")
objeto_r <- sqlQuery(conexion,paste0("SELECT * FROM TABLA WHERE FECHA>", fecha ,"AND ESTADO='1'"))
odbcCloseAll()

En ocasiones realizamos consultas más complejas, yo suelo "jugar con frases" y directamente pasar a sqlQuery la frase. Truco sencillo.