Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Data Dictionaries
This material was covered during lectures on January 24, 1997.
A data dictionary is an organized listing of all the data elements that are pertinent to a system, with precise, rigorous definitions of each (where possible).
These help to ensure that both developers and potential users of a system have a common understanding of all the inputs, outputs, etc., in a system.
Warning: While almost every reference includes a discussion of data dictionaries, the format used for data dictionary definitions seems to vary widely from reference to reference. For example, while the following presentation is based on material in the references given below (and borrows from each), it doesn't follow any one of these references very closely - and it wouldn't be possible to follow more than one of them closely, at the same time!
Please follow the format use in examples given in lectures, labs, and in these online notes (rather than in the other reference material) when preparing data dictionary entries for CPSC 333.
Each data dictionary includes a name, kind, and either a formal definition (a type) or an informal definition (a description), or both.
This is the name of whatever is being defined, that is used on other requirements and design documents.
To make the data dictionary easy to use (and maintain), data dictionary definitions should be ordered by name (with names appearing in alphabetical order).This will be a very short description of the ``kind'' of data element that is being defined - attribute, entity, relationship, and so on.
The information that should be displayed here will be described separately, later on, for each of the kinds of data items that one might define.
This will be a formal definition of the ``data type'' for the data item. It will resemble (but not be identical to) the kind of definition of a ``regular language'' that one might give using a ``regular expression'' (as seen, for example, in CPSC 313).
This will be a short English description of the data item. It might supplement the ``kind'' and ``type'' information given above by including details that would be difficult to give otherwise, and in some cases it might replace the formal (``type'') definition altogether.
It's possible, as well, that it might include a reference to a picture or ``screen dump,'' for a description of part of a user interface, etc.
For many data items, it will be possible - and not too difficult - to give a formal definition of the types of values that the data item can assume. In this case, you should include a formal definition for the data type: While you'll need to understand the meaning of the symbols used in the definition in order to make sense of it, this kind of definition will generally be much more precise than a less formal English description of the data type - which can easily be incomplete or ambiguous.
On the other hand, some data items aren't easily described this way - especially things like parts of the user interface, such as menus to be displayed, prompts for information, error messages, and so on. You should probably use an informal description instead of a formal type definition, for these.
As well, you may sometimes want to use a combination of both: For example, you might use the ``formal'' part to define a general data type, and then use the informal description to annotate the formal definition, by mentioning values that shouldn't appear, the ways that values should be interpreted, and so on.
So, if you're trying to decide whether to specify something ``formally'' or ``informally'' - use your judgment, keeping in mind that there might be more than one right choice, and that you want your description to be as clear - precise, but also readable - as you can make it.
Later on, more detail will be given about the kind of information that should be included in a definition for each kind of data item you will want to define. Quite a few details be mentioned.
Keep in mind, when reading this and when preparing data dictionary definitions, that all these details might not be needed - or appropriate - in a data dictionary that you produce during requirements analysis and specification. Sometimes, the right answer will be, ``it doesn't matter how the system reacts'' or, ``it doesn't matter (or, we don't know) what value is used,'' this early on in software development.
If something like this happens, then you shouldn't feel that you ``absolutely must'' make up something, to put into a definition. Otherwise, you risk making design and implementation decisions for your system, much earlier than you should.
On the other hand, though, you should try to find out whether a given detail is an important part of the system's requirements, if work on a data dictionary causes you to suspect that it might be.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Data Dictionaries