CPP 526: Foundations of Data Science I

This lab demonstrates the process of joining two datasets through a merge() function. This is one of the most common and most important processes in data science, because it allows you to combine multiple datasets to link observations that pertain to the same individuals / cases. The deepest insights often come from bringing data together in this way.

We will use the following packages for the lab:

library( dplyr )

You can create a new R Markdown file, or download the LAB-06 RMD template:

Overview of Joins

Inner, Outer, Left and Right

There are two things to remember when conducting joins. The first is that when you merge two datasets it is rare for them both to contain the exact same observations. As a result, you need to make decisions about which data to keep and which data to drop post-merge. There are four options:

Keep everything: “Outer Join”
Keep only observations in both datasets: “Inner Join”
Keep all observations from dat1: “Left Join”
Keep all observations from dat2: “Right Join”

These options are specified through the all=, all.x=, and all.y= arguments in the merge() function, where the arguments all.x stands for observations in dat1, and all.y stands for observations in dat2 in this example.

And the equivalent operations in dplyr:

Compound IDs

It is often the case where a single ID does not unique specify observations needed to join data. For example, if you are looking at the relationship between employee eye color and their height, these are both variables that can only have one value per employee, so the employee ID would be sufficient to merge the eye color and height datasets.

If we want to look at the relationship between employee sick days in a given year and their performance, we now might have multiple years of data for each employee. To merge these two datasets we need to use both ID and YEAR. This is an example of a compound ID - two or more variables are needed to create a unique key for the join.

Consider an example where sales representatives get a bonus if they sell over $10,000 in subscriptions each year. We have one database generated by the sales department, and another generated by HR. We want to merge them to ensure bonuses have been properly issued. The data tables are structured as follows:

id	year	sales
A	2001	54000
A	2002	119000
B	2001	141000
B	2002	102000
C	2001	66000
C	2002	68000

id	year	bonus
A	2001	$0
A	2002	$10,000
B	2001	$10,000
B	2002	$10,000
C	2001	$0
C	2002	$0

The RIGHT way to merge these tables is to specify the set of IDs that allow you to indentify unique observations. The employee ID is not sufficient in this case because there are separate observations for each year. As a result,

merge( dat1, dat2, by=c("id","year") )         %>% pander()

id	year	sales	bonus
A	2001	54000	$0
A	2002	119000	$10,000
B	2001	141000	$10,000
B	2002	102000	$10,000
C	2001	66000	$0
C	2002	68000	$0

The WRONG way to merge these two datasets is to use only the employee ID. In this case, since the rows are now no longer unique, the only choice the merge() function has is to join EVERY instance on the right to each instance on the left. It has the effect of blowing up the size of the database (notice we have increased from 6 to 12 rows), as well as duplicating fields and incorrectly aligning data.

Row number 2, for example, reports that employee A received a bonus on $54,000 in sales.

merge( dat1, dat2, by="id" )         %>% pander()

id	year.x	sales	year.y	bonus
A	2001	54000	2001	$0
A	2001	54000	2002	$10,000
A	2002	119000	2001	$0
A	2002	119000	2002	$10,000
B	2001	141000	2001	$10,000
B	2001	141000	2002	$10,000
B	2002	102000	2001	$10,000
B	2002	102000	2002	$10,000
C	2001	66000	2001	$0
C	2001	66000	2002	$0
C	2002	68000	2001	$0
C	2002	68000	2002	$0

The solution is to ensure you are using the combination of keys that ensures each observation is correctly specified.

Merge Keys

Your “keys” are the shared IDs across your datasets used for the join. You can check for shared variable names by looking at the intersection of column names in both datasets:

intersect( names(dat1), names(dat2) )

## [1] "id"   "year"

This works when the datasets were generated from a common system that uses standardized and identical ID names. In other cases, the same key may be spelled differently (‘year’ vs. ‘YEAR’) or have completely different names.

