4D v16

4Dと4D SQLエンジン統合の原則

ホーム

 
4D v16
4Dと4D SQLエンジン統合の原則

4Dと4D SQLエンジン統合の原則  


 

 

原則として、4D SQLエンジンはSQL-92互換です。つまり使用するコマンドや関数、演算子、シンタックスの詳細な説明が必要な場合、SQL-92リファレンスを参照できます。これらは例えばインターネットで見つけることができます。

しかし、4D SQLエンジンはSQL-92の機能を100%サポートしているわけではありません。また特定の追加の機能をサポートしています。

この節では、4D SQLエンジンの主たる実装と制限について説明しています。

4DのSQLエンジンは4Dデータベースの深い部分に統合されているため、テーブルやカラム (フィールド) 、レコードの最大数や、テーブルやカラムの命名規則に関する制限は、標準の内部的な4Dエンジン (DB4D) と同じです。以下にこれらをリストします。

  • テーブルの最大数: 理論的には20億ですが、4Dとの互換性のため32767となっています。
  • 1テーブルの カラム (フィールド) の最大数: 理論的には20億ですが、4Dとの互換性のため32767となっています。
  • 1テーブルの ロー (レコード) の最大数: 10億
  • インデックスキーの最大数: 文字、テキスト、フロート型インデックスでは1280億、その他のインデックス型(スカラー型)では2億5600万
  • 主 キーにNULL値は許されずまたユニークでなければなりません。主キーカラム (フィールド) にインデックスを付ける必要はありません。
  • テー ブルやフィールドの最大文字数: 31文字 (4Dの制限)

異なるユーザにより作成されたとしても、同じテーブル名は許可されません。標準の4Dコントロールが適用されます。

以下の表では、4D SQLでサポートされるデータタイプと、それに対応する4Dのタイプを説明しています:

4D SQL説明4D
Varchar 文字テキストテキストまたは文字
Real範囲+/-1.7E308の浮動小数点数実数
Numeric 範囲+/- 2E64の数値64 bit整数
Float浮動小数点数 (事実上無限)Float
Smallint 範囲-32,768から32,767の数値整数
Int 範囲-2,147,483,648から2,147,483,647の数値倍長整数
Int64 範囲 +/- 2E64の数値64 bit整数
UUID32個の16進文字で表現される16バイトの数値 (128 bit)UUID 文字フォーマット
Bit TRUE/FALSEまたは1/0値のみをとるフィールドブール
Boolean TRUE/FALSEまたは1/0値のみをとるフィールドブール
Blob2GBまで: 画像、アプリケーション、ドキュメントなどのバイナリオブジェクトBlob
Bit varying2GBまで: 画像、アプリケーション、ドキュメントなどのバイナリオブジェクトBlob
Clob2GB文字までのテキスト。この カラム (フィールド) にインデックスは付けられません。これはレコード自身には保存されません。テキスト
Text2GB 文字までのテキスト。このカラム (フィールド) にインデックスは付けられません。これはレコード自身には保存されません。テキスト
Timestamp 日付と時間。日付は'YYYY/MM/DD'フォーマットで時間は'HH:MM:SS:ZZ'フォーマット個別に処理される日付と時間 (自動変換)
Duration'HH:MM:SS:ZZ'フォーマットの時間時間
Interval 'HH:MM:SS:ZZ'フォーマットの時間時間
Picture2GBまでのPICTピクチャピク チャ

数値タイプ間の自動変換が実装されています。
数値を表す文字列は対応する数値に変換されません。特別なCAST関数を使用して、タイプ間の変換を行うことができます。
以下のSQLデータタイプは 実装されていません:

  • NCHAR
  • NCHAR VARYING.

NULL値は4D SQLランゲージおよび4Dデータベースエンジンに実装されています。しかし4Dランゲージではサポートされていません。にもかかわらず、Is field value NullSET FIELD VALUE NULLコマンドを使用して、4DフィールドのNULL値を読み書きできます。

4Dでの互換性のため、4Dデータベーステーブルに格納されたNULL値は、4Dランゲージを使用して操作する際、自動でデフォルト値に変換されます。例えば以下の文において:

 myAlphavar:=[mytable]MyAlphafield

MyAlphafieldフィールドにNULL値が含まれる場合、myAlphavar変数には"" (空の文字列) が代入されます。

デフォルト値はデータ型により異なります:

  • 文字およびテキストデータ型: ""
  • 実数、整数、および倍長整数型: 0
  • 日付データ型: “00/00/00”
  • 時間データ型: “00:00:00”
  • ブールデータ型: False
  • ピクチャデータ型: 空のピクチャ
  • Blobデータ型: 空のBlob

