D597 Data Management, catalog number DTAN 5216, is a three competency unit graduate course in the WGU School of Technology. The catalog describes it as building proficiency with relational and non relational databases, covering storage architecture, data types and structures, normalization and querying. The word that shapes the whole course is and. This is not a relational course with a chapter about alternatives at the end. It asks you to hold two storage models side by side and choose between them for a stated use, which means every design decision you make has to be argued rather than assumed.
Choosing a model, then defending the choice
Relational design earns its place through guarantees. A schema declared in advance, types enforced, relationships constrained by keys, and transactions that either complete or leave nothing behind. Those guarantees cost you flexibility and they cost you joins at read time, and both costs are acceptable in exchange for data you can trust.
Non relational stores trade differently. A document store lets structure vary between records, which suits data whose shape is genuinely irregular and whose access pattern is retrieval by key rather than combination across entities. A key value store is faster still and knows almost nothing about what it holds. A wide column store spreads a very large table across machines. Each buys scale or flexibility by giving up something the relational model provides for free, usually enforcement, and the giving up is silent, which is why designs that pick a document store for well structured transactional data end up rebuilding validation in the application layer.
Graduate rubrics in this space almost always want the comparison made against a use case rather than in the abstract. The strongest submissions state the access pattern first, meaning what gets read, how often, by what key and in what combination, then choose. The weakest describe both families accurately and then pick one for reasons that would apply to any project.
Normalization is the other half, and it is a place where students either overshoot or undershoot. First normal form removes repeating groups so each cell holds one value. Second removes partial dependence on part of a composite key. Third removes dependence between non key attributes. The point of all three is that a fact lives in exactly one place, so an update cannot leave the database disagreeing with itself. What graduate work adds is knowing when to stop: a reporting table that is denormalised on purpose, with the reason and the refresh mechanism stated, is a design decision rather than an error.
Turning scored aspects into a section plan
WGU keeps scoring detail inside your Course of Study rather than in the public catalog, so open the rubric and count aspects before you design anything. Each aspect is scored on its own and a score of 2 in each aspect passes the task. Nothing averages, so a normalised schema will not carry a query section whose results are never explained.
Take headings from the rubric's nouns. Database deliverables tempt students into a build narrative, and a build narrative hides the justification aspects inside descriptions of what they did next.
The word budget, worked. Assume seven scored aspects and directions asking for roughly 2,200 words alongside schema and query artifacts. Reserve 150 for the business scenario and 100 for the close, leaving 1,950 across seven aspects, or about 280 each. Then reweight. The aspect asking you to justify the storage model needs a use case, the comparison and the decision, so lift it to 450. The normalization aspect needs the dependencies shown and each step explained, so give it 400. Aspects whose evidence is mostly artifact, such as the schema itself or the queries, compress to 180 of narrative each because the artifact carries the weight. The total still lands near 1,950.
Before submitting, check that every table in your schema has a stated primary key and that every relationship has a stated cardinality. Those two facts answer a surprising share of design aspects on their own.
A structure that fits a database design deliverable
Where the task directions specify a structure, follow it exactly. Where the shape is open, this arrangement keeps design decisions separable from build steps and makes each aspect easy to locate.
| Section | What belongs in it | How it gets scored |
|---|---|---|
| Scenario and requirements | The organization, what it stores, and the questions the data has to answer | Frames the design; requirements stated as entities rather than questions weaken later justification |
| Access patterns | Reads and writes, their frequency, their keys and their latency needs | Scored where named; the section that makes the model choice arguable |
| Model selection | Relational or non relational, compared on the requirements above, with the trade off accepted | Scored on the argument, not on the popularity of the choice |
| Conceptual and logical design | Entities, attributes, relationships, cardinality and keys | Scored on completeness; missing cardinality is a frequent gap |
| Normalization | The dependencies, the form reached, and any deliberate denormalisation with its reason | Scored on the reasoning through each form rather than on the end state |
| Physical considerations | Data types, sizes, indexes, constraints and storage architecture | Scored on fit; oversized text columns and missing constraints both show |
| Queries | The statements that answer the stated questions, with results and an explanation | Scored on whether each query answers a question you raised earlier |
| Governance | Access control, retention, backup and who owns definitions | Scored where named; graduate rubrics usually name it |
| References | Textbook, documentation and standards, APA formatted | Scored where citation is named in the aspect |
Evidence craft when the deliverable is a schema
Design work is evidence in itself, but only if it is legible. An evaluator has to be able to read your schema without running it, which puts the burden on naming, annotation and consistency.
- Name objects consistently and say what convention you used. Mixed conventions inside one schema read as unplanned.
- Choose data types deliberately and justify anything unusual. A date stored as text is a design error that propagates into every query.
- Show the dependencies when you normalise. The functional dependency list is the evidence; the resulting tables are only the outcome.
- Include the actual statements, formatted and readable, where the directions allow artifacts. A described query cannot be checked.
- Show results with row counts, and explain what each result means for the question it answers.
- Cite documentation for any engine specific behaviour and a textbook or standard for design principles, in APA.
The move that reads as graduate work is stating the failure mode of your own design. Every schema has one: a query that will get slow as a table grows, a constraint that will annoy an application team, a denormalised table that will drift if its refresh fails. Naming it and describing the monitoring that would catch it demonstrates ownership rather than optimism.
What separates Competent from a submission sent back
Aspects are scored independently, so returns are usually narrow. The most common cause in this course is a normalization section that presents finished tables without showing the dependencies that justified them.
- The model choice refers to a stated access pattern rather than to general properties.
- Every entity has a primary key, every relationship has a cardinality, and foreign keys are shown.
- Normalization is worked through form by form, with the dependency that each step removes named.
- Every query traces to a question stated in the requirements section.
- Any denormalisation is deliberate, labelled and explained, including how the copy stays current.
Performance assessment work at WGU can be revised and resubmitted without a grade penalty, so a return costs time only. In a six month flat rate term that time competes directly with the next course, and design tasks are unusually easy to fix before submission and unusually slow to fix after, because a schema change ripples through every query and every screenshot.
Six mistakes that cost time in D597
- Choosing a non relational store because it is modern. The choice has to come from the access pattern, and a rubric that scores justification will not accept fashion.
- Normalising to third form by memory. The scored content is the dependency analysis. Skipping it leaves the aspect with nothing to grade.
- Ignoring cardinality. A relationship without a stated multiplicity leaves the design ambiguous and often hides a missing junction table.
- Writing queries that answer nothing asked. Each statement should map to a requirement, or it is a demonstration rather than a deliverable.
- Using text types for everything. It works and it destroys sorting, comparison and validation, and evaluators of a graduate course will say so.
- Leaving governance out. Access, retention and ownership are cheap to write and frequently scored, which makes omitting them an avoidable loss.
How support works on this course
Send the rubric from your Course of Study, the task directions and the scenario. The work comes back aspect mapped: access patterns stated before the model choice, a comparison that reaches a decision and accepts a trade off, a schema with keys and cardinality shown, normalization worked through the dependencies rather than asserted, queries tied to stated questions, and a governance section. The walkthrough explains why each decision follows from the requirements, which is the reasoning the rest of the graduate sequence assumes.
Where a proctored objective assessment sits on this course, the boundary is fixed. Proctored exams are yours to sit. We prepare only, with practice schemas, drilled normal forms and query exercises plus an honest go or wait read. We never sit assessments and we never ask for portal credentials.
Questions students ask about D597
Is D597 the same course as DTAN 5216?
How much SQL do I need before starting?
Does the course expect me to use a specific database engine?
Schema drafted but the justification is missing?
Send your rubric and scenario. You get an aspect mapped draft with access patterns stated first, dependencies shown and every query tied to a requirement.
Where D597 sits in WGU's programs
The July 2026 catalog places this code in 3 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.