C792 Data Modeling and Database Management Systems, catalog number NURS 6010, is a two-CU course in the MSN Nursing Informatics specialty covering the planning, analysis and design of a relational database management system for nurse administrators, clinicians, educators and informaticists. It is the most technical thing in the specialty and the course nurses arrive at most nervous about. The reassurance is real: relational design is a way of thinking about clinical reality, and nurses already think that way.
What NURS 6010 is actually testing
A relational model is a claim about how the world is organised. A patient has many encounters. An encounter has many observations. A medication order belongs to one encounter and refers to one drug. Every one of those sentences is a design decision, and getting them right is most of database work. Nurses are good at this because clinical reasoning is already relational, even if nobody has ever named the structure.
What is scored is the modelling, not the coding. Can you identify entities, define attributes, choose a key that is genuinely unique, get the cardinality of a relationship right, and normalise far enough that the same fact is not stored in two places. The classic mistake in clinical data is storing a patient's address on every encounter row, which produces a database where a person can live in three places at once depending on which visit you read.
The second theme is that clinical data is unusually awkward. Time matters, because a blood pressure is meaningless without when. History matters, because you often need the value as it was recorded then rather than as it is now. Identity is hard, since the same person arrives under different name spellings and record numbers. Values change meaning over time when a unit or a scale is revised. A design that ignores all of that will pass a textbook test and fail a hospital.
The third is governance. Who may read which rows, how personal data is protected, how audit trails work, and how long data is retained. Those are design questions as much as policy ones, and a database paper that leaves them out is incomplete.
Turning scored aspects into a section plan
The rubric sits in your Course of Study rather than in the WGU catalog. Count the aspects before you build. Each scores independently on a three-point scale and each needs a 2, so an elegant model with no security section will still come back.
The word budget, worked. Where the narrative around a design deliverable runs to about 1,300 words across five scored aspects, reserve 100 for an opening naming the clinical problem the database serves and 80 for a close, leaving 1,120, or 224 per aspect. Then weight it. The normalisation aspect deserves 320, because it needs an example of a specific anomaly your design prevents. The security aspect can hold at 180 if it names concrete controls. That leaves 620 for three aspects at about 207 each, which is enough when the diagram carries part of the evidence.
Draw the model before you write. An entity relationship diagram exposes design problems that prose hides, and once the diagram is right the narrative is largely a matter of explaining decisions the picture already shows.
A structure that fits a database design deliverable
Task directions govern where they specify a format. Where they do not, this arrangement matches how design work is usually assessed.
| Section | What belongs in it | What earns the aspect |
|---|---|---|
| Purpose | The clinical or administrative question the database exists to answer | A concrete question, since it justifies every later design decision |
| Entities | The things being stored, named as singular nouns with a definition each | Definitions; an entity nobody can define is usually two entities |
| Attributes and types | Fields per entity with data types, and which are required | Types chosen deliberately, especially for dates and coded values |
| Keys | Primary and foreign keys, with a note on why a natural key was or was not used | A key that is genuinely unique and stable over time |
| Relationships | Cardinality and optionality for each association | Cardinality that matches clinical reality rather than convenience |
| Normalisation | The form reached and an anomaly the design prevents | A named anomaly with an example; a claim of third normal form alone is weak |
| Temporal handling | How the design records when something was true as well as what was true | The clinical-data-specific element that separates strong work |
| Security and governance | Access control, audit, de-identification, retention | Controls named specifically rather than as principles |
| Queries supported | Two or three questions the design answers, with the join path described | Proof the model works for its stated purpose |
| References | APA list of database and health informatics sources | Standards and regulation cited to their issuing bodies |
The query section is the cheapest way to demonstrate that the design functions. Take the purpose question from your first section and walk it through the tables. If the path is awkward, the model is wrong, and you have found that out before an evaluator does.
Evidence craft in a design course
Design deliverables are judged on internal coherence as much as on citation, but the sourcing still matters where it appears.
- Cite normalisation and modelling concepts to database literature rather than to a tutorial site. The concepts are old, stable and properly documented.
- Cite health data standards to their maintaining organisations with a version, particularly where your design stores coded clinical values.
- Cite privacy and retention requirements to the regulation or an authoritative summary, not to a training slide.
- Keep the diagram and the narrative in agreement. A mismatch between the picture and the text is the fastest way to lose a design aspect, and it happens whenever one is revised without the other.
- Use consistent naming throughout. If the entity is Patient in the diagram it is Patient in the text, not patients or PatientRecord.
- Quote sparingly. Definitions of normal forms are heavily reproduced, and WGU runs submissions through a similarity check.
The habit that most improves a clinical data model is testing it against a messy real case. A patient with two record numbers, a transfer between facilities mid-stay, a correction to a value recorded three days ago. If the design handles those, it is a clinical design. If it only handles the clean case, it is a textbook exercise.
What separates Competent from a submission sent back
Aspects score on their own, and normalisation and keys are the usual returns.
- Every entity has a definition and a stable primary key.
- Cardinality reflects clinical reality, including the awkward cases.
- Normalisation is demonstrated with an anomaly the design prevents.
- Time is handled explicitly somewhere in the model.
- Diagram and narrative agree on every name and relationship.
WGU performance assessment work can be revised and resubmitted with no grade penalty, so a return costs schedule rather than standing. Terms are six months at a flat rate, so each course closed early lowers what the rest effectively cost. C792 is short, and students who front-load the diagram usually close it quickly, which protects room for the heavier field experience later in the specialty.
Six mistakes that cost time in C792
- Building one wide table. A spreadsheet with more columns is not a relational design, and it fails the first normalisation question asked of it.
- Using a natural key that changes. Names change, record numbers get merged, and a key that moves breaks every relationship built on it.
- Getting cardinality from convenience. One patient to one address is easier and wrong.
- Claiming a normal form without showing it. Name the anomaly the design prevents and give an example.
- Forgetting time. Clinical values are only meaningful with a timestamp, and history is frequently required as well.
- Leaving out access control. A database holding patient data has a security design whether you write it or not.
How support works on this course
C792 is the course where nurses discover they can do this, provided the first model is built rather than described. Send the rubric out of your Course of Study with the task directions and the work starts with the entity relationship diagram, tested against messy clinical cases before any prose exists. From there you get keys and cardinality checked, normalisation demonstrated with a concrete anomaly, temporal handling designed in, a security section with named controls, and a query walkthrough that proves the model answers its own purpose question.
The boundaries hold. Objective assessments at WGU are proctored, so we prepare only, never sit them, and never ask for portal credentials. On field-based courses in this specialty we never complete practice hours, contact mentors or sites, sign placement paperwork or fill in hour logs.
Questions students ask about C792
Is C792 the same course as NURS 6010?
Do I need to write code for C792?
What if I have never used a database?
Modelling a clinical database for C792?
Send your Course of Study rubric and the task directions. We build the diagram first, test it against messy cases, then write the design decisions up.
Where C792 sits in WGU's programs
The July 2026 catalog places this code in 2 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.