Is is the Data or the Log that is using up all this space?
It you have a big transaction log from big updates and if its not a transactional database (e.g. constantly updated all the time e.g. with customer sales) then you could shrink the log and clear the transaction history. Just backup the database beforehand just in case.
To do this in T-SQL window type
backup log 'databasename' with no_log
Then shrink the database through the taskpad (make sure you select Log rather than the default Data from the drop down list).
The problem you are going to have, is that the data file will only shrink from the end backwards, in the same fashion as the log file does.
You could try exporting your tables, dropping the originals, and then import the tables back in again. This should (and I stress should) put all the data at the beginning of the data file (you may need to shrink the data file when you drop the tables) - leaving any empty space at the end of the data file.
I have never actually used this method, and I cannot emphais enough the need for testing - but in theory this should work.
If it is production, you should schedule regular transaction log backups around your db backups to ensure recoverability. After a full backup, delete all the previous t-log dumps, and start over. This frees up space in the t-log, but does not shrink it. If you have never backed up your t-log, it's probably at a size it will never hit again once you schedule regulart t-log backups (if not simple recovery mode). I would back up the log to file, shrink it, take a full backup, delete the t-log file you just backed up, and put a log backup/dumping schedule in place around your regular full backups. This is essential if it is an active prod database.