How to explore an existing data structure with DataLens
For the database nobody documented and everybody depends on: see what is actually there, as a diagram, without reading DDL for a week.
What you will do
You will build a source model from the datasets you have connected, see the tables and their relationships laid out as a diagram, and export it in a format you can put in front of other people.
This is the reverse of designing a model — you are recovering one from a system that already exists.
When this is useful
- You have inherited a system and need to understand it before changing anything.
- You are scoping a migration and need to know what is actually in the source.
- A project discussion needs a diagram and none exists.
- You are learning data architecture and want to read a real schema rather than a textbook one.
Before you start
- Datasets loaded from the system — Connect the database and load the tables you care about. See the database connection guide if you have not done this.
- A sense of scope — Load the tables that matter rather than all four hundred. A diagram of everything is a diagram of nothing.
Steps
Open Model → Source Model
Select Model in the navigation, then the Source Model tab.
The source model is what your data looks like now. The target model, on the neighbouring tab, is what you intend it to look like — keeping them apart is the point of having two tabs.
Your loaded datasets available to place on the model canvas.
Add the tables to the canvas
Add the datasets you loaded from the source system. Each appears as a node listing its columns and their types.
Nodes are typed — Raw, Staged, View, CRM, Lake, Data Product — so where a table came from stays visible on the diagram.
Table nodes on the canvas with their column lists.
Establish the relationships
Use Relationships to record how the tables connect — which column in one refers to which in another.
This is the part a database rarely tells you honestly. Foreign keys are frequently absent even where the relationship is real, and recording it here is how the knowledge stops living in one person's head.
Connectors between nodes showing the relationships.
Mark facts and dimensions
Classify tables as Fact or Dimension where that distinction is meaningful — facts hold the events and measures, dimensions hold the descriptive attributes.
It makes the diagram readable at a glance and sets up any dimensional modelling that follows.
Read the model
Lay out the canvas so the diagram makes sense to somebody who has not seen it before. Which tables are central, which are peripheral, and where the joins run are all now visible rather than inferred.
Export it
Export the model as a PNG image or SVG diagram for a document or a slide, as SQL DDL, as a JSON model, or as a CSV schema listing.
SVG for documents that get resized, PNG for anything pasted into a deck, DDL when someone needs to recreate the structure.
The exported file downloaded in the format you chose.
What happens next
With the source understood, the target model is the natural next step — what the data should look like once it has been through your pipeline.
Mapping source to target is a tab of its own, and is where the two models get connected column by column.
Example
An architect joins a project with a PostgreSQL database and no documentation. They load the eight tables that matter, build the source model, record the relationships the foreign keys do not declare, mark the fact table, and export an SVG. The project's first architecture discussion starts from a diagram rather than from guesses.
Tips
- Model the tables that matter. Completeness is not the same as usefulness on a diagram.
- Record relationships that exist in practice even where no foreign key declares them — that undeclared knowledge is exactly what gets lost.
- Export SVG for documents. It stays sharp when someone resizes it.
- Marking facts and dimensions early makes the layout organise itself.
Limitations
- The model covers datasets loaded into DataLens. Tables you have not loaded are not in it.
- Relationships that no foreign key declares must be recorded by you — they cannot be inferred from data alone with any confidence.
- Exports are PNG, SVG, SQL DDL, JSON model and CSV schema. Other diagram formats are not produced.
- A source model documents structure. It is not a live mirror of the source database and does not update when the source changes.
Related how-to guides
Connect a database
Connect PostgreSQL, MySQL, SQL Server, Redshift, BigQuery or Snowflake, browse the tables and load what you need.
Map source to target
Connect source columns to target columns, see what is unmapped, and export a source-to-target mapping.
Trace where a column came from
Follow a field back from the dataset you are looking at to the source it came from, step by step.
Generate a data document
Produce an architecture document, a model spec, a mapping or a runbook from what you have already built.
Related questions
More of these on the DataLens FAQ page.
Can DataLens help me understand a database structure I did not design?
Yes. Connect the database, preview and load the tables that matter, then build a source model on the Model screen. You get tables, columns, types and relationships as a diagram you can lay out, read and export.
Can I export a data model diagram from DataLens?
Yes. A model can be exported as a PNG image, an SVG diagram, SQL DDL, a JSON model or a CSV schema listing — so it can go into a document, a slide deck, or a script that recreates the structure.
Does DataLens detect relationships between tables automatically?
Relationships you record are what the model shows. Many real relationships are not declared as foreign keys in the source database, so recording them explicitly is part of the work — and is precisely the knowledge that otherwise stays undocumented.
Try this in DataLens
DataLens is in private beta. Request access and work through this guide on your own data.
Request beta access