Rivero L.Encyclopedia of database technologies and applications.2006

models are not adequate for the task, although there have been attempts to develop explicit, declarative representations for business rules. Among them, ORM (Halpin, 1995) provides several mechanisms to specify constraints related to the participation of entities in relationships, which affects some structural and action assertions. Also, an extension for UML (Rumbaugh, Jacobson, & Booch, 1999) has been proposed that addresses expression of constraints: OCL (Object Constraint Language), a semiformal language that can handle most structural and action assertions (Demuth, Hussmann, & Loecher, 2001). A representation specifically for business rules is Ross’s method (Ross, 1994). However, all these representations lack formal semantics, and most of them lack a methodology to indicate how different kinds of rules are to be represented. Finally, none of them addresses the question of how business rules are to be incorporated into the design of an information system.

One of the most well-known and used conceptual models, the entity-relationship (ER) model (Chen, 1976), falls very short of the task of capturing business rules (Badia, 2004). In ER models, there are three basic concepts: entity types, attributes, and relationships. Clearly, the entity types are used to denote business objects, of which rules are predicated. Rules, then, must be expressed in ER models using either attributes or relationships. However, many kinds of rules cannot be expressed with these means: the domain rules of Von Halle and Fleming (1989) actually give us properties of the attributes of the object; because attributes in ER models have no further structure, this information cannot be captured. For example, given an entity type Employee, and an attribute Age, the fact that Age should be between 18 and 65 cannot be expressed in an ER model. Such information can be captured in a data dictionary; however, more complex rules that relate several attributes cannot be added to a dictionary. Assume, for instance, that Employee has two attributes, Salary and Rank, and that each rank determines a maximum and minimum salary for employees in that rank. Such complex relation is unlikely to be written in a data dictionary (under which term, Salary or Rank, should it be included?). As for triggering operations—and the action assertions and derivations of GUIDE (2000)—because they express dynamic aspects and ER models focus on structure but have no dynamic component, such types of rules cannot be represented, either. As an example, assume that a rule exists stating that the salary of an employee can never surpass that of his or her manager. When salaries change, the rule should be used to check the correctness of any increase. However, such rules are not expressible in an ER model. Depending on the type of rule, semiformal techniques such as decision trees, tables, state transition diagrams, or methods in object-

Business Rules in Databases

oriented models, can be used. However, business rules are intrinsically connected to the data; therefore, it would be desirable to express them in a formalism that has a direct connection to the conceptual model. Finally, note that information about the business rule cannot be captured in any of these formalisms, even though metadata about the business rule (e.g., author, date, sponsor, source, purpose, relation to other rules) is necessary to manage a collection of business rules effectively.

Expressing Business Rules in Data

Models

Even if business rules are somehow captured at requirement specification time, the current process for implementing business rules (usually, to give some specification to a programmer so that an application can be written enforcing the rules) has several drawbacks: The process of creating and codifying a rule is long, laborintensive, and involves several groups of people, creating a risk for miscommunication; assessing impact of rules (the quality and adequacy of the data produced by its application) is extremely difficult; and changing the rules is extremely difficult.

To decide how to express a given business rule, the most promising approach is to classify the rule according to some characteristic that will allow one to determine an efficient implementation. There are some obvious options, such as classifying rules as static or dynamic or classifying rules according to the data they affect.

The first classification makes sense because some rules are more intimately bound to change than others. For instance, a rule stating that salary increases for employees cannot exceed 10% is clearly dependent on a change. Therefore, I define dynamic rules as those that are directly related to change, and static rules as those that are not. Even though this definition is somewhat ambiguous, it can be made more precise with a test. To specify the rule, is there a need to refer to the before- and-after of a certain action? If one applies the test to the examples, the rule about employees’ salaries not being higher than the managers can be seen as static, while the rules about employees salaries not increasing by more then 10% can be seen as dynamic.

As for classifying rules according to the data they affect, to make such a distinction meaningful in the context of a database the classification must be based on the conceptual model used to design the database, one can then talk about rules affecting a single attribute, several attributes within a single entity, several attributes in several entities, and relationships, which implicitly means the related entities. There is good reason

