Putting business logic in a DBMS can afford some logical layering, but has significant practical and strategic drawbacks:
Lock-in. Your code will be bound to that database and its available facilities, probably forever. Database migrations have historically proven extremely hard, and are thus very rare. Database lock-in has been an extensive and expensive business problem. The more tightly coupled you are to DBMS facilities, the harder it will be to ever separate from those dependencies.
This weakness is probably permanent. I've had significant discussions with CTOs at IBM, Microsoft, Oracle, and other DBMS makers about database-resident logic. Some, like Microsoft, are relatively positive. Most, however, are dismissive of or hostile to the idea; while they support it in key dribs and drabs like stored procedures, and while they appreciate developers locking themselves into their products whenever possible, they don't generally see logic-in-the-DBMS as a style of development practiced by most customers, thus not a sound place to invest significant resources.
Failure to support -ities. One of the key motivators for layered architectures is separating concerns to support modularity, scalability, availability, testability, flexibility, security, and other "-ities." Middleware engines such as application servers designed for N-tier, layered architectures often have significant abilities to isolate components from each other (for security and availability), to scale up or out (for scalability), to recognize and dynamically adjust to failed resources (for availability), and otherwise leverage the separation of concerns that layering enables. Putting logic inside a DBMS defeats many of those opportunities. Even when DBMS clusters are supported, the semantic guarantees for which databases are beloved (e.g. referential integrity, ACID) are weakened. Their internal logic programming systems have similar potholes in multi-instance support.
Impedance mismatch. With business logic in the DBMS you will still face the problem of "impedance matching" between DBMS constructs (e.g. tables and relations) into programming language constructs (e.g. objects and collections). Business logic layers often transparently up-level raw data into business-relevant objects (either directly or with the assistance of a related "business object," "ORM," or "domain" layer.) Dropping your business logic into the DBMS means that you don't have such a convenient place to "shim" DBMS results. Meaning the application code that touches your data will either touch lower-level constructs, or still require an outside-the-database mapping layer. It's not an impossible structure, but it's unwieldy.