Bir objeye bağlı (dependent) objeleri bulmak için data dictionary viewlerinden dba_dependencies view’ini sorgulayabiliriz. Oracle’ın örnek schemalarından HR schemasındaki employees tablosu için bunu yapalım:
SQL> SELECT *FROM dba_dependencies
WHERE referenced_owner = ‘HR’ AND referenced_name = ‘EMPLOYEES’;
Bu sorgunun çıktısı schema üzerinde değişiklik yapılmadıysa şu şekilde olacaktır:

OWNER,NAME
HR,EMP_DETAILS_VIEW
HR,SECURE_EMPLOYEES
HR,UPDATE_JOB_HISTORY
OE,EMPLOYEES

Bu basit sorgu ile kolaylıkla hr.employees tablosuna bağlı olan objeleri listeledik. DBA_DEPENDENCIES viewi olmasına rağmen, Oracle bağlı objelerin bulunması için bize yardımcı bir araç olarak DEPTREE_FILL prosedürünü sunmaktadır. Bu prosedür ve prosedürün çalışmacı için gerekli tablolar ve viewler UTLDTREE.SQL adlı scripte yer alır. Scripti bir kez çalıştırdıktan sonra DEPTREE_FILL prosedürü kullanmaya başlayabiliriz.

$ cd $ORACLE_HOME/rdbms/admin
$ sqlplus / as sysdba @utldtree.sql

DEPTREE_FILL prosedürü 3 adet parametre alır. Birinci parametre objenin tipi, ikincisi objenin sahibi/scheması, üçüncüsü objenin ismidir. Bu bilgileri verdiğimizde DEPTREE_FILL, objeye bağlı olan diğer objeleri bulur. Prosedür çalıştıktan sonra deptree ve ideptree viewlerini kullanarak sonucu görüntüleyebiliriz:

SQL> EXEC deptree_fill( ‘table’ ,’hr’,'employees’);
SQL> SELECT * FROM deptree;
NESTED_LEVEL,TYPE,SCHEMA,NAME,SEQ#
———————————————————
0,TABLE,HR,EMPLOYEES,0
1,VIEW,HR,EMP_DETAILS_VIEW,22
1,TRIGGER,HR,SECURE_EMPLOYEES,24
1,TRIGGER,HR,UPDATE_JOB_HISTORY,25
1,SYNONYM,OE,EMPLOYEES,26
İlk sorgumuzda yazdığımıza benzer sadece biraz daha detay içeren bir sonuç elde ettik. Bu durumda kafamıza şu soru takılabilir: DBA_DEPENDECIES ile bağlı objeleri bulabildiğime göre neden DEPTREE_FILL prosedürünü kullanayım? Deptree_fill’i kullanmak için veritabanında bir script çalıştırılarak ek bir prosedür oluşturuluyor, ayrıca objeleri listelemek için tek sorgu yerine önce prosedür çalıştırılıp sonra view sorgulamız gerekiyor.
Bunun cevabı nested_level‘de gizli. Deptree_fill ile, bağlı objelerin, asıl objeye kaçıncı seviyeden bağlı olduklarını gösteren nested_level değerini bulabiliyoruz. Yani deptree_fill, bir birine direk olarak bağlı olmayan objeleri de bize gösterebiliyor. Örnekle açıklayalım:
CREATE VIEW hr.bolum_maas
AS
SELECT department_name, MAX(salary) en_yuksek
FROM hr.emp_details_view
GROUP BY department_name
Bu komutla hr.emp_details viewini kullanan bir başka view oluşturuyoruz. Bu view, emp_details’deki bilgilere göre dolayısıyla hr.employees tablosundaki bilgilere göre bize bir sonuç döndürecek. Bu nedenle bu viewin de hr.employees tablosuna bağlı olduğunu biliyoruz, ama dba_dependencies’i sorguladığımızda şu sonucu gelir:
OWNER,NAME
———————————-
HR,EMP_DETAILS_VIEW
HR,SECURE_EMPLOYEES
HR,UPDATE_JOB_HISTORY
OE,EMPLOYEES
Görüldüğü üzere son oluşturduğumuz view yok. Çünkü dba_dependencies sadece 1. dereceden bağlı olan objeleri gösteriyor. Bizim son oluşturduğumuz hr.bolum_maas ise sadece hr.emp_details’e bağlı göründüğünden sorgu sonucunda listelenmiyor.
Yeniden deptree_fill’i hr.employees için çalıştırıp, deptree viewini sorguladığımızda ise şu sonucu alıyoruz:
NESTED_LEVEL,TYPE,SCHEMA,NAME,SEQ#
———————————————————
0,TABLE,HR,EMPLOYEES,0
1,VIEW,HR,EMP_DETAILS_VIEW,22
1,TRIGGER,HR,SECURE_EMPLOYEES,24
1,TRIGGER,HR,UPDATE_JOB_HISTORY,25
1,SYNONYM,OE,EMPLOYEES,26
2,VIEW,HR,BOLUM_MAAS,23

Bu sonuç, dba_dependencies viewini sorgulamak yerine deptree_fill kullanmanın faydasını açıklıyor. Deptree_fill, hr.employees tablosuna bağlı tüm objeleri son oluşturduğumuz (Hr.bolum_maas) view dahil olmak üzere gösterdi. Eğer deptree_fill prosedürünü sys kullanıcısı ile çalıştırırsanız, objeyi kullanan cursorları da görebilirsiniz.