IT 216 – Chapter 8 Notes (Data Dictionaries & Repositories)

Learning Objectives

• Understand analyst use of data dictionaries and repositories when studying data–oriented systems.
• Recognize how CASE tools help build and maintain these repositories.
• Be able to create dictionary entries for
  • Data processes, flows, stores, structures, logical & physical elements (all sourced from DFDs).
• Appreciate the dictionary’s role in helping users keep an information system up-to-date and consistent.

Cataloging with Data Flow Diagrams (DFDs)

• DFDs supply raw material for the dictionary.
  • Items catalogued: Processes, Flows, Stores, Structures, Elements.
• Cataloging is carried out inside the data dictionary so that every symbol on a DFD has a detailed textual counterpart.

Major Topics Covered

• Data dictionary (metadata reference work).
• Data repository (larger project knowledge base).
• Formal definitions for flows, structures, elements, stores.
• Practical use of the dictionary for
  • Screen/report design
  • Logic design
  • XML creation & data exchange.

What Is a Data Dictionary?

• A "reference work of data about data" → metadata.
• Collects, standardises, and coordinates data terms so everyone uses the same meanings.
• Oxford-style definition: "A set of information describing the contents, format and structure of a database and relationships between its elements, used to control access to and manipulation of the database."

Core Purposes

• Maintain consistent data definitions across projects.
• Automate cross-referencing: when an element changes, every program/table using it is automatically updated.
• Provide complete documentation and eliminate redundancy.
• Validate the correctness & completeness of DFDs.
• Furnish a starting point for designing screens, reports, files and XML.

Function List (Seven Classic Functions)

1. Provide thorough documentation.
2. Eliminate redundant data definitions.
3. Validate each DFD.
4. Give a launch-pad for screen/report prototypes.
5. Spell out file contents.
6. Support development of process logic.
7. Generate XML definitions automatically.

Data Repository vs. Data Dictionary

• Dictionary = detailed facts about data & procedures.
• Repository = larger umbrella that also holds:
  • Procedural logic / use-cases
  • Screen & report design specs
  • Data relationships
  • Project requirements & deliverables
  • PM information (budgets, schedules, issues)

How Dictionaries Tie Into DFDs

• Each DFD symbol receives an entry:
  • Flow → description, structure, element list, form.
  • Store → description, record structure, keys, volume.
  • Process → mini-spec or pseudocode.
• Ensures traceability from graphical model to textual spec.

Dictionary Categories

• Data flows
• Data structures
• Data elements
• Data stores

Describing these categories establishes a common vocabulary for analysts, developers & users.

Defining a Data Flow: Mandatory Fields

• ID (unique number) – prevents duplication.
• Unique descriptive Name.
• General description (purpose).
• Source (external entity, process, or store).
• Destination (entity, process, or store).
• Type (file, screen, report, internal, etc.).
• Structure name – pointer to element list.
• Volume/Time e.g. $10/\text{hour}$.
• Comments/notations (input media, validation rules, etc.).

Flow Types & Volume Examples

• Record entering/exiting a file.
• Report, form, or screen.
• Internal message between processes.
• Volume expressed in records/day, transactions/minute, etc.

Sample Flow Entry (Key Points)

• Name: Customer Order.
• Source: Customer (screen).
• Destination: Process 1 – Update Order.
• Volume: $10/\text{hour}$.
• Comment: order may arrive by web, email, fax, or phone.

Describing Data Structures (Algebraic Notation)

• = → is composed of
• + → and (concatenation)
• { } → repetition (zero or more occurrences)
• [ ] → either / or (mutually exclusive)
• ( ) → optional (may be blank or omit on screens)

Example – High-level Order

Customer Order =
  Customer Number + Customer Name + Address + Telephone +
  Catalog Number + Order Date + [Available Order Items] +
  Merchandise Total + (Tax) + Shipping & Handling + Order Total +
  Method of Payment + (Credit Card Type) + (Credit Card Number) + (Expiration Date)

• Optional elements wrapped in ( ).
• Choice elements wrapped in [ ].
• Repetitive group {Available Order Items} holds multiple occurrences.

Structural Records

• Structural record = group of related elements (logical “mini-structure”).
  • Example: Customer Name = First Name + (Middle Initial) + Last Name.
• Benefits of generic naming (street, city, zip): define once, reuse in many systems.

Logical vs. Physical Data Structures

• Logical – represent what the business needs; match user’s mental model.
• Physical – add implementation details such as
  • Key fields, status codes, transaction codes
  • Passwords, repeating group limits, space-filler fields

Data Element Characteristics (Element Description Form)

• Element ID / Name – descriptive & unique.
• Aliases – other common names (e.g., Receivable Account Number for Customer Number).
• Short description – concise definition or business rule.
• Base vs. Derived
  • Base → initially keyed or captured.
  • Derived → calculated by a process (e.g., Net Pay).
