I often think it would pay, before people are confused by OO programming, for them to sit down and think about how they would store data if they only had pen and paper, and if they had to perform all operations on the data themselves with the pen.
"Objects" tend to encourage a mental model where everything is a little machine of its own. These quickly compose into Rube-Goldberg machines. They can be fascinatingly intricate, but also extremely inefficient with design effort, computer power, and amenability to change.
By contrast, data on paper is a dead thing. It doesn't have buttons you can press. But it is also there in its most essential form, free from the clutter of all machinery. And people tend to be familiar with the culture of paper records, or with skeuomorphic representations of it (a text document, a spreadsheet, a file, a folder, a link, etc).
A database is effectively a computerisation of structured paper record-keeping, and a rigorous and scientific implementation of many of the concepts and practices that were developed for paper record-keeping.
If you wonder how to design the database and don't know where to start, a good place to start would be to simply write down on paper the data you want to store (or at least a subset that appears to you to be a whole example of what you'd be storing).
At least, having done that much, you can also show other people, or describe something you already have.
There are specific transforms available from paper to (relational) database. For example, if on paper you have a heading and list 5 items under, to express some sort of hierarchy or grouping of those items, then in the database you have a repeated value which represents the key for the group - and potentially, a link to another table which stores things about the group.
People tend naturally using paper to minimise redundancy and avoid all unnecessary work, within their ability to do so.
Sometimes, the trick with people who are very familiar with paper but not computers, is explaining how visual relationships between fields on paper, or widgets that hold many sheets together like treasury tags, staples, and folders, are often represented in the database by shared values - that appear to be redundant repeated data, but are in fact the minimum repetition necessary to express certain kinds of common connection. And it's very easy to think of justifying examples where this actually happens on paper.
But it's easier for anyone to talk about transforming a specific case, rather than consider every possible case.