Ad data dictions usually refers to a "system" that lets you design and
STORES the database STRUCTURE.
We could call the table design view of ms-access the data dictionary for
example. Usually, this data dictionary has things like how many indexes on
the table, the field names of the table. In fact, there is so much
information that needs to be stored about a typical table these days, that
often the table definitions them selves are a database. Thus, the term "data
dictionary". Hence, a database table stores data, but a data dictionary
stores data like a database, but it is storing fields and stuff about the
database.
There is also some view that when you state a system is driven by a data
dictionary, then often this means that the dictionary definitions can
function separately from the database files (the industry as a whole is not
100% clear, or agreed on this point).
Thus, this often means that changes can be made to the data dictionary
SEPARATELY from the data files. This would imply that you could make changes
to the database design while people are using the database! (normally, you
have to kick out all users) So, one great benefit of a data dictionary
system is that you can even add new fields etc WHILE the database is in use.
However, that kind of separation between the data files, and the data
dictionary is not always a 100% true statement. For example, you can't
change, or add new fields to a ms-access JET database WHILE users are
editing the file, so some might argue that ms-access is not a true data
dictionary system.
But, in general, and not splitting hairs, when we speak of a data
dictionary, we really are talking about the information file that defines
the database tables and structures, indexes and perhaps a good deal more
things like triggers etc).
