As a project grows, the database can quickly become difficult to understand.

You may have dozens of tables, each with its own columns and relationships. When working on an existing application, simply knowing that a database is connected isn’t enough, you need to be able to understand how its data is organized.

DevScribe’s Database Doc Tool gives you two ways to explore this structure: Tables and ER Diagram.

In this guide, we’ll use a connected MySQL database to see how both views can help you understand a database schema.

Viewing Your Database Schema

Once your database is connected, open the database in the Database Doc Tool.

At the top of the database view, you’ll find the options for ER Diagram and Tables.

These provide two different ways of looking at the same database.

Tables gives you a structured view of the individual tables, while the ER Diagram gives you a visual representation of the database structure and relationships.

Exploring Tables

Select Tables to see the tables available in your database.

For example, our connected MySQL database contains 38 tables/views.

Each table appears as an individual entry, along with the number of columns it contains.

For example:

• columns_priv: 7 columns
• component: 3 columns
• db: 22 columns
• default_roles: 4 columns
• engine_cost: 7 columns

This gives you an immediate overview of the database without having to query it manually.

Inspecting a Table

Click on a table to expand it.

DevScribe displays the columns belonging to that table along with their data types.

For example, a table can show information such as:

component_id          int unsigned
component_group_id    int
component_urn         text

You can use this view to quickly understand what information a table stores and how its fields are defined.

Switching to the ER Diagram

While the Tables view is useful for inspecting individual tables, sometimes you need a bigger picture.

Select ER Diagram to switch to the visual representation of your database.

Here, tables are displayed as individual components with their columns inside them.

This makes it easier to look at the database as a whole rather than examining one table at a time.

Understanding Relationships Visually

An ER Diagram is particularly useful when you’re trying to understand how different parts of a database connect.

Instead of reading through table definitions individually, you can look at the diagram and see the relationships between tables.

For a larger database, this can make it much easier to answer questions like:

• Which tables are related?
• What does a particular table connect to?
• Which fields act as keys?
• How is information structured across the database?

You can also use Auto-layout to arrange the diagram automatically when working with a larger schema.

Tables or ER Diagram?

Both views are useful, but for different purposes.

You can switch between the two depending on what you’re trying to understand.

If you’re looking for a particular field, the Tables view is usually the better place to start.

If you’re trying to understand how the database is organized as a whole, the ER Diagram gives you a much clearer picture.

Why Schema Visibility Matters

Understanding the schema is often the first step before making changes to a database.

For example, before working on a new API endpoint, you may need to know which tables contain the relevant data. When debugging an existing feature, you may need to understand how several tables are connected.

Having the schema available directly in your development workspace means you can answer those questions without leaving DevScribe.

And because the database is already connected, the schema you’re looking at comes directly from the database you’re working with.

Part of the Development Workflow

This also connects the database back to the rest of your project.

You might start with your API documentation, move to the database to understand where the data is stored, inspect the schema, and then use a saved query to investigate the data itself.

All of these pieces can live within the same DevScribe workspace.

So instead of treating the database as a separate tool, you can use DevScribe to move between:

Schema

Tables

Queries

Data

without breaking your development workflow.

Here’s a walk through:

What’s Next?

Once you understand the structure of your database, working with its data becomes much easier.

You can use the Tables view when you need to inspect specific fields, the ER Diagram when you need to understand relationships, and your saved queries when you need to work with the actual data.

The result is a database you can not only connect to, but actually understand.