In short
A schema teaches Linkr how to read a database: which table holds the patients, which one the hospitalizations, where to find a date of birth. It carries two things — the DDL, which describes the tables, and the mapping, which gives them a role. It is what turns a database you can query in SQL into a warehouse Linkr understands.
The problem a schema solves
Two hospitals store the same information under different names. Here the patient table is called person and the date of birth birth_datetime; there it’s patients and dob. A third kept its in-house model.
Linkr does not guess. With no guidance, a database is just a set of tables: you can write SQL against it, and nothing more. No patient page, no cohorts, no demographic statistics.
The schema is that guidance. It says: the patient table is person; its identifier is person_id; the date of birth is birth_datetime. From there, every warehouse feature knows where to look — and the same dashboard works on OMOP in one hospital and on an in-house model in another.
The two halves of a schema
The DDL
The structure: the CREATE TABLE statements describing tables, columns and keys.
It serves two purposes: drawing the diagram, and building an empty database — this is what “New from schema” executes. Without a DDL a schema is still usable, but it cannot create a database.
The mapping
The roles: which table holds patients, hospitalizations, notes.
This is the half Linkr’s pages depend on. A schema with no mapping can only create empty tables; it is the mapping that makes a database readable.
The two are independent. You can have a DDL with no mapping — the structure is known but the roles aren’t — or the reverse, for a database that already exists and that you are only describing.
In this guide
A schema is obtained, read, then mapped. The first page covers the four ways of getting one and what its page shows — the overview, the DDL and its diagram; the second details the mapping, relation by relation, and what the databases that copy it do with it.
Getting and exploring a schema
Installing it from the catalog (OMOP, MIMIC), importing, duplicating or creating it; then reading its page: the overview, the DDL, the diagram and its table groups.
Mapping a schema
The relations and their contract, the form, the SQL and its check — and what becomes of the databases that copy the mapping, with their overrides.
Going further
- Getting and exploring a schema — the catalog, importing, the DDL and the diagram.
- Mapping a schema — the relations, the form, the SQL and the contract.
- Databases — attaching a schema to a database, and overriding its mapping.
- Concepts — what the dictionaries make possible.
- Concept mapping — aligning your local codes to a standard terminology.
- Community catalog — where OMOP and MIMIC come from.