JPH11195067A - Merchandise information data base - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a merchandise information data base where retrieval speed is high and the merchandise information data base where an option is easily changed by reducing data capacitance. SOLUTION: The merchandise information data base is provided with an automobile having format codes at every basic constitution object and more than two option code 13 which are installed on the basic constitution objects which are expressed by the specified format codes and are provided with option codes. Installation restricting code 12 data which indicates restricting condition in design or technique at the time of installing an accessory constitution object to the automobile 11 is provided between one or more than two kinds of format code 11 data and one or more than two kinds of accessory constitution object code 12 (option code 13) data.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a merchandise information database capable of reducing data capacity and shortening access time, and also relates to a merchandise information database storing combination price data of a plurality of options.

[0002]

2. Description of the Related Art Conventionally, for example, an automobile has been sold with a number of optional components being added to an automobile body which is a basic component. Here, various design or technical restrictions exist between the options. That is, the option a and the option b may have special design or technical restrictions. In general, there are the following two types of constraint relations of vehicle options. The first type of constraint relationship is a one-way constraint relationship,
Only when the option a is added, the option b can be added. In this case, a is called a "child" and b is called a "parent". For example, it is possible to wear an ABS (anti-lock brake system) only when the traction control is turned on. In this case, the traction control is a "child" and the A
BS is the “parent”. The second type of constraint relationship is a bidirectional constraint relationship, in which the option a and the option b must be a set. For example, a radio and an antenna must always be a set. This is because the function is not achieved even if only one of them is attached.

Conventionally, a constraint relationship between options is expressed using a relational database which is a database in a table format. However, the conventional relational database has the following problems. (1) There is a problem that the response of the search is remarkably reduced because the data capacity becomes very large. In particular, it is difficult to accurately determine whether the constraint relationship is one-way or two-way unless all data is read, so that a long response time is required. (2) Unnecessary data that is not related to duplicated data is stored, so that extra data capacity is taken. (3) In addition, when a part of an option is changed, for example, when an option is abolished, it is necessary to delete while searching all items including the option. There was a problem that it took time and cost for maintenance.

In order to solve the above-mentioned problem of the relational database, the present applicant has filed a Japanese Patent Application No. 8-114494.
In No. 8, a product specification price information storage device that constructs a database using an object model was proposed. FIG. 9 shows the class object. A product specification price information storage device for storing relation data between a product having a model code for each basic component and two or more accessory components attached to the basic component represented by a specific model code product. ,
(A) For each model code, attribute data 103 of the accessory component attachable to the basic component represented by the model is provided between the model code data 101 and the accessory component data 102, and (b) The accessory component data 102 includes constraint relationship data 104 with other accessory components, and existence position data 104 of the other accessory component data having a constraint relationship.

FIG. 10 shows the relationship between the data when the relationship shown in FIG. 9 is implemented on a computer and individual entity data is allocated. The relationship diagram applied to the entity in this way is called an instance diagram. Also in FIG. 10, the association is represented by a straight line, but on the computer, the association is realized by a pointer. Model K1, K2
K3 and K4 are entities of automobiles, each of which is a product having a model code, and indicate a relationship that a plurality of options each having an option code are provided. Further, each of the options OP11, OP12, OP21, OP22, O
P31 and OP32 are each associated with another option.

[0006] The first type of connection is OP12 and OP12.
21 or a bidirectional constraint relationship indicated 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 refers to a relationship in which the option b can be added only when the option a is added. In addition, the bidirectional constraint relationship refers to a relationship in which option a and option b must always be set.

In FIG. 10, for example, option OP21
An option OP11 having a two-way constraint relationship with the option OP12 and an option OP12 having a two-way constraint relationship with the option 32 are separately provided. In this manner, a plurality of options can be provided for each type of constraint relationship between options. According to this method, the data capacity is slightly increased, but it is a small amount as compared with the relational database, and does not cause any problem. Conversely, option OP1
1 and the option OP12 are separately provided, so that there is an advantage that data can be easily handled and processing can be speeded up.

