View source | View content page | Page history | Printable version   

Projects:Operate Database/Specifications


Operate Database - Functional Specifications



The purpose of this project is to enable Openbravo's interface to operate database structure directly, this is, once structure is defined in Application Dictionary it should be possible to persist it in DB.

This will make easier the administrator user experience because it will not be necessary to use an external database client in order to create objects in database.

Anyway, current workflow will still available: it will be possible to create object in DB and afterwards import them into Openbravo.

Additionally wizards should be added in oder to facilitate the most commons actions in database objects modelization.


It affects Openbravo's Application dictionary, the way objects are created there and how they are defined.


Design Considerations





Functional Requirements

User roles & profiles

Business process definition

The workflow is as follows:

User stories

Functional requirements based on business processes

User Interface Mockups

Technical Requirements

XML model files creation

A process, callable from Application Dictionary interface, creates the required XML files to save the model. This is performed creating DBSourceManger objects and persisting them.

If approach 2 is implemented, when editing an existing object, the XML file should be the one from the model plus the non-standard elements. This non-standard elements are those that cannot be saved in application dictionary.

Database synchronization

Once XML files have been created, the actual DB objects are modified to fit the new model.

With approach 1, this process could be called automatically after the XML files creation.

With approach 2, before synchronizing database it would be necessary to allow user to edit manually this file in order to add/modify non-standard elements.

Application dictionary synchronization

Current synchronization processes from database to application dictionary must be reviewed in order to adapt them to the new requirements.


Ideally wizards should be created to help user edit/create objects.

There are two possible approaches for these wizards:

At least a wizard for tables should be created, additionally it could be useful to have wizards for triggers, functions and procedures.

Table wizard

This wizard will be used for table creation/modification.

It will automatically:

Data Requirements

In order to be able to create database objects from application dictionary following approach 1, it is necessary to save in application dictionary all required data, currently it is not done.

For approach 2 it should be decided which data is the standard that must be in dictionary and which is not.

Anyway, the elements to take into account are:


Tables are defined in the AD_Table and AD_Column dictionary tables. This is what currently is not defined (or at least not completely).


Additionally is required to ensure that current values that are supposed to match with db values actually match, this includes these fields: isMandatory, defaultValue...

Amount 12 NUMBER 262
Assignment 33 NUMBER 3
Binary 23 BLOB 2
Button 28 CHAR 149
Button 28 NUMBER 8
Button 28 VARCHAR2 1
Color 27 NUMBER 2
Date 15 DATE 222
DateTime 16 DATE 1053
General Quantity 800019 NUMBER 1
ID 13 NUMBER 454
Image 32 NUMBER 3
Integer 11 NUMBER 313
Link 800101 VARCHAR2 1
Link 800101 NVARCHAR2 1
List 17 CHAR 273
List 17 VARCHAR2 8
List 17 NVARCHAR2 1
Memo 34 NVARCHAR2 5
Memo 34 VARCHAR2 2
Number 22 NUMBER 206
PAttribute 35 NUMBER 16
Price 800008 NUMBER 58
Quantity 29 NUMBER 131
Search 30 NUMBER 509
String 10 NVARCHAR2 1029
String 10 VARCHAR2 84
String 10 CHAR 28
String 10 NCHAR 5
Table 18 NUMBER 1273
Table 18 VARCHAR2 41
Table 18 CHAR 2
TableDir 19 NUMBER 2013
Text 14 NVARCHAR2 202
Text 14 VARCHAR2 14
Text 14 CHAR 1
Text 14 CLOB 1
Time 24 DATE 12
YesNo 20 CHAR 1144
YesNo 20 VARCHAR2 1

Currently indexes are not defined in application dictionary. It would be necessary a new pair of tables (ad_index, ad_index_column) depending on ad_table to manage them. Notice that both tables are necessary because in current model there are indexes with more than one column.


Currently these elements are not defined in the dictionary.


Currently these elements are not defined in the dictionary.


Currently these elements are not defined in the dictionary.

Non-Functional Requirements

Open Discussion Items

Closed Discussion Items

Known Issues

Retrieved from ""

This page has been accessed 5,735 times. This page was last modified on 8 June 2012, at 05:29. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.