NL1014288C2 - Computerized system for selecting and buying number of objects via electronic network, e.g. Internet, is flexible and easy to program - Google Patents

Abstract

The program operates in two phases. In the first phase, the user examines the product data and description (1, 2) and selects a product code. In the second phase, data about the number required, price and availability are added to the results held in the memory (6, 7). All the data is assembled (13) and output as a result (3).

Description

Title: Data transformation The invention relates to a method according to the preamble of claim 1.

Such methods are known in practice and are used to compile a target database from different source databases, for example to merge the files of sales, production and administration within a company into a single file for a management information system, or for example for data warehousing. .

It uses a data transformation program specially written to transform the respective source data into target data. This transformation program is run regularly, for example daily or weekly, in order to refresh and update the target data.

2 0 The known data transformation programs have the drawback that for a particular application a specially tailored program has to be written each time. In addition, the writing of the program takes place entirely by means of free programming or by means of rule-based programming in combination with free programming. The disadvantage of free programming is that it is time-consuming and the time required for writing the program is very difficult to predict. Rule-based programming has the disadvantage that it can only perform a few, 30 trivial transformations. In addition, such programs are not flexible and drastic adjustments have to be made in the event of changes, such as the addition of other types of source data and changed desired target data.

The object of the invention is a method of generating a computer program for performing a data transformation. to provide a transformation program in a systematic and predictable manner, whereby free programming can be completely or at least largely omitted.

To this end, the invention provides a method according to claim 1.

According to the invention, the data from the source data structure is brought into a form separate from the source data structure by means of a merging view. In this form, the source data can be further processed in a standard manner. The entities thus obtained are logically combined, grouped and provided with a unique group designation by means of a merging operation. A memory structure can be drawn up on the basis of this grouped data. The desired target data structure can then be compiled on the basis of the memory structure and the source data projected by means of the merging view. In addition to aggregation views, the field values and relationships between data from the source data structures are also transformed by means of field value views and relationship views, respectively, and are processed in the target data structure in the above manner.

Therefore, the data transformation according to the invention is a process consisting of the steps of projection of the source data, and the execution of standard execution rules. Drawing up the transformation rules for use in the projection phase is a highly structured and therefore predictable process, for which the required time and effort can be accurately estimated. After determining the transformation rules, it is also possible to estimate how fast the transformation process will proceed. In principle, the transformation rules need only be determined once for a given source structure and target structure. In the event of changes in the source and / or target entities, adjustments can be made quickly and easily by adjusting the projection phase rules 35 accordingly.

1Dl42êê 3

The invention also provides a computer program which is arranged for carrying out the method according to the invention.

The invention will be further elucidated on the basis of a detailed description of an exemplary embodiment of the invention with reference to Fig. 1. This shows a diagram of a transformation process according to the invention.

In an exemplary embodiment according to the invention, two source data structures are present within a company. The first source data structure contains data about the range of products supplied by the company and is managed, for example, by the purchasing department. The second source data structure contains data on the sales transactions carried out by the company, for example from the computer system that controls the cash registers.

In this exemplary embodiment, a data structure is understood to mean a collection of entities of one or more types, each comprising one or more attributes, the attributes being provided with attribute values. Such structures are known from practice, for example in the field of relational databases. The physical form in which the source data is available can take place in any desired manner, for instance within one or more computers or a network, on one or more hard disks at one or more physical locations; the invention is not limited to any particular physical implementation of the data.

30 To gain insight into the company's sales data, data from both source data structures must be combined into a target data structure. This target data structure can be used, for example, by means of a management information system to obtain information about the sales performance of the company.

. i30l4il§ 4

To this end, it is first determined which data from the sources must be included in the target data structure, in order to obtain the desired information in the target data structure.

According to the invention, the composition of the first source data structure, in this case the product data structure, is analyzed for this purpose, taking into account the source data present and how this data is stored. In particular, it is important here in which structure, for example entity types and attributes, the data are available.

Likewise, the composition of the second source data structure, in this case the sales-transaction data structure, is also analyzed.

15 The product data structure is made up of entities of the entity type PRODUCT described in table 1 below, which has two attributes, namely PRODUCT_CODE and PRODUCT DESCRIPTION. PRODUCT_CODE represents an encoding of a product that is present in the company. PRODUCT DESCRIPTION provides a description of the product in words and punctuation marks.

Table 1. Entity type of product data structure (source data structure 1) _Entity type__Attributes_ _PRODUCT___PRODUCT CODE_