Business Rules in Databases

to look at the scope of the rule: The scope of the tools at our disposal (i.e., checks, assertions, and triggers) is different.

Finally, another important difference among the rules is whether they state a “must” situation or a “should” situation. A must rule is one that the situation cannot be changed to accommodate a violation, while a should rule is one where things can be changed to deal with rule violations. For instance, if the rule about an employee’s salary not being higher than a manager’s is considered a mustrule, any attempts to raise an employee’s salary or lower a manager’s salary have to be outright rejected, and if the rule is considered a should rule, changes can be made. To raise an employee’s salary above a manager’s, the manager’s salary can be raised, too, to preserve the rule. The difference is significant because the system needs to know what options, if any, to offer when rules are violated.

Because our goal is to decide how to implement the rules, we must also take into account the characteristics of the tools available. Table 1 summarizes some important differences among triggers, assertions, and checks.

While triggers and assertions can mention any table and any attribute in the database, checks are limited to the domain or table in which they are declared. Also, checks are not always guaranteed to hold (see example in the previous section), whereas the system guarantees that assertions and triggers will always be enforced. Finally, when a check or an assertion are violated, the transaction that violates them is rejected; when a trigger is fired because a condition it checks for holds (usually a violation of a rule), the action part of the trigger allows a programmer to specify exactly how to react.

The previous observations about rules and tools lead me to propose the following classification in order to guide implementation. The classification does not claim to be optimal; it simply responds to the characteristics of the tools at one’s disposal.

•Static (must) rules: These rules involve a state change, and any transaction that invalidates them must be outright rejected. I further subdivide these rules as follows:

•Rules that affect a single attribute: These may include some domain rules noted in von Halle and Fleming (1989) and the definitions of business terms noted in GUIDE (2000). These rules should

Table 1. Differences among relational database tools

be implemented with a check. As an example, consider the previous rule about employees’ B ages. Implementing such rules as checks is advantageous because it is simple (i.e., checks are

easy to write), natural (i.e., the check can be attached to the domain of the attribute in question or to its table), and, in the case where no other attributes are present, guaranteed to hold.

•Rules that affect several attributes in one entity:

These may include some domain rules and some integrity rules noted in Halle (1998) and some facts and action assertions noted in GUIDE (2000). These rules should be implemented with an assertion, because even though checks can mention attributes in other tables, they are not guaranteed to hold (see the example in the previous section).

•Rules that affect several attributes in several entities: These may include some integrity rules noted in Halle (1998) and some action assertions noted in GUIDE (2000). These rules should be implemented with an assertion, for the same reasons as in the previous case. Assume, for instance, that there are ranks in the organization and each employee has a rank. Associated with each rank there is some information; for instance, the maximum and minimum salary for that rank. An obvious rule is that employees’ salaries remain within what is dictated by each employee’s rank. Then the assertion would have to mention both tables:

CREATE ASSERTION salary-rank

(NOT EXISTS (SELECT * FROM EMPLOYEE, RANK WHERE Employee.rankid

=RANK.rankid AND

(Employee.salary < rank.min_salary OR Employee.salary > rank.max_salary))).

•Dynamic (should) rules: These are rules that involve state changes or that may respond to a violation in several ways, including the triggering operations noted in Halle (1998) and the derivations noted in GUIDE (2000). I can also further subdivide them as was done for static rules; however, in a relational database all such rules must be written as triggers. This is because dynamic rules may have to mention the before-and-after of an action, possible

in a trigger but not possible in a check or an assertion, and “should” rules need to specify how to react to a violation, for which checks and assertions have no proviso, but triggers have the action part. For instance, the rule stating that employees’ salaries must remain within what is dictated by the employees rank can be written as2:

