Your question is not 'funny', don't worry! But it is difficult to answer, because the answer will vary from one database to the next.

A database can have a huge number of moving parts, and not all of them need to be contained within the database itself (SSIS packages, external Windows and Web apps, external scripts and other things can all affect the state of a database). Trying to get to grips with the entire scope of a database and its connected applications is likely to be a big task. I've seen applications where all of the data manipulation code was held outside of the database, in a desktop app, perhaps. Trying to understand 'the layout of the database' in such situations is difficult, because the code is largely hidden (unless you are also an Windows application developer, in which case you may be able to dig into the source code and work things out).

Having said that, if a database is serving a single application and has been built based on the principle of having as much code as possible within the database, the task gets easier. If the database objects also follow strict naming conventions and have been built by a diligent development team, you should be able to get somewhere.

One thing you can do is to create one or more database diagrams (use the 'Database Diagrams' node in SSMS). These will provide a graphical display of relationships between tables (assuming that those relationships have been created in T-SQL).

Beyond that, start looking at the design of some of the tables, views and stored procs to attempt to get a feel for what is going on and how things have been put together.

Don't be daunted if you feel like you are not getting anywhere fast. This is a task which even very experienced developers find difficult.