[0008]

However, the database proposed in Japanese Patent Application No. 8-114948 has the following problems. (1) Since the option data has a constraint relationship, it is necessary to separately give the same option data to each model data for options having different constraint data. That is, in FIG. 10, even if option 1 is the same, option 1
Option 11 for model 3
It was necessary to have it as 12. For this reason, there is a problem that extra data has to be stored and extra time is required for data retrieval. Further, when one option is to be deleted, it is necessary to delete a plurality of option data, resulting in poor maintainability.

(2) When a car is sold, options are provided as standard equipment or installed according to an order depending on the model. Further, even in the case of attachment according to an order, a maker option attached at a maker stage and a dealer option attached at a dealer stage are distinguished. Japanese Patent Application No. 8-1149
The database proposed in No. 48 did not include optional conditions for selling and was managed as a separate database, so it was a database with poor usability. That is, when a customer wants to buy a car, it is important to know what options can be installed on a certain type of car, and whether the option is a manufacturer option or a dealer option. is there. The reason is that there is a difference in the lead time until the vehicle reaches the customer due to the difference in the mounting form. In addition, the dealer option can be installed even after purchasing the car, but the manufacturer option is too late unless selected when ordering. In the conventional apparatus, since the mounting form, which is a condition for sale, is managed as a separate database, it has to be referred to separately, which requires extra work and extra time.

(3) The product information database is handled by a plurality of departments such as a design department, a planning department, and a sales department of a manufacturer, and the content can be changed in each department. However, if a plurality of departments try to change the product information database at the same time, it is difficult to grasp the current data, and there has been a problem of causing confusion. In addition, if a price is entered for the option in the sales department before the installation condition of the new option is added, there is no object for storing the price, and there is a problem that the data is confused.

SUMMARY OF THE INVENTION It is an object of the present invention to solve the above-mentioned problems and to provide a product information database with a reduced data capacity and a high retrieval speed, and a product information database in which options can be easily changed.

[0012]

In order to solve the above-mentioned problems, a product information database according to the present invention has the following arrangement. (1) A product information database including a product having a model code for each basic component and two or more accessory components attached to the basic component represented by a specific model code and having an accessory component code. Between one or more of the model code data and one or more of the accessory component code data, design or technical constraints when the accessory is attached to the product. It has the mounting constraint code data shown.

(2) In the merchandise information database described in (1), in accordance with the mounting restriction code data,
It is characterized by having mounting form code data indicating conditions on sale when the accessory component is mounted on the product. (3) In the product information database described in (1) or (2), in accordance with the mounting constraint code data,
It is characterized by having price data when the accessory is attached.

(4) In any one of the merchandise information databases described in (1) to (3), when a new input process, an edit process, or a delete process is performed from the first input means to each of the data, An exclusive control function that inhibits the processing of the first input means when any of the processing is performed from the second input means, and an input of the price data when the mounting constraint code data has not been input. And a business restriction function for prohibiting the operation.

The product information database of the present invention has the above-described structure, and operates as follows. products are,
The basic components are stored as two or more different type code data. Further, 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 model and is stored as model code data. There are a variety of options that can be mounted on vehicles of each model code, and the options that can be mounted are stored as option data. Here, options that can be mounted on a vehicle having a specific model code are determined. Attribute data indicating which option can be mounted on a vehicle having a specific model code is provided between the model code data and the option code data. That is, there is mounting restriction code data indicating design or technical restrictions between the model code data and the option code data.

