The database-as-a-service paradigm in the cloud (DBaaS) is becoming increasingly popular. Organizations adopt this paradigm because they expect higher security, higher availability, and lower and more flexible cost with high performance. It has become clear, however, that these expectations cannot be met in the cloud with the traditional, monolithic database architecture. This paper presents a novel DBaaS architecture, called Socrates. Socrates has been implemented in Microsoft SQL Server and is available in Azure as SQL DB Hyperscale. This paper describes the key ideas and features of Socrates, and it compares the performance of Socrates with the previous SQL DB offering in Azure.

Data mart consolidation does schema as well as data integration of data marts so as to produce a single physical data mart/warehouse. This implies that multiple data marts must exist. Our proposal is to integrate requirements specifications of data marts. This upstream integration saves the effort of downstream activities performed when data marts are independently developed and then integrated. Without this integration, we get a new problem of loss of business control. Our integration approach is organized in five steps.

Abstract Traditionally, data warehouse requirements engineering is oriented towards determining the information contents of the warehouse to be. This has resulted in a de‐emphasis of the functional perspective of data warehouses. Consequently, it is difficult to specify functions needed for computing business indicators. Our approach aims to elicit needed business indicators from organizational decision makers. Thereafter, indicator hierarchies are built. Then we associate functions with business indicators of the hierarchy. These functions are visualized as use case diagrams. To do this, we extend these diagrams to allow for actor aggregation in addition to actor specialization. Further, we introduce the ‘estimated from’ relationship between use cases, in addition to the ‘extend’ and ‘include’ relationships of UML. We illustrate our proposals with an example.

Situational method engineering can be done using either method module based or intention-architecture, MIA, based approaches. The latter is organized in the three stages of requirements, design, and construction engineering. We focus here on elaborating the relationship between design and construction engineering of the MIA approach. The key concept in design engineering is that of method architecture. We define method architecture as an abstraction of the common properties of methods and propose a method architecture meta-model. At the construction engineering level, we represent a method as a method organisation. Method architecture can be implemented as one or more method organisations. We show that the MIA based approach is generic and can be used to engineer information systems development methods as well as business process models.

Although procuring enterprise resource planning systems from commercial suppliers is becoming increasingly popular in our industry, fitting those systems to customer requirements remains problematic. The authors propose an approach for matching ERP system functionality to customer requirements. The assumption made is that the ERP system postulates a set of requirements that are worth eliciting from the ERP documentation as abstractions of the ERP system functionality. Then, the requirements engineering process is a process that matches the ERP set of requirements against organisational requirements. Those requirements that match, perhaps after adaptation, identify the ERP system features and their adaptations, that must be included in the ERP installation. To facilitate the matching process, the ERP requirements and the organisational requirements are both expressed using the same representation system, that of a map. The paper presents the map representation system and the matching process. The process is illustrated by considering the Treasury module of SAP and its installation in the financial management of a cultural exchanges unit.

Despite a constant improvement in automation in CASE environments, the level of guidance provided to developers is still low, especially in the early phases of information systems engineering. We argue in this paper that a more effective guidance to requirements engineers can be based on a process meta-model which allows us to deal with a large variety of situations in a flexible, decision-oriented manner and supports different levels of granularity in decision making. The paper presents the process guidance meta-model and shows how it can guide the requirements engineer punctuality-to take the right decision in the adequate situation-as well as globally, to control the decision flow.>

A query facility to a network DBMS is described wherein it is possible to retrieve and update the data in the database. Apart from the existential and universal quantifiers, some additional quantifiers, which are found useful in a database environment, are provided for. A facility, called the discourse facility, by which a set of related queries can be asked is also explained. In this, the data retrieved in a query can be used in subsequent queries.

A practical method for scheduling multiple users is described here. This has been done by defining two resource lists, a retrieval list and an update list, which contain the resources required for retrieving and updating the database, respectively. For each user these lists are built at the time of the definition of a subschema. The resource lists thus prepared are used to schedule the users in a suitable manner.

A manner in which new types can be defined in a network model of data is considered. The technique described enables the construction of new record types and new coset types using those defined in the schema. The new types define explicitly the hidden relationships between the data structures of the schema. The rules for constructing both these types are given and their properties are considered.

A range of integrity constraints that can be specified on a schema expressed in the network model of data is presented. These integrity constraints can be of three kinds. The first, called value sets, define values which fields of a record type can take on. The second kind can be specified on a record type and the third kind can be specified on a set type. A mechanism which determines integrity constraints of a schema which are applicable to a subschema is described. It is required that all such constraints be explicitly stated in the subschema and that all constraints explicitly stated should be applicable to the subschema concerned. In order to state applicable constraints it may become necessary to include additional structure in the subschema. The implications of this additional structure are discussed.

Admin is a database management system based on the network model of data. It has a number of data definition facilities over and above those provided by the CODASYL DDLC. It is possible to define a schema and build subschemas on top of it. Further, one can build another layer of subschemas on any given subschema, subject to the restriction that a total of 63 subschemas are built on top of any schema. It is also possible to define one's own value sets from which fields of records can take on values. Further, one can build ‘new’ corecs over currently existing corecs. Similarly, one can also define new cosets between any pair of corec types currently existing in a subschema. There is also an authorization and access control specification available with Admin. All these features are described herein.

In this paper, a DBMS called Samhita is described. Samhita is based on the network model of data. The prime motivation behind Samhita was to re-examine the notion of currency indicators with a view to minimising side effects in currency setting and to introduce the concept of multiple positioning in the data base. An attempt was also made to impose a discipline on data base definition by restricting the network model itself. It is expected that as a result of these efforts a methodology of programming for data bases will emerge.

Abstract In Sangrah, exception conditions of CODASYL have been replaced by fatal errors and by boolean valued functions. Fatal errors can occur either because all the preconditions necessary for a DML statement are not fulfilled or because of the state of the data base at the time when this statement is executed. A mechanism which anticipates the former situation and thereby saves the data base from corruption is presented. Another recovery scheme which protects the data base from an abnormal termination of the user program is also described. This scheme uses a differential file.