Data dictionary requirements, I have not been clear enough on the structure of the data dictionary for the

project. Here are the formatting and referencing requirements for the data dictionary. There were partially provided on Slide 96 from the presentation MSIS 3303 Spring 2011 W8 3-1-2011 LM+DD and in the project requirements. Notes: CONTENT and SPECIFICTY is more important than LENGTH; avoid wasted white space and using narrow margins or tables to make it longer. It should be structured and detailed; but tight in terms of space usage. It needs to be as FULLY cross referenced as possible. All entries need to be included in the DD Table of Contents and the DD Index. Here I have specifically laid out the structure your data dictionary should follow: This is based on what we went over in class, the book and the project requirements. Examples are given for formatting. Throughout the document where you refer to another item in the document you must cross reference it to the page where the referenced item. I have put p# in the examples in most places to represent the page number the item can be found on.

The content SHOULD include information about the data (metadata) in the following SECTIONS and formats. Title: Data Dictionary Data Dictionary Table of Contents The DD must have its own detailed TOC for each section, subsection and item. The body of the DD should start on a new page AFTER the DD TOC 1. Data-Flow Model consisting of details of the Functional Design for all elements of the Data Flow Diagrams (DFDs) a. Processes/Transforms Examples Process 1.0 appropriate name Description Explain what the process does Parent CD (note CD for level zero diagram) P# cross reference Functional Primitive No Children 1.1 Name p# 1.2 Name p# 1.3 Name p# Inflows Name of each on a separate line with cross reference to page# second inflow P# etc. Outflows Name of each on a separate line with cross reference to page# second Outflow P# etc. Lower level example Process 1.1 appropriate name Description Explain what the process does Parent 1.0 appropriate Name P# cross reference Functional Primitive Yes Inflows Name of each on a separate line with cross reference to page# First inflow P# Source: name of (DF, EE or Process FP level)

second inflow P# Source: name of (DF, EE or Process FP level) etc. Outflows Name of each on a separate line with cross reference to page# First Outflow P# Destination: name of (DF, EE or Process FP level) second Outflow P# Destination: name of source (DF, EE or Process FP level) etc. Logic Model for functional Primitive Here put the structured English Minispec or the decision tree/table Process 1.2 appropriate names Etc.. Process 2.0 Appropriate name Etc Process 2.1 Appropriate name Etc Process 2.1.1 Appropriate name Etc REPEAT for ALL Processes b.Data Flows (each one must be CLEARLY defined like this and ALSO the fields must be cross referenced to the DATA MODEL Attribute section where each is described in great detail.) Examples: (note you may have additional detail if required.) Customer Order Description Name Customer Order Aliases (if any) Description Contains customer order information and is used to update the customer master and item files and to produce an order record. Source Customer External Entity (page# cross reference here to the source) Destination Process 1, Add Customer Order (page# cross reference here to the destination) (if this is a process it should be the lowest level process functional primitive) Type Screen Data Structure Order Information Volume/Time 10/hour Comments An order record contains information for one customer order. The order may be received by mail, fax, or by telephone. Any other details required. High Level Data Structure Order Information Customer Order = Customer Number + 32 ( this is the cross reference page # to ERD attribute definition) Customer Name + 33 Address + p# Telephone + # Catalog Number + # Order Date + # {Order Items} + ETC.. INCLUDE cross references for all elements to ERD attribute page Merchandise Total + (Tax) + Shipping and Handling + Order Total +

Method of Payment + (Credit Card Type) + (Credit Card Number) + (Expiration Date) Detailed Structural Records (for compound items) Customer Name = First Name + (Middle Initial) + Last Name Address = Street + (Apartment) + City + State + Zip + (Zip Expansion) + (Country) Telephone = Area code + Local number Note: The Element level is in the Data Model attributes and is cross referenced as above. Repeat for all Data flows c. Data Stores (each one must be CLEARLY defined like this and ALSO the fields must be cross referenced to the DATA MODEL Attribute section where each is described in great detail.) Also every item (field attribute) in a Data Store MUST be accounted for from a DATAFLOW or a calculation in a process.) Examples: (note you may have additional detail if required.) D1 Customer Master Alias Description File Type File Format Record Size Maximum Records Average Records Percent Growth/Year Data Set/Table Name Copy Member Data Structure Primary Key Secondary Keys Inflows

