Prevent Serialization or Unserialize via ODBC Drupal, while a great CMS/Website/Intranet platform, is poor at providing users ability to edit datasets as one might in a spreadsheet or openly editable database table. We get forced into form update, form update, form update etc. Point, scroll and click time wasted. I've yet to find the module or View to edit data like a spreadsheet but still maintain database structure.

In Drupal 6, via ODBC we could easily edit node title, node body, comments or other text fields through programs like OpenOffice Base, LibreOffice Base, Microsoft Excel/Access or HeidiSQL. With Drupal 7 the text/data is serialized (BLOBs) and therefore what was easy changes to many text fields at once is now not possible, easily anyway.


What Drupal View setting, module or api/hook allows datasets to be edited, or
How to unserialize BLOB data for viewing in external programs 
Stop Drupal 7 from serializing in the first place? or,
Other
In normal circumstances you shouldn't edit raw database tables to make changes; there's an extensive API in place which you should use instead (whether that be via the UI, through custom code, interacting via REST, whatever).

Updating tables manually means you deny module hooks the chance to run, potentially leaving your site in an inconsistent state. Not to mention the fact that caches won't be invalidated, leaving your front-end inconsistent for a time.

To directly answer your questions:

A) I'm not sure what you mean by 'datasets' here. If you mean, how do you update a bunch of values for a bunch of entities (e.g. nodes) in one go, then the Views Bulk Operations module should be useful.

B) The data you're referring to is serialised using PHP's serialize() function. You can decode it with unserialize(). I can't comment on how you'd do that in, for example, Excel. Perhaps you could write VBA functions to mirror serialize()/unserialize() and apply them to the incoming/outgoing data?

C) You can't stop Drupal from serialising that data, it's baked right in. Well, you could theoretically do it, but it would be an awful lot of work. You'd probably also find the need to change a lot of contrib modules who rely on the known schemas.

D) I haven't used it personally, but I've heard good things about the Data module. Might be worth checking in to. Feeds might be of interest too.

To sum up: Providing users the ability to make changes to the site by directly manipulating database tables, outside of the API, isn't really one of Drupal's goals (or not one that I've seen mentioned before). If anything, I'd imagine they want to discourage that for the reasons I've mentioned above.