The installation constraint code data has all combinations of options that can be installed in a specific model as data. For example, if Option 1 and Option 2 are bidirectionally restricted in Model 1, Option 1 and Option 2 can be simultaneously mounted on the mounting constraint code Y1 between Model 1 and Option 1 and Option 2. Are stored, and there is no mounting constraint code indicating that the option 1 can be mounted alone and no mounting code indicating that the option 2 can be mounted alone. If Option 1 and Option 2 have a one-way restriction in Model 1, Option 1 and Option 2 can be installed simultaneously in the mounting constraint code Y1 between Model 1 and Option 1 and Option 2. Are stored, and a mounting constraint code indicating that the option 1 can be mounted alone is stored, and there is no mounting code indicating that the option 2 can be mounted alone.
In this case, it is understood that the option 2 can be mounted only when the option 1 is mounted, and the option 1 and the option 2 are in a one-way constraint relationship.

As described above, since the mounting constraint code data is provided between the model code data and the option code data, only one option data need be stored at all times, as disclosed in Japanese Patent Application No. 8-114948. In addition, for options having different constraint data, the same option data need not be individually provided for each model data. Further, when an option is to be deleted, only one option data needs to be deleted, so that the maintainability is improved.

The mounting mode code has sales restriction data when an option is mounted for each mounting restriction code. Examples of the installation restriction code include a code indicating that the option is a maker option attached by the manufacturer, a code indicating that the option is a dealer option attached by the dealer, and a standard indicating that the option is standard equipment. The equipment code is stored. In addition, if the sale of the option is currently suspended, there is no constraint on the sale, and there is no installation form code. Immediately before the sale is started, the mounting mode is input and stored.

The standard product means that it is installed as standard equipment on the vehicle of that type, and that the price of the option is included in the price of the basic components. Conversely, if you don't need that option,
This means that another model should be selected. The maker option is an option attached by the maker, and it is necessary to determine whether it is necessary or unnecessary at the stage of ordering with the maker, and in principle, it cannot be changed later. The dealer option is an option that is installed at the dealer's factory after the vehicle is delivered from the manufacturer to the dealer, and can be changed until the installation work is performed by the dealer. It is also possible to perform additional installation work after purchase.

Since all data relating to the options required by the customer can be searched by merely referring to the database, it is easy to use and the required data can be quickly obtained. In other words, during a business negotiation with a dealer, the customer can instantly introduce the model of the car and the combination of options that can be mounted on the model to the customer on the screen. Customers can select the car model on the spot,
You can choose the option to attach to that model. In addition, when deleting one option, only by deleting the option class, the mounting mode is automatically deleted, so that the maintenance efficiency is improved.

Further, each option is given a price in accordance with each mounting restriction and mounting mode. According to this, it is possible to search all data relating to options required by customers, including prices, simply by referring to this database, so that it is easy to use and the necessary data can be obtained quickly. . In other words, during a business negotiation with a dealer, a model of a car and a combination of options that can be mounted on the model can be instantly introduced to a customer on a screen, and whether the option is standard equipment or not.
An option that allows customers to quickly select whether they are a dealer option or a maker option, and to instantly introduce the total price when each option is installed. You can choose. Also, when deleting one option, just delete the option class,
Since the price is also automatically deleted, maintenance efficiency is improved.

Design information is provided for each object such as an automobile as a basic component, mounting constraints indicating design or technical restrictions, options as accessory components, mounting modes indicating sales conditions, and prices. There are data writing timings such as acquisition, sales specification registration, and sales price registration. In addition, each object has a task of new installation, deletion, and change. However, there is only a change work for the price. Regarding the addition, deletion, and change of each object, it is stored whether or not the processing of addition or deletion is permitted at each data write timing. This is the exclusive control function. That is, the exclusive control function means that when performing new input processing, editing processing, or deletion processing on each of the data from the first input means of a specific department, any of the above processing is performed from the second input means of another department. Is performed, it means that the processing of the first input means is prohibited.

