With the release of Exchange 2007, you could still rely on concepts that were old hat from previous versions of Exchange such as storage groups. You understood, perhaps, that a storage group was a way of bringing together databases (Mailbox and Public Folder) and that transaction logs for those databases would all be written, in sequential order, for multiple databases within a storage group. However, with Exchange 2007's high-availability options, you were constantly told that you can only have one database per storage group if you want these to work. That made sense because the Exchange 2007's approach to high availability uses continuous replication, which mean your transaction logs are shipped over to and replayed at the new location (the new disk, server, or site, depending on if you are using Local Continuous Replication, Cluster Continuous Replication, or Standby Continuous Replication). That basically sums up volumes' worth of Storage Groups, Databases and HA in Exchange 2007. Still with me?
In Exchange 2010, storage groups are gone! Now, you might be thinking, that makes sense. Even in Exchange 2007, it seemed the emphasis shifted from the storage group structure to the database side. You could have 50 storage groups and 50 databases (in the Enterprise Edition), which just seems like an extra step for no reason other than to allow folks the versatility of putting multiple databases into a storage group. Ultimately though this would complicate recovery for administrator's because all of the databases in the storage group share a common log stream.
In Exchange 2010, there's another related change to note: the location for the databases to be managed. Under the Exchange 2007 Exchange Management Console, you would look at the navigation pane through the Exchange hierarchy for servers, then locate the individual server, followed by the storage groups and databases. However, in Exchange 2010 a change has been made in how Databases are viewed in Active Directory. Now they are peer objects with Server objects. What this mens is that, like servers, databases are now global objects and, as a result, the location for database management is now performed under the Mailbox node of the Organization Configuration node (as opposed to under the Server Configuration node like you may be used to).