Entry Points to the Data
Date: Sat, 5 Jun 2004 09:49:48 -0500
Message-ID: <c9smih$j0p$1_at_news.netins.net>
Starting a new thread re Eric's question "What about the users with other entry points?" when talking about how users might retrieve data through any relation or through a simplified set of "portals".
I like my department stores to have departments in them so I can shop for items in the department I would think they would be in. Then if I don't find them there, I can look at the directory or wander around or ask someone and find them in the classification the store decided on. Even though someone else might be looking for shirts and not care whether they were men's or women's shirts, the department store sets up departments (portals, namespaces, entry points) so that you don't have a choice but to use their classifications. And THAT'S A GOOD THING!
The relational model attempts something like this, with the concept of a VIEW to show a logical picture of the data that is different from the base relations. However, these views are typically only constructed when the need arises. If some are designed up front, they are often rewritten to eliminate various unneeded tables for specific reports (from what I have seen, which is not a huge base).
If, on the other hand, we provide the analogy to a men's department, women's department, etc in our data, it might include departments like People, Organizations, Products, Courses, Doctors, Students, ... And, come to find out, this makes perfect sense to users of the data when trying to retrieve it. These are logical, not physical views of the data. For each of these entry points, the user has a list of the vocabulary for what they can query. The user doesn't have to think about grouping and ungrouping in any not-so-intuitive way in order to combine rows so the query returns one row per person, for example (if you are tracking with me, that will make sense, else ask). They simply ask for those data they want and if this department doesn't have what they need, they pick one of the handful of others and look at the vocabulary (attributes) in those departments to see which to use instead.
I'm working on this namespace/portal/entry points/views angle because it appears to me that this is one area where SQL-DBMS's have largely failed and could learn from other models (e.g. PICK). The VIEW notion not only doesn't get us there, it seems unlikely it ever will. Defining these portals as logical departments with behind the scenes definitions like "if I start in this physical department what is the navigation path to grab this data for the customer when they ask for it" has a different kind of elegance than the defined view of "here is now the set of everything the user might want in this logical department" -- that department is big and unweildy to query.
It might be the case that a SQL-DBMS user could set up these departments with the proper groupings in advance to simulate this approach. I've tried it and the biggest problem comes in performance tuning but there is also the problem of just what the set looks like -- if the view includes aggregations to simplify the department, then it loses detail. That isn't the case with a PICK approach simply because you don't need to do the aggregation -- if you define your portal to start at Person, for example, then you can pull in everything related to Person and any query the user does will not explode to more than one returned "line" (not quite a row, because there could be multiple majors for a student, for example, that would take multiple rows, but not duplicate the rest of the data -- it's that dimensional thing). The only way the user gets multiple lines per person is if they request the data to be exploded so that you do get a second line for a second major.
Right now this is a big issue for me, while it is possible that someone could show me how the relational model can do something that to the user looks the same. I just don't see it at this point. Cheers! --dawn Received on Sat Jun 05 2004 - 16:49:48 CEST