The product information database is handled by a plurality of departments such as a design department, a planning department, and a sales department of a maker. If a certain department is performing a process such as a change, the process is performed by another department. Is prohibited by the exclusive control function, a plurality of departments cannot change the product information database at the same time, and the current data can be accurately grasped. For example, when the sales specification registration process is performed and writing is performed in the database of the area of a certain design change number, the sales price registration process cannot write the database of the area of the same design change number. However, it is possible to read the database of the area of the same design change number by using the specification and the price.

The work restriction function means that when the installation restriction code data, which is the content of the sales specification registration, has not been input, the input of the price data, which is the content of the sales price registration, is prohibited. In addition, if the sales specification registration process, which is the preceding process, has not been completed due to constraints on the context of the business, the database of the area with the same design change number cannot be accessed in all other processes that follow. . Also,
If the writing of one design change number has been completed, a new design change number cannot be newly established. Since the product information database of the present invention has both the exclusive control function and the business control function, there is a possibility that an abnormality may occur in the product information database without imposing other restrictions on the access of each department to the database. Absent.

[0025]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A product 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 a basic configuration of a product information database according to the present invention, and FIG. 2 shows an instance diagram thereof. FIG. 1 shows a system for managing model codes of a plurality of vehicles managed by the product information database, options mounted on vehicles having the model codes, and a relationship between the model codes and the options.
The product information database has the product information data shown in FIG. 1 independently for each different design change number.

In the merchandise information data shown in FIG. 1, the automobile 11 and the option 13 as entities are each indicated by a rectangular frame. Also, car 11 and option 13
The mounting constraint 12 and the mounting mode 14 indicating the relationship with are also shown by square frames. Each frame is divided into two by a horizontal line, the set name of each frame is shown on the upper side, and the lower part on the lower side is an expression means (eg, code, name, number Etc.) are shown. here,
The mounting constraint 12 indicates a design or technical constraint when the option 13 is mounted on the automobile 11. In addition, in the mounting mode 14, the option 13 is
1 shows the conditions for sale when the camera is mounted on the camera.

A straight line 1 connecting the car 11 and the mounting constraint 12
5, a straight line 16 connecting the mounting constraint 12 and the option 13
Indicates the relationship between the car 11 and the option 13. The type of association is indicated by the symbol at the end of the straight line. The black circle shown in FIG. 1 is viewed from the side where the black circle is not written,
There are multiple sides with black circles, indicating that they are related. Specifically, it means "one vehicle has a plurality of mounting constraints", and "the mounting constraint has a plurality of vehicles". That is, it means that "one vehicle can be equipped with various combinations of options." In addition, it means "the mounting constraint has a plurality of options." And "one option has the plurality of mounting constraints."
That is, it means that "one option can be attached to a vehicle in various combinations."

A straight line 17 connecting the car 11 and the option 13 and a mounting form 14 indicated by a frame in the middle of the straight line 17 are:
The relation between the car 11 and the option 13 is shown. Here, the loop of the frame of the mounting mode 14 indicates that the mounting mode 14 is a link attribute to the straight line 17. Specifically, it indicates "restriction when selling options", that is, "whether option 13 is a standard product, a manufacturer option installed by a manufacturer, or a dealer option installed by a dealer". The straight line 15, the straight line 16, and the straight line 17 are realized by a computer using a technique called a pointer. That is, in the data representing each frame, the address value of the related frame on the data storage medium is included in the relation. More specifically, the model code data of the vehicle 11 has the address of the mounting constraint 12 that can be mounted on the vehicle 11. Further, the mounting constraint code data of the mounting constraint 12 includes the address of the option 13 that can be mounted on the automobile 11.

FIG. 2 shows the relationship between the data when the relationship shown in FIG. 1 is implemented on a computer and individual entity data is allocated. The relationship diagram applied to the entity in this way is called an instance diagram. Also in FIG. 2, the association is represented by a straight line, but on the computer, the association is realized by a pointer. The model K1 is an entity of an automobile which is a product having a model code, and indicates that the vehicle has Option 1, Option 2, and Option 3 each having an option code. Here, each of the options OP1, OP2, and OP3 is associated with another option. This association is a design or technical constraint, and is a mounting constraint 12. In FIG. 2, instances of the attachment restriction are indicated by Y1 to Y6.

