JPH09305453A - Commodity specification price information storage device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a commodity specification price information device which is fast in retrieval speed by reducing data capacity and which can easily be changed in option. SOLUTION: This commodity specification price information storage device stores relation data on commodities having >=2 type codes K and >=2 options placed on commodity of a specific type code K1. In this case, (a) attribute data on the option OP which can be placed on the specific type code K1 are provided by commodities between type code data and option data and (b) the option data are given the addresses of restriction relation data of other options and other option data having restriction relation.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a product specification price information storage device capable of reducing access time by reducing the data capacity, and also a product specification price information storage for storing combination price data of a plurality of options. It relates to the device.

[0002]

2. Description of the Related Art Conventionally, for example, automobiles have been sold by adding various optional accessories to the automobile body which is a basic component. Here, there are various constraint relationships between the options. That is, there may be special restrictions on the options a and b. Generally, there are the following two types of constraint relationships for automobile options. The first type of constraint relationship is a one-way constraint relationship, and the option b can be attached only when the option a is attached. In this case, a is called a "child" and b is called a "parent". For example,
ABS only when equipped with traction control
(Anti-lock brake system) can be installed, in which case the traction control is the "child" and the ABS is the "parent". The second type of constraint relationship is a bidirectional constraint relationship, and option a and option b must be a set without exception. For example, the radio and antenna must be a set. This is because even if only one of them is attached, it will not function.

Conventionally, the constraint relationship between options is expressed using a relational database which is a tabular database. An example of a relational database is shown in FIG. This table shows that, for example, when the sales model code of the automobile is w1, the option 10A is a parent code, so that if the option 10A is adopted, the child codes options 11B, 12B, and 13C must also be adopted at the same time. Is shown. Therefore, when a bidirectional constraint relationship is expressed using a relational database, as shown in FIG. 10, in a radio that is option a and an antenna that is option b, option a is a parent code and option b is a child. It is necessary to create a pair of columns including a column having a code and a column having the option b as a parent code and the option a as a child code.

Further, when the four options a, b, c, d are in a bidirectional constraint relationship with each other, each of the four options a, b, c, d is shown in FIG. It is necessary to create four fields with the parent code as the parent code and the other three options as the child codes. Therefore, if it is attempted to manage all optional one-way constraint relationships and two-way constraint relationships with a relational database, as shown in FIG. 12, (the number of one-way constraint relationships) +
It is necessary to provide a column for (the number of bidirectional constraint relationships) × (the number of options related to each bidirectional constraint relationship). For this reason,
Very large data capacity is required.

On the other hand, as a method of expressing the constraint relationship of options by using a relational database, in addition to the above method, as shown in FIG. 13, a column of target options is provided on the vertical axis and related options on the horizontal axis. There is also a method in which a column is provided and data indicating whether there is a unidirectional constraint relationship or a bidirectional constraint relationship is stored in the column at the intersecting position. Here, what is shown in FIG. 13 is an expression of only the binary relation,
Different tables are required to express the three-term and four-term relationships. In the case of expressing with one table, FIG.
As shown in, it is necessary to use a ternary relation such as b + c for the related option. That is, when the target option is a and the bidirectional constraint relationship data is entered in the column where the related option intersects b + c, the options a, b,
It is shown that three of c are in a constraint relationship. According to this, although the number of columns on the vertical axis can be reduced, the number of columns on the horizontal axis increases, so that a very large data capacity is required as a whole.

On the other hand, FIG. 15 shows a case in which a product price information storage device for storing the sale price information of a product, including a price different for each option, is expressed using a relational database. Similar to FIG. 9, the vertical axis indicates the sales model, and the horizontal axis indicates the combination of options required corresponding to the sales model. That is, sales model w1
Is equipped with option a, and its selling price is C1.
It is. The sales model w3 includes an option a and an option b, and the selling price is C3.

[0007]