___PRODUCT DESCRIPTION

25

The sales transaction data structure (source data structure 2) is composed of entities of the entity type SALES TRANSACTION described in Table 2 below, which includes five attributes, namely PRODUCT_COE) E, NUMBER_SOLD, SALES_DATE, SALES_TIME and SALES AMOUNT. PRODUCT_C ° DE represents an encoding of a product that is present in the company, incidentally, this code does not * 014288 5 necessarily correspond to the PRODUCT-type code. The attributes COUNT_SOLD, SALES_DATE, SALES_TIME, and SALES_Amount each describe a variable corresponding to the respective designation.

5

Table 2. Entity-type of sales transaction data structure (source data structure 2) -_Enity type__Attributes_ _ SALES TRANSACTION_PRODUCT CODE_ __NUMBER OF SOLD_ __SALES DATE_ __SALES TIME_ '_ SALES AMOUNT_ 10 In this implementation example, the type of target data is built up from the entity data in Table 3 to provide the desired data to the information system.

15 Table 3. Entity types of target data structure

Entity type: Attributes

PRODUCT PRODUCT KEY

__PRODUCT CODE_ __PRODUCT DESCRIPTION _ __NUMBER SOLD_

REVENUE

TRANSACTION PRODUCT KEY

NUMBER OF SOLD SALE DATE

SELL ~ AMOUNT ~~

The target data structure has two entity types, PRODUCT and TRANSACTION. The attributes of the enti-20 text types PRODUCT and TRANSACTION (namely NUMBER_SOLD, SALESDATE, PRODUCT_CODE, PRODUCT DESCRIPTION, and SALES_Amount) are the same as the attributes from the source data structures. The attribute TURNOVER is determined during the transformation from attributes from i * d, -

i; : i ’·, ·. ; Q

J ^ 3 “f · L ö Q

6 source data structure, in this case from the attribute COUNT_SOLD and SALES_Amount. The PRODUCT_KEY attribute is determined during the transformation, taking into account possible values previously assigned (during a possible previous execution of the transformation process).

From the foregoing, the structure of both source data structures and the desired target data structure is known. The required transformation rules can be determined from this. For the data transformation according to the invention, the following requirements have been set up in order to obtain the desired target data from the source data in this exemplary embodiment: - In the data transformation, generated identifications in the PRODUCT_Key attribute must remain persistent. Due to this requirement, once assigned identifications remain the same on successive transformation-derived target structures. This makes it possible to compare certain target structures with each other at different times.

- Products with different PR0DUCT_C0DE, but with corresponding PRODUCT DESCRIPTION should be merged, with the result written in capital letters without punctuation marks. For this purpose a function "unifyT ^ schr ()", which is not further elaborated, is used. This requirement ensures that products that are logically identical but have different coding appear in the target structure under the same designation.

- In the aforementioned combination of products, no transaction data should be lost.

- The attributes NUMBER_SOLD and SALES are calculated from the relevant data of TRANSACTION.

- Fictitious PRODUCT attributes must be created for each unique PR0DUCT_C0DE in SALES_TRANSACTION

35 that does not appear in PRODUCT. This addition of missing attributes ensures that the determined data 1014288 7 are uniform, so that they can easily be processed in a standard manner within the transformation process.

- SALES_TRANSACTIONS must be added per PRODUCT_CODE per SALES_DATE.

5 - In the case of aggregations, priority must be given to the PRODUCT_CODEs and PRODUCT DESCRIPTION and the product data structure. In case of several alternatives within the product data structure, the lowest value should be chosen. This provides an unambiguous determination in a simple manner.

These requirements assume that the PRODUCT_C ° DE is unique in the product data structure.

The above requirements are described according to the invention in transformation rules, of which three types exist, namely aggregation, field value and relationship. The operations required for the data transformation can be described according to the invention in these three types of transformation rules.

In this exemplary embodiment, the transformation rows are elaborated in Structured Query Language (SQL). SQL is a common language for performing operations on relational databases. The invention is not limited to implementation in this language; the invention may also be embodied in another computer language suitable for manipulating data structures.

In this example, the transformation rules are implemented as so-called views. A view contains one or more selection criteria or instructions to form a subset of data that meets the selection criteria from a collection of data. In addition, instructions may also be included to edit or add data to the selected data. In the context of this exemplary embodiment, the application of a view to a source entity set, such as a source data structure, yields a set of entities.

1014288 8

