ConceptBase offers support for maintaining externally materialized views incrementally, but there is currently no automatic support for materialization of views without ECArules. Materialization of views means, that deduced information is stored in the object base. We provide here an example, how to materialize and maintain simple views.
Class Employee with
attribute
salary : Integer
end
View EmployeeWithHighSalary isA Employee with
constraint
c : $ exists i/Integer (this salary i) and (i > 100000) $
end
Class EmployeeWithHighSalary_Materialized
end
The view EmployeeWithHighSalary
contains all employees who earn more than 100.000.
The class EmployeeWithHighSalary_Materialized will
contain the same employees. This implemented by the following
ECArules:
ECArule EmployeeWithHighSalary_Materialized_Ins with
ecarule
er : $ x/Employee
ON Tell(In(x,Employee))
IF new(In(x,EmployeeWithHighSalary))
DO Tell(In(x,EmployeeWithHighSalary_Materialized)) $
end
ECArule EmployeeWithHighSalary_Materialized_Del with
ecarule
er : $ x/Employee
ON Untell(In(x,Employee))
IF In(x,EmployeeWithHighSalary)
DO Untell(In(x,EmployeeWithHighSalary_Materialized)) $
end
ECArule EmployeeWithHighSalary_Materialized_Ins_salary with
ecarule
er : $ x/Employee y/Integer
ON Tell(A(x,salary,y))
IF new(In(x,EmployeeWithHighSalary))
DO Tell(In(x,EmployeeWithHighSalary_Materialized)) $
end
ECArule EmployeeWithHighSalary_Materialized_Del_salary with
ecarule
er : $ x/Employee y/Integer
ON Untell(A(x,salary,y))
IF In(x,EmployeeWithHighSalary)
DO Untell(In(x,EmployeeWithHighSalary_Materialized)) $
end
The first rule checks, if the employee belongs to the view, when the employee was inserted. Note, that we don't use the constraint of the view in the ECArules, we just reuse the view definition here. The second rule does the same for deletion of employees.
The third rule checks, if the employee is an instance of the view class, when the attribute salary was inserted. Again, the fourth rule does the same for deletion of the attribute.
If the number of employees is large it is more efficient to ask for the instances of materialized than to evaluate the view. However, if updates occur quite often, materialization is not good, because materialized view must be maintained for every update transaction.