Databases Reference
In-Depth Information
zweimal vertreten. Bei Datenbanken kann es aus folgenden Gründen Namens-
konflikte bei Tabellen geben:
Es gibt mehr als einen Datenbankadministrator, möglicherweise in verschie-
denen Firmenbereichen. Namenskonventionen oder Absprachen bei jedem
create table
erschweren die Arbeit.
SQL-Skripte von Fremdfirmen werden als Teil einer Datenbanklösung einge-
spielt. Weil die zugehörige Anwendungs-Software die Tabellen unter ihrem
Namen anspricht, können Namenskonflikte nicht durch einfache Umbenen-
nung gelöst werden.
In Java werden Namenskonflikte durch Pakete bereinigt, in SQL mit so genann-
ten
Schemata
. Zu jeder Tabelle gibt es ein Schema. Wir haben bereits explizit mit
Schemata gearbeitet, als wir in Abschnitt 2.7 den Systemkatalog abgefragt haben:
select
*
from information_schema.tables
Hier ist
information_schema
der Schemaname und
tables
der Tabellenna-
me. Für jeden Anwender gibt es ein Standardschema. Werden Tabellen aus die-
sem Schema verwendet, muss der Name des Schemas nicht explizit angegeben
werden. Viele Systeme legen für jeden Anwender ein Schema mit dem Namen
des Benutzers als Standardschema an, H2 verwendet für alle Anwender das Stan-
dardschema
public
. Die Anweisung
select
*
from personen
ist äquivalent zu
select
*
from public.personen
Immer, wenn wir eine Tabelle mit
create table
ohne Angabe des Schemas er-
zeugen, wird sie dem Standardschema zugeordnet. Wir können selbstverständlich
ein anderes Schema explizit angeben:
create table information_schema.personen(
id int primary key,
name varchar(20) not null
)
Wenn wir viele Anweisungen für Tabellen schreiben, die nicht zum Standardsche-
ma gehören, können wir das Standardschema in H2 auch - maximal bis zum Ende
der Verbindung mit dem RDBMS - ändern:
set schema information_schema;
