JP3521722B2 - Product information database system - Google Patents

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 which can reduce access time by reducing the data capacity, and also relates to a merchandise information database which stores combination price data of a plurality of options.

[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 design or technical constraint relationships between the options. That is, there may be special design or technical 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,
Only when the option a is attached, the option b can be attached. In this case, a is called a "child" and b is called a "parent". For example, ABS (anti-lock brake system) can be installed only when the traction control is attached, and in this case, the traction control is the "child", and A
BS 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. However, the conventional relational database has the following problems. (1) Since the data capacity is extremely large, there is a problem that the response of the search is significantly reduced. In particular, accurate determination of whether the constraint relationship is one-way or two-way is not possible without reading all the data, which causes a long response time and is a problem. (2) Since redundant data and unnecessary data having no relation are stored, extra data capacity is taken. (3) In addition, when a part of the options is changed, for example, when a certain option is abolished, it is necessary to delete all the items including the option while searching the database. There was a problem that maintenance took time and cost.

In order to solve the above-mentioned problems of the relational database, the applicant of the present invention filed Japanese Patent Application No. 8-11494.
In No. 8, we proposed a product specification price information storage device that builds a database using an object model. The class object is shown in FIG. A 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 attached to the basic component represented by a specific model code product. ,
(A) For each model code, the attribute data 103 of the accessory component that can be attached to the basic component represented by the model code is provided between the model code data 101 and the accessory component data 102, and (b) The accessory component data 102 has constraint relationship data 104 with other accessory components and the existence position data 104 of the other accessory component data having a constraint relationship.

FIG. 10 shows the relationship between data when the relationship shown in FIG. 9 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. 10 as well, the relation is shown by a straight line, but on the computer, the relation is realized by the pointer. Model K1, K2
Each of K3 and K4 is an entity of an automobile, which is a product having a model code, and has a relationship of having a plurality of options each having an option code. In addition, each option OP11, OP12, OP21, OP22, O
P31 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. 10, for example, option OP21.
The option OP11 having a bidirectional constraint relationship with the option OP12 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.

[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 individually assign the same option data to each model data for options having different constraint data. That is, in FIG. 10, even if the same option 1 is selected, the option 1 for the model 1 is OP
Option 11 for model 3 is set as OP
I needed to have it as 12. Therefore, there is a problem that extra data has to be stored and it takes extra time to search for the data. Further, when deleting one option, it is necessary to delete a plurality of option data, and the maintainability is poor.

(2) When selling an automobile, the option may be standard equipment or attached by order depending on the model. Further, even in the case of mounting by order, the manufacturer option installed at the manufacturer stage and the dealer option installed at the 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 another database, so it was a database with poor usability. In other words, when a customer wants to buy a car, what kind of option can be installed on a certain type of car and at the same time whether the option is a manufacturer option or a dealer option is an important issue. is there. The reason is that there is a difference in the lead time until the automobile reaches the customer due to the difference in the mounting form. Also, the dealer option can be installed even after purchasing the vehicle, but the manufacturer option is too late unless selected at the time of ordering. In the conventional device, since the mounting form, which is a condition for sale, is managed as a separate database, it is necessary to refer to it separately, resulting in unnecessary work and extra time.

(3) The product information database is handled by a plurality of departments such as the design department, the planning department and the sales department of the manufacturer, and the contents can be changed in each department. However, if multiple departments try to change the product information database at the same time, it becomes difficult to grasp the current data, which causes confusion. In addition, if a price is entered for the option in the sales department before a new option mounting condition is added, there is no object to store the price, which causes data to be confused.

It is an object of the present invention to solve the above-mentioned problems, and to provide a product information database in which the data capacity is reduced and the search speed is fast, and a product information database whose options can be easily changed.

[0012]

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

(2) In the product information database described in (1), corresponding to the mounting constraint code data,
It is characterized in that it has mounting form code data indicating sales conditions when the accessory component is mounted on the product. (3) In the product information database described in (1) or (2), corresponding to the mounting constraint code data,
It is characterized by having price data when the accessory is attached.

(4) In any one of the product information databases described in (1) to (3), when a new input process, an edit process, or a delete process is performed on the respective data from the first input means, When any one of the processes is performed from the second input means, an exclusive control function of prohibiting the process of the first input means and the input of the price data when the mounting constraint code data is not input. It is characterized by having a business constraint function of prohibiting the.

The merchandise information database of the present invention, having the above-mentioned configuration, operates as follows. products are,
It is stored as two or more model code data with 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, the options that can be installed in a vehicle of a specific model code are defined. Between the model code data and the option code data, attribute data indicating which option can be mounted on a vehicle having a specific model code is stored. That is, it has mounting constraint code data indicating a constraint condition in terms of design or technology between the model code data and the option code data.

The mounting restriction code data has, as data, all combinations of options that can be mounted in a specific model. For example, when the option 1 and the option 2 are bidirectional constraints in the model 1, the option 1 and the option 2 can be simultaneously mounted in the mounting constraint code Y1 between the model 1 and the options 1 and 2 There is no mounting constraint code indicating that the option 1 can be individually mounted and a mounting code indicating that the option 2 can be individually mounted. In addition, when Option 1 and Option 2 are one-way constraints on Model 1, Option 1 and Option 2 can be simultaneously installed on the installation constraint code Y1 between Model 1 and Option 1 / Option 2. There is no mounting code indicating that the option 1 can be mounted independently, and a mounting restriction code indicating that the option 1 can be mounted individually, and a mounting code that indicates that the option 2 can be mounted independently.
In this case, it is found that the option 2 can be installed only when the option 1 is installed, and the option 1 and the option 2 have 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, it is sufficient to always store one option data, as in Japanese Patent Application No. 8-114948. In addition, it is not necessary to have the same option data individually for each type data for options with different constraint data. Further, when deleting a certain option, only one option data needs to be deleted, which improves the maintainability.

The mounting mode code has, for each mounting constraint code, sales constraint data when an option is mounted. As the mounting restriction code, for example, a code indicating that the option is a manufacturer option installed by the manufacturer, a code indicating that the option is a dealer option installed by the dealer, and a standard indicating that the option is standard equipment The equipment code is stored. Further, when the sale of the option is currently suspended, there is no constraint condition on the sale, so there is no mounting mode code. Immediately before the sales start, the wearing form is input and stored.

The standard product means that it is installed as standard equipment in the vehicle of that model, and that the price of the option is included in the price of the basic component. Conversely, if you don't need that option,
This means that another type should be selected. The manufacturer option is an option that is installed by the manufacturer, and it is necessary to decide whether it is necessary or not at the stage of ordering to the manufacturer, and in principle it cannot be changed later. The dealer option is an option that can be installed at the dealer's factory after the vehicle is delivered from the manufacturer to the dealer, and can be changed until the dealer carries out installation work. It is also possible to add and install after purchasing.

Since it is possible to retrieve all the data relating to the options required by the customer simply by referring to this database, it is convenient and the necessary data can be obtained quickly. In other words, at a dealership negotiation, you can instantly introduce to the customer the model of the car and the combination of options that can be installed on that model on the screen, and whether the option is standard equipment, dealer option, or manufacturer option The customer can select the car model on the spot,
You can choose the option to install for that model. Further, when one option is deleted, only the option class is deleted, and the mounting form is automatically deleted. Therefore, maintenance efficiency is improved.

Further, each option has a price corresponding to each mounting constraint and mounting form. According to this, it is possible to retrieve all the data related to the options that the customer needs, including the price, just by referring to this database, so that it is easy to use and the necessary data can be quickly obtained. . In other words, at a business meeting at a dealer, you can instantly introduce to the customer the model of the car and the combination of options that can be installed on that model on the screen, and whether the option is standard equipment.
It is possible to instantly introduce whether it is a dealer option or a manufacturer option and the total price when each option is installed, so the customer can select the model of the car on the spot and install it in that model. You can choose. Also, if you want to delete one option, just delete the option class,
Prices are also automatically deleted, improving maintenance efficiency.

Design information for each object, that is, a vehicle as a basic component, a mounting constraint indicating a constraint condition on design or technology, an option as an accessory component, a mounting form indicating a condition on sale, and a price. There are data writing timings such as acquisition, sales specification registration, and sales price registration. Further, each object has a work of new installation, deletion, and modification. However, there is only a change in price. Regarding the new installation, deletion, and change of each object, it is stored whether or not the new installation or deletion processing is permitted at each data writing timing. This is the exclusive control function. That is, the exclusive control function means, when performing a new input process, an edit process, or a delete process on the respective data from the first input means of a specific department, any one of the processes from the second input means of another department. If the above is performed, it means that the processing of the first input means is prohibited.

This 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. However, if a certain department is performing processing such as modification, it is processed by another department. Since it is prohibited by the exclusive control function, it is not possible to simultaneously change the product information database in a plurality of departments, and it is possible to accurately grasp the current data. For example, when the sales specification registration process is performed and the database of the area of a certain design change number is written, the database of the area of the same design change number cannot be written by the sales price registration process. However, the database of the area of the same design change number can be read by the process of using the specification and the process of using the price.

The work restriction function means prohibiting the input of price data, which is the content of sales price registration, when the mounting restriction code data, which is the sales specification registration content, has not been input. Also, if the sales specification registration process, which is the work of the previous process, has not been completed due to the context of the work, the database of the area with the same design change number cannot be accessed in all other processes that are the subsequent process. . Also,
When the writing of one design change number is completed, it is not possible to newly set a different design change number. 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 will occur in the product information database without giving other restrictions to the access of each department to the database. Absent.

[0025]

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 a basic configuration of the product information database according to the present invention in an object diagram, and FIG. 2 shows an instance diagram thereof. FIG. 1 shows a model code of a plurality of vehicles managed by the product information database, an option mounted on a vehicle having the model code, and a system for managing the relationship between the model code and the option.
This product information database has the product information data shown in FIG. 1 independently for each different design change number.

In the product information data shown in FIG. 1, the automobile 11 as an entity and the option 13 are each shown by a rectangular frame. Also, car 11 and option 13
The mounting constraint 12 and the mounting form 14, which show the relationship with, are also indicated by square frames. Each frame is divided into two parts by a horizontal line, the set name of each frame is shown on the upper side, and the expression means (eg, code, name, number) for specifically expressing the contents of each frame on the lower side. Etc.) are shown. here,
The mounting constraint 12 indicates a design or technical constraint condition when the option 13 is mounted on the automobile 11. In addition, the mounting form 14 uses the option 13 for the automobile 1
It shows the conditions for sale when it is mounted on the No. 1 unit.

A straight line 1 connecting the automobile 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 automobile 11 and the option 13. The type of association is indicated by the symbol at the end of the line. The black circles shown in Fig. 1 are
There are multiple sides with black circles, indicating that they are related. Specifically, it means that "one car has a plurality of mounting restrictions." And "a mounting restriction has a plurality of cars." That is, it means that various combinations of options can be installed in one vehicle. It also means "the mounting constraint has a plurality of options" and "one option has a plurality of mounting constraints."
That is, "one option is installed in the vehicle in various combinations."

A straight line 17 connecting the automobile 11 and the option 13 and a mounting form 14 indicated by a frame in the middle of the straight line 17 are:
The relationship between the automobile 11 and the option 13 is shown. Here, the loop of the frame of the mounting form 14 indicates that the mounting form 14 has a link attribute with respect to the straight line 17. Specifically, it shows "restrictions 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". Such a straight line 15, a straight line 16 and a straight line 17 are realized by a technique called a pointer in a computer. That is, the address value on the data storage medium of another related frame is included in the relationship in the data expressing each frame. Specifically, it means that the model code data of the automobile 11 has an address of the mounting constraint 12 that can be mounted on the automobile 11. In addition, the installation restriction code data of the installation restriction 12 has the address of the option 13 that can be installed in the automobile 11.

FIG. 2 shows the relationship between the respective data when the relationship of 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. The model K1 is an entity of an automobile, which is a product having a model code, and has Option 1, Option 2, and Option 3 each having an option code. Here, each of the options OP1, OP2, OP3 is associated with another option. This relation is a constraint condition on design or technology, and is the mounting constraint 12. In FIG. 2, instances of the mounting constraint are indicated by Y1 to Y6.

In general, there are the following two types of constraint relationships for automobile options. The first type of constraint relationship is a one-way constraint relationship, in which option b can be attached only when 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 install 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, and option a and option b are relationships that must always be a set. 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.

The meaning of the mounting restriction will be described with reference to FIG. The mounting constraint Y1 indicates that the option 1 and the option 2 can be mounted on the model 1 at the same time. The O in the circle of the mounting constraint indicates the mountable state,
The cross mark in the circle indicates that the device cannot be worn for a predetermined period of time, that is, it is currently idle. In addition, the vehicle 11 and the option 13 which are not connected by the mounting restriction are
It indicates that it cannot be installed. Also, the mounting constraint Y2
Indicates that the option 2 can be separately attached to the model 1. Here, since there is no mounting constraint indicating that the option 1 can be mounted individually, 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 also does not exist, option 1
And option 2 have a bidirectional constraint relationship. As a general rule, the mounting constraint Y3 is Option 1 for Model 1.
And option 3 can be installed at the same time,
It indicates that it is currently suspended. Further, the mounting constraint Y4 indicates that the option 3 can be separately mounted to the model 1.

The mounting constraint 12 for the model 2 is
Y5 and Y6. The mounting constraint Y5 indicates that the option 2 can be mounted independently for the model 2.
Further, the mounting constraint Y6 indicates that the option 3 can be mounted independently for the model 2. Further, with respect to the option 1, since there is no mounting restriction between the model 2 and the option 1, it means that the option 1 cannot be mounted in the model 2. As described above, since the mounting constraint code data is provided between the plurality of model code data K1 and K2 and the plurality of option code data OP1, OP2 and 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 have the same option data separately for each model data when the constraint data is different, so there is no extra No data required Economical and efficient. Also, when trying to delete a model or option,
Maintenance is improved because only one model data or option data needs to be deleted.

Next, the mounting form 14 will be described. Each of the options OP1, OP2, OP3 is associated with another option. This relation is a condition on sale and is shown in the mounting form 14. In FIG. 2, the wearing form 1
The four instances are indicated by X1 to X6. The code P of the mounting form 14 indicates that the option is a manufacturer option that is installed by the manufacturer. Further, S indicates that the option is standard equipment for the model. Further, D indicates that the option is a dealer option installed by the dealer.

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

As described in detail above, according to the product information database of the present embodiment, the option data that can be mounted on the vehicle with a specific model code is stored between the model code data and the option data. Since it is provided as the mounting constraint code data and the mounting mode code data is provided between the model code data and the option data, all the data related to the options required by the customer can be searched just by referring to this database. Therefore, it is easy to use, and necessary data can be quickly obtained. In other words, at a dealership negotiation, you can instantly introduce to the customer the model of the car and the combination of options that can be installed on that model on the screen, and whether the option is standard equipment, dealer option, or manufacturer option The customer can select the model of the car on the spot and choose the option to install the model. In addition, when one model or option is deleted, the mounting form 14 is automatically deleted only by deleting the model class or option class, so that 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 the selling price of an option when an automobile, which is a product, is sold by combining one basic component and a plurality of options. Similar to FIG. 1, the automobile 11 as an entity and the option 13 are each shown by a rectangular frame. In addition, the mounting constraint 12 and the mounting form 14 showing the relationship between the automobile 11 and the option 13 are also shown by square frames. Here, the mounting constraint 12 indicates a design or technical constraint condition when the option 13 is mounted on the automobile 11. In addition, the mounting form 14 is the option 1
3 shows conditions for sale when the No. 3 is mounted on the automobile 11.

A straight line 1 connecting the automobile 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 automobile 11 and the option 13. The type of association is indicated by the symbol at the end of the line. The meaning of the black circles is the same as in FIG. Here, FIG. 3 is different from FIG. 1 in that there is a frame of price 18 between the automobile 11 and the option 13. The price 18 exists for each mounting constraint 12, which represents each combination of all options that can be mounted in the model 1. As a result, the price when installing option 1 and option 2 at the same time is stored regardless of the price when installing option 1 alone or the price when installing option 2 alone, so that the unique work It can be set arbitrarily according to the cost. That is, the price when the option 1 and the option 2 are installed at the same time is generally set to be lower than the total price when the option 1 and the option 2 are installed separately. This is because if they are installed at the same time, the construction work will be common and the construction cost will be low.

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

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

As described in detail above, according to the product information database of the second embodiment, the option data that can be mounted on the automobile with a specific model code is
The mounting restriction code data is provided between the model code data and the option data, and the mounting restriction code data is also provided with the mounting form code data between the model code data and the option data.
Since the price 18 is provided between the option 13 and the option 13 in correspondence with the mounting constraint 12 and the mounting mode 14, all the data regarding the option required by the customer including the price can be obtained only by referring to this database. Since it is possible to search, it is easy to use, and necessary data can be quickly obtained.

That is, at the time of negotiations at a dealer, the customer can instantly introduce the model of the automobile and the combination of options that can be mounted to the model on the screen, and whether the option is standard equipment, dealer option, or manufacturer option. In particular, since it is possible to introduce instantly and the total price when each option is installed, the customer can select the model of the car on the spot,
You can choose the option to install for that model. Further, when one model or option is deleted, the price 18 is automatically deleted only by deleting the model class or option class, so that maintenance efficiency is improved.

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

FIG. 6 shows the design information acquisition (S1), sales specification registration (S2), and sales price registration (S4) of FIG.
Car 11 which is each object in FIG. 3, mounting constraint 1
FIG. 2 is an operation diagram showing whether or not new installation, deletion, and change of 2, option 13, mounting form 14, and price 18 are possible. The vertical items in FIG. 6 are an automobile 11, a mounting constraint 12, an option 13,
An object of mounting form 14 and price 18 is shown. The horizontal items indicate data writing timings such as design information acquisition (S2), sales specification registration (S2), and sales price registration (S4). The vertical items are divided into upper and lower stages or upper, middle, and lower stages, respectively. The upper stage indicates new construction, the second stage indicates deletion, and the third stage indicates change.
However, the price 18 is only changed. ○ in the table
The symbol X indicates whether or not the new or deletion process is permitted at the data write timing. A circle indicates that it is permitted, and a cross indicates that it is not permitted.

FIG. 7 is a diagram showing the operations of the exclusive control function and the work restriction function of the product information database. The vertical items in FIG. 7 are sales specifications registration (S
2), sales specification use (S7), sales price registration (S4),
This figure shows a task of using product price information (S6). Also, the items on the side are items for registering sales specifications in other departments (S
2), sales specification use (S7), sales price registration (S4),
This figure shows a task of using product price information (S6). Each item is divided into upper and lower stages, the upper stage shows the exclusive control function, and the lower stage shows the work restriction function. Here, the exclusive control function means any one of the above processes from the second input means of another department when a new input process, an edit process, or a delete process is performed on the respective data from the first input device of a specific department. When the bending is performed, it means that the processing of the first input means is prohibited. What is the business constraint function?
This means prohibiting the input of price data, which is the content of sales price registration, when the mounting constraint code data, which is the sales specification registration content, has not been input.

That is, when the sales specification registration process is performed and the database of the area of a certain design change number is written, the database of the area of the same design change number cannot be written in the sales price registration process. However, the database of the area of the same design change number can be read by the process of using the specification and the process of using the price. Also, if the sales specification registration process, which is the work of the previous process, has not been completed due to the context of the work, the database of the area with the same design change number cannot be accessed in all other processes that are the subsequent process. . Further, when the writing of one design change number is completed, it is not possible to newly set a different design change number.

A case where the data of the product information database of the present invention is changed will be described with an example. Figure 8
The case of deleting one model will be described. Figure 8
As shown in, when deleting 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 mounting forms related to the model B are automatically delete. That is, as described in the column of the accessory required function at the time of design change in FIG. 8, 1) Delete the set constraints for all the options of the deleted type B. 2) Delete the allocations for all the deleted type B options. The mounting constraint is deleted by deleting the set constraint and the allocation. Also, 4) delete the deleted type B vehicle price. 5) Delete option prices with reserves other than the deleted models B and S (standard equipment). These 1) -5)
The work of is done automatically. Therefore, by deleting only one model, all the mounting restrictions and mounting forms relating to that model are automatically deleted, which facilitates maintenance of the database.

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.

