Das PLSQL Package DBMS_DEVELOPER bietet eine für Entwickler einfache Möglichkeit sich die Metadaten für Datenbank Objekte wie Tabellen und Indizes im JSON Format abzuholen. Bisher konnte man dies mit dem Package DBMS_METADATA erledigen, allerdings liefert dieses nur DDL oder XML und kein JSON Format. Nicht jeder Datenbank Administrator hat den Zugriff auf DBMS_METADATA für Entwickler überhaupt erlaubt.
Mittels DBMS_DEVELOPER kann man für folgende Objekte die Metadaten im JSON Format erhalten:
- Tabellen oder Views die der Benutzer auch lesen (SELECT oder READ) darf.
- Indizes auf Tabellen, die der Benutzer sehen kann.
- Synonyme, die der Benutzer sieht.
Aktuell gibt es im Package nur eine Funktion: GET_METADATA:
DBMS_DEVELOPER.GET_METADATA (
name IN VARCHAR2,
schema IN VARCHAR2 DEFAULT NULL,
object_type IN VARCHAR2 DEFAULT NULL,
level IN VARCHAR2 DEFAULT 'TYPICAL'
etag IN RAW DEFAULT NULL)
RETURN JSON;Die ersten drei Parameter sind eigentlich selbsterklärend. Mit dem LEVEL definiert man, wie ausführlich die Information im JSON Dokument sein soll. Dafür stehen die Werte BASIC, TYPICAL und ALL zur Verfügung. Mit BASIC bekommt man nur die notwendigsten Informationen die Spaltennamen und Datentypen bei Tabellen. Bei TYPICAL werden noch weitere Metadaten, beispielsweise Eigenschaften von Views und Constraint Informationen ausgegeben. Mit ALL erhält man weitere Details wie beispielsweise die vergebenen Objektberechtigungen
Das ETAG ist ein eindeutiger Identifier für die Version des JSON Dokuments. Damit kann man verifizieren, ob zwei Versionen eines JSON Dokument ident sind (bzw. ob sich seit der Erstellung des ersten Dokuments etwas geändert hat).
Beispielaufruf
Hier ein Beispiel für die Tabelle Employees im HR Schema mit der Einstellung BASIC:
set heading off long 1000000
select JSON_SERIALIZE (DBMS_DEVELOPER.GET_METADATA(name => 'EMPLOYEES', LEVEL => 'BASIC') pretty) from dual;
{
"objectType" : "TABLE",
"objectInfo" :
{
"name" : "EMPLOYEES",
"schema" : "HR",
"columns" :
[
{
"name" : "EMPLOYEE_ID",
"notNull" : true,
"dataType" :
{
"type" : "NUMBER",
"precision" : 6
}
},
{
"name" : "FIRST_NAME",
"notNull" : false,
"dataType" :
{
"type" : "VARCHAR2",
"length" : 20,
"sizeUnits" : "BYTE"
}
},
{
"name" : "LAST_NAME",
"notNull" : true,
"dataType" :
{
"type" : "VARCHAR2",
"length" : 25,
"sizeUnits" : "BYTE"
}
},
{
"name" : "EMAIL",
"notNull" : true,
"dataType" :
{
"type" : "VARCHAR2",
"length" : 25,
"sizeUnits" : "BYTE"
}
},
{
"name" : "PHONE_NUMBER",
"notNull" : false,
"dataType" :
{
"type" : "VARCHAR2",
"length" : 20,
"sizeUnits" : "BYTE"
}
},
{
"name" : "HIRE_DATE",
"notNull" : true,
"dataType" :
{
"type" : "DATE"
}
},
{
"name" : "JOB_ID",
"notNull" : true,
"dataType" :
{
"type" : "VARCHAR2",
"length" : 10,
"sizeUnits" : "BYTE"
}
},
{
"name" : "SALARY",
"notNull" : false,
"dataType" :
{
"type" : "NUMBER",
"precision" : 8,
"scale" : 2
}
},
{
"name" : "COMMISSION_PCT",
"notNull" : false,
"dataType" :
{
"type" : "NUMBER",
"precision" : 2,
"scale" : 2
}
},
{
"name" : "MANAGER_ID",
"notNull" : false,
"dataType" :
{
"type" : "NUMBER",
"precision" : 6
}
},
{
"name" : "DEPARTMENT_ID",
"notNull" : false,
"dataType" :
{
"type" : "NUMBER",
"precision" : 4
}
}
]
},
"etag" : "C2BAA871FC47AF364A441F1DCBDBB9D8"
}
Hier kommt wirklich nur das wesentlichste zurück. Mit TYPICAL bekommt man schon deutlich mehr (aus Platz- und Leesbarkeitsgründen, hier nur eine Aufzählung:
- Für jede Spalte, ob diese Teil eines Constraints ist
- Für die Tabelle, die wichtigsten Statistiken wie LastAnalyzed, numRows, sampleSize, avgRowLen,…
- Es werden alle Indizes inkl. den Index Objekt Statistiken mit ausgegeben.
Bei ALL kommen dann noch weitere Informationen wie beispielsweise die folgenden dazu:
- Für jede Spalte die Column Statistiken
- Partitioning Informationen
- Kommentare
- etc.
In den meisten Fällen werden die Entwickler mit den BASIC Informationen zufrieden sein.