What type of approaches and methods are you able to employ to understand a current database if you're assigned with supporting and/or modifying it? How will you easily and effectively increase your understanding of the database you haven't seen before?

  • The very first factor I actually do is create an Entity-Relationship Diagram (ERD). Sometimes you can just describe the metadata with command-line tools but in order to save time you will find some tools that may produce a diagram instantly.

  • Second, examine each table and column make certain I discover the concept of what it really stores.

  • Third, examine each relationship and make certain I realize the way the tables connect with each other.

  • 4th, read any sights or triggers to know custom data integrity enforcement or cascading down procedures.

  • Fifth, read any saved methods. Also read SQL access rights if you will find such.

  • Sixth, go through areas of the applying code which use the database. This is where some additional business rules and data integrity rules are enforced.


update: Someone said a fascinating article "9 Things you can do Whenever You Inherit a Database" with a decent record.

Summary:

  1. Backup copies
  2. Research (the schema documentation steps I mention above)
  3. Speak with the previous designers
  4. A bug database
  5. Source code control
  6. Speak with the customers and/or business proprietors
  7. Establish credibility using the customers by fixing a couple of things or making some improvements
  8. Produce a development atmosphere
  9. Drop obsolete objects

The information dictionary is the friend. Also, try reverse-engineering the database using the reverse-engineering tool on Visio and building your personal group of diagrams. Because reverse engineering is interactive - you build the diagrams - it's a lot more engaging than reading through via a data dictionary. The activeness of the operation is its advantage and that i think it is quite relaxing to get this done.

The majority of the work I actually do is within data warehousing, where poking around source system database schemas is one thing of the core activity. I have carried this out kind of factor on a large number of occasions and discover it really works very well.

Visio professional isn't that costly and also the Visio modelling engine allows you share one among multiple diagrams. Like a bonus, you can include in missing foreign secrets within the diagrams and you receive a helpful group of documentation for that system the finish.

Additionally to Bill Karwin's ideas, I would recommend speaking towards the customers - from time to time customers know a great deal by what their database can be used for, particularly if they are doing any confirming from this.

Schema Spy is a very nice tool for producing an ERD.

Find out if a choice of a Understanding Transfer session is open to you, and when so, make the most of it.

Also, many DBMS's include tools where you can draw/print the database schema with a few useful information (i.e. foreign secrets).

Furthermore, (stolen from NXC) you are able to reverse engineer the database via tools like Visio.

Bill gave a great answer. I'd include that I'd login towards the interface like a test user and then try to understand just what the customers use the information. It can help you realize the why behind a few of the saved procs or design. Being aware of what the information means and it is employed for is crucial to understanding a a database.

When the database is on the business function or subject you're in general not really acquainted with (say it will flight planning and you've got formerly only done financial programs), then request the customers for many reading through material about them matter or visit the library yourself or search the web regarding the subject matter. Request the customers if you will find legal or regulating issues you have to be conscious of. Again a number of this subject material background may explain what appear to become odd design options.