Outflows

Client Master Contains a record for each customer Computer Database 200 45,000 42,000 6% Customer Custmast Customer Record Customer Number Customer Name, Telephone Name of each on a separate line with cross reference to page# First inflow P# Source: name of (DF, EE or Process FP level) Second inflow P# Source: name of (DF, EE or Process FP level) etc. Name of each on a separate line with cross reference to page# First Outflow P# Destination: name of (DF, EE or Process FP level) Second Outflow P# Destination: name of source (DF, EE or Process FP level) etc. copied to a history file and purged if the customer has not purchased an

Etc. whatever other details are required Comments The Customer Master file records are

item within the past five years. A customer may be retained even if he or she has not made a purchase by requesting a catalog. Data Structure ( List all elements at lowest level) (Every item (field attribute) in a Data Store MUST be accounted for from a DATAFLOW or a calculation in a process.) Customer Number + 32 (cross referencepage # to dataflow item (field/attribute) First Name + 35 (Middle Initial) + 37 Last Name 37 Street + 34 (Apartment) + P# City + P# State + P# Zip + P# (Zip Expansion) + (Country) Area code + Local number D2 Appropriate name Etc D3 Appropriate name Etc Continue for all data stores d. Sinks/Sources Appropriate Name Description Type Inflows Textual description Person, Business, internal department, computer system, what it is specifically Name of each on a separate line with cross reference to page# First inflow P# Source: name of (Process FP level) Second inflow P# Source: name of (Process FP level) etc. Name of each on a separate line with cross reference to page# First Outflow P# Destination: name of (Process FP level) Second Outflow P# Destination: name of source (Process FP level) etc.

Outflows

2.

Data Model (consisting of details of all elements of the Entity Relationship Diagrams (ERDs), other sections cross reference it for details) Entities (if any) Contains customer information to be stored in the database Strong/Weak/Associative List all other entities that this one is related to on a single line Order Shipment Etc.

Example Customer Aliases Description Type Relationships

Customer Attributes (this is where detailed meta data is defined that the other sections cross reference to) All Attributes should be defined in as much detail as possible.

Consider ALL of the following Entries (fields) where appropriate: Attribute Name: following specific standard conventions Required: Y/N Null: Y/N Unique: Y/N (means no duplicates allowed is a candidate key) Permanency: Y/N can it change value over time? If not why not? Primary Key: Y/N note PKs cannot be Null must be unique and must be permanent Autoincrement: Y/N Candidate Key: Y/N Foreign Key: Y/N (references field in table) References FIELD in TABLE Data Type: Be very VERY specific use an actual type be detailed Precision: if needed number of decimal places Length: for characters or text Mask: Range: x to xxxx will determine the data type for numeric attributes Domain: Set of valid values enumerated like days of week (Su,M,T,W,Th,F,Sa) Default Value: if f there should be one specify it explicitly

Repeat for all entities (note this also included associative entities) Relationships A relates to B (simple name) Description Relates A to B in a specific Way Business Rule (write business rule from both sides including both modality and cardinality) Each Instance of Entity A is associated with from zero to 5 instance of entity B Each Instance of Entity B is associated with 1 and only 1 instance of entity B

3.

an Interface Specification, consisting of forms, reports, screens, menus, dialogs, warning and error messages. For each include a screen capture and also if needed list out the field names and cross reference their associated to the data model attributes.d

Forms Name: Screen Capture Likst of all items and fields ( cross reference fields to ERD entity definition page ) Reports Screen Prototypes Dialog Boxes Error and Warning Messages Menu Screens Other Elements