 Hi, everyone. It's Monica Wahee here, giving you tips on doing data science in public health. Lately, in public health, I've noticed that they expect us to be able to analyze data coming out of applications. And a lot of times epidemiologists and biostatisticians are not familiar with that kind of data. And, maybe even worse than that, they often don't have the terminology to use to communicate about data coming from applications. That is why I made this online course called Application Basics, so that individuals trained in public health can learn about getting and analyzing data from applications. In this video, I'm going to go over some important terminology from applications, the front end and back end. Probably the most basic of components to an application are the front end and the back end. Applications usually have a data component or data that are handled by the application are stored and displayed. The data component of an application is called the back end, as designated on the right side of the slide. The reason why it is called a back end is because, well, probably like your back end and my back end, almost no one sees it. It's behind the scenes. So, unsurprisingly, the other main component to applications is the front end or the end that everyone is supposed to see, as described by the left side of the slide. The front end is designed to display data in such a way that they are easy to understand and edit. Contrast this to the back end, where data are definitely not stored in a way that are easy to understand or edit. In the back end, data are usually stored in multiple tables in an architecture that makes it easy to do queries and retrieve the data needed. Back ends are also set up to make data management easier. Applications have been designed this way since the early 1990s, with a front end and a back end that are connected, and those are the two main components. I remember running some database programs back in the 1990s. One ran on the Macintosh and was called FileMaker. FileMaker had a front end that looked like invoices or packing slips, and it had an internal back end that kept track of the data for the invoices in packing slips. Then, to back up the database, you just take a copy of your FileMaker file. Oh, those were the days. Nowadays, front ends are usually on the web, split far away from their back ends, which are in some data center or building behind some firewall somewhere. Even modern-day medical record systems like Epic look like they are using a web browser interface for a front end. And you know, if we are talking about medical records, wherever the back end data are, they are hopefully behind a fortress of cybersecurity. Continuing with the Epic example, we also can acknowledge that you can have multiple front ends per back end. Obviously, you have administrative front ends for Epic and patient front ends, like an electronic health record or EHR. So we acknowledge that the front ends have evolved since the 1990s. But what about the back ends? Well, the old back ends used to be mainframe computers. This was before the 2000s. Flat back ends are very stable databases. But they are not very flexible. They are hard to program and modify. By contrast, when technology advanced and we were able to start using structured query language or SQL for our queries, we started to be able to build more flexible databases in normal form. As I said, this technological turning point was in about the 2000s. Now, after 2000 and SQL and normal form started, it was much easier to take copies of the data. That led to SQL programmers making a lot of redundant data in their data structures, which is fine, but can lead to confusion. So I want to teach you about this important concept in databaseing, which is the concept of the live data. There's only one place in the back end where the data are live, meaning that they are being updated constantly as the system changes. If you imagine yourself doing data entry into a system, you want the system to save the data you entered, right? Well, in SQL and normal form, there would be a table in the back end saving the data you entered. That's the live data. Everything else is not live. So imagine you know someone who is a ride sharing driver and this person downloads their data from their app and wants you to analyze it. Let's think about what the front end and back end for a ride sharing app might look like. I made this diagram to help us understand what is going on. Let's start on the right side of the diagram. We have riders using the app and we have drivers using the app. The app is their front end. As you can see, I'm imagining that they are accessing both the front and back end over the internet from the company facility. See the two big data stores in the facility? On the top, we have the live data transactions. This stores the customer data and the geographic data and all the cost data. But below that, we have the application server. That's where the front end is located. And the front end has its own data to deal with. Basically images for buttons and values that it is passing through the app to make it work. I also included a co-location facility on the way left of the slide. See how we have a backup and a failover server. That's basically a mirror of the live data. Also, if you think about ride sharing, there will be a lot of history. Probably they want to archive that history at the co-location facility so they could improve application IO. So if you really had a friend who was a ride sharing driver and they downloaded their data and wanted you to analyze it, it would probably come from a report or query they could do using the front end. But that front end query would be querying from the back end transaction data. So you would have to be comfortable with that data structure in order to help your friend by analyzing the data. In public health, we have a lot of skills. But we often don't have specifically data science skills. In theory, individuals with a health analytics background could analyze data from a ride sharing app. It's just that they don't often know how to go from the data in the application to an analytic data set you can analyze to answer research questions. That's why I created this applications basics online course, specifically for people with a background in health analytics who want to go deeper into data science. Are you in health care or public health but want to better understand how to analyze data from applications? Please consider taking my online course or even joining my online group mentoring program. In the one year self-paced online group mentoring program, I help individuals trained in health care shift their career into a more data science direction. Look for links in the description. I hope this video gave you a new way to look at data coming from applications. If you found it useful, please hit the like button and if I stimulated an interesting thought in your mind, please leave a comment and share it with us. Bye for now. Thank you for watching this video which is part of the Public Health Today to Science rebrand program. If you are interested in joining the program, please sign up for a 30-minute Zoom interview using the link in the description.