Schema, Instance and Metadata

A schema is the design of a database and rarely changes. An instance is the data in it at one moment and changes constantly. Metadata is the stored description of the schema itself.

Concept

Two words are used almost interchangeably in conversation and mean very different things in this subject.

SchemaInstance
What it isThe design: structure, types, constraints, relationshipsThe actual data held at one particular moment
Also calledIntensionExtension, or database state
How often it changesRarely, and deliberatelyConstantly, with every insert, update and delete
Defined byDDL statementsDML statements
AnalogyThe class in a programAn object created from that class

Seeing the difference

SCHEMA  (the design - one, stable)

  students ( roll_no INT primary key,
             name    VARCHAR(50) not null,
             marks   INT check between 0 and 100 )

INSTANCE at 09:00                INSTANCE at 09:05

  21  Meera   87                   21  Meera   87
  22  Ravi    91                   22  Ravi    91
                                   23  Anitha  78     <- inserted

Same schema. Different instance. Adding a row does not
change the design; adding a COLUMN does.

Schemas at all three levels

Each level of the three level architecture has its own schema.

  • External schema — also called a subschema. One per user group.
  • Conceptual schema — one for the whole database.
  • Internal schema — one, describing storage.

There is no such thing as an external instance. The data exists once; the views are windows on to it.

Metadata and the data dictionary

Metadata is data about the data. It is the stored form of the schema, and the DBMS reads it constantly.

Metadata includesExample
Table and column namesstudents.roll_no
Data types and sizesVARCHAR(50)
ConstraintsPrimary key, not null, check
RelationshipsForeign key from enrolments to students
Indexes and storage detailB+ tree on roll_no
Users, roles and privilegesWho may read the marks column
StatisticsRow counts and value distribution, used by the optimiser
Views and routinesTheir definitions

Metadata lives in the data dictionary, also called the system catalog. It is itself stored as tables inside the database, which is why a database is described as self describing.

-- Illustration only: the catalog is queryable like any table.
SELECT table_name, column_name, data_type
FROM   information_schema.columns
WHERE  table_schema = DATABASE()
ORDER  BY table_name, ordinal_position;

Why the optimiser needs metadata

Statistics stored as metadata are what let the query optimiser choose a plan. If the catalog says a column holds 400,000 distinct values, an index lookup is attractive. If it says the column holds two values, a full scan may be cheaper. Stale statistics are therefore a real cause of sudden slowness, which is covered again in the query processing phase.

Common mistakes

  • Saying the schema changes when a row is inserted. That changes the instance.
  • Believing there is one instance per view. There is one database state. Views present it differently.
  • Thinking metadata is optional documentation. The DBMS cannot execute a single query without it.
  • Forgetting statistics are metadata. This link explains a whole class of performance problems.

Exam and interview questions

  1. Differentiate schema and instance with an example.
  2. What are intension and extension?
  3. How many schemas exist at each of the three levels?
  4. Define metadata and list six things a data dictionary stores.
  5. Why does a query optimiser depend on the system catalog?

Practice

  1. Write a three column schema for a library book table, then write two different instances of it.
  2. Classify each as a schema change or an instance change: adding a student, adding a column, changing a data type, correcting a mark, dropping an index.
  3. List four items of metadata a DBMS must read before it can execute a simple query.

Conclusion

The schema is the design and is stable, the instance is the current data and is not, and metadata is the schema stored as data so that the system, and anyone else, can discover the structure without reading application code.

Useful resources

Hand picked references for this topic
Written by Lorens Mishra

Software Engineer Notes Management System Administrator

Continue reading

All DBMS notes →
DBMS

File System versus DBMS

The file based approach fails on redundancy, inconsistency, isolation, atomicity, concurrency, security and integrity. Each failure maps to one specif...

Read more

Discussion

0 comments
Sign in to join the discussion.

No comments yet. Be the first to say something.