What defines minimum quality?
Subjective business logic.
What you are asking is for a bit of business logic to run on the database server itself. SQL Server, Oracle, etc have sold this as an unmitigated Good Thing. It may be good, it may not. But we should be clear that we are merely putting some of our application's logic in the database. It's not "something else".
"Further cleaning and analysis" is an interesting statement. This demonstrates that the database layer may need to be more flexible about the data that it accepts. The decision to reject some data as "unacceptable" is arbitrary and chosen by the organization writing the software.
There is not _one_ business logic layer.
One could just as easily have a dedicated import process that enforces the "import rules". This process has no relationship to the broader application's "business logic".
Furthermore, it _may_ be a good idea to have a completely separate "import database" which handles all the activities around importing data:
Audit trail of rejected data
Workflow for data cleaning including automated cleaning, manual cleaning assignments, manager approval, etc
Analysis and statistical workflows
Then, only once the data has been through this process, it can be migrated to other databases for the broader application's use.
This allows separation of concerns and reduces the complexity of the overall application. The "end user" application(s) need not worry about filtering out "unclean" data.
One mistake enterprise / gov't makes is getting trapped into the notion that everything must fit in one db. This isn't an accident. The large database vendors have been selling this notion for years. :-D
The main fear is often that buggy code will "corrupt the database". Bugs exist. Bugs can also exist in database data restrictions. Code is code. Just because it's "in the db" doesn't make it perfect. Furthermore, what happens to data that the database rejects? Is it lost? Is it buried in a log file? Is this acceptable? How could it be better? How can we allow flexibility for exceptional situations? How do we handle shifting business expectations over time?
Once we start to answer those questions, a different viewpoint begins to emerge.
Enterprise software shouldn't be about locking down servers and calling it done. It's about understanding the data flows, gaining insight into reality, and then making informed decisions to mitigate risk and maximize upside. Management.