All you have to do in order to escape relational purity is store data in cells that isn't relational.

As soon as you have a database with a string type, that string in a cell can store data that isn't relational.

Extracting XML from a database cell and then accessing that XML in your software program using XML query tools or XML parsing, is an example of you defeating the relational model to query data in a non relational way. Your database can still supposedly be relational, even though you have unrelational data in a cell... a paradox that is mind boggling.

A database with a rich type system and a database with strings, allows you to escape the rigidity/boxyness of relational. By rich type system I mean a database that allows you to store structs, objects, and complex data in a cell rather than more simple data like a plain integer or boolean type.

Imagine a database that only allows Integers and booleans, along with strings that max at 10 characters long. This would force you to design everything purely relationally, whereas a database with a string type that is 65,000 characters long allows you to put stuff into the cells under the column which can bypass relational purism (like a massive XML file with tons of data in it:  UnRelational, tag/tree data).

This loophole is both good and bad. The good part about the LoopHole is sometimes we have data (like HTML or MS Word Documents) that just isn't relational. A bunch of paragraphs and tags in document form isn't tabular.  The '''bad''' part about the LoopHole is that people can store all kinds of tree/tag data inside cells which really could potentially be in tables/relations instead. Storing data in cells as if the cell was a miniature database itself, locks that data in that cell and renders it non-query-able by anyone (unless they extract the data from the cell in their software application, but SQL cannot access the sub-data inside the cell! SQL just pulls the data out of the cell as one big lump of continuous data). This loophole therefore can encourage extremely UnNormalized databases.

''On a small scale, humans just plain find trees easier to work with. They are usually conceptually and visually easier to absorb. The problem is the DiscontinuitySpike going between a relational world and a tree world. The best tool for the job at a large scale is not the best tool for the job at a small scale. Thus, we must divide what will be used with which tool, creating a more or less hard-wired classification of domain objects that is based on the tool instead of the domain. EssExpressions try to stretch trees to the large scale, which has proven human-unfriendly for the most part despite 50 years of trying.''