Data Modeling a Maze

Couple of weeks back, my friend took me to a maze. I was lost in a couple of minutes and was getting really frustrated after a while. I wasn't sure what algorithm they had used to construct the maze.

The only algorithm that I knew was the "Wall follower". All you have to do is it to follow either your right-hand or left hand touching the wall and you will reach either the exit or the entrance. I did take the longest path, but eventually reached the EXIT.

This algorithm would work only if all the walls are connected to form a loop. From that point, I was quite fascinated with the algorithms associated with the maze. There are also a few other efficient algorithms like Tremaux's algorithm. Visit Think Labyrinth for more fun.

After that, I thought of simulating a maze. Unfortunately, I am quite inept at programming languages, so decided to do what I know best. I thought of creating a simple data model for a Wall Follower Maze. It turned out to be quite an interesting problem. It took me around 30 minutes to come up with a decent logical data model, that would work for quite some scenarios.

So, the first model that I came up with is shown below. (Click on the picture to enlarge)

Let me give a quick explanation of the model

1. Design Co-ordinate: Super-type Entity
2. Entry, Exit and In-Maze Coordinate: Sub-Type Entities of DESIGN CO-ORDINATE which contains the co-ordinates of the location, where a player has to take a decision.
3. Decision: Entity which holds whether to turn LEFT,RIGHT,UP,DOWN or ABORT.
4. Decision Map: Entity which holds the map of a START-COORDINATE, DECISION TAKEN(whether to move left,right,up,down (or) abort) and an END-COORDINATE (the co-ordinate where he lands after he takes the decision).
5. Player: Entity which holds information about the player of the maze.
6. Movement: Entity which tracks the movement of the player.

There is one interesting phenomenon happening in this model. If an intelligent player has to play this model, this model would work, because the association between MOVEMENT-PLAYER-DECISION MAP has been modeled as an Identifying relationship. It means if a player, tries to navigate the same path twice, the system will spit out an error, (simulating an INTELLIGENT player, because he would never do the same mistake again).

But if a DUMB player had to play this maze, then this model wouldn't work, because a DUMB player would make the mistake of traversing a path with no fruits, again and again. So the association should be made as a Non-Identifying relationship.

How can I model both the scenarios at one-shot, without introducing redundancy in the entities or associations?

One of the ways to model both the scenarios is to track both their movements as 2 different MOVEMENT entities and include the constraint in the INTELLIGENT PLAYER MOVEMENT's entity. But this introduces an extra associative entity. It's easy for a toggle situation, Yes or No, DUMB or INTELLIGENT.

But, if I were to model differing levels of intelligence, how would I do it in a data model, without writing any procedural code to do it? How can E-R data models be efficiently designed for Fuzzy Logic Systems?

I found this as an interesting exercise to showcase that E-R data models are still long way from being truly a self sufficient tool.

We need a modern day E.F.Codd