• Length – decided via standards (state $=2$), history, or capacity + growth.
• Data type – alphabetic, numeric, date, autonumber, etc.
• Input / Output format – templates such as $999.99$ or date masks ($MM/DD/YYYY$).
• Validation criteria
  • Discrete – fixed codes, look-up tables.
  • Continuous – numeric range checks ($>0$, upper limits, modulus-11 check digits).
• Default value – pre-filled choices to reduce keystrokes.
• Comments – truncation impact, check-digit algorithms, security flags.

Truncation Considerations

• Postal mail tolerant to truncated last name; email address is not.

Data Types & Storage Formats

• Common SQL data types: bit, char, varchar, text, datetime, decimal, float, int, money, binary, uniqueidentifier.
• Mainframe formats: packed, binary, display.
• PC/GUI presentation: Currency, Number, Scientific.
• Mask characters for screens/reports: X, 9, N, V, , . / - etc.

Defining a Data Store

Mandatory attributes:

• ID (unique) – avoids redundancy.
• Name (descriptive, unique).
• Alias (e.g., Client Master).
• Description – purpose & contents.
• File Type – computer vs. manual.
• File Format – DB table, sequential, indexed, direct, flat, etc.
• Record Volumes – max, average, $\%$ growth/year (supports disk-space & HW planning).
• Dataset/File name (if known).
• Record Structure – name referencing dictionary definition.
• Primary & secondary keys – must be constituent elements.
• Comments – purge rules, backup windows, security.

Creating the Dictionary – Timing Strategies

• After DFD is finished (documenting).
• In parallel while drawing DFD (iterative).
• Top-down: start with high-level flows & explode.

Analyzing Inputs & Outputs

For each input/output flow:

• Descriptive name.
• User contact (for clarification & approval).
• I/O indicator (input, output, or both).
• Presentation/form (screen, report, undetermined).
• Sequencing elements (e.g., Page Sequence by Zip).
• Detailed element list with
  • Length
  • Base/Derived flag
  • Edit criteria (non-blank, valid state abbreviation, numeric ranges, etc.)

Using the Data Dictionary

• Should be automated, interactive, online, evolutionary.
• Integration with other system programs enables
  • Automatic update propagation.
  • Generation of screens, reports, forms based on element definitions & lengths.
  • Code generation in  COBOL, Java, SQL, etc.
  • Design analysis → detect flaws:
  • Every base output element must appear on at least one input.
  • Derived elements must be produced by some process & appear in an output.
  • All flow elements interacting with a store must be inside that store’s definition.

Reaping Design Benefits

• Faster prototyping (layouts follow dictionary specs).
• Enhanced maintainability (single place for edits).
• Consistent validation & error-checking across programs.
• Simplifies audit & compliance documentation (SOX, GDPR—consistent data definitions).

XML – Extensible Markup Language

• Purpose: platform-independent data interchange between business partners or internal systems.
• XML documents can transform into HTML, PDF, handheld views, printed reports, etc.
• Analysts can export dictionary entries to XML  guarantees that only required data moves outside the company.

Mapping Dictionary to XML

• Each element → pair of XML tags (<lastname>James</lastname>).
• Each structure → nested tags (<address> … </address>).
• Tags themselves become metadata.
• Attributes add extra metadata inside the opening tag (<customer number="C15008">).
• Dictionary hierarchy often mirrors XML hierarchy.

Validating XML Files

• DTD (Document Type Definition) – basic grammar; determines correct element order & presence.
  • Easily generated from dictionary because analyst already set element groupings, counts, and optionals.
• XML Schema (XSD) – richer, strict typing.
  • Specifies exact data types, allowed lengths, number of occurrences (minOccurs, maxOccurs).
  • Can set numeric precision, date formats, enumeration lists, fixed values.
• Validation Tools: any XML parser (e.g., Xerces, Altova) can check an instance document against its DTD/XSD.

Ethical & Practical Implications

• Consistent dictionary prevents data ambiguity, protecting decision quality.
• Automated propagation reduces human error when altering sensitive business rules.
• XML exposure must be controlled—dictionary helps ensure minimum necessary data is shared (privacy).

Real-World Relevance & Connections

• Mailing & billing systems rely on accurate address lengths & validation rules → directly from dictionary.
• E-commerce order processing uses dictionary-generated XML for third-party logistics.
• Regulatory filings (health, finance) often require XML schema compliance—dictionary accelerates compliance.

Key Take-aways

• A data dictionary is the central nervous system of system analysis—equal in importance to DFDs and ERDs.
• Maintaining it diligently ensures valid designs, easier maintenance, faster code generation, and seamless data exchange.
• Tying the dictionary to automated tools and XML unlocks cross-platform interoperability.