The approach to database modelling

Before reading this chapter, read Chapter 1 - Welcome on Board, and Chapter 2 - Architecture that introduce fundamental concepts on Board databases.

Implementing the multidimensional database is the final phase of a broader project implementation process that starts with gathering and analyzing end-user requirements and results in defining the multidimensional model specifications. Board’s characteristics deliver a strong effectiveness while implementing your Management Intelligence project. Thanks to the flexibility, adaptability and scalability of the multidimensional database you can adopt a highly iterative development approach by quickly cycling through the life-cycle phases multiple times.

Let’s consider a traditional waterfall model, the life cycle phases are:

Requirements analysis à design à implementation à integration and testing à delivery à feed-back (and restart from top)

Board considerably shortens all phases, from ”implementation” to ”feed-back”.


The main phases of a database implementation process are


A typical characteristic of analytical applications is that requirements continuously change over time and as a consequence it is likely that you will frequently modify your multidimensional database model, adding new InfoCubes or entities, changing hierarchy structures, adding new data sources and so on. Although some design changes can be implemented online, on the database currently available to end-users, it is strongly recommended that you work on an off-line copy of the database (by off-line we mean a database that cannot be accessed by end-users) when implementing fundamental changes such as adding new entities, InfoCubes or changing a hierarchy structure.

For safety and robustness reasons, two separate environments should be created, one for production and one for development. The production environment usually is a server where the Board Server to which end-users connect is installed and where the public Board databases and Capsules are located. The development environment can be the administrator’s PC having a Board developer license and may be simple stand-alone installation.

Creating two separate environments protects both parties (the end-users and the developer) from interfering with one another’s work; end-users will not interfere with your work as you develop new multidimensional objects and similarly end-users will not be affected by development tasks that could lock a database or absorb a lot of the server’s resources. For example a database is locked while a hierarchy is loaded through a Datareader, during this time users are denied access to the database.