I am not sure why you are afraid of adding more fields to the document. Having 20-30 fields to a document is not a bad thing to do. Do you have any constraints to limit the number of fields in the document?
On Jan 14, 2008 7:59 AM, Roger Camargo <[EMAIL PROTECTED]> wrote: > Thanks for answering. > > It seems that there isn't any other way around, having every combination > of dimension and level. > > The example for the observations of the dimension, would be as follow, > maybe isn't such an important information to be stored, but type it is. > > Dimension name: Region > Dimension observations: The dimension only includes countries of south > america <--This would be the observations of the dimension. > Dimension type: Geographical > > OK, now it seems that I have one document per combination of dimension and > level (following the example I provided it would be something like this > doc 0: id=0, name="Quarter sales per region", desc="Description of the > cube", dimension="Region", level="Country" > doc 1: id=0, name="Quarter sales per region", desc="Description of the > cube", dimension="Region", level="City" > doc 2: id=0, name="Quarter sales per region", desc="Description of the > cube", dimension="Time", level="Year" > doc 3: id=0, name="Quarter sales per region", desc="Description of the > cube", dimension="Time", level="Quarter" > > OK and adding the Dimension type would end up like this: > > doc 0: id=0, name="Quarter sales per region", desc="Description of the > cube", dimension="Region", dimensiontype="Geographycal" level="Country" > doc 1: id=0, name="Quarter sales per region", desc="Description of the > cube", dimension="Region", dimensiontype="Geographycal" level="City" > doc 2: id=0, name="Quarter sales per region", desc="Description of the > cube", dimension="Time", dimensiontype="Time" level="Year" > doc 3: id=0, name="Quarter sales per region", desc="Description of the > cube", dimension="Time", dimensiontype="Time" level="Quarter" > > Now what about the custom properties? > > Custom property name: Update Frequency > Custom property value: Quarterly > Custom property name: Last update > Custom property value: 2006-01-01 > > I'm afraid that I would end up not using them for the search, they would > have each one a field, and because the user can create any number of these > custom properties they would be hard to query them. Or is there any correct > way to add them to the document model? > > Roger Camargo > UMSS "University" > Cochabamba - Bolivia > > ------------------------------ > Date: Sun, 13 Jan 2008 17:07:52 -0500 > From: [EMAIL PROTECTED] > To: java-user@lucene.apache.org > Subject: Re: How to model hierarchy info to be searched related to a > document > CC: [EMAIL PROTECTED] > > > Roger, > > Why can;t you have one document for every combination of dimension, > level ? Add cube name , id and description too as a field to all documents > , all it would be reduntant information, but you can live with it i suppose? > > > I think you are developing an application to search a cube ? > > what do you mean by observations of a dimension ? is there an example? > > On Jan 11, 2008 7:57 PM, Roger Camargo < [EMAIL PROTECTED]> wrote: > > I'm trying to index information related to Olap Cubes. > > Each cube I'm trying to model it like a document. > > The cube have the following information: > > ID - Unique identifier for the cube > Name - Name of the cube > Description - Description of the cube > > (There can be many dimensions per cube) > Dimension name - Name of the dimension of the cube > Dimension observations - Observations related to the dimension. (Optional) > Dimension type - Type of the dimension > > (Each dimension has at least one Level, but there can be many levels per > dimension) > Level name - Name of the level > Level observations - Observations of the level (Optional) > > (There has to be at least one Fact per cube) > Fact name - Name of the fact > Fact aggregation - Aggregation of the fact > > (Also there can be custom properties added by the user, with the form > Name,Value) > Custom property name - Name of the custom property > Custom property value - Value of the custom property > > Right now I'm just indexing the first 3 ID, Name and Description, but I > would also want the other information to be indexed and search the cube with > that information. > > -------------------------------------------------------- > Data sample: > > ID: 0 > Name: Quarter sales per region > DescriptÃon: Description of the cube... > > Dimension name: Region > Dimension observations: The dimension only includes countries of south > america > Dimension type: Geographical > > Level name: Country > Level observations: Observations of the level.... > > Level name: City > Level observations: Observations of the level.... > > Dimension name: Time > Dimension observations: Has data only from the year 2000 > Dimension type: Time > > Level name: Year > Level observations: No observations > > Level name: Quarter > Level observations: No observations > > Fact name: Sales > Fact Aggregation: Sum > > Fact name: % Quarter Growth > Fact Aggregation: AVG > > Custom property name: Frequency > Custom property value: Quarterly > > Custom property name: Last update > Custom property value: 2006-01-01 > -------------------------------------------------------- > > My problems would be the following. > > 1. How to index "Dimension name" and "Dimension observations". > If there would be just Dimension names, I cound index it as a single Field > with multiple values. > But with the addition of the observations, I need to know if the search > term was founded within the observation, to wich dimension belongs the > founded observations. > And the same happens with the "Dimension type" > > 2. There can be many of these Dimension name, observations, type. The same > applies for the Level name, observation - Fact name,type - Custom property > name, value. > > 3. The levels. if the search term was founded in the level observation, I > would need to know to which level name is related the level observation > founded along with the dimension related, and finally the cube itserlf. > > Well... this was a bit long question to be my first one. > > Maybe what I want can't be done, maybe there could be some walkaround that > someone knows it. > > I was thinking that if it can be posible to have a field, with additional > info attached to the value, that is not searchable, it just needed when the > field value is retrieved it. > > For example a Multi-value field called DimObs. > > Value1: "Observations related to the first dimension of the cube" > Related info: "Dimension name1" > > Value2: "Observations related to the second dimension of the cube" > Related info: "Dimension name2" > > When the search is performed and is founded in the DimObs, for example > "first". > Then the search found "first" int the DimObs, but I would need to retrieve > the "Related info" to know to which Dimension belongs the observations > founded. > > Thanks in advance for keeping with me till the end of this mail and for > any suggestions that could give me. > > Roger Camargo > UMSS "University" > Cochabamba - Bolivia > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today it's FREE! > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > > > ------------------------------ > Express yourself instantly with MSN Messenger! MSN > Messenger<http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/> >