In general, there are the following two types of constraint relations of options of a vehicle. The first type of constraint relationship is a one-way constraint relationship in which an option b can be attached only when an option a is attached. In this case, a is called a "child" and b is called a "parent".
For example, only with traction control,
It is possible to wear an ABS (anti-lock brake system), 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, in which option a and option b must be a set. For example, a radio and an antenna must always be a set. This is because the function is not achieved even if only one of them is attached.

Referring to FIG. 2, the meaning of the mounting restriction will be described. The attachment constraint Y1 indicates that the option 1 and the option 2 can be attached to the model 1 at the same time. O in the circle of the mounting constraint indicates a mounting possible state,
The crosses in the circles indicate that they cannot be worn for a predetermined period, that is, they are currently inactive. In addition, the car 11 and the option 13 which are not connected by the mounting restriction are:
Indicates that it cannot be attached. Also, the mounting constraint Y2
Indicates that the option 2 can be mounted alone on the model 1. Here, since there is no mounting constraint indicating that the option 1 can be mounted alone, it can be seen that the option 1 can be mounted only when the option 2 is mounted. That is, option 1 and option 2 have a one-way constraint relationship. If the mounting constraint Y2 does not exist, the option 1
And Option 2 have a bidirectional constraint relationship. In addition, the mounting constraint Y3 is, in principle, an option 1 for the model 1.
And Option 3 can be installed at the same time,
Indicates that it is currently suspended. Further, the mounting constraint Y4 indicates that the option 3 can be independently mounted on the model 1.

The mounting constraint 12 for the model 2 is as follows.
Y5 and Y6. The mounting constraint Y5 indicates that the option 2 can be mounted alone on the model 2.
The attachment constraint Y6 indicates that the option 3 can be independently attached to the model 2. In addition, since there is no mounting restriction between the type 2 and the option 1 for the option 1, it means that the option 1 cannot be mounted on the type 2. As described above, since the mounting constraint code data is provided between the plurality of model code data K1, K2 and the plurality of option code data OP1, OP2, OP3, the option data corresponds to one model. It is only necessary to store one for the same option, and as in Japanese Patent Application No. 8-114948, it is not necessary to separately provide the same option data for each model data when the constraint data is different. Economical and efficient without data. Also, when trying to delete a model or option,
Since only one type data or option data needs to be deleted, maintainability is improved.

Next, the mounting mode 14 will be described. Each of the options OP1, OP2, and OP3 is associated with another option. This association is a condition for sale and is indicated by the mounting form 14. In FIG.
4 are denoted by X1 to X6. The code P of the mounting mode 14 indicates that the option is a maker option that can be attached by the maker. S indicates that the option is standard equipment for the model. D indicates that the option is a dealer option attached by the dealer.

X1 corresponds to the mounting constraint Y1, and indicates that the simultaneous mounting of the option 1 and the option 2 indicated in the mounting constraint Y1 is a maker option. X2 corresponds to the mounting constraint Y2, and indicates that the mounting of the option 2 indicated by the mounting constraint Y2 is a manufacturer option. The reason why X3 does not exist is that the mounting constraint Y3 is currently suspended. X4 corresponds to the mounting constraint Y4, and the mounting of the option 3 indicated by the mounting constraint Y4 corresponds to the model 1
Indicates that it is a standard feature. Also,
X5 corresponds to the mounting constraint Y5, and indicates that the mounting of the option 2 indicated in the mounting constraint Y5 is a manufacturer option. X6 is the mounting constraint Y6
This indicates that the mounting of the option 3 indicated by the mounting constraint Y6 is a dealer option.

