Best Index Scenario

I have a 10 year old DB that someone "converted" from Access to SQL 2000 about 5 years ago.
Since then the DB has grown substantially and has 1 large table (3+ Billion rows) in the following structure:

CREATE

 

TABLE [dbo].[TData](
[TDate] [smalldatetime] NOTNULL,
[SID] [int] NOTNULL,
[IID] [int] NOTNULL,
[TUnits] [smallint] NOTNULL,
[TSales] [real] NOTNULL,
[TTypeID] [tinyint] NOTNULL,
[TPVal] [real] NULL,
CONSTRAINT [PK_TData] PRIMARYKEYNONCLUSTERED
(
[TDate] DESC,
[SID] ASC,
[IID] ASC
)WITH(PAD_INDEX =OFF, STATISTICS_NORECOMPUTE =OFF, IGNORE_DUP_KEY =OFF, ALLOW_ROW_LOCKS =ON, ALLOW_PAGE_LOCKS =ON,FILLFACTOR= 99)ON [PRIMARY]
)ON [PRIMARY]
CREATECLUSTEREDINDEX [IX_TData_Clustered] ON [dbo].[TData]
(
[SID] ASC
)WITH(PAD_INDEX =OFF, STATISTICS_NORECOMPUTE =OFF, SORT_IN_TEMPDB =OFF, IGNORE_DUP_KEY =OFF, DROP_EXISTING =OFF, ONLINE =OFF, ALLOW_ROW_LOCKS =ON, ALLOW_PAGE_LOCKS =ON,FILLFACTOR= 99)ON [PRIMARY]

 

 

 

Before you get too whipped up, I know there are a number of issues with this old structure which is why I'm rewriting it rather than converting and so it is a good time to evaluate indexes.

TDate, SID, IID together must be unique.  The new strcuture will be physically ordered by TDate, SID and IID will to have Non-Clustered Indexes

My questions pertains to the PK. 
What is the best indexing scenario.

1) Keep the three column composite PK
2) Create a BIGINT AutoIncrement PK and a Unique Index/Constraint on TDate, SID, IID
3) Skip the PK altogether and just add a Unique Index/Constraint to TDate, SID, IID.
4) ???

Typical queries will join on IID, SID with where clause to filter by a range of TDate's as well as a subset of IID's and SID's (Sometimes SID filtering is omitted to get the entire set of SIDs)


Thanks