Late response, but to my knowledge Karthick's reply is the preferred way to handle transactional (or 'detailed') level reporting from BW despite the many other suggestions to put it in the Cube.
Cubes are optimized for reporting on small dimensions, and fields with high levels of detail will balloon whatever dimension they are placed in (and the fact table, too) and degrade performance. Rule of thumb is to try to keep the rowcount for each of your dimension tables to around 10% that of the fact table.
DSOs are flat tables that are intended for holding detail level data. Keep the high level data in the Cube and use a jump query (RRI) to pass parameters into a query on the DSO. You can also create secondary indexes on DSOs if you know what parameters you'll need to filter on.
If the DSO is still too large to handle reasonably fast reporting, create a streamlined reporting version of it if possible, or a version that contains only one year's worth of data or break it up into manageable domains.
The other methods will work, but they won't scale up well if you have lots of data.