The terms in software world doesn't usually have a well regulated definition , it is more about understanding the concept and having an organised approach to testing than testing what ever comes to our mind.
so don't need to break your head over these definitions , just remember the below
One of the reliable definitions you can refer is from ISTQB glossary: https://glossary.istqb.org/app/en/search/
A test level that focuses on individual hardware or software
so you can define what is component in anyways , it can be a class , an package, a library and so on.
Going too deep and finding the smallest component is not worth it so we considers a class or library as a unit and tests all the methods in the object works fine depending on your project.
Integration testing :
Testing performed to expose defects in the interfaces and in the
interactions between integrated components or systems.
Here again you can define what to integrate . so imagine you have 10 components and each component is integrated with each other components .
So if you try to test all this combinations , then you will spend all your time in testing than in developing something
so we don't test all the integrations we will test the integrated system as a whole ,
so in integration test we are testing a system of integrated components works fine, or the interface (API) that allows this integration works fine.
in the latest version of definition we have :
A test level that focuses on interactions between components or
they have removed the interface part , but i will like stick on to first definition as it makes more sense.
A test level that focuses on verifying that a system as a whole meets
Again system can be defined only by you on the context of your project . For example if your working with multiple agile teams. Each teams responsibility is to provide a delivery that is considered as a system for them
eg furniture is a system sitting on it , jumping on it is part of system testing
in your case if database is part of your team then DB+API+UI is your "system" , you will make sure this works as a whole.
but if your responsibility is to develop API+UI your system is (API+UI) not DB
System integration testing
A test level that focuses on interactions between systems.
eg Moving the chair into a house/room , so your checking how two system the "house" and "chair" works together
in your case:
if DB is handled by some other team , you are checking how "DB+API+System" work together
- Don't worry much about definitions , testing is highly context
- The definition of component/unit, systems, integration etc changes according to your project
- You don't have to dissect your product into so many minute components , but to many reusable component , and test its re-usability.
- Don't worry too much on component integration because in lower level of abstractions there will be too many integrations you cannot test them all and you don't have to
- Tests the interfaces this interactions and tests the system as whole
- Concentrate more on business use case than just functionality