As described above in detail, according to the product information database of the present embodiment, option data that can be mounted on a car having a specific model code is stored between the model code data and the option data. Since it is provided as mounting restriction code data and mounting type code data is provided between model code data and option data, all data related to options required by customers can be searched simply by referring to this database Therefore, it is easy to use and required data can be obtained quickly. In other words, during a business negotiation with a dealer, the customer can instantly introduce the model of the car and the combination of options that can be mounted on the model to the customer on the screen. The customer can select the model of the car on the spot and select the option to attach to that model. Further, when one model or option is deleted, simply by deleting the model class or option class, the mounting mode 14 is automatically deleted, so that the maintenance efficiency is improved.

Next, a product information database according to a second embodiment of the invention will be described in detail with reference to the drawings. FIG. 3 is an object diagram showing a method of storing a selling price of an option when a vehicle as a product is sold by a combination of one basic component and a plurality of options. As in FIG. 1, the vehicle 11 and the option 13 as entities are each shown by a rectangular frame. In addition, the mounting constraints 12 and the mounting modes 14 indicating the relationship between the automobile 11 and the options 13 are also indicated by square frames. Here, the mounting constraint 12 indicates a design or technical constraint when the option 13 is mounted on the automobile 11. In addition, the mounting mode 14 is the option 1
3 shows sales conditions when the vehicle 3 is mounted on the automobile 11.

A straight line 1 connecting the car 11 and the mounting constraint 12
5, a straight line 16 connecting the mounting constraint 12 and the option 13
Indicates the relationship between the car 11 and the option 13. The type of association is indicated by the symbol at the end of the straight line. The meaning of the black circles is the same as in FIG. Here, FIG. 3 differs from FIG. 1 in that a frame of price 18 exists between the car 11 and the option 13. A price 18 exists for each installation constraint 12 that represents each combination of all options that can be installed in a model 1. As a result, the price when option 1 and option 2 are installed at the same time is stored irrespective of the price when option 1 is installed alone and the price when option 2 is installed alone. It can be set arbitrarily from the cost etc. That is, the price when option 1 and option 2 are installed at the same time is generally set lower than the total price when option 1 and option 2 are installed individually. This is because if they are installed at the same time, the construction will be common and the construction cost will be low.

Next, FIG. 4 shows the relationship between the data when the relationship of FIG. 3 is implemented on a computer and individual entity data is allocated. In FIG. 4 as well, the association is represented by a straight line, but on the computer, the association is realized by a pointer. Model K1 or Model K2
Is an entity of a basic component of a vehicle having a model code, and indicates that the vehicle has Option 1, Option 2, and Option 3 each having an option code.
Here, each of the options OP1, OP2, and OP3 is associated with another option. This association is a design or technical constraint, and is a mounting constraint 12. In FIG. 2, instances of the attachment restriction are indicated by Y1 to Y6. Each option OP1, OP2, OP3 is
Each is associated with a different option. This association is
This is a condition for sale, and is the mounting mode 14. In FIG.
Instances of the mounting mode 14 are indicated by X1 to X6. P indicates that the option is a manufacturer option that can be attached by the manufacturer. Also, S
Indicates that the option is standard equipment for that model. D indicates that the option is a dealer option attached by the dealer.

Next, the price 18 will be described. Price 1
8 is Z corresponding to each mounting constraint 12 and mounting mode 14.
1 to Z6. Z1 corresponds to the mounting constraint Y1 and the mounting mode X1, and indicates that the simultaneous mounting price of the option 1 and the option 2 indicated in the mounting constraint Y1 is 150 yen. Further, Z2 corresponds to the mounting constraint Y2 and the mounting mode X2, and indicates that the mounting price of the option 2 indicated in the mounting constraint Y2 is 50 yen. Also, Z3 does not exist because the mounting constraint Y3 is currently inactive. Z4 corresponds to the mounting constraint Y4 and the mounting mode X4. Since the mounting of the option 3 shown in the mounting constraint Y4 is standard equipment for the model 1, the price is included in the basic components. Therefore, the price as an option is 0 yen. Z5 corresponds to the mounting constraint Y5 and the mounting mode X5, and indicates that the mounting price of the option 2 indicated in the mounting constraint Y5 is 50 yen. Z6 corresponds to the mounting constraint Y6 and the mounting mode X6, and indicates that the mounting price of the option 3 indicated in the mounting constraint Y6 is 100 yen.

