How much does an ordered query of an attribute costs in terms of operations when the attribute is a key or an attribute?
Not sure what your question is exactly, as the symbols you use seem a bit confusing, but the general idea I think is this:

Firstly, you have to visit all records in the heap to find those where Attribute = 50, so that would be, in pages, 100000 records times 100 bytes each divided by 1024 (page size) rounded up, which comes to 9766. This determines your I/O cost, which will be all you need to know for the query without ordering -- matching records can be returned to the client immediately.

The rest is impossible to evaluate without knowing the selectivity of your search criteria, that is, how many records match it. For the query with ORDER BY ultimately you will need to 1) store all matching records in memory, determining your memory cost, and 2) sort them, determining your CPU cost. 

Edit:

With Attribute uniformly distributed across 1000 distinct values we can estimate that the equality predicate will fetch on average 100000/1000 = 100 rows, each 100 bytes long, which will require 10000 bytes to store. CPU cost to sort them will be proportional to log₂(100 rows).

Note that some smarty-pants optimizer might notice that there's no need to order the result set by the value that's on the right hand side of the sole equality predicate and ignore the ORDER BY clause altogether.