他方、このメカニズムは原則として、クエリのような4Dデータベースエンジンレベルでは適用されません。実際、空の値の検索 (例えばmyvalue=0) はNULL値が格納されたレコードを見つけませんし、逆の場合も同様です。両方のタイプの値 (デフォルト値とNULL) がレコードの同じフィールドに存在する場合、処理が変更されたり、あるいは追加のコードが必要となることがあります。
この不便さを避けるために、4Dランゲージで、すべての処理を標準化するために使用できるNULL値を空値にマップオプションがあります。ストラクチャエディタのフィールドインスペクタにあるこのオプションを使用すると、デフォルト値を使用する原則をすべての処理に拡張できます。NULL値を含むフィールドは、機械的にデフォルト値を含むものとして扱われます。このオプションはデフォルトでチェックされています。

NULL値を空値にマッププロパティはデータベースエンジンの低レベルで考慮されます。特にIs field value Nullコマンドに影響します。

NULL値の入力を拒否フィールドプロパティは、NULL値が格納されることを防ぐ目的で使用されます:

フィールドのこの属性にチェックが入れられていると、そのフィールドにNULL値を格納できなくなります。この低レベルのプロパティはSQLのNOT NULL属性に対応します。
一般的に、4DデータベースでNULL値を使用したい場合、4DのSQLランゲージのみをデータベースで使用することをお勧めします。

: 4Dでは、フィールドに"必須入力"属性を設定することもできます。2つの設定のコンセプトは似ていますが、スコープが異なります。"必須入力"属性はデータ入力コントロールであり、“NULL値の入力を拒否”属性はデータベースエンジンレベルで動作します。
この設定がされたフィールドがNULL値を受け取ると、エラーが生成されます。

4D の統合 SQL サーバーは、ODBC API に沿った日付と時間の定数をサポートします。ODBC 日付・時間定数のシークエンスのシンタックスは以下の通りです:

{constant_type 'value'}

constant_typevalue詳細
dyyyy-mm-dd日付のみ
thh:mm:ss[.fff]時間のみ
tsyyyy-mm-dd hh:mm:ss[.fff]日付と時間(timestamp)

注: fff はミリ秒を意味しています。

例えば、以下の様な定数を使用することが出来ます:

{ d '2013-10-02' }
{ t '13:33:41' }
{ ts '1998-05-02 01:23:56.123' }

SQL においては、月または日に "0" を指定している日付は拒否されてしまいます。例えば、次のような式はエラーを生成します: {d'0000-00-00'}、CAST('0000-00-00' AS TIMESTAMP) など。空日付 (Null日付ではないことに注意) に対して SQL クエリを行うには、次の例のように4D式を利用します:

 C_LONGINT($count)
 $blankDate:=!00-00-00!
 Begin SQL
            SELECT COUNT(*) FROM Table_1
            WHERE myDate = :$blankDate
            INTO :$count;
 End SQL

プロジェクトメソッドにおいて設定可能な"SQL利用可"プロパティは、SQL経由の4Dプロジェクトメソッドの実行を管理します:

このオプションがチェックされていると、このプロジェクトメソッドを4D SQLエンジンから実行できます。デフォルトではチェックされておらず、4Dプロジェクトメソッドは保護されていて、4D SQLエンジンから呼び出すことはできません。メソッドを4D SQLエンジンから実行可能にするには、このオプションにチェックしてそれを認可しなければなりません。

このプロパティはODBC Driver経由、あるいはBegin SQL/End SQLタグの間に挿入されたSQLコード、またはQUERY BY SQLコマンドによる実行など、内部外部問わずすべてのSQLクエリに適用されま す。