As described in detail above, according to the product information database of the second embodiment, the data of the option that can be mounted on a car with a specific model code is
The mounting constraint code data is provided between the model code data and the option data as the mounting constraint code data, and the mounting mode code data is provided between the model code data and the option data.
Since the price 18 is provided between the and the option 13 in correspondence with the mounting constraint 12 and the mounting mode 14, all data relating to the option required by the customer including the price can be obtained simply by referring to this database. Can be searched, so that it is easy to use and necessary data can be quickly obtained.

That is, in a business negotiation with a dealer, a model of a car and a combination of options that can be mounted on the model can be instantly introduced to a customer on a screen, and whether the option is a standard equipment, a dealer option, or a maker option The customer can select the model of the car on the spot because it can be introduced instantly and the total price when each option is installed can be instantly introduced.
You can choose the option to attach to that model. In addition, when one model or option is deleted, the price 18 is automatically deleted only by deleting the model class or option class, thereby improving the maintenance efficiency.

Next, the operation of the product information database will be described with reference to a functional model shown in FIG. After obtaining information for designing a product (S1), a sales specification on how to sell this product is registered (S2).
As a result, data of only the part storing the product specification information in the product information database is obtained (S3). This corresponds to the parts shown in FIGS. Here, the product specification information can be read, and the product specification information can be used for catalog creation or the like (S7). Next, sales price information, which is an option price, is registered (S4). This completes the writing of all data shown in FIGS. 3 and 4 (S5). Thereafter, business such as negotiations is performed using the product information database (S6).

FIG. 6 shows the steps of obtaining design information (S1), registering sales specifications (S2), and registering sales prices (S4) in FIG.
3, the vehicle 11 and the mounting constraint 1 which are the objects.
FIG. 9 is an operation diagram showing whether new, deletion, and change of an option 13, an installation mode 14, and a price 18 are possible. The vertical items in FIG. 6 are a car 11, a mounting constraint 12, an option 13,
An object having a mounting form 14 and a price 18 is shown. The horizontal items indicate data writing timings of obtaining design information (S2), registering sales specifications (S2), and registering sales prices (S4). The vertical items are divided into upper and lower tiers or upper, middle, and lower tiers. The upper tier indicates new installation, the second tier indicates deletion, and the third tier indicates change.
However, the price 18 is only changed. ○ in the table
× indicates whether or not the new or deleted process is permitted at the data write timing. ○ indicates that it is permitted, and X indicates that it is not permitted.

FIG. 7 is a diagram showing the operation of the exclusive control function and the work restriction function of the product information database. The vertical items in FIG. 7 indicate sales specification registration (S
2), sales specification use (S7), sales price registration (S4),
This shows a task of using product price information (S6). The next item is the sales specification registration (S
2), sales specification use (S7), sales price registration (S4),
This shows a task of using product price information (S6). Each item is divided into upper and lower rows, the upper row indicates an exclusive control function, and the lower row indicates a task restriction function. Here, the exclusive control function means that when a new input process, an edit process, or a delete process is performed on the data from the first input unit of a specific department, any of the processes is performed from the second input unit of another department. If this is done, it means that the processing of the first input means is prohibited. The business constraint function is
If the installation constraint code data, which is the content of sales specification registration, has not been input, this means that input of price data, which is content of sales price registration, is prohibited.

