Safe to Shrink Database in this Scenario?
This should answer your question : http://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/

Quoted:


  So what if you do need to run a shrink? For instance, if you’ve
  deleted a large proportion of a very large database and the database
  isn’t likely to grow, or you need to empty a file before removing it?
  
  The method I like to recommend is as follows:

Create a new filegroup
Move all affected tables and indexes into the new filegroup using the CREATE INDEX … WITH (DROP_EXISTING = ON) ON syntax, to move the

  
  tables and remove fragmentation from them at the same time
      Drop the old filegroup that you were going to shrink anyway (or shrink it way down if its the primary filegroup)
  
  Basically you need to provision some more space before you can shrink
  the old files, but it’s a much cleaner mechanism.
  
  If you absolutely have no choice and have to run a data file shrink
  operation, be aware that you’re going to cause index fragmentation and
  you should take steps to remove it afterwards if it’s going to cause
  performance problems. The only way to remove index fragmentation
  without causing data file growth again is to use DBCC INDEXDEFRAG or
  ALTER INDEX … REORGANIZE. These commands only require a single 8KB
  page of extra space, instead of needing to build a whole new index in
  the case of an index rebuild operation.


So if you have multiple filegroups you can use this technique, otherwise you can make a shrink and then do a rebuild of your indexes.