I have a database that has extensible objects. I need to know how to/if I can join descendants of a common parent to a related table. (This is implemented in a standard relational database; the concepts are object oriented, but it's not an object DB)
Here's an example:
I have an object, called a 'User'.
I've extended that object to create a new object called a 'Teacher' so, a teacher is a user, but it's got a whole bunch of other stuff about it that makes it a teacher.
I've extended the user object again to create a 'Student'.
The objects Student and Teacher are discrete objects in my qvd.
Now, the User object has a child called 'Login'. Both a Student and a Teacher may 'login', which creates a login record.
I want to discuss, in my QVD, logins generally, and allow the user to choose if they are interested in teacher logins or student logins.
I could create a student_login and a teacher_login; but I don't really want to. Additionally, that prohibits me from discussing logins in general, and restricts me to discussing one kind of object or the other.
(I a fully aware that this is a bad example, and you'd never want to do this in the above example, but in my REAL scenario, it actually makes sense, it's just a bit esoteric)
I would likely concatenate the Student and Teacher data into a single User table in QlikView, with null values for the fields they don't share in common. A "User Type" or "User Class" field would have values 'Student' and 'Teacher' to distinguish between them. They would be keyed by a "User ID" field. The Login table would also have the "User ID" field. Selecting a "User Type" of 'Teacher' would then show you only the teacher logins.
If you really wanted, you could have a User table, a Teacher table and a Student table. All would be keyed by field "User ID". All the common fields would be on the User table. All of the other fields would be on the other tables as appropriate. You would again have a "User Type" field to distinguish between the two. I could see building it that way in a relational database system. But I think it's just unnecessary complexity in QlikView.
I would likely concatenate the Student and Teacher data into a single User table in QlikView, with null values for the fields they don't share in common. A "User Type" or "User Class" field would have values 'Student' and 'Teacher' to distinguish between them. They would be keyed by a "User ID" field. The Login table would also have the "User ID" field. Selecting a "User Type" of 'Teacher' would then show you only the teacher logins.
If you really wanted, you could have a User table, a Teacher table and a Student table. All would be keyed by field "User ID". All the common fields would be on the User table. All of the other fields would be on the other tables as appropriate. You would again have a "User Type" field to distinguish between the two. I could see building it that way in a relational database system. But I think it's just unnecessary complexity in QlikView.
That's a really great thought. I'm still a bit new to Qlikview, and thinking in wholistic data terms. I'm just trying to think through the ramifications of doing it this way... I think the best way for me to figure that out is to give it a shot.
I don't know if this is the right approach, but one way to relate two different objects on the same table without loops is with a SEMANTIC load. In a semantic load, you specify the relationship between two objects, and QlikView handles the data differently than in a normal table. For the simplified example we're discussing, you would have data like "Jane Doe, Teaches, Algeabra 201" and "Bill Smith, Attends, Algeabra 201". I haven't actually used semantic loads in practice, so I'm not sure exactly how it all fits together. But now I'm curious.
OK, looks like the semantic load avoids the circular references by only letting you move one step at a time. For instance, We could start by selecting a teacher. We then click on the "Teaches ->" relationship. The teacher is automatically unselected, and all classes she teaches are selected. Click on a class, and click on the inverse "<- Attends" relationship, and the class is unselected, and all students in the class are selected.
Here's a small file demonstrating the technique with one teacher, one class, and two students. Again, it may not be what you need, but it might be at least worth a look.
I was already down the semantic load trail, from another of your suggetions, and I have a similarly functional example, but the next bit that I can't seem to get is relating my semantic table back to my base table.
So, to use your sample as a starting point, let's assume I have now added a users object that contains both students and teachers. how do I now get the semantic relationship that I've built to select the relevant members of the other objects?
ie: I select Jane Doe's record in the users table, how do I use the semantic table to now instead select all of Jane's students? the semantic table functionality works, but it isn't related to anything.
