Improve performance of a Fact Table I have a Fact table CardTransactionFact

Table Structure

TABLE [dbo].[CardTransactionFact]
    [CardTransactionID] [int] IDENTITY(1,1) NOT NULL,
    [TransactionTerminalID] [int] NOT NULL,
    [SourceAccountTypeID] [int] NULL,
    [DestinationAccountTypeID] [int] NULL,
    [RimNo] [varchar](15) NULL,
    [CaptureCodeID] [int] NOT NULL,
    [RoutingCodeID] [int] NOT NULL,
    [ProcessingCodeID] [int] NOT NULL,
    [ActionCodeID] [int] NOT NULL,
    [NetworkCodeID] [int] NOT NULL,
    [ProductCodeID] [int] NOT NULL,
    [AcquiringCountryCodeID] [int] NOT NULL,
    [IssuingCountryCodeID] [int] NOT NULL,
    [TransactionCurrencyCodeID] [int] NOT NULL,
    [AmountBD] [decimal](18, 3) NOT NULL,
    [LocalCurrencyCodeID] [int] NOT NULL,
    [CardIssuerBank] [int] NOT NULL,
    [CardTypeID] [int] NOT NULL,
    [SuspectTransactionFlag] [char](1) NOT NULL,
    [ReversalTransactionFlag] [char](1) NOT NULL,
    [LocalTransactionDateKey] [int] NOT NULL,
    [LocalTransactionHourKey] [int] NOT NULL,
    [BBKRole] [char](1) NOT NULL,
    [AmountRangeKey] [int] NULL,
    [CustomerKey] [int] NULL


Size: 11GB
No of Rows : 56,959,828



It has become very difficult to access this table now, a simple Select count(*) from CardTransactionFact takes hours to execute.

most of the columns in the table are just integers that's why i didn't do any indexing.

What do you think i should do to improve this table, and increase the speed of query's to this table


If indexing which columns should i index and why
Is it good idea to Partition the table
Any Other suggestions
Lots of stuff wrong here, thankfully lots that can be fixed.

Problems:


You have a heap. Good odds this is heavily fragmented and pages are spread throughout the 82GB data file. See sys.dm_db_index_physical_stats for guidance on checking fragmentation.
You only have 6GB of memory, if you're lucky maybe 4GB is available to the buffer pool.
Reading between the lines, you are using dog slow SATA spinner drives.
A scan of the table will require 11GB of random IO across that dog slow drive and churn the buffer pool completely 3 times over.


Fixes:


Create a clustered index on the table. CardTransactionId looks like the only sensible choice currently.
You desperately need memory. 128GB would be reasonable for an 82GB data warehouse.
You have woefully inadequate IO. SSDs would the cheapest fastest fix.


11GB does not fit into 6GB, it really is that simple. A very rough estimate suggests the table will occupy ~1.5million 8KB pages which given 100 IOPS would take approximately 4 hours to read from disk (assuming worst case, 100% random read, no read-ahead etc).