I have a DB and application that's designed to handle a distinct structure of exactly 4 dimensions: Molecule, Atom, Particle, and Quark. There is a many-to-many relationship at all levels of the system, enabling users to reuse Atoms in various Molecules, Particles within various Atoms, etc.
A Particle must always belong to an Atom, a Quark to a Particle, etc. However, these 4 distinct models are not sub-types, and there is no inheritance involved.
When the application loads, it is designed to set the local context based on the current Molecule. There are hundreds of hard-coded methods, calls, and database relations that assume that the local context of the system is determined by the current Molecule. When a Molecule is loaded, all of its Atoms, Particles and Quarks are loaded as well. The system is designed to assume that every Molecule will have >= 1 Atoms, which have >= 1 Particles, which have >= 1 Quarks.
I am asked to adjust the system so that the top-level context can additionally handle being an Atom instead of a Molecule. Since all of the DB relations and methods assume that an Atom belongs to a Molecule, the implementation of this would require introducing checks at every point in the system, to check whether the current top-level object is a Molecule or an Atom.
If the system were truly arbitrarily multidimensional, rather than hard-coded to 4 dimensions (i.e. if rather than these four named dimensions, the system were designed to have arbitrarily named objects which contain objects to n dimensions), this might be feasible. However, the system would have been designed to handle that at the beginning (almost like a basic object-oriented system).
However, the current system was initially designed to have exactly 4 layers of dimensionality, permanently. Each of the four dimensions of the system has a distinct name and set of attributes. Everything from the DB relations to the frontend UI is hardcoded to assume this.
I see two potential solutions; the first seems like a fine solution, and the second seems to be a convoluted anti-pattern:
Simply create a one-off "Molecule" when the Atom is desired to be at the top level of the local presentational context. On the back end, this would allow us to move forward without making any major changes to the system. On the front end, we would also get away with this easily, because there are no visual references to Molecule on the front end—it is only used to provide context for the Atom the user is looking at and is never shown to the user. For Atoms that have no Molecule, we simply populate the top level of the application with their containing "one-off non-molecule" and go on our merry way.
Attempt to make the system handle situations where an Atom is at the top level AS WELL as when a Molecule is at the top level. No other contexts would be supported—only these two. This would require a major overhaul of the system architecture of the entire platform, and introduce all sorts of conundrums. Without a total re-architecture, all method calls and DB relations would have to check for the local dimensional context of the system (is it 4-deep, or 3-deep?), and then act in accordance with that. Half of our top-level method calls would break, since they'd be looking for something that doesn't exist, and without some sort of ingenious solution that I'm not sure even exists, the important lowest-level method calls would never be reached. This is especially difficult because Atoms and Molecules have different attributes.
This sounds like a wildly difficult thing to implement, because it would break the whole concept of the idea of a schema. Like building a coffee maker with a hole into which you can EITHER place a Keurig cup OR pour unground coffee beans. It makes no sense.
A system should be designed to assume EITHER a single, distinct level of dimensionality, OR N levels of dimensionality. A system designed to handle both N and N-1 dimensionality seems needlessly overly complicated to implement.
Does such a system which simultaneously supports N and N-1 dimensional relations have a name?
Is this an anti-pattern?
Does such a system which simultaneously supports N and N-1 dimensional relations have a name?
No, at least not that I know of, but indeed IMO your assumptions are not correct: you seem to be conflating the (conceptual) data model and the fact that there is a hierarchy of those entities with those relationships, with data access patterns, i.e. the queries and commands one might issue, which indeed needn't be retrieving or touching the whole data hierarchy to make sense.
the current system was initially designed to have exactly 4 layers of dimensionality, permanently. [...] Is this an anti-pattern?
No, not per se: in a domain where that is the given data model and "that's it" (which is a conceptual requirement, not a technical one), it does make perfect sense to implement the fixed semantics with a fixed data and code structure that strictly reflects the semantics.
I am asked to adjust the system so that the top-level context can additionally handle being an Atom instead of a Molecule.
I too agree you should go with your option 1, create a "virtual" Molecule containing just that Atom, virtual as in not concretely in the database. That not only minimizes coding efforts, it is also quite in line with the intended fixed semantics.