Your definition of "atomic" is problematic since it is unclear what the "one thing" is. Is "works according to specifications" one thing? Is a single instruction one thing?
Unit testing is one type of automated tests, the other common type is integration testing. But in my opinion the important part is that tests are automated. I would argue that "unit test" is sometimes used where "automated test" would be more appropriate.
Tests some type of "unit". This might be a small method, or something much larger. The important thing is that it is fairly self contained, with few dependencies to the outside and a well defined behavior. These dependencies are then mocked, so that only the unit is tested.
Testing smaller units have the benefit of making a bug easier to fix once it has been found. While this is useful, it is in my experience a larger problem to find the bugs in the first place. I can stand a little bit of debugging if I understand the expected behavior of the unit well.
You should write tests the interface of the unit, and avoid testing internal implementation details. Naturally this might involve multiple methods, and that is not really a problem. If you often need to update existing tests when making changes to code it may indicate that the tests and/or interface is poorly designed.
Tests how units talk to each other and interact.
In practice there will be disagreements of what is a unit test or integration test. In my opinion the difference is mostly irrelevant. The end goal is to find bugs faster and cheaper. Any automated test that does this is a good one. Call it whatever you want. A better division might be according to runtime. Group tests that are slow to run and run these less frequently.
Testing of databases
When using a database it is often a good practice to separate the database parts from the rest of the application. This means you should be able to test most of the application with a mock of the database.
To test the database parts you can just use an actual database for your testing. Have the tests create a new database, populate it with some fake data, and run some queries to verify that everything works. This will be much easier if you have an automated way to create databases from scratch. This is often useful since database abstractions are leaky. Something that works with one database vendor might not work with another. It can also be very useful when developing to have a easy and fast way to test any changes. Just make sure to have some cleanup strategy to avoid accumulating obsolete test data.
Don't focus to much on terminology, and focus more on writing tests that add value for you and your particular application.