APPENDIX F

Database and SQL Fundamentals for OFA 1

A no-prior-knowledge introduction to tables, keys, relationships, basic SQL vocabulary, reading query results, and data quality.

Appendix Purpose and Scope

A.This appendix collects and expands on the data and SQL literacy content introduced across Modules 4, 6, and 7 into a single reference.
B.It is written for a learner with no prior database experience.
C.It deliberately stops short of teaching an OFA 1 to write production queries independently - that remains a technical role's responsibility.
D.The goal here is fluency as a reader and requester, not as a database developer.

Why Data Literacy Matters for an OFA

A.Nearly every system an OFA works with stores its information in a database.
B.Examples of Systems That Store Information in Databases

C.Membership records
D.Activity tracking
E.Volunteer contacts
F.Facility schedules

G.An OFA who cannot read a simple query or a simple query result is dependent on someone else to translate every data-related question, which slows down even simple work.
H.An OFA who can read data confidently, while still deferring to technical teammates for anything that writes or changes data, becomes noticeably more effective at requirements, documentation, and testing alike.

Relational Database Table Structure

A.A relational database stores information in tables, which look much like spreadsheets.
B.Each table has columns (also called fields) that define what kind of information is stored.
C.Each table has rows (also called records) that hold one instance of that information.
D.For example, a simplified Wards table might look like this:

WardID	WardName	StakeID
101	Maple Grove Ward	12
102	Riverside Ward	12
103	Sunset Ward	14

E.Each row describes one ward.
F.Each column describes one attribute of a ward.
G.Attributes Each Column Describes

H.Its identifier
I.Its name
J.Which stake it belongs to

K.This is the same basic structure underlying nearly every system an OFA will work with, even though the real tables are far larger and more numerous.

Keys and Relationships

A.Primary and Foreign Keys

B.A primary key is a column, such as WardID above, that uniquely identifies each row in a table - no two wards share the same WardID.
C.A foreign key is a column in one table that refers to the primary key of another table, which is how databases represent relationships between things.
D.In the example above, StakeID in the Wards table is a foreign key pointing to a separate Stakes table.
E.This means each ward belongs to exactly one stake, but a stake can have many wards.

F.The One-to-Many Pattern

This "one-to-many" pattern is the most common relationship structure an OFA will encounter.

Examples of the One-to-Many Pattern

1.One stake, many wards
2.One ward, many members
3.Recognizing this pattern helps make sense of how a system is organized even before looking at a single query.

Basic SQL Vocabulary

A.Core SQL Keywords

B.SQL (Structured Query Language) is the standard language for asking a relational database questions.
C.For those authorized to do so, SQL is also used to change what a database contains.
D.An OFA 1 needs to recognize the following building blocks, in roughly the order they appear in a typical query:

Keyword	What It Does	Plain-Language Translation
SELECT	Specifies which columns to return	"Show me these pieces of information..."
FROM	Specifies which table to look in	"...from this table..."
WHERE	Filters which rows to include	"...but only the rows that match this condition..."
ORDER BY	Sorts the returned rows	"...sorted in this order."
JOIN	Combines rows from two related tables using a shared key	"...matched up with related information from another table."

E.Reading a Sample Query

Putting these together, a query that lists ward names in the Riverstone Stake, sorted alphabetically, combining the Wards and Stakes tables, might look like this:

F.> SELECT Wards.WardName, Stakes.StakeName > > FROM Wards > > JOIN Stakes ON Wards.StakeID = Stakes.StakeID > > WHERE Stakes.StakeName = 'Riverstone Stake' > > ORDER BY Wards.WardName;

G.An OFA 1 should be able to read this query and describe in plain language what it returns.

The query returns a list of ward names in Riverstone Stake, alongside the stake name, sorted alphabetically by ward.

H.An OFA 1 is not expected to write a query like this unassisted.
I.That remains the responsibility of a qualified technical resource.

SELECT Wards.WardName, Stakes.StakeName FROM Wards JOIN Stakes ON Wards.StakeID = Stakes.StakeID WHERE Stakes.StakeName = 'Riverstone Stake' ORDER BY Wards.WardName;

Interpreting Query Results

Interpreting a Query Result

1.A query result is itself just a small table.
2.Reading it carefully matters as much as understanding the query that produced it.
3.Two common pitfalls are worth watching for:

Common Pitfalls When Reading Query Results