However, in the conventional product specification database and product price information storage device,
There were the following problems. (1) The relational databases shown in FIGS. 10 to 12 have an extremely large data capacity, which causes a problem that search response is significantly reduced. In particular, it is not possible to accurately determine whether the constraint relationship is unidirectional or bidirectional unless all data is read,
It took a long time to respond, which was a problem. (2) The relational databases shown in FIGS. 13 and 14 also have a very large data capacity, so that there is also a problem that the response of the search is significantly reduced.
Further, in this relational database, as shown in FIG. 13, since redundant data and unnecessary data having no relation are stored, an extra data capacity is taken.

(3) In addition, when a part of the options is changed, for example, when the option d is abolished in FIG. 11, all the items including the option d are deleted while being searched. Since it must be done, there was a problem that maintenance and management of the database took time and cost. (4) On the other hand, in the relational database shown in FIG. 15, as the number of options increases, the size of the table becomes huge and the data capacity explosively increases, so there is a problem that the search response is significantly reduced. It was If some of the options are changed, for example, if the option d is abolished in FIG. 15, it is necessary to delete all the items including the option d while searching the database. There was a problem that maintenance and management took time and cost.

(5) Further, when the same option a is attached to different basic components, it may be necessary to reduce the price of the option a, or conversely, it may be necessary to add an additional price. This is because even if the same option is installed, the price of the mounting bracket and the like may be different and the installation work cost may be different due to the difference in the basic components. In such a case, in the conventional relational database shown in FIG. 15, different columns have to be provided for the option a1 and the option a2, and there is a problem that the data capacity further increases. (6) In addition, some options may be discounted by being used in combination with other options. Even in that case, the relational database shown in FIG.
+ B has to be provided with a different column, which causes a problem of increasing the data capacity.

The present invention solves the above-mentioned problems and provides a product specification price information storage device that reduces the data capacity and has a high search speed, and a product specification price information storage device whose options can be easily changed. With the goal.

[0011]

In order to solve the above problems, a commodity specification price information storage device of the present invention has the following configuration. (1) Product specification price information storage device for storing relationship data between a product having a model code for each basic component and two or more accessory components mounted on the basic component represented by a specific model code product (A) For each model code, attribute data of an accessory component that can be attached to the basic component represented by the model code is provided between the model code data and the accessory component data, and (b) ) The accessory component data has constraint relationship data with other accessory components and the existence position data of the other accessory component data having a constraint relationship.

(2) In the device described in (1), the first type code basic component and the first accessory component are connected by attribute data, and the second type code basic component and the first accessory are connected. When the component is connected by attribute data, the first accessory component data is stored separately for the first model code product data and the second model code product data. . (3) In the device described in (1), the first model code basic component and the first accessory component are connected by the first attribute data, and the second model code basic component and the first accessory component. When the product is linked by the second attribute data, the first constraint relationship data between the first accessory component and the first other accessory component, the first accessory component and the second others. It is characterized in that the second constraint relationship data with respect to the accessory component of is stored separately as different types.

(4) In a product specification price information storage device for storing sales price data of a product consisting of a combination of a basic component and an accessory component, (a) combination conditions of accessory components that can be mounted on the basic component The attribute data that is
Between the basic component data and the accessory component data,
(B) Individual accessory component price data is stored for each attribute data. (5) In the device described in (4), (a) the accessory component data includes constraint relationship data between the first accessory component and the second accessory component, and (b) the constraint relationship data,
It is characterized by including additional price data added to the first accessory component price and the second accessory component price. (6) In the device described in (5), the additional price data is different data corresponding to the basic component.

The product specification price information storage device of the present invention, having the above-mentioned configuration, operates as follows. The product is stored as two or more model code data having different basic components. Also, accessory components to be attached to the product are stored as two or more accessory component data. Here, accessory components that can be attached to a specific model code product are predetermined. For example, an automobile has two or more model codes for the same vehicle type and is stored as model code data. In addition, there are many options that can be mounted on each type of automobile, and the mountable options are stored as option data. Here, options that can be installed in a vehicle of a specific model code are predetermined. Between the model code data and the option data, there is attribute data indicating which option can be installed in a vehicle of a specific model code. That is, each model code data has an address of an attachable option.

