Context Transition in CALCULATE and Clarification of Correct Terminology

Question

Dear Team,
Question #1:
If I create a Calculated Column with this aggregate calculation:
SUM-Aggregate =SUM(PlayersTable[Salary])
Is this a correct statement:
“Aggregate functions are affected by Filter Context, but will ignore Row Context and will show the same aggregated number in every row of the Calculated Column.”
Question #2:
If I create a Calculated Column with this aggregate calculation inside the CALCULATE function:
SUM-Aggregate-in-CALCULATE =CALCULATE(SUM(PlayersTable[Salary]))
Are these correct statements (these are my interpretations of Alberto Ferrari’s & Marco Russo’s book MS Excel 2013 Building Data Models with PowerPivot):
“An aggregate calculation inside CALCULATE will show just the row values not the aggregate values, and so if there is no relationship on this table, the Calculated Column will simply show the individual amounts for each row from the Salary column.”
“Inside CALCULATE, there is no Row Context”
“If you use only the first argument in CALCULATE, it will transform Row Context to Filter Context.”
Question #3:
If the three statements are TRUE from question #2, how do I make sense of them given that as a person new to PowerPivot I “see” CALCULATE returning individual row amount and thus think that CALCULATE is doing a Row Context”
Question #4:
If I create a Calculated Field:
TotalSalary:=SUM(PlayersTable[Salary])
And then create this Calculated Column:
SUM-CalculatedField-Auto-Call-To-CALCULATE =[TotalSalary]
Is this a correct statement:
“The Calculated Field comes with an automatic CALCULATE function wrapped around it and so because it is in a Calculated Column it will show just the row values and not the aggregated value”.
Sincerely, Mike "Struggling To Learn PowerPivot" Girvin

Answer 1

First, a minor thing, but I'm Greg. Michael Amadi proposed my original response as an answer to the thread, but hasn't participated otherwise in the thread.
I don't know how familiar you are with SQL, but I'll try explaining with that.
TotalAmountCC =SUM(fSales[amount]) is roughly equivalent to the following being evaluated:
SELECT
f1.*
,TotalAmountCC = (SELECT
         SUM(f2.amount)
        FROM fSales f2
FROM fSales f1
Wrapping your measure in CALCULATE() changes the filter context for evaluation. 
TotalAmountCC2 =CALCULATE(SUM(fSales[amount])) is roughly equivalent to the following
SQL:
SELECT
f1.*
,totalcc2 = (SELECT
SUM(f2.amount)
FROM fSales f2
WHERE f2.date = f1.date AND
f2.[sales rep] = f1.[sales rep] AND
f2.product = f1.product AND
f2.amount = f1.amount
FROM fSales f1
What CALCULATE() is doing is looking at every field in the row, and then it is finding every row that matches on all fields. When you introduce a primary key, it is a logical impossibility for any two rows to have matching values for every field. Power Pivot
does not in this case understand that a primary key exists, it is simply looking for rows where the field which happens to be called [PrimaryKey] is equal to the value of that field on the current row.
For a more concrete example, I will look at what is happening on the first and second rows of each table for each formula.
TotalAmountCC
Row 1: Just take the sum of all values in the field [amount]
Row 2: Just take the sum of all values in the field [amount]
TotalAmountCC2
Row 1: Create a filter context that will only consider rows where [date] = 9/3/2014 AND [sales rep] = 'joe' AND [product] = 'p1' AND [amount] = 22. Evaluating the table with respect to this filter context gives us two rows, row 1 and row 4. We then
sum the field [amount] for these rows
Row 2: Create a filter context that will only consider rows where [date] = 9/4/2014 AND [sales rep] = 'sindy' AND [product] = 'p2' AND [amount] = 15. Evaluating the table with respect to this filter context gives us only one row, row 2. Thus we
evaluate the sum of the field [amount] for this one row. Doing so returns the value since adding 15 and nothing is 15
TotalAmountCC3
This is exactly the same as above.
TotalAmountCC4
Row 1: Create a filter context that will only consider rows where [PrimaryKey] = 1 AND[date] = 9/3/2014 AND [sales rep] = 'joe' AND [product] = 'p1' AND [amount] = 22. Evaluating the table with respect to this filter context gives us only one
row, row 1, because row 4 does not match on [PrimaryKey], even though it matches on all other fields. Thus, we evaluate the sum of the field [amount] for this one row, giving us 22, the value on that row.
Row 2: Create a filter context that will only consider rows where [PrimaryKey] = 2 [date] = 9/4/2014 AND [sales rep] = 'sindy' AND [product] = 'p2' AND [amount] = 15. Evaluating the table with respect to this filter context gives us only one
row, row 2. Thus we evaluate the sum of the field [amount] for this one row. Doing so returns the value since adding 15 and nothing is 15.
It is important to note that it doesn't matter that the field you added is a primary key, or that it is named [PrimaryKey]. You could have added time of day, and so long as the values are different for each row, you'd see the same behavior. Setting the table
property of the field as a primary key will not change the behavior of CALCULATE() in this situation. The only thing CALCULATE() is doing is evaluating the function (SUM() in our case) for every row where every single field is equal to the values of that field
for the current row.