• My first step is to use ModelRight's reverse engineering function to suck the database schema into a diagram. Then I spend a little time arranging the diagram to study the relationships between the tables.

    Once I understand table categories (these are master tables, these are detail tables, these are code lookup tables, etc.) I start concentrating on understanding which table holds what. Alas I find third party vendors are seldom very good at relational database design.

    One product didn't use clustered indexes. At all. Another decided that joins were for the weak. 🙂

    And yet others don't understand that tables should have descriptive names. Sigh.

    Once I have all that, then I start tracking down what individual columns store. As I do so I add comments and note fields, see if there are any consistently named columns, and so forth. In effect the ERD becomes the data dictionary, with the added advantage that it's also a pretty picture.

    My last step is to use SSMS to explore the stored procedures/functions and see if they're named well. Usually--no. (shaking head). Is that approach supposed to be security by obscurity? Or just being bloody minded to outsiders?