[0048]

According to the product information database of the present invention, the data of the accessory components that can be attached to the component with a specific model code is stored as 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 one model and the same accessory component. -1149
When the constraint data is different as in No. 48, it is not necessary to separately provide the same accessory component code data for each model data, so that it is not necessary to have extra data, which is economical and efficient. In addition, when trying to delete a certain model or accessory component, it is only necessary to delete one model data or option data, thus improving the maintainability.

[Brief description of 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.

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.

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 the product information database.

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

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

[Explanation of symbols]

11 car class 12 Mounting constraint class 13 Option Class 14 Wearing form class 18 price classes

Front page continuation (72) Inventor Ayumi Yagi 1 Toyota Town, Toyota City, Aichi Prefecture Toyota Motor Corporation (56) References JP-A-5-274326 (JP, A) JP-A-9-292983 (JP , A) JP-A-9-305453 (JP, A) JP 2001-519938 (JP, A) (58) Fields investigated (Int.Cl. ⁷ , DB name) G06F 17/60 G06F 12/00 G06F 17 / 30

Claims (5)

(57) [Claims] 1. A basic structure that is an instance of a type class.
Multiple model code data attached to the product, and the basic component that is an instance of the option class
Multiple optional accessories attached to the accessory components attached to the
Data and the basic component that is an instance of the mounting constraint class
Design or technical control when installing the accessory components
A combination of a model and an option that includes the mounting constraint code data indicating the condition and satisfies the constraint condition.
When all the items are listed, they correspond to each of the combinations.
The above-mentioned mounting constraint code data that exists
Type corresponding to the model included in the combination
Expression code data and options included in the combination
Associated with each option code data corresponding to
The data to be attached is the relevant model code data and the relevant option.
Code data and the mounting constraint code data
The model and options that do not meet the above constraints.
The mounting constraint code data corresponding to the combination does not exist.
Is configured to determine whether a particular combination satisfies the constraint conditions.
Determine the presence or absence of mounting constraint code data corresponding to the combination
A product information database system that is characterized by doing things . 2. The product information database system according to claim 1, wherein the mounting constraint code data is a specific model code data and a first option code data.
The first data to be associated with the
Data that associates the data with the second option code data
And the specific option code data are included in the second option code.
With third data that is associated only with
However, a combination of models and options that satisfy the above constraints
When all the conditions are listed, the constraint condition is the second option.
Basic configuration of accessory components with option code data
Only when attached to the product, the first option code
Attach the accessory components with data to the basic components
If there is a one-way constraint that allows
And, the constraint, with the first option code data
The attached accessory parts and the second option code data
Be sure to attach the attached accessory components to the basic components.
If it is a bidirectional constraint that does not hold, the third data exists
If the third data is not present, the constraint is determined by determining the presence or absence of the third data.
Determine whether the condition is the one-way constraint condition or the two-way constraint condition.
Product information database system, characterized in that the constant
Mu. 3. The product information database system according to claim 1 or 2, wherein the product that is an instance of a mounting mode class is attached to the product.
Mounting form that indicates the conditions for sale when mounting a metal component
Correspond the code data to the mounting restriction code data
Combination of types and options that include the above-mentioned constraints
When all the items are listed, they correspond to each of the combinations.
There is the above-mentioned mounting form code data, and the model and option
The mounting form code data corresponding to the combination does not exist.
Is configured to determine whether a particular combination satisfies the sales conditions,
Performed by determining the presence / absence of mounting form code data
Product information database system, characterized in that. 4. The product information database system according to claim 1 , wherein the accessory, which is an instance of a price class, is mounted.
If the price data of the case corresponds to the mounting constraint code data
Combination of types and options that include the above and satisfy the above constraint conditions
When all the items are listed, they correspond to each of the combinations.
Of the model and options that do not meet the above constraint conditions
Make sure that the price data corresponding to the combination does not exist.
The price of a specific combination is determined based on the price data
Product information database system according to claim Rukoto. 5. In any one of the product information database system according to claim 1 to claim 4, instrumentation deposition constraint code data, stowed configuration code data, the new input process of price data, editing processing, regarding the removal process has a first input means and second input means for inputting information, first the new input process from the input unit to the data editing process,
Or when performing the removal process, it is determined whether any of the processing from the second input means is being performed, the second
When it is determined that any of the input means associated processing is being performed, the exclusive control means for prohibiting the processing of the first input means, price data from said first input means or the second input means When inputting, it is determined whether or not the mounting constraint code data is input, and when it is determined that the mounting constraint code data is not input, the price is input from the first input unit or the second input unit. A product information database system, comprising: a work restriction unit that prohibits data input.