Reporting Services

Course Description

Reporting Services addresses the complete process of building and distributing reports. Students utilise integrated reporting services capabilities, including new and enhanced features, employing report builders, wizards, and design tools to construct reports while developing competency in data analysis procedures and models.

Within the SCNS taxonomy, COP is the Computer Programming prefix. Daytona State publishes this at 3 credits, offered spring, with COP1000 as prerequisite. ⚠ The single term of offering is worth planning around.

Reporting looks like the least glamorous corner of data work and it is where the organisation's decisions actually get made. Executives do not read the database; they read the report. Which means a report that is subtly wrong is more dangerous than no report at all — people act on it, confidently, for months, and the error is only discovered when a number is finally reconciled against something else. The professional obligation in this field is to know what your numbers mean and to be able to prove them.

Daytona State does not publish a lecture and laboratory split for this course. Its computing and office systems courses are unsuffixed and run at the standard 15 contact hours per credit — CEN4010, CEN3722, CNT2402, OST2401 and CGS1570 are all live at 3 credits and 45 hours. This course is priced at that convention.

Learning Outcomes

Required Outcomes

• Describe the role of reporting within an organisation's data stack.
• Describe reporting architecture and its components.
• Connect to data sources and manage connections securely.
• Write queries to retrieve report data efficiently.
• Describe datasets, data sources, and their reuse.
• Build a report using a report designer.
• Build a report using a wizard and describe the limits of doing so.
• Lay out a report for readability and print or screen use.
• Group, sort, and aggregate data correctly.
• Compute totals and subtotals and verify them.
• Apply expressions and calculated fields.
• Apply parameters and allow user-driven filtering.
• Apply conditional formatting purposefully.
• Build charts and select chart types appropriate to the data.
• Avoid misleading visual presentation.
• Build drill-down and drill-through reports.
• Build subreports and describe their performance cost.
• Optimise report performance.
• Describe caching, snapshots, and scheduled execution.
• Deploy reports to a report server.
• Configure subscriptions and automated distribution.
• Apply security so that users see only what they are entitled to see.
• Validate report output against the source data.
• Document a report's definitions, sources, and assumptions.

Optional Outcomes

• Describe self-service business intelligence tools.
• Describe data warehousing and dimensional modelling.
• Describe mobile and embedded reporting.
• Describe dashboard design principles.
• Describe data governance and metric definitions.
• Build an end-to-end reporting solution.

Major Topics

Required Topics

• Reporting in the data stack
• Reporting architecture
• Data sources and connections
• Efficient report queries
• Datasets and reuse
• Report design
• Wizards and their limits
• Layout for readability
• Grouping, sorting, aggregation
• Totals and verification
• Expressions and calculated fields
• Parameters and filtering
• Conditional formatting
• Charts and chart selection
• Avoiding misleading presentation
• Drill-down and drill-through
• Subreports and performance
• Report performance optimisation
• Caching, snapshots, scheduling
• Deployment
• Subscriptions and distribution
• Report security
• Validation against source
• Documenting definitions and assumptions

Optional Topics

• Self-service business intelligence
• Data warehousing and dimensional modelling
• Mobile and embedded reporting
• Dashboard design
• Data governance and metric definitions
• End-to-end solution

Resources & Tools

• Build things and keep them. In computing the portfolio is the qualification — a public repository of working projects with readable code and a clear README does more for employment than a transcript.
• Git and a public repository host — free; version control is expected of every candidate, and using it from your first course is the cheapest habit to acquire.
• Free-tier cloud accounts (AWS, Azure, Google Cloud, Oracle) — real infrastructure to practise on at no cost; set a billing alert before you start.
• Virtualisation and containers — VirtualBox and Docker are free, and a broken lab you can rebuild in a minute is what makes experimentation cheap.
• Official documentation — language, database, and framework docs are authoritative and version-correct in a way that copied answers are not. Learning to read documentation is the skill that separates practitioners.
• Vendor certifications — Microsoft, AWS, Oracle, CompTIA and Cisco credentials are named by employers in job advertisements; many have free training paths and student pricing.
• Your instructors and the lab — supervised time on real systems is the part you cannot get from a video.
• Internships and co-op placements — the strongest single predictor of employment at graduation. Start looking a year before you think you should.
• Free-tier and developer editions of database and reporting platforms — SQL Server Developer Edition, PostgreSQL, and Power BI Desktop are all free and let you build a complete stack on a laptop.
• Public open datasets — data.gov, Census, and Florida agency open data portals are free and are far better practice material than tidy textbook tables.

Career Pathways

• Software developer — SOC 15-1252.
• Computer systems analyst — SOC 15-1211; the requirements-and-design role.
• Database administrator and architect — SOC 15-1242 and 15-1243.
• Data analyst, business intelligence developer, and data engineer — strong demand and a common entry route for people who like data more than application code.
• Network architect — SOC 15-1241; and network and systems administrator, SOC 15-1244.
• Information security analyst — SOC 15-1212; strong growth, and systems or database work is the usual route in.
• Data scientist and machine learning practitioner — SOC 15-2051.
• Systems integration and enterprise applications — frequently overlooked by students and consistently well paid.
• Florida's defence, space, and simulation sector, plus healthcare, hospitality, financial services and a large public sector — ⚠ many defence roles require U.S. citizenship and some a security clearance.
• Managed service providers and consultancies — broad exposure quickly, and a common early career step.
• Continue to a bachelor's or graduate degree — Daytona State's computing bachelor's programmes are the direct route.