The check above at least allows you to catch instances where variable names would be repeated, and thus duplicated in the merged file. When this happens, like the ‘year’ variable in the example above, the merge operation will add an ‘x’ and ‘y’ to the end of the variable names to specify which dataset they originated from (‘year.x’ and ‘year.y’ in the example above).

In instances where variable names differ, you can specify the names directly using “by.x=” and “by.y=”:

merge( dat1, dat2, by.x="fips", by.y="FIPS" )

In Summary

You will be using the merge() function in this lab to join datasets. You need to specify two arguments in each merge call.

merge( dat1, dat2, by="", all="" )

Your IDs used to join dataset:

Use “by=” when variable names are identical
Use “by.x=” and “by.y=” when the variable names are spelled differently
Remember the c() when you have a compound key: by=c(“FIPS”,“YEAR”)

Specify an outer, inner, left, or right join:

all=TRUE creates an outer join
all=FALSE creates an inner join
all.x=TRUE creates a left join
all.y=TRUE creates a right join

Data

This week’s lab uses the Lahman baseball dataset.

library( Lahman )
data( People )
data( Batting )
data( Salaries )
data( Teams )

We are interested in identifying the teams that have achieved the largest number of wins on the smallest budgets. Who are the teams that have far outperformed their resource constraints?

This analysis requires us to link two tables from Lahman - the Salaries table for pay, and the Teams table for total wins per season. Our outcome of interest will be the cost of each win that a team earns in a season.

If we are comparing salaries across several decades, it is important to adjust salaries for inflation so that everything is in 2016 dollars. For simplicity sake we are assuming steady 3% inflation each year since 1985. Tranform the raw numbers and save the variable as salary.adj.

# adjust old salaries for inflation
# to convert all salaries into 2016 dollars
# assuming a 3 percent inflation each year 
Salaries <- 
  Salaries %>% 
  mutate( salary.adj = salary*(1.03)^( max(yearID) - yearID ) )

head( Salaries ) %>% pander()

yearID	teamID	lgID	playerID	salary	salary.adj
1985	ATL	NL	barkele01	870000	2175070
1985	ATL	NL	bedrost01	550000	1375044
1985	ATL	NL	benedbr01	545000	1362544
1985	ATL	NL	campri01	633333	1583383
1985	ATL	NL	ceronri01	625000	1562550
1985	ATL	NL	chambch01	8e+05	2e+06

Total wins for each season are reported in the Teams table:

head( Teams ) %>% pander()

Table continues below
yearID	lgID	teamID	franchID	divID	Rank	G	Ghome	W	L
1871	NA	BS1	BNA	NA	3	31	NA	20	10
1871	NA	CH1	CNA	NA	2	28	NA	19	9
1871	NA	CL1	CFC	NA	8	29	NA	10	19
1871	NA	FW1	KEK	NA	7	19	NA	7	12
1871	NA	NY2	NNA	NA	5	33	NA	16	17
1871	NA	PH1	PNA	NA	1	28	NA	21	7

Table continues below
DivWin	WCWin	LgWin	WSWin	R	AB	H	X2B	X3B	HR	BB	SO
NA	NA	N	NA	401	1372	426	70	37	3	60	19
NA	NA	N	NA	302	1196	323	52	21	10	60	22
NA	NA	N	NA	249	1186	328	35	40	7	26	25
NA	NA	N	NA	137	746	178	19	8	2	33	9
NA	NA	N	NA	302	1404	403	43	21	1	33	15
NA	NA	Y	NA	376	1281	410	66	27	9	46	23

Table continues below
SB	CS	HBP	SF	RA	ER	ERA	CG	SHO	SV	IPouts	HA	HRA
73	16	NA	NA	303	109	3.55	22	1	3	828	367	2
69	21	NA	NA	241	77	2.76	25	0	1	753	308	6
18	8	NA	NA	341	116	4.11	23	0	0	762	346	13
16	4	NA	NA	243	97	5.17	19	1	0	507	261	5
46	15	NA	NA	313	121	3.72	32	1	0	879	373	7
56	12	NA	NA	266	137	4.95	27	0	0	747	329	3

