D191: Advanced Data Management is the course where the database sequence stops being a quiz and becomes a project. Instead of a multiple-choice exam, you build working PostgreSQL objects in pgAdmin, record a Panopto demo, and submit a written document that evaluators read line by line.

Students who moved quickly through D426 and D427 often hit their first real wall here, not because the SQL is harder, but because the grading works differently. There is no auto-grader telling you that you are one syntax fix away from passing. You submit, wait, and either get a pass or a list of sections to revise.

Reality Check: Why D191 Feels Harder Than D426/D427

The first adjustment is mental. D426 and D427 trained you to answer questions about normalization, joins, and keys. D191 asks you to demonstrate those ideas inside a living database, then explain your reasoning in writing. A lot of advice floating around online still references an older version of the course with an objective assessment. Ignore it. The current D191 is a performance assessment from start to finish, and every study hour should go toward the project rubric.

The second adjustment is feedback. Evaluators grade against competencies, and when something fails, the response can read as generic. A single failed code section can flag a professional communication competency that had nothing wrong with it on its own. That pattern, more than any individual SQL question, is what makes retakes feel confusing. Treat the rubric as your primary study guide, and build your submission so each section stands on its own.

Building Your Foundational Study Stack

Your course materials are enough to pass, provided you use them in the right order. Stack them deliberately: environment first, template second, human help third.

Virtual Lab and pgAdmin Setup

Start the virtual lab session before you read anything else. pgAdmin inside the lab is where your stored procedures, triggers, and functions will live, so getting comfortable with the interface early saves hours later. Save every script to a local folder as a .sql file while you work. Lab sessions time out, and losing a trigger you spent an evening debugging is a preventable frustration. Before recording anything, run your full script against a clean database so you know it executes top to bottom without manual fixes.

DM Docx and Course Chatter Workflow

Download the DM Docx template first and read it before writing a single line of SQL. The template mirrors the rubric, and each heading tells you exactly what the evaluator expects to find. Keep it open beside pgAdmin and fill sections as you complete them rather than reconstructing your reasoning at the end. Course Chatter and the instructor group are useful for confirming ambiguous requirements, and a quick search there often answers questions about expected output formats. When you make a design decision, write one sentence explaining it in the document. That habit pays off across several rubric sections at once.

Rubric Traps That Trigger Evaluator Rejections

Three traps show up in retake threads again and again. Each one is easy to avoid once you know it exists.

F1 Data Freshness

This competency asks you to state exactly how your data stays current. "Regularly" or "periodically" will not satisfy it. Name the mechanism and the schedule: a cron job that runs monthly, a trigger that fires on insert, or a scheduled procedure with a specific interval. If your automation is described rather than implemented, spell out the exact schedule you would configure. Precision is the entire point of F1.

J Professional Communication

This one confuses students because it rarely fails alone. J acts as a catch-all competency, and a generic rejection flag here often appears when any code section elsewhere in the submission fails. Fix the technical sections first, then reread your document for tone, formatting, and completeness. If you receive a J rejection with no specific comments, check every other section before rewriting your prose.

Sources and Citations

Handle references carefully. If you used in-text citations anywhere, keep a properly formatted reference section. If you did not cite sources in the body of your document, delete the reference section entirely. A floating list of sources with no in-text anchors is a common reason submissions get returned, and the fix takes thirty seconds.

SQL Traps: SELECT INTO and Silent Failures

PostgreSQL is more permissive than evaluators are. In raw SQL, SELECT INTO quietly creates a table the moment you run it, which means your script works in pgAdmin while the submitted logic is harder for a reviewer to follow. Evaluators routinely return submissions that use it without explanation. Build tables with explicit CREATE TABLE statements followed by INSERT INTO, or use CREATE TABLE AS. Both forms show intent and match what the rubric expects to see.

Silent failures follow a similar pattern. A trigger compiles but never fires because the timing clause is wrong. A function runs once and then breaks on a second call because it was not written to handle repeated execution. A procedure references an object in a schema your script never created. None of these throw obvious errors during casual testing, so test on a clean database before recording anything. Drop your objects, run the full script top to bottom, and confirm every piece works in one pass.

RUN THE SCRIPT IN THIS ORDER, ON A CLEAN DATABASE 1 2 3 4 5 clean DB CREATE TABLE + INSERT INTO triggers functions procedures then query the final tables and show populated, transformed data — that is the Panopto demo. No audio needed: comments starting with -- let the evaluator follow each block. SILENT FAILURES THIS CATCHES The trigger never fires a wrong BEFORE/AFTER or row/statement clause still compiles It breaks on the second run a function not written to handle repeated execution passes once An object is missing the script references a schema it never created F1 Data Freshness — name the mechanism and the schedule A monthly cron job, a trigger that fires on insert, or a scheduled procedure with a specific interval. "Regularly" or "periodically" satisfies nothing here. Precision is the entire point of F1. Treat the rubric as the primary study guide — and build each section so it stands on its own.
Figure 1. How a D191 submission is assembled: a clean run of tables, triggers, functions and procedures, the three silent failures that survive casual testing, and the F1 freshness rule.

Core Concept Checklist

Use this list to audit your project before submission:

  • Keys: primary, foreign, composite, and how each relationship is enforced.
  • Joins: inner, left, right, and full, plus where each appears in your reporting logic.
  • Index behavior: where indexes help, where they slow writes, and why you chose the ones you did.
  • ERD: entities, relationships, cardinality, and whether the diagram matches your final tables.
  • Normalization: confirm each table reaches third normal form and note any deliberate denormalization.
  • Stored procedures: input parameters, error handling, and repeatable execution.
  • Triggers: before versus after timing, row versus statement scope, and the exact event that fires them.
  • Functions: return types, deterministic behavior, and how they differ from your procedures.
  • ETL documentation: extract sources, transformation rules, load targets, and the freshness schedule from F1.

Panopto Demo and Written Write-Up

The video demonstration causes unnecessary stress for many students. You do not need to record audio or speak during the Panopto demo unless you want to.

Evaluators only need to see your SQL statements execute cleanly in pgAdmin and verify that your output tables populate as intended. Adding clear inline SQL comments starting with -- above each query block allows the evaluator to follow your demonstration step by step without requiring a voiceover.

Keep the recording short, focused, and structured:

  • Show a clean database with no temporary tables.
  • Execute your creation scripts, functions, triggers, and procedures top to bottom.
  • Query the final tables to display populated, transformed data.

The 7-Step Retake Routine

If your submission gets returned, treat it as a quick edit rather than a failure. Follow this exact 7-step sequence:

  1. Read the Evaluator Comments First: Open the evaluation report and highlight the specific section tags marked as "Approaching Competency."
  2. Isolate Technical Failures: If section J is flagged, ignore it initially and fix any broken SQL or missing template sections first.
  3. Test in a Clean Environment: Drop all tables, triggers, and functions in pgAdmin and run your entire script from line one to ensure zero silent syntax errors.
  4. Update the DM Docx Template: Ensure every change in your SQL script is accurately reflected in your written document.
  5. Re-verify Citations and F1: Double-check that your data freshness schedule is explicit and that any unused reference sections are completely removed.
  6. Re-record the Panopto Walkthrough: If your SQL script changed, record a fresh video showing the clean execution of the updated code.
  7. Resubmit with Line-by-Line Revisions: Submit the revised files, adding a short note highlighting the specific changes made based on evaluator feedback.

References

Sikandar Ali - Academic Consultant
Written by Sikandar Ali

Sikandar Ali is a skilled academic consultant with expertise in research methodology and essay structure. With over 10 years of experience, he helps students develop critical thinking and writing skills for academic success.