Implications on Application Development

Abstract

In the previous chapters, we introduced the ideas behind our new database architecture and their technical details. In addition, we showed that the in-memory approach can significantly improve the performance of existing database applications.

Self Test Questions

 

• 1. Architecture of a Banking Solution

  Current financials solutions contain base tables, change history, materialized aggregates, reporting cubes, indices, and materialized views. The target financials solutions contains...

  • (a) only base tables, reporting cubes, and the change history.

  • (b) only base tables, algorithms, and some indexes.

  • (c) only base tables, materialized aggregates, and materialized views.

  • (d) only indexes, change history, and materialized aggregates.

• 2. Criterion for Dunning

  What is the criterion to send out dunning letters?

  • (a) Bad stock-market price of the own company

  • (b) Bad information about the customer is received from consumer reporting agencies

  • (c) When the responsible accounting clerk has to achieve his rate of dunning letters

  • (d) A customer payment is overdue.

• 3. In-Memory Database for Financials

  Why is it beneficial to use in-memory databases for financials systems?

  • (a) Financial systems are usually running on mainframes. No speed up is needed. All long-running operations are conducted as batch jobs.

  • (b) Operations like dunning can be performed in much shorter time.

  • (c) Because of the high reliability of data in main memory, less maintenance work is necessary and labor costs could be reduced.

  • (d) Easier algorithms are used within the applications, so shorter algorithm run time leads to more work for the end user. Business efficiency is improved.

• 4. Connection between Object Fields and Columns

  Assume that “overdue” is expressed in an enterprise system business object by four fields. How many columns play a role to store that information?

  • (a) all columns of the table

  • (b) two columns

  • (c) four columns

  • (d) one column.

• 5. Languages for Stored Procedures

  Languages for stored procedures are...

  • (a) designed primarily to be human readable. They follow the spoken english grammar as close as possible.

  • (b) strongly imperative, the database is forced to exactly fulfill the orders expressed via the procedure.

  • (c) usually a mixture of declarative and imperative concepts.

  • (d) strongly declarative, they just describe how the result set should look like. All aggregations and join predicates are automatically retrieved from the database, which has the information “stored” for that.