Relational tables should contain data and not logic - correct?
It Depends

The purpose of a database is to store valid data in a secure fashion for multiple users across multiple applications.

Some of the logic will focus on the valid data portion of that statement.  These will be your constraints and data types.

Other parts of code within the database will focus on the multiple applications portion.  For example, a VIEW will hide some complex logic to ensure that all applications see the data in an identical manner.  One application could be a web based application, the other application could be a 3rd party report generator.

OLTP

Within an OLTP system, the complex SELECT statement and the last modified date logic doesn't make much sense.

If this is suppose to be an OLTP system, you should try to change things so that they follow normal relational database practices.

Data Warehouse

The complexity of your pseudo-code SELECT statement and your date of last edit logic makes perfect sense in a Data Warehouse [DW] environment.  However, they are probably part of an ETL/ELT process for materializing the data into a denormalized table for faster report generation.

The TABLES and VIEWS and MATERIALIZED VIEWS are built to solve a very specific set of business problems.  From my experience, those objects are used as the source for various Business Reports.  In some cases, one table/view per report is created to solve a Business Requirement.

No FKs?  That's probably normal for a DW.  The data in the tables could be refreshed with TRUNCATE followed by INSERT...SELECT.  In this situation, a Foreign Key could do more harm than good.

As I read the comments, it seams your company needs to move to a more formal OLTP hierarchical design.  I wish you luck.