Are you or is anyone else on your SDE doing non-versioned or versioned editing? What sort of analysis are you doing and why does it need to be in SDE and not a file or personal geodatabase? Typically geoprocessing-type analyses produce a lot of junk or intermediate tables that you really don't want in your multiuser environment. How frequently will you be doing schema changes and what are the nature of the schema changes? Does your organization already have established procedures as to when and how to perform schema changes?
The point is you can't just "do whatever you want" if there are other users in your database. DBMSes and SDE implement concurrency and locking to ensure the ACID properties are not broken and so that you don't inadvertently blow things up.
Also there is a difference between the types of locks in SDE. This help topic has a good overview. Essentially there are shared locks which are created when someone is viewing or editing an object class, and there are exclusive locks for when someone is attempting to change the schema of an object class themselves. As for feature datasets, locks apply to all the object classes in a feature dataset, so that is more likely to work against you than for you.
You can find out what users have locks to an SDE layer using sdemon or by looking at the
SDE_layer_locks SDE system table. Provided you have the necessary permissions you could delete those locks that are preventing you from making your schema changes, at the risk of blowing away someone else's edits or worse. Know the risks and ramifications of modifying system tables before you do so!
Note that in 10.1, they are adding geodatabase administration tools that make viewing and managing user locks/connections easier.