Further, the constraint condition with other options is stored in the option data as the constraint relational data and the address of the other option data. That is, when the option 1 that can be mounted on the model code 1 and the option Y have a one-way constraint relationship, the option 1 data includes
The address of option Y is stored together with the one-way constraint relationship data. And option 1 and option Y
If and have a bidirectional constraint relationship, the option Y data also stores the address of option 1 together with the unidirectional constraint relationship data. Option 1 and Option Y
By storing the one-way constraint relationship between and, it is recognized that option 1 and option Y have a two-way constraint relationship.

As described above, since the optional address that can be attached to the model code data is stored, the data capacity can be remarkably reduced as compared with the relational database. Furthermore, since the option stores the constraint relationship with other options and the addresses of other options, the data capacity can be significantly reduced as compared with the relational database. Then, since the data capacity is reduced, the data access speed is increased and the processing speed of the entire system is improved. Also, when deleting one option, the conventional method is to search for that option and
Although it had to be deleted one by one, this device can easily and quickly delete options by only deleting the option data linked to the model code.

Further, when the option 1 and the option X which can be mounted on the model code 2 are in a one-way constraint relationship, the option 1 data 2 is separated from the option 1 data for the model code 1 for the model code 2. I remember.
According to this method, option 1 data, option 1
Although there is a demerit to store the same data twice, such as data 2, there is an advantage that the handling of data is simple. Instead of this method, one option 1 data is linked to type 1 and type 2, and the first constraint relationship data between option 1 and option Y and the second constraint relationship data between option 1 and option X are different types. May be stored as the relational data. As a result, the data capacity can be reduced.

Further, in the above commodity price information storage device, the option price data is stored in the attribute data between the basic component data and the option data. That is,
Although the option price may change depending on the basic components that are installed, in the past, the option price was treated as constant and the option price was changed by processing such as discounts. Since the individual option price is stored for each attribute data corresponding to the component, it is possible to have a plurality of option prices. The reason why the option price changes is that the price of the mounting bracket and the cost of installation work differ depending on the basic components.

By storing the option price data in the attribute data as described above, the price data which has been conventionally stored for each combination of the basic component and the option in the relational database is uniformly stored as the option price data. Therefore, the data capacity can be reduced. And because the data capacity decreases,
The access speed to data becomes faster, and the processing speed of the entire system improves. In addition, in the case of deleting one option, in the conventional method, the option had to be searched and deleted one by one, but in this device, the option tied to the model code is linked. You can easily and quickly delete options simply by deleting the data. You.

Further, the constraint relation data stores the additional price added when the option 1 and the option 2 are combined, and the processing is performed, so that it occurs when a specific option is combined. It can respond to price changes quickly and reliably. Furthermore, when option 1 and option 2 are combined, the price change may differ depending on the basic component, that is, the additional price may change. Even in that case, since the additional price data is stored as different data corresponding to the basic component, it is possible to deal with it quickly and accurately.

[0021]

BEST MODE FOR CARRYING OUT THE INVENTION A commodity specification price information storage device according to an embodiment of the present invention will be described in detail with reference to the drawings. FIG. 1 shows an object diagram of the basic configuration of the database of the product specification price information storage device, and FIG. 2 shows its instance diagram. FIG. 1 shows a model code of a plurality of vehicles managed by the product specification price information storage device, an option installed in a vehicle having the model code, and a system for managing the relationship between the model code and the option. There is. The automobile 11 as an entity and the option 12 are each shown by a rectangular frame. Each frame is divided into two parts by a horizontal line, the set name of each entity is shown on the upper side, and the expression means (eg, code, name, number, etc.) for concretely expressing each entity on the lower side. )It is shown.