In this example, the desired target structure has two entity types. According to the invention, two aggregation views corresponding to the respective target entity types are determined for this purpose. The merge views are arranged in such a way that application of the merge views to the source structures, the information required for the relevant target entity is obtained from the source structures and is brought into a generic format.

Application of a merging view according to the invention to one or more source data structures yields an entity set of an entity type with at least the following attributes: - SID (System IDentification): a unique identification of the source data structure, in this example 1 or 15 2.

- DID (Data IDentification): a unique identification of entity within a source data structure.

Combined, SID and DID uniquely identify a particular entity.

20 - type: designation of the combination criterion, for example in the form of a name.

val: value from the source associated with the aggregation criterion, such as, for example, a certain attribute from the source data, or the result of an operation performed on one or more attributes of the source data.

The attributes typ and fall occur in combination; according to the invention, multiple combinations of attributes type and trap can occur per merge view.

With merge views according to the invention, the following functions can be performed, among others: - persistence of identification of target data in the target data structures, whereby an entity determined by the merge view that was already determined in a previous transformation process is provided with Equal identification, and 10 14288 9 - Entity-level deduplication facilities, which allow redundant entities to be removed from source data structures.

For the aforementioned data transformation according to the exemplary embodiment, the following two examples of aggregation views according to the invention have been prepared incorporating part of the transformation rules. The views are presented in SQL, and are respectively the SW_PRODUCT merge view and the SW_TRANSACTIE merge view. Here, the merge view SW_PRODUCT must be applied to the source data structure 1 (PRODUCT) and the merge view SW_TRANSACTIE must be applied to the source data structure 2 (TRANSACTION). As a result of applying both merge views, an entity set is determined that has a predetermined generic form that is separate from the form in which the source data was initially available. This further simplifies the further processing of the data.

20 Code snippet 1. Merge view SW_PRODUCT: create view SW_PRODUCT (sid, did, 25 typ, val) as select 1 sid, 3 0 PRODUCTJ30DE did, 'CODE' typ, PRODUCT_CODE val from PRODUCT union all 35 select distinct 1 sid , PRODUCT_CODE did, 'DESCRIBE' typ, unify_omschr (PRODUCT DESCRIPTION) val from PRODUCT 40 union all select distinct 2 sid, PRODUCT_CODE did, "CODE1 typ, PRODUCT_CODE val 1014288 10 I from SALES TRANSACTION;

Pseudo-code fragment 2. Merge view SW_TRANSACTIE:

5 create view SW_TRANSACTION

(sid, did, typ, val 10) as select distinct 2 sid, PRODUCT_CODEI | SALES_DATE did, 15 "CODE_DAY1 typ, PRODUCT_CODEI | SALES_DATE val from SALES TRANSACTION;

In this example, the desired target structure 20 has two entity types. According to the invention two field value views corresponding to the respective target entity types are determined for this purpose. The field value views are arranged in such a way that application of the field value views to the source structures, the information required for the relevant target entity is obtained from the source structures and is brought into a generic format. In particular, the attribute values for the attributes of the target entities are determined.

Application of a field value view according to the invention to one or more data structures yields an entity set of an entity type with at least the following attributes: - SID (System IDentification) unique identification of the source data structure, in this example 1 or 2.

35 - DID (Data IDentification) unique identification of entity within a source data structure.

Combined, SID and DID uniquely identify a particular entity. Incidentally, the invention can also be applied with a single attribute to unambiguously designate an entity.

1014288 11 - target attributes; one or more attributes from the source data structure, each corresponding to an attribute of a target entity.

Field value views according to the invention can, among other things, perform the following functions: - format uniformity, whereby data that have the same meaning, but are represented in different ways in the source (s), are displayed in the same way in the target data structure, 10 - facilities at attribute and attribute corbination level, through which contradictory data can be removed from the data sources.

For the above-mentioned data transformation according to the exemplary embodiment, the following two examples of field value views according to the invention are drawn up and shown in SQL, namely the field value view VWV_PRODUCT and the field value view VWV_TRANSACTIE. The VWV_PRODUCT field value view should be applied to the source structures and the VWV_TRANSACTIE field value view should be applied to the source structures. The result of applying both views is that an entity set is determined that has a predetermined, generic form that is separate from the form in which the source data was initially available. This further simplifies the further processing of the data. This allows the values of the entities in the target data structure to be populated later along with the entities determined by merge views.

Pseudo-code fragment 3. Field value view VWV_PRODUCT

