+1 for a question that comes up frequently, though everyone say not to query SDL Tridion databases. It's easy to query "content" from the storage broker (hints below).
Content Manager vs. Content Delivery
The Content Management System (CMS) and its database stores component and pages as well as their history. In CMS, can "inspect component data" using the Core Service as well as the TOM.NET API (in templates).
However, Content Delivery (CD) stores pages and component presentations, the rendered output of a component and a component template. You retrieve these as files or through the CD API. The Broker lives in CD.
CMS-side component information is available in CD if it's metadata or if your templates outputted them.
The broker database is just one of several ways to store rendered output. It assumes you're using dynamic component templates and storage configuration that places component presentations in the database, which may not apply for a given publication, implementation, or CMS.
As a practical example of why querying either the CM or CD databases is a bad idea, sometime between SDL Tridion R5.3 and 2011, the broker database changed from comma-separated values in the
CUSTOM_META table to repeated key-value pairs. Also in SDL Tridion 2011 (SP1, I think), file-based metadata was deprecated.
Inspecting Component Data
Use a component's Source tab to see how SDL Tridion stores it on the CM-Side. Otherwise see my posts on how to get it with a trivial XSLT template or simple C# code.
To get fields from the delivery-side, consider starting with SDL Live Content's CD section (requires login).
I sometimes check (read-only, i.e.
select statements) the broker database to troubleshoot. For example, you might need to check the
CUSTOM_META tables to confirm configuration settings or troubleshoot something like encoding.
However, again there are much easier and supported ways to get at components and component presentations.