The most important aspect of a database is that it stores your data predictably.
With just one editor it's pretty easy to keep data in good shape: just apply the last change. However, databases are usually being accessed by many users, and concurrency causes things to get tricky.
Here are the main things you need to know in order to reason about database locks:
Record locking prevents simultaneous access to data
How do you make sure that multiple edits happening at almost the same instant have correct results?
You force them go one at a time.
Locks are applied to data for the duration of an update or delete making it so that only one transaction (think edit) can access them at a time.
Other transactions that are trying to edit that same data are put into a queue to wait their turn.
From here on out the way database locks are implemented is mostly fancier, more efficient versions of making transactions go one at a time.
These details are important to keep as little waiting as possible, but you don't need them to form a mental model!
"Deadlocks" are when two locks are waiting on each other
Let's say we have an antique book trading database.
I decide I want to give you a first edition "Grapes of Wrath" and you want to give me a beautifully illustrate copy of "Alice in Wonderland".
If we submit our requests simultaneously each of our accounts would get a lock, BUT both of those locks would stay infinitely because they are waiting on each other to complete in order to start.
The main solution to this situation is to abort one of the locks and let the other finish.
Locks can be applied on several different levels
Database level locking - can't change anything anywhere
Page level locking - lock an entire page for editing
Row level locking - As granular as it gets, lock individual rows
BONUS Application level locking: some databases allow you define your own locks.
These three pieces of knowledge should give you just enough to reason about database locks, and to google your way out of locking issues.