Generally, ransomware runs as a program in your operating system, encrypts files (possibly depending on file type), and, if you're lucky, doesn't leave any time bombs in decrypted exe files later.
However, ransomware could directly target a database, although I'm not aware of any which does that (yet). This would likely be a targeted attack, not a general one, as general attacks try to find as many targets as possible, and there are many more general servers/PCs than database servers.
If I wanted to write some ransomware to target you directly, I'd write a stored procedure and attach it to a trigger somewhere. Make the stored procedure do nothing for a week or two after infection, to make sure current backups contain the stored procedure as well. After two weeks, the stored procedure would start to encrypt your database tables. Make an encrypted copy of every table, which would take a while, then drop the original tables, at which point you'd notice something is wrong.
In that scenario, all your full backups would have the stored procedure and trigger as well, so after restoring a backup your database would seem normal for a while, until the trigger hits again.
Of course, the stored procedure would normally not be able to access your file system (but beware of databases that allow file system access), but a database that becomes unusable every few days is bad enough for your organization.
If you are able to do a clean install of your software, and create an empty database according to vendor specs, then restore just the table data (basically, a restore that contains only DML, no DDL statements), you'd get rid of the ransomware.