EVENT:UPDATE(EMPLOYEE) CONDITION: (NOT EXISTS (SELECT *

FROM RANK WHERE rankid =

NEW.rankid AND

(NEW.salary > TEMP.max_salary OR NEW.salary < min_salary)

ACTION: …

If this is a should rule, several things can be done when the rule is violated; rejecting the salary change is only one of them. The desired behavior is programmed into the action part. Note that there is also more than one way in which the rule can be violated: not only by changing an employee’s salary, but also by changing an employee’s ranking or changing a ranking’s maximum or minimum salary. Hence, multiple triggers should be written, unless the system allows compound events to be expressed.

As an example of a typical dynamic rule, use the old example of salaries not increasing by more than 10%. In this case, the trigger would look like this:

EVENT: UPDATE(EMPLOYEE) CONDITION: OLD.salary * 1.1 > NEW.salary ACTION: …

As stated previously, the use of triggers is limited in many cases. Using an approach like the one proposed here, the use of triggers may be avoided in some cases.

Although implementation issues are not mentioned here, they are an important aspect of the problem because, as stated previously, trigger systems add substantial overhead to database processing. It is also likely that assertions are not implemented in commercial systems because of the difficulty of supporting them efficiently. Both assertions and triggers interact with the transaction processing part of the system, raising difficult questions, such as, When should a trigger or assertion be checked? What should be done when more than one assertion or trigger should be executed? Does order matter? This is an area that is still the subject of considerable research (Widom & Ceri, 1996).

Business Rules in Databases

FUTURE TRENDS

To implement business rules in a relational database, it is necessary not only to find some way to capture and express the rule in the requirement specification, perhaps using a combination of techniques (and surely going beyond what usual conceptual models have to offer), but also to find some way of implementing the rule in the database, a process that might get complicated. It is clear that checks, assertions, and triggers together manage to cover most of the usual business rules; however, it is difficult to decide which tool to use for a particular rule. It therefore would be desirable to develop either a new construct specifically tailored to business rules or to extend the existing rules to make the task more manageable. From the analysis used here, some obvious avenues of development can be pointed out. For instance, extending checks and assertions with the ability to specify what to do in case a condition is violated or ensuring that a check is always guaranteed to hold would allow many static rules to be expressed without having to resort to triggers, which could then be used only if truly necessary.

CONCLUSION

Although business rules are a very important part of information systems, there is little academic research on them. Some practitioners have contributed to the understanding of the subject, but there is no underlying framework for its study. Also, support for business rules in conceptual models and database systems leaves much to be desired. As a result, eliciting, expressing, and capturing business rules remain more of an art than a science. However, given their practical importance, more research in the subject is expected in the near future.

REFERENCES

Badia, A. (2004, March). Entity-relationship modeling revisited. ACM SIGMOD Record, 33(1), 77-82.

Chen, P. (1976). The entity-relationship model: Toward a unified view of data. ACM Transactions on Database Systems, 1(1), 9-36.

Date, C. (2000). An introduction to database systems (7th Ed.). Reading, MA: Addison-Wesley.

Davis, F. (1993). Requirement specification: Objects, functions and states. Upper Saddle River, NJ: Prentice Hall.

Business Rules in Databases

Demuth, D., Hussmann, H., & Loecher, S. (2001). OCL as a specification language for business rules in database applications. In M. Gogolla & C. Kobryn (Eds.), Proceedings of the 4th International UML Conference: Vol. 2185

(pp. 104-114). New York: Springer.

GUIDE (2000). The GUIDE business rules project: Final report. Business Rules Group.

Halle, B. von, & Fleming, C. (1989). Handbook of relational database design. Reading, MA: AddisonWesley.

Halpin, T. (1995). Conceptual schema and relational database designI (2nd Ed.). Upper Saddle River, NJ: Prentice Hall.

Krogh, G. (2000). Enabling knowledge creation. UK: Oxford University Press.

Melton, J., & Simon, A. R. (2002). SQL 1999: Understanding relational language components. San Francisco: Morgan Kaufmann.

Paton, N.W. (Ed.). (1999). Active rules in database systems. New York: Springer.

Ross, R. (1994). The business rule book: Classifying, defining and modeling rules. Database Research Group.

Rumbaugh, J., Jacobson, I., & Booch, G. (1999). The unified modeling language reference manual. Reading, MA: Addison-Wesley.

Widom, J., & Ceri, S. (Eds.). (1996). Active database systems: Triggers and rules for advanced database processing. San Francisco: Morgan Kaufmann.

KEY TERMS

Action: Part of a trigger that is executed when the condition in the trigger is evaluated and found true. This is the most open-ended part of a trigger, because different database vendors have allowed different functionality in their implementations. At a minimum, data manipulations operations (e.g., insert, delete, update) are allowed.

Assertion: Expression in a relational database system that allows stating a condition involving several attributes and several tables. Assertions are first-class database entities, such as tables.

Business Rule: Statement that defines or constrains business objects, their behavior, and relationships. Usu- B ally expressed in a semiformal language, using a vocabu-

lary of business terms and verbs such as have to, should, and must.

Business Term: Word or expression denoting a concept that has a particular meaning in the context of an enterprise.

Check: Expression in a relational database system that allows stating a condition involving an attribute in a table; used with CREATE DOMAIN or CREATE TABLE statements.

Condition: Part of a trigger that is evaluated when the event in the trigger takes place. It is usually a predicate in SQL that evaluates to true or false.

Event: Part of a trigger that refers to the occurrence of a certain situation. When the event occurs, the rule is triggered (i.e., is scheduled so that its condition is evaluated). In most systems, the event can mention only basic database actions (e.g., insertions, deletions, updates).

Trigger: Rule of the form Event-Condition-Action, used in relational database systems to implement active functionality.

ENDNOTES

1Also, managerial issues (enforcing the rules, setting business policies, etc.) are not dealt with here.

2Because different systems implement triggers in very different ways, I use a stylized syntax that makes clear the EVENT, CONDITION, and ACTION of each trigger. Because expressiveness is the main interest, implementation issues that surround the use of triggers are not dealt with. In particular, and to simplify, it is assumed that every trigger is applied to the database immediately after the event takes place. Within the body of the trigger, the words OLD and NEW refer to the affected tuple(s) values before and after the event is applied to the database.

Christoph Bussler

Digital Enterprise Research Institute (DERI), Ireland

BUSINESS-TO-BUSINESS (B2B) INTEGRATION TECHNOLOGY

Businesses worldwide started exchanging electronic business messages with each other around 1970. This coincides with the establishment of wide-area computer networks. Businesses realized the potential immediately to send electronic messages instead of paper letters in order to conduct business electronically. Computer networks provided a significant increase of transmission speed, less failures due to message losses, and direct processing of messages upon receipt without manual transcript from paper to computer terminals or vice versa. Overall, business interactions became a lot more reliable and efficient.

The direct processing capability of electronic messages enabled the seamless integration of the messaging environment and the back-end application system processing. The electronic integration of businesses was achieved this way and the technological basis was called business-to-business (B2B) integration technology. However, B2B integration technology was not affordable to every business independent of its size due to its high deployment and maintenance cost. Therefore, only big businesses could afford electronic B2B integration. Smaller businesses continued to rely on paper letters or fax transmissions.

Today it is commonly accepted to exchange electronic messages between businesses. Current trends are to make B2B technology more accessible to every business independent of its size through ubiquitous Web technology. This new technology is called Web services and all software vendors readily provide solutions (Alonso, Casati, Kuno, & Machiraju, 2004; Bussler, 2003).

BACKGROUND

Dedicated networks called value added networks (VANs) started providing the transport of electronic messages between businesses around 1970. Since their service is very reliable they still are extremely popular today and widely used. VANs do not support direct communication between businesses. Instead, businesses have to upload and download messages asynchronously from VANs. VANs provide a persistent mailbox system where every partner has a dedicated mailbox storing the electronic

messages addressed to it. Based on their behavior VANs are an asynchronous network for exchange of messages. In addition (“value added”), they provide services like storage, backup, and billing.

Through the emergence of VANs, business-to-busi- ness (B2B) integration was born (Bussler, 2003). VANs made a big difference in competitiveness since businesses could rely on the extreme high speed of electronic data transmission compared to paper-based communication through postal services. Different industries embarked on B2B integration through, at that time, a new form of communication.

It became immediately apparent that it is not advantageous at all for businesses to define their own message formats and send them over VANs. This would require a business to deal with all the different message formats defined by all its business partners if each one would provide its own message format. A significantly better approach was to standardize the message formats across businesses so that a business could use the same message formats across all its business partners from the same industry. In specific industries, message definition standards have been developed for over 30 years now. An example for the supply-chain industry is EDI (ASC, 2004), for the banking industry is SWIFT (2004), and for the insurance industry is ACORD (2004). These standards are called B2B standards and enable the fast integration of a business with others in the same industry. A business can comply with the standard and by that is ensured that the message exchange with the other partners is interoperable. The standardized message formats ensure interoperability.

While the message formats have been standardized, the technical software implementations for B2B communication have not. Every VAN is providing its own communication software for uploading and downloading the messages from the mailboxes. In order to allow messages to be automatically processed by back-end application systems, businesses had to integrate their VANs’ communication software into their information system environment. This back-end application system connectivity is necessary for retrieving and storing the data from the back-end application systems that are communicated with through the communication software. That meant that each business had to do custom implementation in order to make the B2B communication with its partners work.

Business-to-Business Integration

INTEGRATION TECHNOLOGY

In the late 1980s and early 1990s, the first B2B integration products appeared on the software market. These products were off-the-shelf software that did not require any custom coding by the businesses anymore in order to either connect to the VAN’s software or the back-end application system software. Instead, it could automatically link the VANs’ communication software and the back-end application systems (like, for example, enterprise resource planning, ERP, systems) within the businesses. Establishing B2B integration became more and more like a turn-key software solution instead of a custom coding task.

This automatic connectivity to back-end application systems is achieved through specialized software adapters that adapt the B2B integration product’s interface to the particular interface of the back-end application system (Apte, 2002). An adapter enables the B2B integration technology to insert as well as to extract data from the back-end application system. The benefit for the businesses was that they did not have to perform any custom coding anymore but could use prepackaged B2B integration software instead. That allowed buying the integration functionality without going through internal software development processes. A standard called J2EE Connector Architecture (JCA, 2004) allows software vendors to build standardized adapters. This contributes to the turn-key nature of integration products.

The main problem of B2B integration, besides integrating back-end application systems and the communication software to connect to VANs or the Internet, is data definition mismatches. An example of a data definition mismatch is that an address can be defined as a single string or as a structured record, where each address element like city or zip code is stored in a separate field. Mediation (or, synonymously termed, transformation) overcomes the data definition mismatch problem that exists between B2B standards and the data models of back-end application systems. The same piece of data can be represented very differently in a B2B standard and in a back-end application system. When data is extracted from the back-end application system in its format, it has to be reformatted to the message format of the B2B standard. This reformatting is called mediation (Bussler, 2003; Omelayenko & Fensel, 2001; Rahm & Bernstein, 2001). Not only the structure of the data might have to be changed (e.g., from a one-string representation into a structured record), but also the content representation (e.g., “Ireland” in one representation has to be replaced by “IRL” in another one). The change has to happen in such a way that the meaning of the data (data semantics) is not changed at all, i.e., the data semantics have to be absolutely preserved.

Not only data structures and vocabularies can mismatch, but also the message exchange sequences. For B example, while a back-end application system might send

one message and expects a return message back, a B2B interaction might have more messages, including acknowledgement messages, in order to establish an exactly once transmission. These differences in message exchanges are overcome by process mediation (Fensel & Bussler, 2002). Process mediation ensures that all communicating parties receive the messages in the sequence they require.

When businesses send and receive messages they have to make sure that they know their communication partners. Otherwise they might accept messages that are not sent by a contractually bound partner. If this is the case then messages might be processed that should not. On the other hand, messages must only be sent to partners, not to any other organization. In order to define partners as well as their specific properties, standards like collaboration protocol profile/ agreement (CPP/A) are established (ebXML, 2004).

Adaptation, data and process mediation, as well as partner management are the most essential concepts that integration technology has to implement.

CURRENT DEVELOPMENTS

The availability of software products for B2B integration lowered their price significantly, mainly because custom coding was not necessary any more. This enabled smaller business to participate in B2B integration and soon more businesses made use of the B2B integration technology then ever before.

In the mid-1990s XML (XML, 2004) emerged as viable technology and was picked up by software developers around the world. At the same time, the first B2B integration products based on XML as the message syntax were formed and appeared on the market. The promise was that the new technology was going to make the B2B integration task a lot easier and a lot cheaper. However, this was not the case as the same integration problems like adaptation, mediation, or partner management had to be solved, just on a different technological basis. Mediation, adapters, connectivity to network software, etc. all require a solution in the context of XML-based integration technology, too.

The Internet was available as a communication platform and many B2B integration products started using the Internet instead of VANs. That proved difficult since the open and unreliable Internet required the development of secure and reliable communication protocols. This is in contrast to VANs that are proprietary networks and their access is restricted to the VANs’ customers. In addition,

there was not asynchronous behavior of the network anymore. Instead, businesses had to communicate directly with each other. This required sufficient uptime to avoid communication errors due to unavailability.

Recently new B2B integration standards like RosettaNet (2004), cXML (2004), and ebXML (2004) have appeared. These use XML as the syntax for defining message types. However, XML did not deliver on the promise that standards became better or easier to use. The promise was delivered on the assumption that a commonly accepted message syntax will make a significant difference. Instead, the contrary happened. Because it was so easy to define message types in XML, too many were created, quickly contradicting the purpose of standards as such. Instead of less variety of message types, a huge number appeared. The flurry of proposed XML message standards made potential customers wonder about how these are going to be managed in the long run. Consequently, customers held back in investing into XML-based B2B technology and continued to use VANs instead.

XML and the formats used earlier for B2B standards do not capture the semantics of the data, just the structure (syntax) of the data. Because of this situation it is not possible for the B2B integration technology to semiautomatically or fully automatically perform the mediation. Instead, a developer has to develop the rules that define the mediation by hand. While this is a possible solution, manual encoding of the rules often leads to severe mistakes in the B2B communication.

Independent of its usefulness, once XML was “discovered” it became clear that XML messages can be sent through HTTP connections. The sending of XML messages through Internet technology is called Web services. Prominent standards in the space are SOAP (2004) and WSDL (2004). Both together allow defining basic and single message exchanges between a client and a server. Soon it was discovered that single message exchanges are insufficient for serious communication patterns between businesses. Several so-called process standards try to address this like BPEL (2004), ebXML BP (2004), and WSCDL (2004) as well as many research groups.

FUTURE TRENDS

The advent of Semantic Web technology promises to improve the overall situation significantly, especially providing solutions for the mediation problem. Ontology languages like RDF (2004), RDFS (2004), and OWL (2004) allow capturing semantics about data. Message formats can be defined with ontology languages not only describing the syntax but also the semantics. Once the semantics are formally captured, the mediation problem can be addressed a lot better. This is possible since the semantics

Business-to-Business Integration

are formally denoted and the integration technology can infer from this if two data definitions match or not. If they do, transformation between the two can be automatically achieved. If not, a human can be brought into the loop, helping to overcome the semantic mismatch. However, solving the transformation problem based on ontologies is a very recent development and no products can be bought yet that have this higher-level functionality.

A significant effort applying Semantic Web technology in order to solve the integration problems is the Web Service Modeling Ontology (WSMO, 2004). This ontology, which is developed by a significant number of organizations, uses Semantic Web technology to define a conceptual model to solve the integration problem that encompasses B2B integration. The main conceptual elements proposed are ontologies for defining data and messages, mediators for defining transformation, goals for dynamically binding providers, and Web services for defining the interfaces of communicating services. In order to define a specific B2B integration, the formal Web Service Modeling Language (WSML, 2004) is defined. This can be processed by a WSML parser. In order to execute B2B integration the Web Service Modeling Ontology Execution environment (WSMX, 2004) is developed. It serves as a runtime environment for integrations defined through WSML.

CRITICAL ISSUES OF B2B INTEGRATION TECHNOLOGIES

Despite the widespread use of B2B integration in industry and governmental organizations, B2B integration technology is still an area of major product development efforts. Software vendors like BEA (2004), IBM (2004), Microsoft (2004), and Oracle (2004) continue to develop new products providing B2B integration functionality.

In recent years the scientific community picked up the topic of integration in the context of Web services (2004) and Semantic Web activities (Fensel & Bussler, 2002); see also future trends above.

Independent of the specific approaches in industry and academia, critical issues, as listed in Table 1, have to be addressed for the technology to work and for the research to make significant contributions.

CONCLUSION

Business-to-business (B2B) integration is absolutely essential for current businesses and organizations to not only stay competitive but also gain market share. Furthermore, the trend is going towards connecting all

enterprises electronically for the benefit of the enterprises as well as customers. Once all business are connected, all business interactions can be implemented as business messages, making the interactions as efficient as possible.

Ultimately the Semantic Web technology will make the task of integrating businesses easy due to the semantic description of the message formats as well as choreographies and orchestration. Once semantically described, the goal of self-composing enterprises becomes feasible.

REFERENCES

ACORD (2004). ACORD Corporation. www.acord.org

Alonso, G., Casati, F., Kuno, H., & Machiraju, V. (2004).

Web services: Concepts, architectures and applications. Berlin, Germany: Springer-Verlag.

Apte, A. (2002). Java Connector Architecture: Building enterprise adaptors. Indianaopolis, IN: Sams.

ASC (2004). The Accredited Standards Committee (ASC) X12. www.x12.org

BEA (2004). BEA Corporation. www.bea.com

BPEL (2004). OASIS Web Services Business Process Execution Language. www.oasis-open.org/committees/ tc_home.php?wg_abbrev=wsbpel

Bussler, C. (2003). B2B integration. Berlin, Germany: Springer-Verlag.

cXML (2004). Commerce XML. www.cxml.org/

ebXML (2004). Electronic Business using eXtensible Markup Language (ebXML). www.ebxml.org

ebXML BP (2004). OASIS ebXML Business Process. w w w . o a s i s - o p e n . o r g / c o m m i t t e e s / t c _ h o m e . p hp?wg_abbrev=ebxml-bp

Fensel, D., & Bussler, C. (2002). The Web Service Modeling Framework WSMF. Electronic Commerce Research and Applications, 1(2).

IBM (2004). International Business Machines Corporation. www.ibm.com

JCA (2004). J2EE Connector Architecture. java.sun.com/ j2ee/connector/index.jsp

Microsoft (2004). Microsoft Corporation. www.microsoft.com

Omelayenko, B., & Fensel, D. (2001). An analysis of integration problems of XML-based catalogues for B2B e- commerce. In Proceedings of the ninth IFIP 2.6 Working Conference on Database (DS-9): Semantic Issues in E- commerce Systems. New York: Kluwer.

Oracle (2004). Oracle Corporation. www.oracle.com

OWL (2004). Web Ontology Language. www.w3.org/ 2001/sw/WebOnt/

Rahm, E., & Bernstein, P. (2001). A survey of approaches to automatic schema matching. VLDB Journal, 10.

RDF (2004). Resource Description Framework. www.w3.org/RDF/

RDFS (2004). Resource Description Framework Schema. www.w3.org/TR/rdf-schema/

RosettaNet (2004). Rosettanet. www.rosettanet.org

SOAP (2004). Simple Object Access Protocol (SOAP) 1.2. www.w3.org/TR/soap12-part1/ and www.w3.org/TR/ soap12-part2/

SWIFT (2004). Society for Worldwide Interbank Financial Telecommunication (SWIFT). www.swift.com

Web Services (2004). Web Services Activity. www.w3.org/ 2002/ws/

WSCDL (2004). Web Services Choreography. www.w3.org/2002/ws/chor/

WSDL (2004). Web Service Description Language (WSDL) 1.1. www.w3.org/TR/wsdl

WSML (2004). Web Service Modeling Language. www.wsmo.org/wsml

WSMO (2004). Web Service Modeling Ontology. www.wsmo.org

WSMX (2004). Web Service Modeling Execution Environment. www.wsmx.org

XML (2004). Extensible Markup Language. www.w3c.org/ XML/

Business-to-Business Integration

KEY TERMS

B2B Integration Technology: A software system that provides business-to-business integration functionality by sending and receiving messages and retrieving and storing them in back-end application systems.

Back-End Application System: A software system that manages business domain–specific data for businesses, e.g., enterprise resource planning (ERP) systems.

Business Partner: A business partner is a company or organization with which to engage in a business relationship, e.g., buyer, seller, or shipper.

Choreography: Choreography is the message exchange behavior that a business exposes in order to participate in a business relationship based on electronic message exchange.

Mediation: Mediation is the semantics-preserving transformation of a message in one message format into a message of a different message format that represents the same information.

Message Standard: A message standard defines the attributes as well as possible values that a business has to use in order to support interoperable electronic message exchange.

Orchestration: A business uses orchestration in order to define the electronic message interaction with other business partners in order to fulfill its obligations.

Value Added Network: A value added network is a company that provides network capabilities to business partners that want to exchange electronic messages. A VAN also provides storage, backup, security, and other services in order to provide more message exchange functionality.

Jean-Luc Hainaut

University of Namur, Belgium

Jean Henrard

REVER S.A., Belgium

Jean-Marc Hick

REVER S.A., Belgium

Didier Roland

REVER S.A., Belgium

Vincent Englebert

University of Namur, Belgium

INTRODUCTION

Designing and implementing a database comprising a few tables require a level of expertise that is readily found among most experienced users, provided they are somewhat keen on office productivity tools. Playing a dozen of hours with Microsoft Access should give clever and motivated users sufficient feeling and technical skill to develop small workable databases.

However, things quickly get harder for larger databases, particularly when they have to be integrated in different environments and to meet the needs of several applications. Very large and complex databases often include distributed heterogeneous components that have been developed by dozens of more or less skilled developers at different times, with different technologies and through different methodologies (or absence thereof). Mastering, integrating, maintaining, renovating, evolving, and migrating such complex systems and developing new components for them are highly complex engineering processes that are far beyond the capacity of individuals, whatever their experience and skill. Such problems cannot be addressed without the help of robust methodologies, supported by powerful tools. The following conservative figures illustrate the need for a disciplined, tool-based, approach to database engineering. Considering that (1) each conceptual entity type should ideally be accompanied by a two-page documentation giving its precise semantics and properties, (2) each entity type, together with its attributes and relationship types, translates into two tables on average, and

(3) each table is coded by 150 lines of SQL statements, including structural and active components; a standard conceptual schema comprising 1,000 entity types will

be described by a 2,000-page documentation and will produce 300,000 lines of SQL-DDL code. Since database engineering is a special branch of software engineering, the concept of database-centered computeraided software engineering tools—DB CASE tools for short—appears quite naturally. As a matter of fact, most CASE tools include a strong component intended to help developers design and produce (mainly relational) databases.

This paper discusses some important aspects and functions of DB CASE tools through the description of DBMAIN, a programmable general-purpose CASE tool that has been designed to support most complex engineering processes for large databases. In particular, it includes, besides standard functions, powerful capabilities for reverse engineering and federated database building.

BACKGROUND: DATABASE ENGINEERING REQUIREMENTS

Database engineering mainly deals with data structures, data and code related to one or several databases, all of which must be adequately documented in order to be exploited, maintained, and modified in a reliable and efficient way all along the lifetime of these databases. The core of the documentation of a database is a hierarchy of schemas, each of which describes in a precise way its information/data structures at a definite level of abstraction. Most design approaches agree on a fourlevel architecture comprising a conceptual schema, a logical schema, a physical schema, and code (Batini, Ceri, & Navathe, 1992). The conceptual schema describes the information structures that are of interest in