A database usually, but not always, sits on a Server.
Think of it like your larder or kitchen pantry, and let’s tack onto that the assumption you have a butler. You get up in the morning and ask your butler to bring you some breakfast. The butler goes to the pantry pulls out the nuts and fruit, pulls the onions out of the onion bin, grabs the cheese, salad, mushrooms and tomatoes out of the fridge, chops up the mushrooms, onions and tomatoes, heads over to the chooks and picks up a few eggs, get out the whisk from the drawer, whisks the eggs, adds some salt and pepper from the cupboard, takes the fry pan out of the drawer, picks up the oil next to the stove, fries up the mushroom and onion, scoops them into a bowl to the side, pours in the whisked eggs, turns and lifts until it starts to bubble, spreads the remaining ingredients evenly over the eggs, adds some cheese, flip, put onto a plate, add the salad, fruit and nuts on the side. Voila – breakfast for you.
The thing is – unless access is otherwise controlled – anyone else can have their butler go in and see what you had for breakfast, and even the entire larder and kitchen. They can make a few things for themselves or take off with the whole lot. Even lock you out of your own pantry or belongings.
Databases hold your data and the applications that overlay it know how to put it together. They are a goldmine of information – for both you and attackers.
DMZ, Cloud and any other internet facing Database Servers are also vulnerable to SQL Injection Attacks, where by an attacker typing some code into the login for the public or semi public website or application login, may be able to view all the content in a database or change it, for example customer information, and pricing.