D427 Data Management - Applications appears under banner number ITEC 2117 and is worth 4 competency units. It moves from modelling into working with a live database: conceptual modelling in MySQL, retrieval from simple selection through subqueries and joins, and the creation and modification of databases, tables, views, primary and foreign keys, and indexes. D427 and ITEC 2117 name one requirement. This is the course where students stop reading about relational data and start getting answers out of it.
Joins are the course, and everything else supports them
Almost every difficulty students report in D427 traces back to a join misunderstood. An inner join keeps rows that match on both sides, so it silently discards anything unmatched. A left join keeps every row from the left table and fills the right with nulls where nothing matched, which is why it is the tool for finding what is missing. Once you can predict the row count of a join before running it, subqueries and views stop being separate topics and become ways of naming a result set you already understand.
Subqueries are the second gate. The distinction worth learning is between a subquery that runs once and produces a value or a set for the outer query to use, and a correlated subquery that runs again for every row of the outer query. The first is usually fast and the second is usually the reason a query that worked on ten rows takes a minute on ten thousand. Knowing which kind you wrote is often the entire answer to a performance aspect.
Views and indexes then round the course out with two different promises. A view names a query so people stop rewriting it and stop getting slightly different answers. An index trades storage and write speed for read speed on specific columns. Neither is free, and an aspect asking you to justify one is asking what it cost.
Work here returns Competent or Not Competent, without letter grades, and WGU keeps no ordinary grade point average, with 4 competency units describing its share of a flat-priced six month term. Since term pricing is flat, closing a query-heavy course promptly is straightforwardly worth money.
Building the plan out of scored aspects
If your version of D427 is assessed by a performance assessment, expect aspects that are proven by a query and aspects that are proven only by explanation. WGU requires a score of 2 in each aspect for a task to pass and judges each aspect separately, so a set of correct queries with no justification leaves half the rubric untouched.
Do the arithmetic first. Take eight scored aspects with a written component near 1,600 words alongside your SQL. Reserve 110 words for context naming the database, its version and the scenario, and 90 for the close, leaving 1,400. If five aspects are demonstrated by queries, allow 120 words each to state the business question, point at the query and show the result, which is 600. The remaining 800 covers three explanatory aspects at roughly 266 each, enough for a decision, its cost and the alternative. Everything totals 1,600 and nothing is orphaned.
The habit worth carrying: write the business question above every query, in one sentence, before the SQL. It forces you to know what you are asking, it gives the evaluator the context to judge whether the query answers it, and it makes the whole document readable by someone who does not want to parse SQL to follow your argument.
Shape for a query and implementation deliverable
D427 work generally produces scripts plus a document. The proportions below apply to the document.
| Section | Content | Share |
|---|---|---|
| Environment | Database system and version, schema loaded, and how to reproduce your starting state. | 7 percent |
| Schema summary | Tables, keys and relationships as implemented, with anything that differs from the supplied model called out. | 13 percent |
| Retrieval work | Each business question, its query, and the result set, moving from simple selection to joined and nested cases. | 26 percent |
| Join reasoning | Why each join type was chosen and what would change if it were swapped. This is the highest-value block. | 17 percent |
| Views and indexes | What was created, who benefits, and what each one costs in maintenance or write performance. | 17 percent |
| Integrity and constraints | Keys enforced, referential actions chosen, and what happens on delete or update. | 12 percent |
| Close | What you would tune first if the data grew tenfold. | 8 percent |
Evidence in an applied query course
Your strongest evidence is output. A query pasted without its result proves you typed something; a query with the returned rows, or with a row count where the set is large, proves it did what you claim. Where a result is empty, say so and explain why the empty set is the correct answer, because an unexplained empty result reads as a failure rather than a finding.
For behavioural claims, cite the documentation of the database system by name and version. Join semantics, null handling, index types and referential action behaviour all vary between systems in documented ways, and generic SQL advice from a tutorial site is exactly the sort of source that turns out to be describing a different product. Where you make a claim about performance, either measure it and report what you measured, or frame it as reasoning from how the operation works rather than as a fact.
Sample data deserves the same care as sources. If you built your own test rows, say how many and what edge cases you deliberately included: a customer with no orders, an order with a null field, a duplicated name. Those rows are what make a left join visibly different from an inner join in your output, and a reader who can see the difference in your results does not have to take your join reasoning on trust. Test data chosen to exercise the interesting cases is itself a demonstration of understanding.
Follow the citation style named in your task and place each reference beside the claim it supports. Consistent formatting is not cosmetic here: a document where every query is laid out the same way lets an evaluator scan for the join clause in two seconds, and readability is quietly part of how work gets judged.
What passes and what returns
Competent submissions read as though a competent analyst wrote them for a colleague. Each query has a question above it and a result below it, join choices are explained rather than assumed, and views and indexes come with a stated cost. The schema section matches what the scripts actually build.
Returns concentrate in four places. Queries appear with no results, so correctness cannot be judged. Inner joins are used everywhere by habit, quietly dropping the rows the question was actually about. Indexes are added to every column as though they were free. Or the explanation aspects are answered with descriptions of what SQL keywords mean, which spends the word budget on material the evaluator does not need.
Before submitting, run one check that takes five minutes and prevents most of the above. For each query in your document, write down the number of rows you expect, then run it and compare. Where the numbers differ, you have either found a bug or discovered something about the data worth writing a sentence about. Both outcomes improve the submission, and doing this systematically is the closest thing this course has to a guaranteed quality gain.
None of it is expensive to fix. Performance assessment work at WGU can be revised and resubmitted without a grade penalty, so submit once every aspect has a real answer. If your section also carries an objective assessment, note that WGU objective assessments are proctored, and our line does not move: we prepare with query drills, join reasoning practice and a candid read on your preassessment result. We will not take your exam, are absent for the whole of it, and we would refuse portal credentials if they were offered.
Queries return the wrong rows?
Send the D427 rubric and your SQL. We work through join logic with you and return a headed document plan with word targets.
Seven mistakes that cost time in D427
- Defaulting to inner joins. They silently drop unmatched rows, which is often exactly the population the question was about.
- Not predicting row counts. Estimate before you run. A result ten times larger than expected usually means a join condition is missing.
- Correlated subqueries by accident. If the inner query references the outer one, it runs per row. Know when you have done that and whether you meant to.
- Indexing everything. Indexes cost storage and slow writes. An index aspect wants the tradeoff, not enthusiasm.
- Ignoring nulls. Null is not zero and not an empty string, and comparisons involving it behave in ways that quietly change results.
- Queries without results. Output is the evidence. Without it the evaluator has to run your script to score you, and may not.
- Explaining SQL keywords. The evaluator knows what a join is. Spend the words on why this join, on this data, for this question.
Three questions students ask about D427
Do I need D426 before starting D427?
Does it have to be MySQL?
How complex do the queries actually get?
Where D427 sits in WGU's programs
The July 2026 catalog places this code in 8 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.