You commented that you were working on a "mission statement" for the DB in question. This is THE crucial time in your DB. You will not find another part so important until you reach final testing. That "mission statement" is your roadmap for whatever happens down the road. It pays you BIG TIME to build a good database "mission and goals" document. Niklaus Wirth, the creator of the Pascal programming language, was quoted as saying "80% of all programming problems originate from bad data design." (He said it in Polish so that is a translation, not a direct quote.)
I have reached a wall in my brain.
If you have a good design document and know where you wanted to go, you will find that like the Biblical Joshua at the Battle of Jericho, that document will make those walls come tumbling down.
Don't let the design phase daunt you. Realize that time spent in design is time well spent. It pays dividends when you start code implementation. One of the biggest mistakes people often make with databases is "shooting from the hip" i.e. starting to code before the data design is essentially complete. Oh, sure, you stumble across issues during implementation and have to go back to tweak something. Happens all the time. But you want to get the "big picture" laid out early. That way, the "big ticket" items can be easily implemented.