I'm guessing that you are substituting Pages, Words and Letters for the actual table names and items tracked in your database. That makes it very hard to understand your post. If you reply back with a description based on the actual items and tables it will be much easier for others to suggest a solution.
OK i was just trying to simplify
I am project managing an interactive design project that will be made up of Screens.
The Screens will be made up of Assets (images, videos, audio, etc) and what we are calling Apps (which will also be built from Assets)
SO I need to track information and progress of both Assets and Apps, but ultimately my main concern is the completion of Screens
Does this make more sense ?
I can build the individual tables and give each asset, app, and screen an identifier, but im not sure how to set up the relationships between them.
I will create a layout that shows me the screen name and all of its corresponding assets - one of which may be an app - in which case I need a layout which can give me further info about that app and its assets
I may need other layouts for assets based ont heir class (image, video , etc) - so should I simply treat apps as an asset type ?
My thought was that that would make a circular relationship - any thoughts ?
Cant wrap my head around this table structure and relationship path
Thanks for any ideas
Can an App be built from other Apps?
Since an App can be built out of assets and a Screen can be built from assets, what's the difference between them? (You might want to treat Screens as assets also.)
It sounds like you need to support a recursive (not circular relationship here.) In which case, I think treating apps as a kind of Asset would make sense. You can, if needed, use a 2nd table occurrence of your assets table to support linking assets to other assets.