The first step with delivering the project, was to create a draft Database Schema, which was a direct translation of old hardcopy data into a new schema model. We explained to the client in great detail, about what a database is, the steps taken with building a database, and best practice when designing one. The biggest change moving from a hardcopy paper report to an SQL-based data system, was defining the types of data that will be used, as well as constraints, data types and reports that can be generated from a finalised data set. While hardcopy reports have been around for many years, ultimately the hardcopy paper has no definition to what sort of information can be written down other than verbal instructions; Such as explaining to only write what sort of information can be written on a particular position on a page; whereas a database can be built with Data Validation which will only record data, if it meets a specific criteria. Data Fidelity refined translating the data from hardcopy to SQL, by conversing with Ted, and finding out exactly what sort of information he wanted to be able to pull from the data, and how he wanted to view it. We were able to identify a few ways of reporting on the data, such as by displaying data between two user defined dates, but also displaying a default date range for a reporting page, defaulting to display the previous 30 days of data, unless specified. As well as this, previous hardcopy paper reports were completed in a ‘shift report’ style, including all information recorded by carers during their specified shift. Ted wanted a displayed ‘shift report’ which included everything entered during the specific shift. This meant creating a function which would automatically input a default value in a field, specific to the last entry for a dataset relating to shift data; such as carer name, shift start time and shift end time. As for the medium in which to build the app, Ted had requested that we either reduce or eliminate the ‘key man’ risk, meaning that should he require changes to be made in the future, that either himself or another database administrator is able to quickly and easily read and understand the schema, to make changes if required in the future. Originally, we were going to build the system using Microsoft SQL Server, and host on Google Cloud, accessible via a mobile web app packaged in a .apk file. Upon further consultation, the licencing cost of using a cloud-based SQL server was too great for Ted, as well as this he was unsure how to navigate Google Cloud, and half his staffers used iOS, which cannot read .apk files natively. We opted to build the system using Appsheet, a Firebase system which uses Google Sheets as a backend for an app which can be deployed to both Android & iOS via email link. AppSheet was able to greatly reduce the monthly cost to almost nothing, and Ted has previous experience using Microsoft Excel for managing staffing & bookkeeping; He was able to pick up Google Sheets almost immediately. He was confident should he need to change the database in the future, he was able to do so by adding, updating or deleting columns in Google Sheets. For Web Development Newcastle