DATA 5003 Module 2 Analytics System and Data Sources Description Example

Five Systems, One License Number: Designing the Analytics System for a Restaurant Group's Inspection Study

Student Name

American College of Education

DATA5003: Data Analytics

Module 2 Assignment

Instructor Name

March 13, 2028

Introduction

In Module 1, I framed a question for Cedar and Salt, the composite eleven-location Chicago restaurant group where I manage food safety and operations: which conditions and practices predict a failed city inspection, and where should we focus our food safety budget? Answering it requires data from five places that have never been combined. This paper describes the analytics system that will bring them together. It covers the components of the system, each data source and how it will be extracted, how the sources will be joined, the tools chosen, the data quality checks, and governance: who owns the data, who may see it and how results will be reported.

Components of the System

An analytics system, however small, has the same parts as a large one: sources where data are created, a process for extracting and cleaning them, a store where they are combined, tools for analysis and a way of presenting results to decision makers. Wixom and Watson (2001), studying data warehousing projects, found that data quality and system quality shaped whether the resulting systems were seen to deliver value, and that management support and adequate resources contributed to implementation success. For a restaurant group without an analyst, the lesson is to keep the system simple, reliable and owned by someone with the authority to fix problems in the sources.

Source One: City Inspection Records

The main external source is the City of Chicago's food inspection data set on its open data portal (City of Chicago, 2026). The portal offers an application programming interface that returns records in a structured format, filtered by facility type and date. For this project, a monthly query will pull all restaurant inspections for the prior month, and a one-time query has already pulled all 13,864 restaurant inspections conducted in 2025. Each record includes the license number, which is the key for linking to our own kitchens, the inspection date, type and result, the city's risk category and a violations field in which each violation number and description is followed by the inspector's comments.

Sources Two to Five: Internal Records

Four internal sources fill in practices. Weekly self-inspections are completed by kitchen managers on tablets using a form tool that exports to a spreadsheet, with 40 items scored pass or fail. Pest control reports arrive from our contractor as scanned report files after each monthly visit, listing findings by location; these must be entered by hand. Training records live in the learning management system, which exports each employee's food handler and allergen training dates. Maintenance tickets live in a facilities ticketing tool, with each ticket's kitchen, equipment type, open date and close date. Together, these describe the conditions inspectors are likely to see.

Joining the Sources

The sources share two keys: the kitchen, identified in city data by the license number and in internal data by our location code, and the date. A small lookup table will map each of our eleven location codes to its city license number. For each city inspection of one of our kitchens, the system will then calculate features from the internal data for the preceding 90 days: the average self-inspection score, whether a pest finding was reported, the share of staff with current training and the number of open maintenance tickets for hand sinks, refrigeration and dish machines. For the citywide analysis, which covers all Chicago restaurants, only the city data will be used, because internal data exist only for our kitchens.

Cleaning the Violation Field

The hardest single task is turning the city's violation text into usable data. Each record's violations field is a long string in which violations are separated by a vertical bar, and each violation begins with a number, a period and an uppercase description, followed by the word Comments and the inspector's notes. The script will extract the number and description of each violation with a pattern match, store one row per violation per inspection and keep the comments in a separate field for reading later. A test on the 2025 data showed that passing inspections averaged about 1.4 distinct violations, inspections that passed with conditions about 3.2 and failed inspections about 4.1, which confirms that the extraction works and that violation counts carry information worth analyzing.

Tools

The tools match the group's size and skills. A shared cloud spreadsheet will store the lookup table and the hand-entered pest data. A short script, run monthly by our IT contractor, will query the city portal, extract violation numbers from the text field and write a clean table. The combined data will be stored in a small cloud database included in the company's existing productivity software. Analysis in Modules 3 and 4 will use the spreadsheet and the script's statistical functions, and results will be shown in a simple dashboard that kitchen managers can open on their tablets. No new software purchase is required; the IT contractor's time is estimated at 16 hours to set up and two hours a month to maintain.

Data Quality

Data quality means more than accuracy. Wang and Strong (1996), surveying data consumers, found that people judge data quality along several dimensions, which they sorted into four families: qualities of the data itself, like accuracy; qualities that depend on the task, like relevance and timeliness; qualities of presentation, like how easily the data can be interpreted; and how easy the data is to reach. The system includes checks for each. For accuracy, the script will flag inspection records whose violation text cannot be parsed. For timeliness, city data will be pulled monthly and internal data weekly. For interpretability, violation numbers will be stored with their official descriptions. For accessibility, kitchen managers will see their own data on the dashboard without needing to request a report.

Governance

As the manager responsible for food safety, I will own the system and the quality of its data. The IT contractor maintains the script and database. Kitchen managers own the accuracy of their self-inspections and are responsible for correcting missing weeks. Access will be limited: kitchen managers see their own kitchen and citywide patterns, the owners see all kitchens, and individual employees' training records appear only in summary form. Data on other restaurants from the city portal are public, but reports will discuss citywide patterns rather than naming competitors, as Module 1 committed.

Risks and Next Steps

The main risk is that the system becomes another report no one opens. To avoid that, the dashboard will show only five measures that link directly to the business question, and the monthly operations meeting will review it. A second risk is that hand entry of pest reports lapses; if so, I will ask the contractor for a spreadsheet export instead of scanned reports. With the system in place, Module 3 will describe the 2025 citywide data using descriptive statistics and visuals.

Conclusion

The analytics system brings together the city's public inspection records and four internal sources, linked by license number and date, with features calculated for the 90 days before each inspection. Simple tools fit the group's size, data quality checks follow a research-based view of what makes data useful, and clear ownership and access rules govern it. The system is modest, but it is designed to answer one business question reliably.

References

City of Chicago. (2026). Food inspections [Data set]. Chicago Data Portal. https://data.cityofchicago.org/Health-Human-Services/Food-Inspections/4ijn-s7e5

Wang, R. Y., & Strong, D. M. (1996). Beyond accuracy: What data quality means to data consumers. Journal of Management Information Systems, 12(4), 5-33. https://doi.org/10.1080/07421222.1996.11518099

Wixom, B. H., & Watson, H. J. (2001). An empirical investigation of the factors affecting data warehousing success. MIS Quarterly, 25(1), 17-42. https://doi.org/10.2307/3250957