SQL 92 は、ANSI/ISO 準拠の 最新公式SQLで、SQL言語と、さまざまなインプリメンテーションに関する長い経験の集大成である。
FrontBase は、SQL 92のすべてを、実際にインプリメントした、初の主力産業向けデータベース・サーバである。これは、データベース・サーバで作業する際、とりたてて重要、というほどのことではないが、しかし、注意しておくべき２，３の最新事項の１つでもある。利用者が、おそらく最も混乱しやすいコンセプトは、SCHEMAに関する概念だろう。市場の製品の多くにおいて、SCHAMAという言葉が使われているにもかかわらず、このコンセプトをインプリメントしたものは、ほとんどない（少なくとも、SQL 92 的センスにおいて、である）。
実際、SCHEMAのトップには、CATALOGとよばれるレイヤーがある。SQL 92データベースは、いくつものCATALOGから成り立っており、それぞれは、SHEMAの数を保持している。１つのSCHEMAは、TABLE や VIEW、DOMAIN、COLLATIONなどなどのオブジェクト数を入れるコンテナのように見える。
CATALOGs
現在、FrontBaseは、データベースにおいて、あるCATALOGのサポートを提供している。このCATALOGは、データベース名を継承する。たとえば、もしMovies.fb という名前のデータベースを生成すると、カタログ名は、MOVIESとなるのだ。 このカタログ名は、常にデフォルトのカタログ名としてみなされるので、実際にCATALOGについて悩む必要はほとんどない。
SCHEMAs
上記に述べたように、カタログには、複数のSCHEMAを含めることができる。SCHEMAの所有者はユーザであり（以下で取り上げる）、所有権を持つユーザのみが、SCHEMAにオブジェクトを追加したり、 オブジェクトをSCHEMAから取り除くことができる。、tableやview、domainなどが、SCHEMAオブジェクトとなりえる。GRANT/REVOKEステートメントを使うことによって、その他のユーザに対し、スキーマ内のオブジェクトに関係する優先権を与えることも可能である。たとえば、tableについて、INSERTを使う特権を与える、など。
SCHEMA 内のオブジェクトは、 いわゆる修飾名で参照することができる：
[[<catalog name>.] <schema name>.] <object name>
SQL 92 は、“デフォルトすべて”という設定という売りこみなので、現在のSCHEMAに含まれるオブジェクトを参照したいときはいつでも、すでに与えられた <オブジェクト名>を使うことができる。
新しいデータベースが作成されたら、2つのSCHEMAが生成される：DEFINITION_SCHEMA と INFORMATION_SCHEMA である。DEFINITION_SCHEMA は、他のすべてのSCHEMAを 整備するために使われる、全オブジェクトを収めるものである。INFORMATION_SCHEMAは、DEFINITION_SCHEMA内のオブジェクトにアクセスするための、様々なオブジェクトや、数多くの、便利なオブジェクトを収めるものである。たとえば、あるデータベース中で定義されたTABLEsを参照したいとき、以下のようなSQL 92ステートメントを実行すればよいだろう：
SELECT * FROM INFORMATION_SCHEMA.TABLES;
INFORMATION_SCHEMA.TABLES は、実際には次のように定義される VIEW である：
CREATE VIEW INFORMATION_SCHEMA.TABLES AS
SELECT * FROM DEFINITION_SCHEMA.TABLES;
INFORMATION_SCHEMA 中の VIEWsは、すべて、非更新である。すなわち、次のように、INSERTを実行した場合：
INSERT INTO INFORMATION_SCHEMA.TABLES ....
実行結果は失敗に終わる。
DEFINTION_SCHEMAは、FrontBaseそのものによって、 排他的に占有される。よって、他のどんなユーザが、直接操作したり、アクセスすることは不可能だ。
新しいSCHEMAは次のようにして生成する（このとき、現在のユーザがSCHEMAの所有者となる）：
CREATE SCHEMA <schema name>;
|
-- SQL 92の基準を参照すれば、この例の
--完全な文法がわかる。この例は、全体の
--ごく一部を抜粋したものである。
|
あるSCHEMAを、カレント・スキーマに変更するには：
SET SCHEMA '<schema name>';
(ここで、スキーマ名は、キャラクタ・ストリングを使って、すでに与えられていることに注意）
定義済みのSCHEMAについて、一覧を見るには：
SELECT * FROM INFORMATION_SCHEMA.SCHEMATA;
どれが、カレント・スキーマであるかを調べるために、CURRENT_SCHEMAというストリング関数を使うことができる。ただし、CURRENT_SCHEMAは、SQL 92をFrontBaseで拡張したものである点に注意すること。
USERs
SQL 92におけるユーザの概念は、比較的単純であるものの、スキーマの概念と非常に密接に関係していることも事実である。
データベースにアクセスするために、ユーザ名が必要となる。これがなければ、アクセス拒否されるだろう（FrontBase は、SQL 92を拡張して、パスワード・プロテクトも提供している）。
新しいデータベースが生成されたとき、数種類のユーザ名も、同時に生成される。具体的には、次のようなものである：_SYSTEM および _PUBLICである。これら２つのユーザ名は、SQL 92でも、特別なユーザ名として扱われている。実際、アンダースコア（_）から始まるようなユーザ名は、通常は認識されないために、使われていない。
新しいユーザを生成するには：
CREATE USER <user name> [DEFAULT SCHEMA <schema name>];
デフォルトのスキーマを変更するには：
ALTER USER <user name> SET DEFAULT SCHEMA <schema name>;
オプションの <schema name>は、ユーザ名が生成されたとき、実際に存在するものに限られ、かつ、生成されたユーザがデータベースにアクセスしたときは必ず、このスキーマがデフォルトとなる。デフォルトの <schema name>が与えられていない場合、ユーザ名と同じ綴りのスキーマが生成され、これがデフォルトとなる（ユーザがデータベースに初めてアクセスするときに最初に現れる）。
だれがカレント・ユーザであるかを調べるために、USER および CURRENT_USERというストリング関数を使うことができる（USERは単に、CURRENT_USERを手短かに表記したものである）。
あるユーザ名を、カレント・ユーザに変更するには：
SET SESSION AUTHORIZATION <user name>;
定義済みのユーザ名・リストを見るには：
SELECT * FROM INFORMATION_SCHEMA.USERS;
DATE, TIME and TIMESTAMP
SQL 92 は、入念に設計された時間に関するコンセプトを持っており、その中には、以下のようなデータ・タイプが含まれる：
DATE
TIME
TIME WITH TIME ZONE
TIMESTAMP
TIMESTAMP WITH TIME ZONE
DATE は、年、月、日という情報を持つ。時間についてのコンポーネントはない。
TIME は、時、分、秒についての情報を持つ。
TIMESTAMPはｍ年、月、日、時、分、秒についての情報を持つ。
TIME あるいはTIMESTAMP は、文字通り、データベースに挿入される。サーバのタイムゾーンが、文字に付け加えられる。たとえば：もし、サーバがデンマークで稼動しており、今が８月としよう。すると、サーバのタイムゾ―ンは、GMT+02:00である。もし、TIMESTAMPとして、 '1999-08-02 11:49:00'がインサートされると、その文字列は、+02:00補正されたものなのだ。一方、TIMESTAMP '1999-01-02 11:49:00'が挿入された場合には、それは、+01:00補正されたものである（なぜならば、１月にサマー・タイムは適用されないからだ）。
タイムゾーンを越えて完全にコントロールしたい場合には、TIMESTAMP WITH TIME ZONEというデータタイプを使わねばならない。たとえば：TIMESTAMP '1999-08-02 11:49:00-08:00' といった具合に、である。
同様のコメントが、TIMEおよびTIME WITH TIME ZONEについても適用される。
Keywords and Identifiers
SQL 92には、広範囲にわたるキーワードがあり、自分の識別子に対するスペリング（綴り）を選択しようとしたとき、ちょっと驚くかもしれない。ここで、識別子は先頭文字がアンダースコア(_)でないもの、という規定にも注意を払っておくこと。
“衝突問題（collision problems）”の発生を抑える方法は、いろいろある：
SQL 92 で、アンダースコア（_)で終わるキーワードはない。たとえば、SELECT_ は、識別子として、まったく有効である！
SQL 92 は、時に機転が利かない。たとえば、識別子としてのMoviesは、MOVIESのに由来するものと判断されてしまう。
Learning more about SQL 92
ANSI であれISOであれ、その規格のコピーを常に保持しておくことが可能である。ただし、その規格は、本当はユーザ向けのものではない。SQL 92についてよく知るためには、 “A Guide to The SQL Standard, Fourth Edition”（Chris J. Date, Hugh Darwen 著）を購入せねばならない。この本は、SQL 92のコンセプトや、その構造のすべてを解説している。やや、学術的な視点から書かれているものの、 SQL 92の規格を知るためには、この本は必読であり、内容を理解しておくことは不可欠である。
同書は、Addison-Wesley社から発行されており、ISBNは、#: 0-201-96426-0である。この本を簡単に入手したいなら、www.amazon.comにアクセスすればよい。もちろん、近くの書店でも入手可能である。
|
