A UnitOfWork is a business transaction. Not necessarily a technical transaction (db transaction) but often tied to technical transactions.
In the enterprise application patterns it is defined as
Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
It does not define how changes are written nor the storage type.
An applcation might write changes to a
- database using SQL
- file system using streams
- persistence service using http requests
- distributed cache or even in-memory storage using method invocations
A UnitOfWork (business transaction) collects changes to business objects and ensures that other business transactions will only see valid business objects.
E.g. When your application executes a use case it modifies business objects. If two business transactions (usually use cases) are executed in parallel your application must take care about the changes that each business transaction performs and the time when other business transactions will see them.
Technically this is often done using a db transaction. Thus a unit of work is usually a db transaction.
Applications that use ORM-frameworks to handle persistence usually have a one-to-one relationship between the unit of word and the db transaction. So the difference between a unit of work and a db transaction is usually not relevant for developers.