semantic relation

VLDB Journal 2 (4) Storey: Understanding Semantic Relationships 459 object (e.g., Assignment can be thought of as an aggregate of Project and Employee) or an attribute (e.g., Employee has Name). Recently, a number of systems have been developed that attempt to automate the database design process, among which are SECSI (Systrme en Conception de Systrme d& 39;Informations; Bouzeghoub et al., 1985); the View Creation System (Storey, 1988; Storey and Goldstein, 1988; 1990a; 1990b; AVIS (Automated View Integration System; Wagner, 1989); OICSI (Rolland and Proix, 1986; Cauvet et al., 1988; Proix and Rolland, 1988); and CARS (Computer Aided Requirements Synthesis; Demo and Tilli, 1986). 3 Some of these systems rely on the user (who may or may not be a database design expert) to identify and provide, as input, the relationships that one would find, for example, in an entity-relationship model of the user& 39;s application. Most of the systems deal with the input on a syntactical basis only; that is, they simply treat the names of the entity types and verbs that appear in relationships as strings of characters. They do not have sophisticated means for capturing much information about an application beyond that provided by the user. There are various ways in which information about semantic relationships could aid an automated tool for database design. First, many database design tools are interactive where the user is either a database designer or, possibly, an end-user. If a user were to provide, as input, a (semantic) relationship of the form, A verbphrase B, a database design system could "understand" the design impact of the relationship and make inferences about it. This is easily demonstrated by the well-known class inclusion or/s-a relationship. If a user indicates that Managers are Employees, for example, then a system could automatically delete from Manager any (non-key) attributes that are found in Employee because Manager could "inherit" them from Employee. This minimizes redundancy that might appear in the design. Similarly, if the user provides, as input, the three relationships, Foreman is-a Manager, Manager is-an Employee, and Foreman is-an Employee, then the system can ignore the latter relationship because it is redundant. These types of inferences are possible because the semantics of is-a relationships are well-understood. Based on what a system "knows" about semantic relationships (from the analysis carried out in this article), it could make certain design decisions. For example, if a member-collection relationship (such as Employee member-of Committee) is identified, the system could infer that a priori attributes (e.g., "max ") and derived attributes (e.g., "average-age") are applicable and prompt the user to provide them. Dahlgren (1988) distinguishes between things which are "typical" and "inherent" in the real world. Typical things usually take place (e.g., managers usually prepare budgets). Inherent properties are always true (e.g., employees have names and addresses). One would expect a system with knowledge about the real world to "know" these types of things. Some could be captured using case relationships 3. For an overview of these and others, see Lloyd-Williams (1991); Ram (1989); Storey and Goldstein, in press; Storey, 1993, in press). 460 (discussed later). As an extreme situation, suppose that the system had a dictionary of semantic relationships that included applications found to be most useful in previous design sessions. Then the system could suggest, for example, an Employee entity type through which various kinds of employees were related by is-a relationships (Manager is-an Employee, Secretmy is-an Employee, etc.). Unfortunately, there are not, as yet, adequate capabilities for database design systems to capture such real world knowledge (Storey, 1992a). Some work, however, has been carried out. The SECSI system