A straight line 13 connecting the automobile 11 and the option 12 shows the relation between the automobile 11 and the option 12. The type of association is indicated by the symbol at the end of the line.
The black circles shown in FIG. 1 indicate that there are a plurality of sides where black circles are written as seen from the side where black circles are not written and they are related. Specifically, it means "one car has a plurality of options." And "an option has a plurality of cars." That is,
It means that a plurality of options can be installed in one car. "One option can be installed in a plurality of cars." The circular arc 14 shown in the lower right of the option 12 indicates that the entities in the own assembly are related to each other. Specifically, it indicates that “to install one option, another option must be installed”.
Such a straight line 13 and a circular arc 14 are realized by a technique called a pointer in the product specification price information storage device (computer). That is, it means that the address value on the data storage medium of another related entity is included in the relationship in the data expressing each entity.
Specifically, it means that the model code data of the automobile has an address on an attachable optional data storage medium including a relation of being attachable.

FIG. 2 shows the relationship between data when the relationship shown in FIG. 1 is implemented on a computer and individual substantive data is allocated. In this way, the relationship diagram that applies to entities is called an instance diagram. In FIG. 2 as well, the association is shown by a straight line, but the association is realized by the pointer on the computer. Model K1, K2, K
Reference numerals 3 and K4 represent the entities of automobiles, which are products each having a model code, and have a plurality of options each having an option code. In addition, each option OP11, OP12, OP21, OP22, OP
31 and OP32 are associated with different options.

The first type of association is OP12 and OP.
21 or a bidirectional constraint relationship represented by a bidirectional arrow in the relationship between OP12 and OP32. The second type is a one-way constraint relationship represented by a one-way arrow in the relationship between OP22 and OP31. Here, the one-way constraint relationship means a relationship in which the option b can be attached only when the option a is attached. The bidirectional constraint relationship is a relationship in which the option a and the option b must always be a set.

In FIG. 2, for example, the option OP11 having a bidirectional constraint relationship with the option OP21 and the option OP12 having a bidirectional constraint relationship with the option 32 are separately present. In this way, it is possible to have a plurality of options for each type of constraint relationship between options. According to this method, although the data capacity is slightly increased, it is a small amount as compared with the relational database, which is not a problem. Conversely, option OP1
The presence of 1 and the option OP12 separately has an advantage that data can be easily handled and the processing can be speeded up.

Instead of the above method, it is also possible to express the relationship without increasing the number of options by changing the meaning of the line expressing the relationship for each constraint relationship between the options. That is, as shown in FIG. 4, each of the model K1 and the model K2 is connected to the option OP1, the option OP1 connected to the model K1 has a constraint relationship with the option OPX, and the option OP1 connected to the model K2 is
It has a constraint relationship with the option OPY. Option OP1
When there are two or more types of functions in and the model K1 is specified, the address of the option OPX becomes an argument,
When the model K2 is designated, the address of the option OPY becomes an argument. According to this method, since the number of options is not increased, the data capacity can be reduced.

Up to now, the constraint relationship due to the combination of two options has been described, but the expression of the constraint relationship due to the combination of three or more options can be expressed by connecting three or more options with a line as shown in FIG. Can be expressed. That is, FIG. 3 shows the state of the constraint relationship due to the association of the three options. When the option OP1 which can be installed in the automobile of model K1 is installed, the option OP2 and the option OP3 can be installed.

As described in detail above, according to the commodity specification price information storage device of the present embodiment, the option attribute data that can be attached to the vehicle with a specific model code is converted into the model code data and the option data. Since the option data has the constraint relation data with other options and the address of the other option data having the constraint relation, the option data has a significantly larger data capacity than the relational database. The price calculation processing speed can be increased. Also, if you want to delete one option, just delete the option class, there is no need to search and delete one by one like a relational database,
Maintenance efficiency is improved.

Next, a commodity specification price information storage device of another invention will be described in detail with reference to the drawings. FIG. 5 is an object diagram showing a method of storing the selling price of a car when a car, which is a product, is sold by combining one basic component and a plurality of options. 6 and 7 show object diagrams when the notation is changed. Similar to FIG. 1, the basic component 21 as an entity and the option 22 are connected by a straight line 24. The meaning of the black circles is the same as in FIG.

