Fuente
Si cuando una operación consiste en una serie de pasos, bien todos ellos se ejecutan o bien ninguno, es decir, las transacciones son completas.
Es la propiedad que asegura que sólo se empieza aquello que se puede acabar. Por lo tanto se ejecutan aquellas operaciones que no van a romper las reglas y directrices de Integridad de la base de datos.
Esta propiedad asegura que una operación no puede afectar a otras.
Esta propiedad asegura que una vez realizada la operación, ésta persistirá y no se podrá deshacer aunque falle el sistema.
Fuente:
In [1]:
options(repos = "https://cloud.r-project.org") # Definimos repositorio
if (!require("pacman")) install.packages("pacman") # Si no tenemos, pacman, lo instalamos
In [2]:
pacman::p_load(dplyr, # librería para manipular datos
RSQLite, # librería para acceder a SQLite
nycflights13) # data for all, 336776, flights departing NYC in 2013
In [18]:
my_db <- src_sqlite("my_db.sqlite3", create = T) # just give the path and the ok to create a table.
Ahora, copiaremos los datos mediante:
copy_to()
El uso de esta función no es recomendable con grandes conjuntos de datos.
In [20]:
flights_sqlite <- copy_to(my_db, # destino
flights, # DF de origen
temporary = FALSE, # hacemos nuestro objeto no temporal
indexes = # Generamos el "index" para acelerar análisis
list(c("year", "month", "day"),
"carrier", "tailnum"))
In [22]:
flights_sqlite <- tbl(nycflights13_sqlite(), "flights") # Caching nycflights db
In [24]:
explain(flights_sqlite)
In [25]:
tbl(my_db, sql("SELECT * FROM flights")) # Probemos a ejecutar la búsqueda con SQL...
In [26]:
select(flights_sqlite, # los datos
year:day, # seleccionamos desde la columna 'year', hasta 'day'
dep_delay, # también 'dep_delay'
arr_delay) # y 'arr_delay'
In [27]:
filter(flights_sqlite, # los datos
dep_delay > 240) # seleccionamos un retraso mayor a 240...
In [30]:
arrange(flights_sqlite, # los datos
year, month, day) # las columnas
In [31]:
mutate(flights_sqlite, # los datos
speed = air_time / distance) # agregamos la columna 'speed'
In [32]:
summarise(flights_sqlite, # los datos
delay = mean(dep_time)) # la función a aplicar, mean()
When working with databases, dplyr tries to be as lazy as possible:
For example, take the following code:
In [13]:
c1 <- filter(flights_sqlite, year == 2013, month == 1, day == 1)
c2 <- select(c1, year, month, day, carrier, dep_delay, air_time, distance)
c3 <- mutate(c2, speed = distance / air_time * 60)
c4 <- arrange(c3, year, month, day, carrier)
Suprisingly, this sequence of operations never actually touches the database. It’s not until you ask for the data (e.g. by printing c4) that dplyr generates the SQL and requests the results from the database. Even then it only pulls down 10 rows.
In [14]:
c4
To pull down all the results use collect(), which returns a tbl_df():
In [15]:
collect(c4)
You can see the query dplyr has generated by looking at the query component of the object:
In [16]:
c4$query
You can also ask the database how it plans to execute the query with explain(). The output for SQLite is described in more detail on the SQLite website. It’s helpful if you’re trying to figure out which indexes are being used.
In [17]:
explain(c4)