D426 Data Management - Foundations is listed under banner number ITEC 2116 and carries 3 competency units. Its work is modelling: producing conceptual, logical and physical data models, then building and normalizing databases and tables inside a SQL-enabled database management system. D426 is the current version of this material. The legacy entry with the same title is C175 under banner ITEC 2104, and only the code shown on your Degree Plan will close your requirement.
Three models, one subject, deliberately separated
The reason this course insists on three levels of model is that each answers a different question. The conceptual model asks what things the business cares about and how they relate, in language a manager would recognise, with no keys and no data types anywhere. The logical model turns those things into relations with attributes, keys and cardinalities, still without committing to a product. The physical model commits: this database system, these column types, these indexes, this storage decision. Students who collapse the three into one diagram lose the ability to explain why anything is the way it is, and explanation is what the rubric aspects usually want.
Cardinality is the concept that repays the most attention. Getting one-to-many the right way round, recognising a many-to-many that needs an intermediate table, and noticing an optional participation are the skills that decide whether the logical model survives contact with real data. Draw relationships in both directions and read them aloud as sentences. A customer places many orders; an order is placed by exactly one customer. If either sentence sounds wrong, the model is wrong, and it is far cheaper to find that on paper than after you have built and loaded the tables.
Normalization is the other half. Its purpose is not tidiness, it is preventing update anomalies, and framing it that way makes each normal form memorable. First normal form removes repeating groups so a value has one place to live. Second removes partial dependencies on part of a composite key. Third removes dependencies between non-key attributes. Almost every question you meet at this level can be answered by asking which anomaly the current design still permits.
Assessment closes as Competent or Not Competent, and neither letter grades nor an ordinary grade point average are recorded, and 3 competency units is how the course's weight is expressed in a six month flat-rate term. Closing a modelling course early is worth more than the units suggest, because the courses that follow it are heavier.
Turning aspects into modelling deliverables
Where D426 is assessed by a performance assessment, the scored aspects usually map onto artifacts as much as onto prose: a diagram, a script, an explanation. WGU requires a score of 2 in each aspect for a task to pass and scores each one alone, so producing three beautiful diagrams while leaving the normalization justification unwritten earns a return, whatever the diagrams look like.
Budget both kinds. Suppose the rubric shows six scored aspects, three satisfied by artifacts and three by explanation, with a written component near 1,400 words. Artifact aspects need locators: 100 words each naming the file, what it shows and how to read it, which is 300. The remaining 1,100 goes to the three explanatory aspects at roughly 366 each, which is enough to state a decision, show the anomaly it prevents, and name the alternative you rejected. Add a 90 word opening naming the scenario and the database system and you land near 1,490, so trim one explanatory block to 300 and the plan fits.
The reusable idea: the more visual your artifact, the shorter its prose should be, and the more the written aspects should carry justification the diagram cannot express. A diagram shows what you decided. Only prose can show why the alternative was worse.
Shape for a modelling and normalization deliverable
The typical D426 submission includes models, a build script and a document. The proportions below apply to the document.
| Section | Content | Share |
|---|---|---|
| Scenario and scope | The business, the process being modelled, and what is deliberately out of scope. | 8 percent |
| Conceptual model notes | Entities and relationships in business language, with the sentence test applied to each relationship. | 15 percent |
| Logical model notes | Attributes, primary and foreign keys, cardinalities, and how many-to-many relationships were resolved. | 19 percent |
| Normalization argument | The form reached, the anomaly each step removed, and any denormalization you chose on purpose. | 22 percent |
| Physical implementation | Database system, data types, constraints and indexes, each with a reason. | 16 percent |
| Verification | Sample inserts and queries proving the structure holds, with the actual output shown. | 12 percent |
| Close | Known limits of the model and what would change at ten times the data volume. | 8 percent |
Sourcing modelling claims
Modelling theory is settled, which makes the sourcing straightforward and makes weak sourcing obvious. Normal form definitions, dependency concepts and relational algebra belong to a recognised database text or to the course materials, and quoting a definition precisely is worth more than paraphrasing it loosely, because these definitions are exact and a loose paraphrase is usually wrong in a way an evaluator can name.
Implementation claims move to a different authority. Data type ranges, index behaviour, constraint enforcement and identifier limits belong to the documentation of the specific database system you used, and they differ across systems. Name the system and version once at the top and cite its documentation whenever you assert behaviour rather than theory. Where your task asks about data protection or retention, the relevant published standard or regulation is the source rather than a summary of it.
Notation is worth a sentence of its own in your document. Several relationship notations are in common use, and they mark optionality and cardinality differently enough that a reader using the wrong key will misread your model. Say which notation you used, include a small legend, and then apply it identically across every diagram. Evaluators are not trying to catch you out on symbols, but a model they cannot read confidently is a model they cannot award full credit to.
Apply whichever citation style the task specifies and attach every source to the sentence that depends on it. In a modelling document, add one discipline: give every diagram and every table a number and a caption, then refer to them by number in the prose. Aspects that ask you to explain a design decision are far easier to score when the evaluator can follow your sentence straight to the artifact it describes.
The line between Competent and returned
Competent work shows a chain of reasoning from business scenario to physical table. The conceptual model contains nothing technical, the logical model resolves every many-to-many relationship, the normalization section names anomalies rather than reciting definitions, and the physical model explains its types and indexes rather than listing them.
Returns follow recognisable shapes. All three models look the same because the student drew one diagram three times. Normalization is described in the abstract with no reference to the actual tables. A relationship is drawn the wrong way round, which quietly invalidates everything downstream of it. Or the script builds tables that do not match the model that precedes it, which is the single most damaging inconsistency available in this course.
There is a test that catches most of these in ten minutes. Take three realistic rows of business data from your scenario and try to place them into your physical tables by hand. If a value has nowhere to go, an entity is missing. If you have to repeat a value across rows, a normalization step was skipped. If you cannot decide which table a value belongs in, a relationship is modelled wrongly. Real data is a better critic of a model than another read-through.
Performance assessment work can be revised and resubmitted with no grade penalty, so completeness beats polish when you are deciding whether to submit, since an early submission leaves room for a revision cycle. If your course also carries an objective assessment, WGU objective assessments are proctored and our position is fixed: preparation only, including modelling drills, normalization practice and a candid read on your preassessment. We will not take your exam, take no part once one begins, and your portal login is never something we touch.
Model and script disagreeing?
Send the D426 rubric, your diagrams and your build script. We check them against each other and return a headed plan with word targets.
Seven mistakes that cost time in D426
- Confusing D426 with C175. Same title, different catalog entries and different banner numbers. Only the code on your Degree Plan closes your requirement.
- Drawing one diagram and labelling it three ways. Each model level answers a different question, and an aspect that asks for a conceptual model wants no data types in it.
- Leaving a many-to-many unresolved. It cannot be implemented as drawn, so it signals immediately that the logical model was never tested against reality.
- Reciting normal forms. Definitions are free to look up. Naming the specific anomaly your design removed is the part being scored.
- Model and script drifting apart. Build the script from the model, then read them side by side before submitting. Every mismatch is a scoring problem.
- Ignoring cardinality direction. Read every relationship aloud as two sentences. Wrong-way relationships propagate into keys and then into queries.
- Denormalizing by accident. Deliberate denormalization with a stated reason is a strong answer. Accidental redundancy is the error the whole topic exists to prevent.
Three questions students ask about D426
How far do I need to normalize?
Which diagramming tool should I use?
Is D426 harder than the older C175 version?
Where D426 sits in WGU's programs
The July 2026 catalog places this code in 14 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.