Skip to main content

Data Solution

IA1:
image.png
image.png

IA2:
image.png

IA3:
image.png

Data Flow Diagram

image.png

Conventions

When students develop data flow diagrams, they should:

  • choose meaningful names for processes, flows and data stores, including
    • nouns for entities, data flows and data stores
    • verbs or verb-object names for processes that describes what the process does, e.g. check 
      credentials 
  • number processes and data stores 
  • identify data stores as
    • D — data on disk (retained even if the system is turned off)
    • M — manual data (physical files, paper records or manually processed digital data)
    • T — temporary (not retained long-term) or transient (rapidly changing, e.g. RAM, cache).

Information comes from and goes to entities and data stores via processes, therefore entities 
may not: 

  • send data directly to other entities 
  • send data directly to data stores (data must be processed first) 
  • get data directly from data stores (data must be processed first).

ER Diagram

There are two types of Entity Relationship Diagrams:

  • Chen notation style
  • Crow’s Foot/Martin/Information Engineering style

There are three tools that are useful for creating the ERD:

Data Dictionary

A data dictionary shows what data will be stored in a table. What goes into a table varies depending on the individual but the required data is:

  • Field Name
  • Field Type

Other common information is:

  • Length
  • Primary Key
  • Not Null
  • Description
  • Validation
  • Example

Sample Data

This is a table that shows what kind of data will be stored in the table. It is really useful when talking about the data. The data itself does not need to be real but similar to what might be in the system.

Example SQL

For more complex systems it might be a good idea to list the common queries that will be used by the system so you can talk about them.

  • SELECT
  • INSERT
  • UPDATE
  • CREATE TABLE

Password DB Example - Data Solution

Data Flow Diagram
ER Diagram

The database only needs a single table. At the moment the name of the site is considered to be unique and the primary key. If the user wants to have 2 different accounts at the same site they can use a slightly different name (gmail1, gmail2). Active is a hidden field that the user will never be able to see and will only interact with indirectly (1 for active and 0 for archive).

Data Dictionary

Passwords:

Field Name Type Length Primary Key Required Validation Rules
Name Text 3-20 Yes Yes
Username Text 5-20
Yes
Password Text 3-50
Yes
URL Text 0-200

Must be HTTP[s]://
Comment Text 500


Icon Blob



Active bool

Yes
Sample Data

Passwords

Name Username Password URL Comment Icon Active
Gmail apple@gmail.com 123abc https://www.gmail.com/

image.png

 True
Hotmail bannana@hotmail.com Password1 https://hotmail.com/

image.png

 True
NetFlix apple@gmail.com 123abc https://nextfix.com/

image.png

 False
Example SQL
  • UPDATE Passwords set password = ? WHERE username = ?
  • INSERT INTO Passwords(Name, Username, Password, URL, Comment, Active) VALUES (?, ?, ?, ?, ?, 1)
  • UPDATE Passwords Set Active = 1 WHERE Username = ?
  • UPDATE Passwords Set Active = 0 WHERE Username = ?

There is a problem with the database created. Have a look at the evaluation for the mistake.

Back to top