Netezza is a data warehouse appliance. Data warehouse best practices are that the database does not enforce pk/fk integrity.The pk/fk integrity check (on a row-by-row basis) is a transactional scenario. Netezza is not a transactional database, in any sense of the words.

In a data warehouse, the enforcement and management of pk/fk is always the domain of the data processing environment. If we delegate this to the database, it would be a violation of VLDB Rule #10 - Never involve the RDBMS in row-by-row data processing. As such, the database can only tell us that we got it wrong. It cannot actually fix the problem (only the data processing application can).

That's correct, but when you think about it, the RDBMS sits as a passive gateway. It either allows or disallows but does not actively participate in the process of fixing the data. All it can really say is - "I already have one of those, so I'm throwing an error and not allowing you to add another". And that's fine, but in data warehousing, we'd really rather not see the error at all. Because by the time we see the error, it's just too late. We have to take steps to back out what shouldn't be there in the first place. When could we have known this? Prior to loading it.

What we need is a way to remove the duplicates completely so that when the data is inserted, the load will complete without errors. The only positive way to do this is to join the incoming data to the target to find the dupes. We can do this far more efficiently in Netezza because we can make it a co-located join, This is far more efficient than testing for this condition one-row-at-a-time. Since Netezza doesn't apply constraints, we have to do this if we don't want dupes. But we'd have to do it with the RDBMS too, since we don't want the RDBMS involved in checking the data at this level. The RDBMS is constrained to check one-row-at-a-time and thus must violate Rule #10 - Never involve the RDBMS in bulk data processing.

So either way, the ELT/ETL process is required to manage the data into place without involving the less efficient constraint behavior.

I don't think introducing an unreliable source changes the problem, you still have to clean the data prior to loading it.  Putting a constraint on a table would prevent you from loading duplicate records but it doesn't tell you what to do with them, it just rejects them.  At some point you have to have a process to deal with the duplicates, so you might as well make it part of your ETL process.

So if your data source is Excel (which is questionable in general, but reality sometimes does get in the way of what we would really like to have), you would load the data into a staging table and then use a stored procedure to validate the data, if there are no constraint violations, the procedure would then load the data into the target table, if there are, it might deal with the violations or just reject them and leave it up to the developer / end user to figure out what needs to be done and try again.