Table continues below
BBA	SOA	E	DP	FP	name
42	23	243	24	0.834	Boston Red Stockings
28	22	229	16	0.829	Chicago White Stockings
53	34	234	15	0.818	Cleveland Forest Citys
21	17	163	8	0.803	Fort Wayne Kekiongas
42	22	235	14	0.84	New York Mutuals
53	16	194	13	0.845	Philadelphia Athletics

Table continues below
park	attendance	BPF	PPF	teamIDBR
South End Grounds I	NA	103	98	BOS
Union Base-Ball Grounds	NA	104	102	CHI
National Association Grounds	NA	96	100	CLE
Hamilton Field	NA	101	107	KEK
Union Grounds (Brooklyn)	NA	90	88	NYU
Jefferson Street Grounds	NA	102	98	ATH

teamIDlahman45	teamIDretro
BS1	BS1
CH1	CH1
CL1	CL1
FW1	FW1
NY2	NY2
PH1	PH1

Note that the Salaries table records data using people as the unit of analysis, and Teams records data using teams as the unit of analysis. In order to merge these tables you will first need to convert people salaries into aggregate team salaries or team budgets.

Follow these steps to build your dataset:

Aggregate salaries by team and year into a total salaries variable (group_by + summarize).
Include a count of players per team each season.
Merge the Teams dataset with your new team salaries table using both teamID and yearID as unique keys.
Create a new variable that measures the cost of each win for each team, by season.
Filter the results to retain only teams that have at least 25 teams on their roster each year.
Sort your list and report the teams with the lowest cost per win.

Your table will look something like this (this table not sorted to show the moneyball teams).

Notes:

n represents the number of players where salaries were available. Data was not available for all players in all seasons, so we filter by n > 25 to ensure we have a reliable estimate of the team’s budget that year.
cost.per.win is represented in hundreds of thousands of dollars here for simplicity. (wins / (budget/100000) )
Rank is from Teams, and is their final league ranking at the end of the season.

If you are interested in some of the actual math behind Moneyball (“Sabermetrics”) that breaks open the black box of each season to figure out what types of players to recruit to maximize wins, you should check out this nice blog or this R book on baseball statistics.

How to Submit

Use the following instructions to submit your assignment, which may vary depending on your course’s platform.

Knitting to HTML

When you have completed your assignment, click the “Knit” button to render your .RMD file into a .HTML report.

Special Instructions

Perform the following depending on your course’s platform:

Canvas: Upload both your .RMD and .HTML files to the appropriate link
Blackboard or iCollege: Compress your .RMD and .HTML files in a .ZIP file and upload to the appropriate link

.HTML files are preferred but not allowed by all platforms.

Before You Submit

Remember to ensure the following before submitting your assignment.

Name your files using this format: Lab-##-LastName.rmd and Lab-##-LastName.html
Show both the solution for your code and write out your answers in the body text
Do not show excessive output; truncate your output, e.g. with function head()
Follow appropriate styling conventions, e.g. spaces after commas, etc.
Above all, ensure that your conventions are consistent

See Google’s R Style Guide for examples of common conventions.

Common Knitting Issues

.RMD files are knit into .HTML and other formats procedural, or line-by-line.

An error in code when knitting will halt the process; error messages will tell you the specific line with the error
Certain functions like install.packages() or setwd() are bound to cause errors in knitting
Altering a dataset or variable in one chunk will affect their use in all later chunks
If an object is “not found”, make sure it was created or loaded with library() in a previous chunk

If All Else Fails: If you cannot determine and fix the errors in a code chunk that’s preventing you from knitting your document, add eval = FALSE inside the brackets of {r} at the beginning of a chunk to ensure that R does not attempt to evaluate it, that is: {r eval = FALSE}. This will prevent an erroneous chunk of code from halting the knitting process.

Lab 06 - Dataset Joins