Notes:

  • メソッドに"SQL利用可"属性が設定されていても、実行の際には環境設定レベルおよびメソッドプロパティレベルで設定されたアクセス権 が考慮されます。
  • ODBC SQLProcedure関数は、"SQL利用可"属性が設定されたプロジェクトメソッドのみを返します。

  • 自動コミットトランザクション: このオプションを使用してSQLエンジンの自動コミットメカニズムを有効にできます。自動コミットモードの目的は、データの参照整合性を保つことにあります。このオプションがチェックされていると、トランザクションの中で実行されていないすべてのSELECTINSERTUPDATE、そしてDELETE (SIUD) クエリは、自動でアドホックなトランザクションに含められます。これによりクエリが完全に実行されるか、エラーが発生した場合にはキャンセルされることが保障されます。
    すでにトランザクションの中にある (参照整合性がカスタムに管理されている) クエリは、このオプションの影響を受けません。
    このオプションにチェックがされていないと、(SELECT... FOR UPDATE クエリを除き) 自動トランザクションは生成されません (SELECTコマンド参照)。デフォルトでこのオプションはチェックされていません。
    SET DATABASE PARAMETER コマンドを使用して、プログラムでこのオプションを管理することもできます。
    : 4D SQLエンジンによりクエリされるローカルデータベースのみがこのパラメタの影響を受けます。外部データベースの場合、自動コミットメカニズムはリモート のSQLエンジンが処理します。
  • 大文字小文字を区別した文字列比較: このオプションを使用してSQLクエリ時の文字列比較を変更することができます。このオプションはデフォルトでチェックされていて、SQLエンジンは文字列比較 (ソートやクエリ) の際に大文字小文字を区別します。それに加え、文字のアクセント付き・なしも区別します。例えば“ABC”=“ABC” ですが “ABC” # “Abc” また "abc" # "âbc" となります。
    SQL エンジンと4Dエンジンの動作を揃えたいなど特定のケースでは、文字列比較で大文字小文字を区別したくない (“ABC”=“Abc"="âbc") 場合があります。そのようにするには、このオプションの選択を外します。
    SET DATABASE PARAMETERコマンドを使用して、プログラムでこのオプションを管理することもできます。

4Dはスキーマのコンセプトを実装しています。スキーマはデータベースのテーブルを含む仮想的なオブジェクトです。SQLにおいてスキーマの目的は、異な るデータベースオブジェクトのセットに特定のアクセス権を割り当てることです。スキーマはデータベースを、そのデータベース全体を形成する個々の独立する エンティティに分割します。つまりあるテーブルはいつもただ1つのスキーマに属します。

  • スキーマを作成するにはCREATE SCHEMAコマンドを使用します。そしてGRANTREVOKEコマンドを使用してスキーマにアクセスタイプを設定できます。
  • テーブルをスキーマに割り当てるには、CREATE TABLEまたはALTER TABLEコマンドを呼び出します。また4Dのストラクチャエディタにある インスペクターパレット の"スキーマ"ポップアップメニューを使用することもできます。このメニューにはデータベースで定義されているすべてのスキーマが表示されます:
  • スキーマを削除するには、DROP SCHEMAコマンドを使用します。

Note: スキーマによるアクセスコントロールは、外部からの接続のみに適用されます。Begin SQL/End SQLタグ、SQL EXECUTEQUERY BY SQL等によって4D内で実行されるSQLコードは、常に完全なアクセスを持ちます。

4D SQLサーバのレベルでは、マルチデータベースのアーキテクチャが実装されています。4Dでは以下のことが可能です:

  • SQL LOGINコマンドを使用して、既存のデータベースにログインする。
  • あるデータベースから他のデータベースに、SQL LOGINSQL LOGOUTコマンドを使用してスイッチする。
  • USE DATABASEコマンドを使用して、カレントデータベースに代わり、別の4Dデータベースを開いて使用する。

SQLランゲージでは主キー(プライマリーキー)を使用して、テーブル中のレコード (行) を指定するテーブルカラム (フィールド) 決定します。主キーの設定は、特に4Dテーブルのレコード複製機能(SQLを使用した複製参照)および4Dテーブルのログ機能を使用するためには4D v14以降では必要となります。

4Dでは2つの方法を使用して主キーを管理できます:

  • SQLランゲージを使用する
  • 4Dのストラクチャエディタを使用する

注:

テーブルを作成するとき (CREATE TABLEコマンドを使用) またはカラムを追加や変更するとき (ALTER TABLEコマンドを使用)、主キーを設定できます。主キーはPRIMARY KEY句とそれに続くカラム名またはカラムリストで指定されます。 詳細はを参照してください。

4Dではストラクチャーエディターのコンテキストメニューを通じて、主キーを直接作成・削除することができます。

この点についてのより詳細な情報については、4D デザインリファレンス マニュアルの主キーを設定、削除するを参照して下さい。

4D の統合SQLエンジンは、標準のSQL viewsをサポートしています。ビューとは複数の異なるデータベースのテーブルからのデータを受け取れる仮想テーブルです。ビューは定義されると SELECT 宣言の中で実際のテーブルと同じように使用することができます。

ビュー の中のデータは SELECT コマンドに基づいた定義クエリによって定義されます。定義クエリの中で使用される実際のテーブルは「ソーステーブル」と呼ばれます。SQLビューには標準 のテーブルと同じように列と行がありますが、実際に存在しているわけではなく、セッションの間メモリーに格納された処理結果を表示しているにすぎません。 実際に一時保存されているのはビューの定義だけです。

4D v14ではビューを管理するためのSQLコマンドが二つ用意されています。SQLコマンドDROP VIEW です。



参照 

sql_data_type_name

 
プロパティ 

プロダクト: 4D
テーマ: 4DでSQLを使用する

 
履歴 

 
ARTICLE USAGE

SQLリファレンス ( 4D v16)