That is, when the sales specification registration process is performed and the data is written in the database of the area of a certain design change number, the sales price registration process cannot write the database of the area of the same design change number. However, it is possible to read the database of the area of the same design change number by using the specification and the price. In addition, if the sales specification registration process, which is the preceding process, has not been completed due to constraints on the context of the business, the database of the area with the same design change number cannot be accessed in all other processes that follow. . When the writing of one design change number has been completed, a new design change number cannot be newly set.

A case where the data of the product information database of the present invention is changed will be described with reference to an example. FIG.
Next, a case where one model is deleted will be described. FIG.
As shown in Fig. 5, when the operator deletes only the model B after obtaining the product information, if the operator deletes only the model B, the program stored in the product information database operates, and all the mounting restrictions and the mounting modes related to the model B are automatically set. delete. That is, as described in the column of the necessary functions at the time of design change in FIG. 8, 1) the set constraint for all the options of the deleted model B is deleted. Also, 2) the allocation for all options of the deleted model B is deleted. By deleting the set constraint and the allocation, the mounting constraint is deleted. 4) Delete the deleted model B vehicle price. 5) Delete option prices with provisions other than the deleted models B and S (standard equipment). These 1) to 5)
Work is performed automatically. Therefore, by simply deleting only one model, all the mounting restrictions and mounting modes related to that model are automatically deleted, so that maintenance of the database is facilitated.

The present invention is not limited to the above embodiment, and various changes can be made without departing from the gist of the present invention. For example, in this embodiment, a car and its options have been described, but it is obvious that the present invention can be applied to other products. Further, in the present embodiment, the case where the number of basic components is one has been described, but the same applies to a product composed of two or more basic components.

[0048]

According to the merchandise information database of the present invention, data of an accessory component that can be attached to a component having a specific model code is converted into one or more model code data and one or more model code data. Since the attachment constraint code data is provided between the accessory component code data and the accessory component code data, it is sufficient to store one accessory component code data for the same accessory component for one model. -1149
When the constraint data is different as in No. 48, it is not necessary to separately have the same accessory component code data for each model data, so that it is economical and efficient to have no extra data. Further, when a model or an accessory component is to be deleted, only one model data or option data needs to be deleted, so that the maintainability is improved.

[Brief description of the drawings]

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

FIG. 2 is an instance diagram of FIG. 1;

FIG. 3 is an object diagram showing a configuration of a product information database according to a second embodiment.

FIG. 4 is an instance diagram of FIG. 3;

FIG. 5 is a functional model diagram of a product information database.

FIG. 6 is a first operation diagram showing the operation of the product information database.

FIG. 7 is a second operation diagram showing the operation of the product information database.

FIG. 8 is an explanatory diagram of data change of a product information database.

FIG. 9 is an object diagram showing a configuration of a conventional product information database.

FIG. 10 is an instance diagram of FIG. 9;

[Explanation of symbols]

 11 Car class 12 Mounting restriction class 13 Option class 14 Mounting mode class 18 Price class

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Ayumi Yagi 1 Toyota Town, Toyota City, Aichi Prefecture Inside Toyota Motor Corporation

Claims (4)

[Claims] 1. A product information database comprising a product having a model code for each basic component and two or more accessory components attached to the basic component represented by a specific model code and having an accessory component code. In one or more of the above model code data and 1 or 2
A product information database comprising, between the accessory component code data and the accessory component code data, mounting constraint code data indicating design or technical constraints when the accessory component is mounted on the product. 2. The product information database according to claim 1, further comprising: mounting mode code data indicating a sales condition when the accessory component is mounted on the product, corresponding to the mounting constraint code data. Product information database characterized by the following. 3. The product information database according to claim 1, wherein the product information database has price data when the accessory is attached, corresponding to the attachment constraint code data. . 4. The product information database according to claim 1, wherein a new input process, an edit process, or a delete process is performed on each of the data from a first input unit. An exclusive control function for inhibiting the processing of the first input means when any of the processing is performed from the two input means, and inputting the price data when the mounting constraint code data has not been input. A product information database having a business restriction function to prohibit.