Here, FIG. 5 differs from FIG. 1 in that the straight line 2
4 is that the option price 23 is connected by a semicircle 25. That is, a plurality of options 26 attachable to the basic component 21 are stored as attribute data, and individual option price data is given to each specific option 26 connected to the basic component 21. The object diagram shown in FIG. 5 can be rewritten without changing the contents to the object diagram shown in FIG. 6 or 7. In other words, the same applies when the price is a member of the option class.

Next, FIG. 8 shows the relationship between data when the relationship of FIG. 5 is implemented on a computer and individual substantive data is allocated. In FIG. 8 as well, the relation is shown by a straight line, but on the computer, the relation is realized by the pointer. The models K1 and K2 are the entities of the basic components of the automobile, each of which has a model code, and have a relation of having a plurality of options each having an option code. The price of the option OPA of the model K1 is A1, and the price of the option OPA of the model K2 is A2. In addition, the price of option OPB which model K1 has is
The price of the option OPB included in the model K2 is B2. Same option OP
The price of A is different depending on whether it is attached to the model K1 or the model K2, because the price of the mounting bracket and the installation work cost are different. Here, in terms of data handling,
It is possible to store the price of the mounting bracket and the installation work cost as another price and process them as a combination price thereof, but there is a problem that the processing speed becomes slow due to too much data.

Each option OPA, OPB, OP
Each C has an associated option. Then, when the option OPA and the option OPB are combined and attached, price data that is discounted by β from the price of A1 + B1 is stored in the option OPA data. In this case, when the option OPA and the option OPB are combined, the discount is always performed by β. Discounting due to the combination of the two is a frequent occurrence in regular trading. As a result, β can be discounted without creating another option data of A1 + B1.

Also, option OPB and option OP
When attaching in combination with C, and when the model K2 is designated, the condition / price data for reducing the price by α rather than the price of B1 + C1 is stored in the option OPA data. In this case, when the option OPB and the option OPC are combined, the model K
Only when 2 is specified, α is discounted. Therefore, even when the option OPB and the option OPC are combined and attached, the discount is not performed when the model K1 is designated. This is because, depending on the model code, there are cases where discounting is not performed with the option. For example, when the basic component price is set low, there is a case where discounting is not performed in order to make profit as an option.

Next, the operation of the commodity specification price information storage device will be described with reference to FIG. If you want to find the combination price including the options tied to model K1, first type K
Prepare a function that finds the price including the options tied to 1. This function has the optional addresses (S1, S2, S3) tied to the model K1. All addresses S1, S connected to model K1
2, S3 receives the above-mentioned function, and a message that asks for each option price operates, and the option A
Bring a price A1 at. Similarly, bring the price B1 in option B. Similarly, bring the price C1 in option C.

This function also activates a function of whether or not there is exceptional condition data in option A, option B, and option C, and if there is an exceptional condition, brings up the correction price in the exceptional condition. That is, for example, the function for obtaining the option price activated by the option A has the exceptional condition between the option A and the option B and the discount value β. In addition, the function that obtains the option price started with option B is option B and option C.
And the exceptional condition with and the discount value α. Model K1
Then, depending on the collected option price and exceptional conditions,
Calculate the option price. This makes it possible to obtain the total price of model K1 when the options are combined.

As described in detail above, according to the product specification price information storage device of the present embodiment, the attribute data, which is the combination condition of the options that can be attached to the basic component, is converted into the basic component data and the option data. The price of the basic component and the price of each installed option do not add up to the selling price because individual accessory component price data is stored for each attribute data. In this case, that is, it is useful for storing the product specification price information when the option combination price changes depending on the combination condition.

The present invention is not limited to the above embodiment, and various changes can be made without departing from the spirit of the present invention. For example, in the present embodiment, the automobile and the option thereof have been described, but it goes without saying that the present invention can be applied to other products. Further, in the present embodiment, the case where there is one basic component has been described, but the same applies to a product configured with two or more basic components.