30 create view VWV_PRODUCT (sid, did, PRODUCT_CODE, 3 5 PRODUCT_DESCRIPTION, NUMBER_SOLD,

REVENUE

) as 1014288 12 select 1 sid, PRODUCT_CODE did, PRODUCT DESCRIPTION PRODUCT DESCRIPTION, 0 qty. sold, 5 0 ΟΜΖΕΤ from PRODUCT union all select 2 sid, PRODUCT_CODe did,

10 'fictional' I IPRODUCT_CODE

PRODUCT_DescriptionJV! NG, sum (NUMBER_SOLD) NUMBER_SOLD,

sum (TURNOVER) TURNOVER

from TRANSACTION

15 group by sid, did, PRODUCT DESCRIPTION;

Pseudo-code fragment 4. Field value view VWVORANSACTIE

20 create view VWJTRANSACTIE (sid, did, NUMBER_SOLD, 25 SALES_ATUM / sales_amount) as select 2 sid, 3 0 PRODUCT CODE] | SALES_DATE did, sum (NUMBER_SOLD) NUMBER_SOLD, SALES_DATE SALESDATE,

sum (TURNOVER) TURNOVER

from TRANSACTION

35 group by sid, did, sales date;

In this example, the desired target structure 40 has two entity types. To this end, according to the invention, a relationship view is determined which establishes the relationship between the two target types, which may come from different source structures. The relationship view is arranged in such a way that application of the information thereof to the source structures obtains the information required for the composition of the target entities regarding the relationship between the entities of the source structures.

i w; v v 0 13

Application of a relationship view according to the invention to one or more data structures yields an entity set of an entity type with at least the following attributes: 5 - from_sid: (System IDentification) unique identification of the source data structure, in this example 1 or 2.

- from_did: (Data IDentification) unique identification of a first entity.

10 - to_did: unique identification of a second entity referenced by the first entity.

- to_sid: unique identification of a second source data structure referenced by the first entity.

The combination from_sid and from_did unambiguously indicate a specific first, starting entity, of the relationship specified by the relationship view. Correspondingly, the combination of to_sid and to_did unambiguously indicates a certain second, target entity of the relationship specified by the relationship view. Incidentally, according to the invention other suitable identifications can also be used for the start and target entity.

Relationship views according to the invention may, inter alia, provide relationship facilities, with which relationships between entities in the target data structures are constructed and maintained, using methods known per se for relational databases, whereby entities are provided via referring keys (such as e.g. image a foreign key) point to the uniquely identifying key (such as a primary key) of another entity.

Pseudo-code fragment 5. Relation view RLV_TRANSACTIE_PRODUCT

35 create view RLV_TRANSACTIE_PRODUCT

(from_sid, from_did, 1014288 14 to_sid, to_did) as 5 select distinct 2 from_sid; PRODUCT_CODEI SALE_DATE from_did, PRODUCT_CODE to_did 2 to_sid, f rom TRANSACTION; 10

In the following, an example of a transformation process according to the invention will be described with reference to an example with reference to Fig. 1.

Use is made of the 15 views described above. In the example, two source data structures 1 and 2 (see Tables 4 and 5, and Figure 1) of the types shown in Tables 1 and 2 are provided with entities with valued attributes. A row in Tables 4 and 5 forms an entity, and the columns are attributes, with an attribute value being entered at each relevant position.

Table 4. PRODUCT (source data structure 1) -PRODUCT ”'CODE (' FRÖDUCT DESCRIPTION- _MYOGIO__1 liter of low-fat yogurt_ _HMLK10__1 liter of semi-skimmed milk_ _VMLK05_ whole milk, half a liter

VMLKHL FULL MILK HALF LITER

25 table 5. SALES_TRANSACTION (source data structure 2)

PKÜBUCT_CODE SUMMER SOLD j SALES DATE SOLD SALES AMOUNT

'MifOGlO 3 10-07-1999 13: 17 6.30 HM1.K10 2 10-07-1999 14:28 3.9Ö -VMLK05--3--10-07-1999--14: 56--3750 - VMLKHL - S - 10-07-1999--15: 24--7700 -MYOGIO - 3--1T-07-1999--097TB - 6770- -HMLK10--2 - ΓΤ-07-1999 --Ï0T30--3750 -7HCK05--3 - ΓΤ-07-1999 - TT705--3750- -VMLK05--1--11-07-1999--12: 09--07B5- VMLKHL 8 11- 07-1999 11:16 7700 ~ COCÖLA ........ 'L ............--- 11707-1999 ------- TTTJB "ιι, ιο ~ According to the transformation process of the invention, the two merge views, as shown in 1014288 code fragment 1 and 2 applied, also called projected, are applied to the respective source data structures 1 and 2 (4 and 5 in Fig. 1). operation can be found in Tables 6 and 7.

