A clustered index actually defines data storage. You can have one or more columns as the key for the clustered index, but you won't get any INCLUDE columns in there because it stores the data. It's different than a non-clustered index which can have INCLUDE columns at the leaf level (making it sort of act like a clustered index).

If you're asking if you should have two columns to make the clustered index unique... that's hard to answer without seeing the query and the structure in question. All clustered indexes are unique, either through you providing unique column(s) or by the addition of a uniquifier value (essentially an IDENTITY column providing an assurance of uniqueness).

Generally I suggest making the clustered key the most used access path to the data (since it stores the data). If that's one column or three, it's usually the best way to go, even if they're not unique. However, the most efficient clustered index is a monotonically increasing, integer value that is unique (putting that in there because someone is going to get worked about what is the most efficient). The reason I go with the most used access path to the data versus the most efficient clustered index is because it doesn't matter how efficient the index is if it isn't used regularly. You only get one per table (with the possibility of creating a materialized view as you seem to be exploring) so you may as well make it an index that sees a lot of use.

If I'm off the mark here, let me know.