OracleMaterializedviews & Hierarchical Data
Download as PPTX, PDF1 like931 views
The document discusses using materialized views to store and retrieve hierarchical data. It describes using an adjacency list to store location data like country-state-city in a single table. This allows variable depth data to be stored without changing the data model. However, queries to find descendants can be slow. A better approach is to use a closure table materialized view, which stores all ancestor-descendant relationships and enables faster retrieval, though uses more space. The materialized view would be refreshed periodically to recreate the closure table based on changes to the adjacency list table.
OracleMaterializedviews & Hierarchical Data
- 1. Oracle Materialized Views For Hierarchical Data Storage And Retrieval.
- 2. Materialized Views Application Materialized views is well known concept to any oracle pl/sql enthusiast. Lets look at a case study where materialized views are used to achieve the desired result with the expected performance. Storage and Query of Hierarchical Data: Any programmer would have invariably come across the problem of storage and retrieval of data that share a hierarchy among themselves. The most common would be storing location data as in Country>>State>>City. Lets assume for this discussion that a record/node has only one parent. One way to store this data is to have separate table structure for each level i.e. Country, state, city etc. However this method may not be suitable for a rapidly changing system. Let’s say a new country gets added which has further segregation like "Country>>State>>City>>County”. Hence to represent the data one has to add a new table County to the data model in the current design to be able to store the data. Needless to say that one also has to change the retrieval query joins to bring in the new data. An approach to the above problem can be , the above data can be stored in a single table with every record having a reference to its parent record. This approach of representing a tree is commonly known Adjacency list as the parent-child are adjacent to each other.
- 3. Adjacency List For Location/Place This structure takes care of the variable depth problem of the tree. Hence now data of any depth can be stored without creating new tables to the data model. Another example would be the reporting structure of an employee. A junior employee may have a long chain of supervisors going up to the CEO, where as a CEO may report to only one person.
- 4. The previous slide structure while adding flexibility does introduce some limitations, most of which can be worked around but at the cost of performance. While queries that involves immediate children, like finding the states in countries or cities in State are very fast, things starts to get messy when one needs to find all the descendants of a node. May be one can use CONNECT BY clause with SYS_CONNECT_BY_PATH to achieve it. But that will need more computation and string comparisons. A more elegant approach would be to make use of Closure Tables to represent the tree. A closure table stores, as records, pair of nodes that have an ancestor/descendant relationship irrespective of the depth or level of the nodes in the tree.
- 5. Closure Table For Location/Place
- 6. Hence while adjacency list is more intuitive, closure table performs better for data retrieval of course with some space usage overheads. Now to have the best of both worlds , one may use the adjacency list for accepting data from the User Interface for OLTP systems or by data uploads in DSS systems. Then a materialized view could be used to create the Closure table over the adjacency list table. Every time data is loaded , the materialized view can be refreshed to recreate the closure table. The closure table is used in the joins with other tables in the queries.