DB view with flexible number of columns?

Question

In my Oracle 10 I have these tables
Customer table:
id      customer
1       John
2       Bob
Item table
id      item_name
1       itemA
2       itemB
3       itemC
4       itemD
Purchase table:
id      item_id date    customer_id
1       3       070202  2
2       6       070203  5
...I'd like to create a view like this:
        itemA   itemB   itemC   itemD   ...
John    3       4       0       0       ...
Bob     0       3       0       0       ...
...The view showed John purchased itemA 3 times, item B 4 times. Bob purchased itemB 3 times. This assume each customer only by one item at a time, which is a reasonable simplification of my situation.
Such a view (with variable number of columns) is needed not in our web application but also provide an understandable data source for non IT professional to use report software. If my approach of solving this problem is completely wrong, I'd also like to know what's the common practice. Thank you very much in advance!
Message was edited by:
user609663

Answer 1

I have tried to ask the question in a way that greatly simplify current problem to make it easy for others to understand without having to explain a lot of background information and 'the situation'; it seems I over-simplified the issue to make it even not worth solving or a wrong question being asked. So here I explain the complete problem and look for advice again (be prepared, pretty long description following:). I am a purchased customer of Oracle 10 DB and I reasonably expect being considered as Oracle user looking for help rather than students trying to play smart with assigned data normalization course exercises.
We are working on a system that collects data from interview results. The questionnaires for the interviews are formatted with a coded question, followed by user's answer to the question, like the following:
     Question Code   Question content   Answer
     H001            ...                123
     H002            ...                45
     H003            ...                33
     H004            ...                66
     H005            ...                4,66
     ...             ...                ...The users answer question with a digit, for some special questions, e.g. H005, they are allowed to answer with a set of digits. There are thousands of interviews each year, the simplest solution to collect the interview answers is to use such a db table:
simple_db_table:
id   H001  H002  H003  H004  H005  H006  H007
1    123   45    33    66    4     82    9
...This solution have two problems:
1. It doesn't properly store answers to questions that requre a set of digits, like H005.
2. The number of questions and their codes change from one survey to another, but the table have fixed number of columns and column names.
And two benefit:
1. With such simple table, people who use report software that directly access oracle db can creat their reports on easy-to-understand data presentation;
2. calculation based on questionnaire data is simple, e.g. get the average of H007/H009 for questionnaires that have H002 > H003 * 600 would be:
SELECT SUM(H007) / SUM(H009) FROM simple_db_table WHERE H002 > H003 * 600;Next solution we have normalized tables:
questionnaire_entry_table:
id                 NUMBER
questionnaire_name CHARquestionnaire_definition_table:
id                 NUMBER
questionnaire_id   NUMBER
question_code      CHAR
question_content   VARHCARinterview_table:
id                 NUMBER
questionnaire_id   NUMBER
date               DATEquestionnaire data table: itv_data
id                 NUMBER
interview_id       NUMBER
question_code      CHAR
answer             NUMBERWith the new structure, it just turn the problems of simple_db_table to its benefit and simple_db_table's benefit become the problem:
1. Personnel who use report creation software feel too confused to make report based on such tables, because they do not understand the normalized modeling. In our case, effective training is difficult because there will be many geographically distributed people make reports based on this structure and they have lower IT knowledge than database administrators. These personnel can make reports based on simple_db_table.
2. calculation based on questionnaire data is very difficult.
To explain 2, let's take the same example, we still wish to get the average of H007/H009 for questionnaires that have H002 > H003 * 600, my method is:
setp 1: create a view with by using:
       CREATE VIEW v (id, H002, H003) AS
       SELECT a.itv_id, a.H002, b.H003
         FROM itv_data a, itv_data b
       WHERE a.interviewee_id=b.interviewee_id
         AND a.question_code='H002' AND b.question_code='H003';step 2: create a stored procedure to get the calculation result:
       CREATE OR REPLACE PROCEDURE get_result (result OUT NUMBER) IS
         sh007 NUMBER := 0;
         sh009 NUMBER := 0;
       BEGIN
         SELECT SUM(H007) INTO sh007 FROM itv_data
           WHERE itv_id in (SELECT id FROM v WHERE H002 > H003 * 683);
         SELECT SUM(H009) INTO sh009 FROM itv_data
           WHERE itv_id in (SELECT id FROM v WHERE H002 > H003 * 683);
         idc := sh007/sh009;
       END get_idc;As you can see the calculation become much more complex and might involve overhead.
There might be better way to calculate the result that I don't know yet. We have some 100 different formulas to calculate different results, so it's important to get them right and efficiently.
The best solution seems to me is that to create such a view from itv_data and other tables so that to reflect the same structure of simple_db_table. So here comes the question I originally asked how is it possible to create a view with flexible number of columns. I made the very simple example in my original posted message wishing to get an idea of this is possible or the way to go.
I may be taking a completely wrong approach to attack the problem, e.g. perhaps there is a simpler way to get_result from itv_table and for report creation users I should use a metadata layer on top of the normalized table structure (e.g. by using Metadata Query Language from Pentaho BI). But anyway I'd like to get some insightful ideas from the forum. Again thanks for help in advance.