[0038]

According to the commodity specification price information storage device of the present invention, optional attribute data that can be mounted on a vehicle with a specific model code is provided between the model code data and the option data. Since data has constraint relation data with other options and addresses of other option data having constraint relations, the data capacity can be significantly reduced compared to a relational database, and the price can be reduced. The calculation processing speed can be increased. Further, when deleting one option, it is not necessary to search and delete one by one as in a relational database, only by deleting the option class, which improves maintenance efficiency.

According to the product specification price information storage device of the present invention, attribute data, which is a combination condition of options that can be attached to the basic component, is provided between the basic component data and the option data, and the attribute data is stored. Each accessory component price data is stored, so if the price of the basic component and the price of each installed option do not add up to the selling price, that is, the combined price of the options is It is useful for storing product specification price information when it changes depending on the combination conditions.

[Brief description of drawings]

FIG. 1 is an object diagram showing a configuration of a database of a product specification price information storage device according to a first embodiment.

FIG. 2 is an instance diagram of FIG.

FIG. 3 is an instance diagram showing a constraint relationship due to a combination of three or more options.

FIG. 4 is an instance diagram showing another expression format of constraint relationships.

FIG. 5 is an object diagram showing a configuration of a database of a product specification price information storage device according to a second embodiment.

FIG. 6 is an object diagram in which FIG. 5 is rewritten.

FIG. 7 is an object diagram obtained by further rewriting FIG.

FIG. 8 is an instance diagram of FIG.

FIG. 9 is a table showing a conventional relational database.

FIG. 10 is a table showing a bidirectional constraint relationship.

FIG. 11 is a table showing bidirectional constraint relationships for four options.

FIG. 12 is an explanatory diagram showing the number of columns in a relational database.

FIG. 13 is a table showing a relational database of another conventional expression.

FIG. 14 is a table showing a relational database for expressing a constraint relationship of a combination of three or more options.

FIG. 15 is a table showing a conventional relational database including prices.

[Explanation of symbols]

 11,21 Automotive class 12,23 Option class 22, Price class K type instance OP Option instance

Claims (6)

[Claims] 1. Product specification price information storage for storing relational data between a product having a model code for each basic component and two or more accessory components mounted on the basic component represented by a specific model code. In the device, for each model code, attribute data of an accessory component that can be attached to the basic component represented by the model is provided between the model code data and the accessory component data, and the accessory component data The commodity specification price information storage device is characterized in that the relation specification data with another accessory component and the existence position data of the other accessory component data having the constraint relationship are provided. 2. The apparatus according to claim 1, wherein the first model code basic component and the first accessory component are linked by attribute data, and the second model code basic component and the first accessory component. When the product and the product are linked by attribute data, the first accessory component data is stored separately for the first model code product data and the second model code product data. Specification price information storage device. 3. The apparatus according to claim 1, wherein the first type code basic component and the first accessory component are linked by the first attribute data, and the second type code basic component and the first type code basic component are connected. When the accessory component is connected by the second attribute data, first constraint relationship data between the first accessory component and the first other accessory component, the first accessory component and the first accessory component data. (Ii) A product specification price information storage device, characterized in that the second constraint relationship data with other accessory components are stored separately as different types. 4. A product specification price information storage device for storing sales price data of a product comprising a combination of a basic component and an accessory component, which is a combination condition of the accessory component attachable to the basic component. A commodity specification price information storage device, characterized in that attribute data is provided between basic component data and accessory component data, and individual accessory component price data is stored for each of the attribute data. 5. The apparatus according to claim 4, wherein the accessory component data includes constraint relationship data between the first accessory component and the second accessory component, and the constraint relationship data is the first accessory configuration. A commodity specification price information storage device including additional price data to be added to a product price and a second accessory component price. 6. The product specification price information storage device according to claim 5, wherein the additional price data is different data corresponding to the basic component.