1.A blank or "NULL" value in a result does not always mean zero or "no."
2.It typically means the information was never recorded, which is a different problem than the information being recorded as absent.
3.A result with more rows than expected often indicates a JOIN has matched rows in an unexpected way.
4.For example, this can return one row per activity a member attended, rather than one row per member.
5.When a result looks larger or smaller than expected, the right response is to ask a technical teammate why, not to assume the extra or missing rows are a data problem.

Data Quality Concepts

Standard Data Quality Dimensions

Data quality is commonly described using a handful of standard dimensions, drawn from data management frameworks such as DAMA-DMBOK, that are useful vocabulary for an OFA supporting a migration or integration.

Dimension	What It Means	Example Problem
Accuracy	The data correctly reflects reality	A member's recorded address is out of date
Completeness	All expected data is present	A required field, such as activity date, is blank on many records
Consistency	The same fact is represented the same way everywhere it appears	One ward records dates as MM/DD/YYYY and another as DD/MM/YYYY
Timeliness	The data is current enough to be useful	A report reflects last quarter's numbers when this quarter's are needed
Uniqueness	Each real-world thing is represented by exactly one record, not several	The same volunteer appears twice under slightly different name spellings

These dimensions are exactly what Module 10's data migration business case is training an OFA to notice, now given their standard industry names.

What OFA 1 Should Be Able to Do With Data

Core Data Literacy Skills

1.Read a simple table of data and describe what it shows in plain language.
2.Read a simple SELECT query, with or without a WHERE clause, and describe what it returns.
3.Recognize the data quality dimensions above when reviewing a sample of real records.
4.Ask a precise question of a technical teammate when a query or its result is unclear, rather than guessing.

What Comes Next at OFA 2

OFA 2 Data Expectations

At OFA 2, an OFA builds on all of the above, performed independently rather than under close guidance.

New Skills an OFA 2 Begins to Develop

1.Adjust a filter value, such as a date, name, or ID, in an existing, reviewed query with light technical guidance.
2.Draft a data lookup request specific enough for a technical teammate to act on without a follow-up clarifying conversation.
3.Interpret a query result well enough to identify whether it answers the original business question.
4.None of this is expected of an OFA 1.

When to Escalate to a Technical Resource

Escalation Triggers

An OFA 1 should always route a request to a technical teammate or database administrator, rather than attempting it directly, whenever one of the following conditions applies:

Conditions That Require Escalation

1.The request would write, update, or delete any data rather than only read it.
2.The query would need to be run against a live production system rather than a test or reporting environment.
3.The data involved is confidential (personal, financial, or otherwise sensitive).
4.The OFA is not fully confident they understand what a query will do before it runs.
5.None of these are a sign of insufficient skill.
6.They are the correct, expected behavior at this level, and remain good practice well beyond it.

Practice Exercises

Exercise Set

Exercise 1

Given the Wards and Stakes tables shown earlier, write in plain language what the following query returns, without running it: "SELECT WardName FROM Wards WHERE StakeID = 12 ORDER BY WardName."

Exercise 2

1.A colleague shares a query result with three columns (MemberID, ActivityDate, Attended) and says some rows show a blank ActivityDate.
2.In plain language, explain what a blank ActivityDate most likely means and what question you would ask before assuming it indicates a data error.

Exercise 3

Using the Data Lookup Request Template in Appendix C, draft a request asking a technical teammate to identify all wards with no recorded activity in the last two months.

Common Data Terms Reference

Data and Systems Terminology

1.Beyond the SQL vocabulary above, an OFA will regularly encounter the following data and systems terms in conversation, documentation, and reporting.
2.This reference is meant for recognition, not mastery.

Term	Plain-Language Definition
Normalization	Organizing data across multiple related tables to avoid storing the same fact redundantly in more than one place
Referential integrity	A database rule ensuring a foreign key always points to a row that actually exists, preventing "orphaned" references
Index	A structure that helps a database find rows faster, similar to an index at the back of a book
Stored procedure	A saved, reusable set of SQL statements that a technical team can run without rewriting the logic each time
ETL (Extract, Transform, Load)	The standard process of pulling data out of a source system, reshaping it, and loading it into a destination system, most relevant to data migrations
Data warehouse	A large, centralized store of data pulled together from multiple systems, typically used for reporting rather than day-to-day transactions
Batch job	A process that runs on a schedule (such as nightly) and processes a group of records at once, rather than reacting instantly to a single event
Real-time processing	Handling data or a request immediately as it occurs, rather than waiting for a scheduled batch job

Appendix E Appendix G