Feature model configuration is known to be a hard, error-prone and time-consuming activity. This activity gets even more complicated when it involves multiple stakeholders in the configuration process. Research work has proposed approaches to aid multi-stakeholder feature model configuration, but they rely on systematic processes that constraint decisions of some of the stakeholders. In this paper, we propose a novel approach to improve the multi-stakeholder configuration process, considering stakeholders' preferences expressed through both hard and soft constraints. Based on such preferences, we recommend different product configurations using different strategies from the social choice theory. We conducted an empirical study to evaluate the effectiveness of our strategies with respect to individual stakeholder satisfaction and fairness among all stakeholders. Results indicate that particular strategies perform best with respect to these aspects.

No abstract available.

We are currently designing a class modification methodology for GemStone. We describe the current status of the design. We choose from two basic approaches and then introduce those aspects of GemStone necessary for an understanding of the paper. After defining a set of invariants for GemStone databases, we discuss specific class modification operations in terms of maintaining these invariants. We next discuss several issues that impact class modification. These issues include concurrency and authorization, and lead to difficult choices.

We describe the results of developing the GemStone object-oriented database server, which supports a model of objects similar to that of Smalltalk-80. We begin with a summary of the goals and requirements for the system: an extensible data model that captures behavioral semantics, no artificial bounds on the number or size of database objects, database amenities (concurrency, transactions, recovery, associative access, authorization) and an interactive development environment. Object-oriented languages, Smalltalk in particular, answer some of these requirements. We discuss satisfying the remaining requirements in an object oriented context, and report briefly on the status of the development efforts. This paper is directed at an audience familiar with object-oriented languages and their implementation, but perhaps unacquainted with the difficulties and techniques of database system development. It updates the original report on the project [CM], and expands upon a more recent article [MDP].

Article Free Access Share on Relaxing the universal relation scheme assumption Authors: Jacob Stein View Profile , David Maier View Profile Authors Info & Claims PODS '85: Proceedings of the fourth ACM SIGACT-SIGMOD symposium on Principles of database systemsMarch 1985 Pages 76–84https://doi.org/10.1145/325405.325415Published:25 March 1985Publication History 7citation83DownloadsMetricsTotal Citations7Total Downloads83Last 12 Months12Last 6 weeks2 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

Users of a relational database must explicitly navigate between relations in order to establish a connection among a set of attributes spanning several relation schemes. While a universal scheme interface to a relational database provides users with automatic navigation, it usually imposes on the database a unique role assumption. This assumption requires every attribute name to represent a unique role in the database, so that connections among sets of attributes are unambiguous.

In universal scheme interfaces to relational databases, an attribute name must represent a unique role in the database, so that the connection among a set of attributes is unambiguous. A drawback to this requirement is that several attributes can represent the same underlying class of of entities, but the relationship among those attributes is not captured in the database scheme. As our method for relating attributes uses natural joins, some semantically meaningful.

One of the main goals of database systems, relational systems in particular, is to provide a degree of physical data independence for users and programs. Users should not need to know the exact physical storage structures to use the database, and should be protected from changes in those structures. We attempt to go a step further, to logical data independence. We want an interface to a relational database where a user need not be concerned with how the data has been partitioned into various relations. The natural relation schemes to be used, from a semantic point of view, may be decomposed in the database for normalization or redundancy reasons. Our approach essentially loads all the semantics onto the attributes. In our query language tuple variables are not bound to specific relations. Rather, the system uses the set of attributes, say X, that appear in a query with a tuple variable, say t, to combine the database relations to form a single relation with scheme X over which t ranges. We describe our method for constructing such a relation given the associated set of attributes X. When tuple variables are bound implicitly, the logical connectives 'and', 'or', and 'not' take on 'semantic overtones' since they can affect the binding. We discuss the motivation behind the chosen semantics for these connectives. Our goal is a powerful, yet concise, query language with natural semantics.