CSE1IS Information Systems
Week 6

System (Data) Dictionary

• Preliminary investigation/analysis reveals detail about data.
• Dataflow diagrams show the flow and processing of this data,
  .....but supporting documentation is required to explain and document the detail.  
• i.e. details of
  • data flows
  • external entities
  • data stores
  • processes
• and ...
• • data structures
  • data elements

This supporting documentation is known as the System or Data Dictionary.  

• component name and/or number
• aliases
• definition and/or description
• notes

1. Data Structures (of data):

A Data Structure can be (loosely) defined as a data item composed of multiple other related data items,
eg. invoice = inv# + customer details + inventory details + ....
Data Structures can be composed with 3 operations:

1.1 Sequence:

• eg.: Employee_Name = Firstname + Middle_Initial + Lastname
• "+" links the data elements or data structures together to form the data structure "Employee_Name"

1.2 Selection:

• eg.: Daily_Assignment = [ RDO_Date | Work_Date + Work_Task ]
• [ ] indicates a selection and the choices are separated by the vertical bar "|"

1.3. Iteration:

• A data structure may consist of a number of occurances of another data structure or data element
• eg.: Monthly_Schedule = 28{ Daily_Task }31
• { } indicates an iteration with the optional minimum and maximum values

2. Hierarchy of a Data Structure:

A data structure comprises a set of data used by a business that appear as data flows on the DFDs.
Such a set is like the data fields used on a form such as a time sheet or monthly work schedule.

Take a lecturer's subject administration system as an example:

• A "Tutorial List" has been identified as a data flow (in the both the context and level 0 diagrams)

• CSEIS: Information Systems Tutorial List Group 2   Times: Wed 9:05/B209, Thu 9:05/B209   Tutor: Brian
  Firstname	Lastname
  Lleyton	Hewitt
  Alicia	Molik
  :	:

    
• This form contains 2 main sets of data:
  • once-off heading
  • repeated student names

2.1 Documenting the Tutorial List Data Flow:

As specified on page 169 of S.C.&R., full documentation (see Fig 4-28), or as required by CASE programs including Visible Analyst (see Fig 4-28b), includes:

data flow name:	tutorial list
alternate name:	<none>
abbreviation:	<none>
structure (record):	tutorial_list_heading + tutorial_details + { student }
description:	a listing for tutors to record attendance
origin:	process 2 - Generate Lists
destination:	external entity - Tutors
volume & frequency:	10 listings produced twice a year

Notes:

1. Entries are only provided for alternative names and abbreviation if they exist. In most cases they will be left blank.
2. The structure or record entry documents the way in which the data flow is structered. In this case it can be broken down (decomposed) into a series of simpler data structures. The use of {} indicates repetition i.e. A tutorial list consists of one heading, one set of tutorial and tutor details and many students. (For each student there is a student_firstname and a student_lastname.)
3. The origin  and destination of the data flow is documented. Possibilities are (i) an external entity (the destination in this case), a process (the origin in this) or a data store.
4. Volume & frequency documents the number of examples of the data flow, and also how often the data flow occurs
5. Every entry in the system (data) dictionary must have a unique name.

2.2 Decomposition into Data Elements:

Data Element is a single piece of data.
Data structures are required to be decomposed into their data elements.
(Data structures are in italics and data elements in bold):

• tutorial list = tutorial_list_heading + tutorial_details + { student }
• tutorial_list_heading = subject_code + subject_name
• tutorial_details = tutorial_group + 1{ tut_time + tut_room }2 + tutor_name
• student = firstname + lastname

2.3 Documenting a Data Element:

As specified on page 168-169 of S.C.&R., full documentation includes:

data element name:	tutorial_group
alternate names:	<none>
type & length:	numeric, 0 decimals
output format:	99
default value:	<none>
prompt/column heading:	GROUP:
source:	external entity - Head of Dept
security:	lecturer
responsible end user:	lecturer
acceptable values:	1 to 10
other validation:	unique valuewithin subject
derivation formula:	sequence starting at 1 within each subject
description/comments:	uniquely identifies each tutorial grp

 Notes:

Sometimes it is more convenient to document data elements in tabular form and restrict the entries to name, type and
length, acceptable (or valid) values, other validation. (One row per data element :-). When doing this collate like data elements together under an appropriate heading. eg.:

Student data elements
name	type	acceptable values	validation/comments
student_id	character(8)	99999999	first digit 9 or 2
firstname	char(25)	alpha only	allow for international char symbols
:	:	:	:

2.4 Documenting Data Stores:

• Almost by definition, data in data stores are related, so document similar to the student data elements table above.
• Include the data store number and name in the heading
• Include input and output flows
• Specify any Primary Keys (unique identifier for each record)
• S.C.&R. Fig 4-29 displays full documentation in Visible Analyst.

2.5 Documenting Processes:

• Includes process number and name
• Process description
• Include input and output flows
• Processes are "doing something" and is where any decision making involved in the system will occur.
• Logic for decisions required may be expressed as Decision Tables, or in Structured English (Pseudocode?)
• Examples of processes that involve a decision:
  • Verify Order (or enrolment etc.) -
  • Enrol in Subject - have prerequisite conditions been satisfied
  • Grant a Loan
  • Calculate Commission (or Discount) - algorithm may involve comparing multiple factors

2.5.1 Decision Tables:

• A Decision Table may have multiple outcomes, not just accept or reject
• Process for creating a Decision Table:
  1. list all conditions
  2. list all outcomes
  3. create a table listing every combination of conditions
  4. specify outcome for each combination
  5. group combinations with the same outcome together and simplify table, if possible
• S.C.&R. Fig 4-39 of the Verify Order process is a very good example:
  
• S.C.&R. Fig 4-36 displays full documentation in Visible Analyst including the logic required expressed in Structured English.

2.6 Documenting External Entities:

• Entity name, description and alternate names
• Include input and output flows
• S.C.&R. Fig 4-31 displays full documentation in Visible Analyst.

3. Examples:

3.1 Decomposition Example:

3.2 Decision Table Example:

The process "Enrol in Subject" uses the following logic:

A student can enrol in a subject if the student has satisfied all prerequisites, although if a subject has partially satisfied prerequisites (eg. one out of two) then the student can enrol with the subject coordinator's permission. However, all prerequisite requirements can be waived with the course coordinator's permission.

References:

• Shelly, Cashman & Rosenblatt, Systems Analysis and Design, 6th Edition,  Course Technology, 2006.

copyright © 2006 Brian Retallick. This page last updated on Tuesday 26 August 2008 by Noel McEwan, La Trobe University, Bendigo