C175 Data Management - Foundations carries banner number ITEC 2104 and is worth 3 competency units. It covers the SQL data definition and data manipulation command families, the difference between structured and unstructured data, storage methodology, and the basics of protecting data at rest and in transit. C175 is the legacy code for this material; the current version is D426, which carries the identical title under banner ITEC 2116. The two cover the same ground and only the code on your Degree Plan closes your requirement.
Two command families and one habit of mind
The technical core of C175 is a distinction students often blur: data definition language changes the shape of the database, and data manipulation language changes what is inside it. Creating a table, altering a column, dropping an index: those change structure. Inserting a row, updating a value, deleting records, selecting results: those change or read contents. Once that split is automatic, error messages stop being mysterious, because most beginner errors are attempts to manipulate something whose definition does not permit it.
The structured versus unstructured material is where the course reaches beyond SQL. Structured data has a schema decided before the data arrives, which makes queries fast and change expensive. Unstructured and semi-structured data pushes that decision to read time, which makes ingestion easy and analysis harder. The assessment is unlikely to ask you which is better; it is far more likely to ask which suits a described situation, and the answer always comes from how the data will be used rather than from what it looks like.
Storage methodology and data security round the course out, and they are more connected than they appear. Where data lives determines who can reach it, what a backup actually protects against, and how long a restore takes. A security basics aspect that mentions encryption is usually also asking whether you know the difference between protecting data on disk and protecting it while it moves.
WGU grades this as Competent or Not Competent, with no letter grades and no ordinary grade point average, and the 3 competency units describe course size within a six month term. That term is flat priced, so an early close on a foundations course is capacity you get to spend elsewhere.
From rubric aspects to a queryable plan
If your version of C175 uses a performance assessment, the scored aspects are the outline. Database tasks fail in a specific way when that is ignored: students submit a working script and assume the code answers every aspect. WGU requires a score of 2 in each aspect for a task to pass, aspects are judged individually, and aspects about justification or data classification cannot be satisfied by a correct statement.
Convert before you draft. Take a rubric with five scored aspects and a written component around 1,300 words alongside your SQL. Reserve 100 words for context naming the database platform and the scenario, and 80 for a close, leaving 1,120. If two aspects are demonstrated directly by code, give them 130 each as pointers that name the statement and how to verify the result. That leaves 860 for three explanatory aspects, or about 287 each, which is room for a claim, an example and a consequence. The document lands at 1,300 and every aspect has a home.
The transferable principle: never spend prose describing what a statement does when the statement is visible. Spend it on why this structure, what the alternative would have cost, and what the data classification implies for how it is stored.
Shape for a database foundations deliverable
C175 work usually pairs a script with a short document. The proportions below apply to the document.
| Section | Content | Share |
|---|---|---|
| Platform and scenario | The database system and version, and the business situation the data serves. | 8 percent |
| Data inventory | What data exists, classified as structured, semi-structured or unstructured, with a reason for each classification. | 16 percent |
| Definition decisions | Tables, columns, types and constraints, with why each type and constraint was chosen. | 20 percent |
| Manipulation and retrieval | The statements that load and read the data, each with the question it answers. | 17 percent |
| Storage approach | Where the data sits, how it is backed up, and what that protects against. | 14 percent |
| Security basics | Access control, protection at rest and in transit, and who can see which columns. | 16 percent |
| Close | Limitations of the design and the first thing you would change at scale. | 9 percent |
What counts as a source in a database course
Syntax and behaviour belong to the documentation of the database system you are using, and versions matter here more than in most subjects because dialects differ in exactly the places beginners get stuck. Name the platform and version once, then cite its documentation for any behavioural claim. Where you are describing the relational model itself rather than one product, a recognised database text is the better authority, and using one signals you understand which claims are universal and which are vendor specific.
Security claims have their own sourcing. Encryption and access control statements should point at a published standard or framework rather than at a vendor's marketing description of its own feature. If your task asks about protecting personal data, the relevant regulation or published guidance is the authority, and quoting the actual requirement is stronger than paraphrasing what someone said it means.
One caution specific to this course: a great deal of freely available SQL material is written for a different system than the one you are using, and much of it is old enough to describe behaviour that has since changed. Before you rely on any example, check whether it names a platform. If it does not, treat it as an idea to verify rather than a source to cite, and confirm the behaviour in your own environment before you write a sentence that depends on it.
Apply whichever citation style the task specifies and cite at the point of claim. One small habit lifts a database write-up noticeably: after each statement you discuss, show the actual result set or the confirmation output. Evidence that the statement ran is different from evidence that it was correct, and evaluators are looking for the second kind.
Competent work and returned work
Competent submissions show a design that someone could defend in a review. Types are chosen deliberately rather than defaulting to text everywhere, constraints exist and are explained, the data classification section reasons from usage rather than appearance, and the security section names specific columns rather than gesturing at protection in general.
Returns cluster around four habits. Every column is a string, which makes the type aspect unanswerable. The classification aspect is answered by definition rather than applied to the scenario's data. The security aspect names encryption without saying where it applies. Or the script is correct and the document narrates it line by line, spending the whole budget describing what the evaluator can already read.
A useful last pass before submitting: read your document as though you were the person who has to maintain this database next year. Can they tell from your write-up which columns hold sensitive values, which statements would break if a type changed, and where the data actually lives? Those are the same questions the aspects are asking in more formal language, and answering them in plain terms usually improves the technical sections at the same time.
Since performance assessment work can be revised and resubmitted at WGU without a grade penalty, submit once every aspect has a genuine answer rather than polishing a script. Where C175 also uses an objective assessment, that exam is proctored and our boundary is absolute: we prepare with syntax drills, query practice and a straight read on your preassessment result, and we take no part during any assessment. We never ask for or handle portal credentials.
Script runs, write-up stalled?
Send the C175 rubric and your schema. We separate code aspects from explanation aspects and return a headed plan with word targets.
Seven mistakes that cost time in C175
- Working the wrong code. C175 is ITEC 2104 and D426 is ITEC 2116. Same title, same subject, different Degree Plan entries. Check yours before you start.
- Blurring definition and manipulation. Most confusing errors resolve instantly once you know which family the failing statement belongs to.
- Defaulting every column to text. Type choice is a scored decision, and a table of strings has thrown away the constraint the type was there to provide.
- Classifying data by appearance. Whether data is structured is decided by whether a schema is fixed before it arrives, not by whether it looks tidy.
- Ignoring the dialect. SQL varies between systems in exactly the places students borrow snippets from. Name your platform and check its documentation.
- Confusing at rest with in transit. They are different protections against different threats, and an aspect that mentions both is testing whether you know that.
- Showing statements without results. A statement proves you wrote it. Output proves it did what you claim.
Three questions students ask about C175
Is C175 the same course as D426?
How much SQL do I need to write from memory?
Do I need to install a database system?
Where C175 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. 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.