According to the invention, when applying the merging views, the result entities are each provided with a GRP designation. This GRP designation uniquely identifies the entities within the collections obtained. Here, each GRP designation assigned is compared with a memory structure (6, 7, 6 ', 7' in Fig. 1) in which previously assigned GRP designations are stored. For entities that are already included in this memory structure, the same GRP designation 15, each stored in the memory structure, is assigned to that entity. As a result, a GRP designation once assigned remains constant in successive transformation processes. This means that indications of returning entities remain persistent to allow cross-comparisons of previously determined target structures.

2 0. Since no previously determined target sets have been determined in this exemplary embodiment, the result entities are provided with a unique, ascending identification number.

25 Table 6. PROJECTION SW_PRODUCT

—SID —- DID - TYP - VKL - ["GRP" ï MYOGIO CODE MYOGIO ï 1__HMLK10 CODE__HMLK10__2_ 1 VMLK05 CODE VMLK05 3 1 VMLKHL CODE VMLKHL 4 1 MYOGIO OMSCHR 1LITERMAGEREYOGHURKALKHKKRMKHMKHKKKKKKKKKKKKKKKKKKK 1 VMLKHL DESCRIBE FULL MILK HALVELITER 8 2 MYOGIO CODE MYOGIO 9 2 HMLK10 CODE__HMLK10__10 2 VMLK05 CODE__VMLK05__11 2 VMLKHL CODE VMLKHL 12 ~ 2 COCOLA CODE COCO LA 13 101 426 $

Table 7. PROJECTION SW_TRANSACTION

16 -5IE - ΠΠ3 - TYP - VRL- 5RP- 2 MYOGIOIO- CODE_DAG MYOG1010-07- ï __07-1999 1999__ 2 HMLK1010- CODE_DAG HMLK1010-07- 2 __07-1999 ___ 1999__ 2 VMLK0510- CODE_DAG VMLK0510-07- 3 07 -1999 1999 2 VMLKHL10- CODE_DAG VMLKHL10-07- 4 __07-1999 ___ 1999__ 2 MYOG1011- CODE_DAG MYOG1011-07- 5 __07-1999 ___ 1999__ 2 HMLK1011- CODE_DAG HMLK1011-07- 6 __07-1999 ___ 1999__ 2 VMLK0511- 1999___1999__ 2 VMLK0511- CODE_DAG VMLK0511-07- 8 __07-1999 ___ 1999__ 2 VMLKHL11- CODEJOAG VMLKHL11-07- 9 __07-1999 ___ 1999__ 2 COCOLA11- CODE_DAG COCOLA11-07- 10 _ 07-1999 __1999__- 5 Now being shown fragment 3 and 4, applied to the source data. The result is shown in Tables 8 and 9 (8, 9 in Fig. 1).

10 Table 8. PROJECTION VWVJPRODUCT

—ΕΠΠ3 —- OFF »- PRODUCT_DESCRIPTION NUMBER_SALES TURNOVER

FISHING MORNING

1 MYOG10 1 liter of skimmed 0 0 ___yoghurt___ 1 HMLK10 1 liter of semi-skimmed 0 0 ___le milk___ 1 VMLK05 whole milk, half 0 0 ___ve liter___ 1 VMLKHL FULL MILK HALF 0 0

LITERS

2 MYOG10 fictional MYOG10 6 12.60 2__HMLK10__fictive HMLK10__4__7,80 2 VMLK05 fictional VMLK05 9 7,85 2__VMLKHL fictional VMLKHL__16 14,00 2 COCOLA fictional COCOLA 5 11,10 15 1014288

Table 9. PROJECTION VWV_TRANSACTIE

17

SID -DID 'A5NTAL_ SALES_ SALES

SOLD DATE

2 MYOG1010-07-1999 3 10-07-1999 6TTÖ 2 HMLK1010-07-1999 2 10-07-1999 3.90 2 VMLKO 510-07-1999 4 10-07-1999 3.50 2 VMLKHL10-07-1999 8 10-07-1999 7.00 2 MYOG1011-07-1999 3 11-07-1999 6.30 2 HMLK1011-07-1999 2 11-07-1999 3.90 2 VMLKO 511-07-1999 5 11-07 -1999 4.35 2 VMLKHLll-07-1999 8 11-07-1999 7.00 ~ 2 COCOLA11-07-1999 5 | 11-07-1999 11.10 5 Now the relationship view, as defined above, is applied to the obtained set, resulting in table 10 (10 in fig. 1).

Table 10. PROJECTION RLV_TRANSACTIE_PRODUCT

10 FROM_SID -FROM_DID - TO_DID - TO SID- 2 MYOG1010-07-1999 MYOG10 2 2 HMLK1010-07-1999 HMLK10 2 2 VMLKO 510-07-1999 VMLKO5 2 2 VMLKHL10-07-1999 VMLKHL 2 2 MYOG1011-07- 1999 MYOG10 2 2 HMLK1011-07-1999 HMLK10 2 2 VMLKO 511-07-1999 VMLKO5 2 2 VMLKHLll-07-1999 VMLKHL 2 ~ 2 COCOLA11-07-1999 COCOLA 2

Then, the obtained entities are combined as shown in Tables 6-10 (11, 12 in Fig. 1). This merging takes place by: 15 First, within a collection of entities with the same SID / DID combination, the same GRP designation is provided. Because the SID / DID combination designates a unique entity, this means that with an equal SID / DID designation, the relevant entities are the same target entity. This takes into account the manner described above for allocating initial GRP designations based on a previously determined memory structure.

si: -r - i 0 U

18

Subsequently, within the same collection of entities with the same typ / fall combination, an equal GRP designation is provided.

When applied to the example, for the set as shown in Table 6, after collecting equal SID / DID combinations, giving entities with the same SID / DID combination the same GRP designation, the values for GRP as shown in the GRP column (in-between).

10 Subsequently, entities with the same type / fall combination are given the same GRP number, based on the GRP (intermediate) indications, which yields the column GRP (new).

The merge is complete when the requirement is met that there are no more entities left that have the same typ / trap combination or the same sid / did combination but still have different GRP identifications. Although in this example this requirement is met by the above described repeated execution of merging steps 20 where the lowest possible GRP number is always chosen in the grouping, the invention is in no way limited to this exemplary algorithm. The invention can be applied with any other algorithm arranged to achieve the aforementioned requirement to terminate the merging.

1 014288

Table 11. MERGER SW_PRODUCT

19

SID "" 1-DIB - TYP - VKE SEP GKP 5EP

(old) (in between) (new)

"I - MYOGIO - CODE-f-MYOGIO - 1--1 I

—I - ΗΜΕΚΓ0 CODE 1 HMLK1Ö:: 2 2 2 —I - VMLK05 CODE VMLKüb 3 3 3 -1 - VMLKHL - CODE VMLKHL 3 3 3

—I - MYOGIO - 0M5CHE - ILTTEEHKGEÏEYOGHDET - 5--1 I

-1 - HMLK10 - DESCRIPTION - LIQUID-HALPVÜLLEMEL'K - 5--2 2 -1 - VMLK05 - OM5CHE - FULL MILK HAEVEL ITEE - 7--3 3 —I - VMLKHL - ÖM5CHK - FULL MILK HALVELITER : -8--3--3- —2 - MYOGIO - CODE - MYOGIO - 9--9--1- —2 - HMLK10 - CODE - HMLKTO-ID TO 2 —2-- VMLK05 - CODE - VMLK05 - Π Π 3 —2 - VMT.KHI, - CODE - VMLKHL - 12--12--3- —2— ÜÜCOLA CODE CÜCÜLA i3 'U ι3 5

The merge operation as applied to Table 6 is then applied to Table 7. For convenience, the GRP column (intermediate) is omitted. The result is shown in Table 12.

10

Table 12. MERGER SWJ TRANSACTION

-STD - DID- TYP - VSE- [~ GEP —- GEP- (old) (new) -2 - MYOGIOIO-TTT ^ - CODE_DAY - MYOG1010-ÜT-1999--1--1- 1999 2 HMLK1ÜIÜ-Ü7- CODE_DAG HMUK1Ö10-O7-1999 2 2 1999 2 VMLKOSlö-öT ^ COUE_ÜAü VMiik0bl0-07-1999 3 3 1999 -2 - VMLKHE10-07 --- CODE ^ DAY - VMLEHLlö-07-1999-- 3--3- 1999 -2 - MYOGlOll-ÜY -'-- C0DE_DAG - MYOGlöll-ö'r-1999--5--5- 1999 2 HMLKIÜ11-07- CODE_DAü HMLK.lüll-07-1999 δ δ 1999 -2 - VMLK0311-0T = - CODE_DAG - VMLK0511- (JT-1999--7--7- 1999 -2 - VMLKO b'irrD, r: - CODE_DAG - VMLKÖ511-07-1999- -8--7- 1999 -2 - VMLKHL11-Ö7 --- CÖDE_DAG - VMLKHL11-07-1999--9--9- 1999 -2 - COCOLAl 1-07 --- CODEJDAG - COCÖLA11-Ö7 -1999 - Tö - Tü- __1999_____ 15 Next, the result obtained is recorded in a memory structure. According to the invention, a memory structure is drawn up for each target entity, the entity type comprising the following attributes: 1 0 U 2 8 8 20 - SID ( System IDentification) unique identification of the source data structure, in this example 1 or 2, - DID (Data IDentific ation) unique entity identification within a source data structure, and 5 - GRP, the GRP designation assigned to the SID / DID combination after the merge process.

When applied to Tables 11 and 12, this yields the result shown in Tables 13 and 14 (6, 7 in Fig. 1).

10

Table 13. PRODUCT MEMORY STRUCTURE

5TD -DTD- GRP-- '1 MYOGIO 1 1 HMLK10 2 1 VMLK05 3 1 VMLKHL 3 2 MYOGIO 1 2 HMLK10 2 2 VMLK05 3 2 VMLKHL 3 2 COCOLA 13

15 Table 14. MEMORY STRUCTURE TRANSACTION

SID —- DID- GRP- 2 MYOGIO10-07-1999 ï 2 HMLK1010-07-1999__2_ 2 VMLKO 510-07-1999__3_ 2 VMLKHL10-07-1999 4 2 MYOGIO11-07-1999 5 2 HMLK1011-07-1999 6 2 VMLKO 511-07-1999 7 2 VMLKHL11 - 07-1999__9_ 2 COCOLA11-07-1999 10

On the basis of the tables obtained by means of the merging and the memory structure, the ultimate target data structure can be built up.

Here, for each unique GRP designation, as known from Tables 13 and 14, a target data entity is created, whereby the GRP value is assigned to the attribute PRODUCT_Key (13 in Fig. 1). The other attributes are entered via the SID / DID combination associated with the GRP designation. Cs r- -λ

. t '0 i - v O

21 removed from the already determined collection, possibly via an operation, such as in the case of the attribute TURNOVER.

The results of this are shown in Tables 15 and 16 (3 in Fig. 1).

5

Table 15. PRODUCT

PRÖDuCt_ PRODUCtCÖ PRÖl) Udt_OMSCHRXjVÏN AAliTAli_VÈRKOC turnover

KEY THE G HT

1 myöGio 1 liter skim yog- δ 12.60 hurt 2 HMLkio l liter iialtvolie 3 7, S ”0 milk 3 VMiiküb whole milk, naive 25 21.55 liter 13 CoCOLA TicETéF C0C0L & 5 11, lö-

10 Table 16. TRANSACTION

"PRODUCT TRANSACTION!" ASKTAL SOLD SALES DATE SALES AMOUNT "KEY KEY

-1--1--3--10-07-1999--57TÜ- -2--2--2--10'-07 7L999--37513- -3--3--3--10 = 07 = 1999--3750- -3--3--8--10-07-1999--7700- -5--1--3--11-07-1999--5730- -5--2 --2--11-07-1999--3790- -7--3--5--11-07-1999--3755- -9--3--8--11-07 = 1999-- 7700- 10 I i3 1 a 11-07 = 1999 11.10 -----

The exemplary embodiment assumes an unambiguous identification of an entity by means of a combination of SID and DID; the invention is by no means limited to this identification. According to the invention, unambiguous identification of entities can take place in any suitable manner, for instance by one or more attributes, whether or not composed.

Although the relational database assumes a relational database, the invention is not limited to this application. The invention can also be applied with other database systems, such as, for example, network or hierarchical systems.

Although in the exemplary embodiment a data transformation is described with respect to a product / sales system, the invention is by no means limited to 1014238 22 this exemplary embodiment. The invention can be applied to other data transformations, such as, for example, data conversions, data quality analysis, batch interfaces, and data warehousing.

The invention is particularly suitable for use in a software generation tool. After determining the transformation rules according to the invention, such a tool can largely generate automatically the software for applying the transformation rules and the execution rules to the source data.

The invention lends itself particularly to execution on a computer, for this purpose the invention can be implemented as a computer program, which is designed to carry out the method according to the invention when executed by a computer. In particular, the computer program may be stored in a computer readable form on an information carrier such as, for example, a memory, disk memory, floppy disk and CD-ROM.

1014288

Claims (8)

A method for assembling a target data structure comprising at least one target entity type, from at least one source data structure comprising at least one source entity type with at least one attribute with an attribute value, characterized by the steps of projecting the source data structure comprising applying at least one aggregation view, yielding a set of candidate entities, of a candidate entity type that includes at least: 10. a unique resource identifier (sid, did) that is different for each resource, identifying an associated resource entity, - an aggregation designation (typ), and - a aggregation value (val), wherein the aggregation value is dependent on said attribute value of said associated source entity, forming an aggregation set comprising aggregating candidate entities based on at least some degree of agreement between associated with -20 e unique source identifiers (sid, did), merging candidate entities based on at least some degree of correspondence between the associated merging designations (typ) and the merging values (val), and assigning unique group identifications 25 (grp) to entities of the merge set, forming a memory structure from the merge set, comprising entities each with one of said unique source identifiers (sid, did) and each one of the unique group identifiers (grp), and transforming the source data structure into a target data structure in accordance with the memory structure, the pooling and the candidate entities. 1 014 ° 0 a The method of claim 1, further comprising the step of projecting the source data structure comprising applying at least one field value view, yielding a set of candidate entities, of a candidate entity type comprising at least: - a unique one for each source different source identification (sid, did) identifying an associated source entity, and 10. at least one attribute that depends on said attribute value of said associated source entity. Method according to claim 1 or 2, further comprising the step of 15 projecting the source data structure applying at least one relationship view, yielding a set of candidate entities, of a candidate entity type comprising at least: - a start identification ( from_sid, from_did) that uniquely identifies a first, target candidate entity, and - a target identifier (to_sid, to_did) that uniquely identifies a second, target candidate entity, thereby establishing a relationship between the first and second candidate entities. Method according to any one of the preceding claims, further comprising the steps of comparing formed candidate entities with a previously determined memory structure in forming a merge set, and assigning candidate entities corresponding to entities of group identifiers occurring in the previously determined memory structure. cations (grp) equal to the relevant entities occurring in the previously determined memory structure. A computer program product, directly inputable into the internal memory of a computer, comprising program components 10H2 & 8 parts configured to perform a method of assembling a target data structure comprising at least one target entity type, from at least one source data structure comprising at least one source entity type with at least one attribute with an attribute value, with the steps of projecting the source data structure comprising applying at least one concatenation view, yielding a set of candidate entities, of a candidate entity type comprising at least: - a unique one for each source different source identifier (sid, did) identifying a corresponding source entity, - a merging designation (typ) and 15. a merging value (val), the aggregation value being dependent on said attribute value of said associated source entity, forming a merger matching set comprising merging candidate entities based on at least some degree of agreement between associated unique source identifiers (sid, did), merging candidate entities based on at least some degree of agreement between associated combination indicia (typ) and the combination values 25 (val), and assigning unique group identifiers (grp) to entities of the merge set, forming a memory structure from the merge set, comprising entities each with one of said unique source identifiers (sid, did) and each one of the unique group identifiers (grp), and transforming the source data structure into a target data structure in accordance with the memory structure, the aggregation set and the candidate entities. 1014 ^ 88 The computer program product according to claim 5, further comprising program code parts adapted to perform the step of projecting the source data structure comprising applying at least one field value view, yielding a set of candidate entities, of a candidate entity type which at least comprises: - a unique source identifier (sid, did) different for each source, which identifies an associated source entity 10, and - at least one attribute which is dependent on said attribute value of said associated source entity. The computer program product of claim 5 or 6, 15 further comprising program code portions adapted to perform the step of projecting the source data structure comprising applying at least one relationship view, which yields a set of candidate entities, of a candidate entity type that at least includes: - a start identification (from_sid, from_did) that uniquely identifies a first, starting candidate entity, and - a target identification (to_sid, to_did) that uniquely identifies a second, target candidate entity, thereby establishing a relationship between the first and the second candidate entity. 8. Computer program product according to any one of claims 5-7, further comprising program code parts adapted to perform the steps of comparing formed candidate entities with a previously determined memory structure in forming a merge set, and assigning candidate entities corresponding to in the previously determined memory structure occurring entities of group identifications (grp) equal to the respective entities occurring in the previously determined memory structure. 'I T *', ν 3