Special Information

⚠⚠ A wrong report is worse than no report — validate before you publish

• People act on reports. A number in a management report becomes a decision, and a subtly wrong number produces confident wrong decisions for as long as nobody reconciles it.
• ⚠ Validate every report against the source before releasing it. Reconcile totals independently, check a handful of individual records by hand, and compare against an existing trusted report where one exists.
• ⚠⚠ Joins silently change your numbers. An inner join drops rows that had no match, and a one-to-many join duplicates rows and inflates every sum — and both produce a plausible-looking total that is simply wrong. Check your row counts.
• Know how nulls behave in your aggregations and comparisons. They are excluded from most aggregate functions and they are not equal to anything, including themselves.
• ⚠ Agree the definition before you compute it. "Active customers", "revenue", and "on time" mean different things to different departments, and most disputes about a report are actually disputes about a definition. Write the definition on the report.
• Check the date boundaries. Inclusive versus exclusive end dates, time zones, and financial versus calendar periods are a persistent source of quiet error.
• Show the report to someone who knows the business before publishing it. They will spot an implausible number instantly in a way you cannot.
• State the as-of time and the data source on the report itself, so nobody compares two reports run at different moments and concludes something is broken.
• ⚠ When you find an error in a published report, say so promptly and specifically. Quietly correcting it destroys trust more thoroughly than the error did.

⚠ Reports leak data, and charts mislead — both are avoidable

• ⚠⚠ A report is an access path to the database, and it is frequently the one with the weakest controls. Apply row-level security so users see only their own scope, and never rely on a parameter default to restrict what someone can see.
• Check what a parameter allows. A user who can change a department parameter can usually read every department, and this is the commonest reporting data leak.
• Be careful with subscriptions and exports. An emailed report leaves your access controls entirely, and a spreadsheet export is forwarded onward without anyone thinking about it.
• Do not include identifiers people do not need — the fewer sensitive fields on the report, the smaller the consequence when it is forwarded.
• ⚠ Truncated axes exaggerate differences, and a bar chart not starting at zero is the standard way to make a small change look dramatic. Do it deliberately, label it, or do not do it.
• Choose the chart for the question. Pie charts are poor at comparison, dual axes invite false correlation, and 3D effects add nothing and distort area.
• Show the denominator. A count without the population it came from can be made to mean nearly anything.
• Do not use colour as the only carrier of meaning, and check contrast — reports are read by people with colour vision deficiency and on bad projectors.
• Keep it readable. A report nobody can interpret at a glance will be interpreted wrongly.

⚠⚠ Real data carries real obligations — and students meet this first in a database course

• The moment a system holds data about people, it is subject to law and to duties that have nothing to do with whether the code works.
• ⚠⚠ Never copy production data into a development or test environment casually. It is one of the commonest sources of real breaches, it is frequently prohibited by policy, and a development database is almost never secured to the standard the production one is. Use synthetic or properly de-identified data.
• De-identification is harder than removing names. Combinations of ordinary fields — date of birth, postcode, sex — re-identify people surprisingly often.
• Collect only what you need and keep it only as long as you need it. Data you do not hold cannot be breached, and retention is a policy decision with legal consequences.
• ⚠ Access only what your task requires. Broad database access is normal for a developer and querying a colleague's or a public figure's record is still a dismissible act — audit logs attribute it to your account.
• Encrypt sensitive data in transit and at rest, and never store passwords recoverably — they are hashed with a purpose-built algorithm, never encrypted and never plain.
• ⚠ Sector rules stack on top: health data under HIPAA, student records under FERPA, card data under PCI DSS, and Florida's Digital Bill of Rights for businesses meeting its thresholds.
• Report a suspected breach immediately. Notification obligations carry deadlines, and concealment turns a manageable incident into a serious one.
• ⚠ Rule 11 applies — privacy law is moving quickly at state level; verify current requirements.

⚠⚠ Authorisation is the line between a computing professional and a defendant

• Never access, scan, modify, or extract data from a system you do not have permission to touch. The technical knowledge these courses give you is exactly what makes unauthorised access easy, which is why the rule matters more in this field than in most.
• Federal exposure: the Computer Fraud and Abuse Act criminalises unauthorised access to a protected computer, and "exceeding authorised access" has been read broadly.
• ⚠⚠ Florida exposure is separate and additional: the Florida Computer Crimes Act, Chapter 815, Florida Statutes, makes offences against computer users, systems and data punishable under state law independently of federal law.
• Having credentials is not the same as having authorisation. Being technically able to query a table or read a record does not mean you may, and systems log that you did.
• Use the lab and build your own. A local database, a virtual machine, or a personal cloud account costs little or nothing and lets you practise lawfully anything that would be unlawful elsewhere.
• Get scope in writing before any authorised testing or administrative engagement.
• ⚠ Rule 11 applies — computer crime and privacy law changes; verify rather than relying on a course guide.

How Florida course levels affect transfer

The first digit of an SCNS number denotes the year of offering, not transferability. Courses at the 1000 and 2000 levels transfer transparently between Florida public institutions, and 3000 to 4000 is unproblematic since both are upper division. The boundary that actually matters is 2000 to 3000, where lower-division credit generally cannot satisfy an upper-division requirement — and it is live here, since Daytona State offers both associate-level and bachelor of science coursework in these prefixes.

COP2072 is 3 credits and approximately 45 contact hours, offered spring only at Daytona State, with COP1000 as prerequisite.