In practice, "disk encryption" and "volume encryption" (often prefixed with "full") are two terms for the same thing. It is almost always more correct to say volume encryption - I can imagine a disk encryption system, but as far as I know none actually are in use - but the terms are used interchangeably.
Now, with that said, I'm not familiar with SAP HANA, and it looks like it's doing something perhaps better termed "file encryption" or "data encryption". User-mode software approximately never interacts with volumes directly (except for operations like formatting or imaging), and a "volume" - especially in the sense of computer data storage - typically refers to a logical range of bytes suitable for e.g. formatting with a file system. (A volume is often, but not always, the same as a partition - which is a physical, rather than logical, range of bytes - but if you have e.g. two partitions which are spanned, they will form one volume.) Getting back to SAP HANA, the page you linked talks about securing against data access "at the operating system level". It's unclear whether this is supposed to be the OS that the software runs on (in which case true security is impossible, as the OS can always read the encryption key out of process memory, or indeed read the decrypted data out of process memory), or protection against the data being read by a different OS (i.e. after a disk was stolen and put in another computer).
It is possible SAP HANA writes to a a disk volume directly, bypassing the file system driver stack, but this is very unlikely. It's more likely that the "data volume" it refers to is contained in one or more files on a file system, and simply means the place where database data is persisted rather than anything an OS would recognize as a "volume". In that case, SAP HANA's "Data volume encryption" is simply a matter of encrypting that data (in userspace, with a key known to the process) before the data is sent to the disk. The degree to which this is a meaningful security measure depends on how secure the key is; it appears the key is stored in the file system, so an attacker with full access to the disk (either offline, or through an OS they control) can probably extract the key and decrypt all the data. However, an attacker that can only access specific files (potentially backups?) that do not include the key wouldn't be able to decrypt the data.
In this case, the difference between [full] disk encryption / [full] volume encryption and SAP HANA's data volume encryption comes down to two things: where the key is stored (must be re-derived or unsealed at boot e.g. from some hardware security device or a password, or just in the file system), and where the transparent encryption/decryption occurs (in the OS storage stack, or in the HANA process). Full volume encryption is meaningless against an attacker whose code is already running on the (virtual or physical) machine but is secure against somebody stealing the hard disk. Process-level data encryption is secure against an unprivileged attacker on the local machine who can't read the key, but is a trivial speed bump against anybody who has unrestricted access to either the file system or the running process.
