Glossary¶
- 1.x style¶
- 2.0 style¶
- 1.x-style¶
- 2.0-style¶
これらの用語はSQLAlchemy 1.4で新しく追加されたもので、 SQLAlchemy 2.0 - Major Migration Guide で説明されているSQLAlchemy 1.4 -> 2.0の移行計画を参照しています。”1.x style”という用語は、SQLAlchemyの1.xシリーズおよびそれ以前(例えば1.3、1.2など)で文書化されている方法で使用されるAPIを指し、”2.0 style”という用語は、バージョン2.0でのAPIの表示方法を指します。バージョン1.4は2.0のAPIのほぼすべてをいわゆる”移行モード”で実装していますが、バージョン2.0はレガシーコードが2.0との互換性を維持できるようにレガシーの
Queryオブジェクトを維持しています。- ACID¶
- ACID model¶
“Atomicity, Consistency, Isolation, Durability”の頭字語。データベーストランザクションが確実に処理されることを保証するプロパティのセットです。(Wikipediaより)
- association relationship¶
2層の relationship で、中間に関連付けテーブルを使って2つのテーブルをリンクします。関連付け関係は many to many 関係とは異なり、多対多テーブルは完全なクラスによってマップされます。多対多の場合のように
sqlalchemy.orm.relationship()構文によって見えないように処理されるのではなく、追加の属性が明示的に利用できるようになります。たとえば、従業員をプロジェクトに関連付け、その従業員の特定のロールもプロジェクトに格納する場合、リレーショナルスキーマは次のようになります:
CREATE TABLE employee ( id INTEGER PRIMARY KEY, name VARCHAR(30) ) CREATE TABLE project ( id INTEGER PRIMARY KEY, name VARCHAR(30) ) CREATE TABLE employee_project ( employee_id INTEGER PRIMARY KEY, project_id INTEGER PRIMARY KEY, role_name VARCHAR(30), FOREIGN KEY employee_id REFERENCES employee(id), FOREIGN KEY project_id REFERENCES project(id) )
上記のSQLAlchemy宣言マッピングは、次のようになります:
class Employee(Base): __tablename__ = "employee" id = Column(Integer, primary_key=True) name = Column(String(30)) class Project(Base): __tablename__ = "project" id = Column(Integer, primary_key=True) name = Column(String(30)) class EmployeeProject(Base): __tablename__ = "employee_project" employee_id = Column(Integer, ForeignKey("employee.id"), primary_key=True) project_id = Column(Integer, ForeignKey("project.id"), primary_key=True) role_name = Column(String(30)) project = relationship("Project", backref="project_employees") employee = relationship("Employee", backref="employee_projects")
ロール名を指定して、従業員をプロジェクトに追加できます:
proj = Project(name="Client A") emp1 = Employee(name="emp1") emp2 = Employee(name="emp2") proj.project_employees.extend( [ EmployeeProject(employee=emp1, role_name="tech lead"), EmployeeProject(employee=emp2, role_name="account executive"), ] )
See also
- atomicity¶
原子性は ACID モデルの構成要素の1つであり、各トランザクションが”all or nothing”であることを要求します。つまり、トランザクションの一部が失敗した場合、トランザクション全体が失敗し、データベースの状態は変更されないままになります。原子性システムは、電源障害、エラー、クラッシュなど、あらゆる状況で原子性を保証する必要があります。(Wikipediaより)
- attached¶
現在特定のに関連付けられているORMオブジェクトを示します。
See also
- backref¶
- bidirectional relationship¶
relationship システムを拡張したもので、2つの異なる
relationship()オブジェクトを相互に関連付けることができます。これにより、どちらかの側で変更が発生したときにメモリ内で調整されます。これら2つの関係を構築する最も一般的な方法は、一方の側に対してrelationship()関数を明示的に使用し、もう一方の:func:~sqlalchemy.orm.relationship が自動的に作成されるように、それに対して`backref`キーワードを指定することです。これを one to many で使用した例に対して次のように説明できます:class Department(Base): __tablename__ = "department" id = Column(Integer, primary_key=True) name = Column(String(30)) employees = relationship("Employee", backref="department") class Employee(Base): __tablename__ = "employee" id = Column(Integer, primary_key=True) name = Column(String(30)) dep_id = Column(Integer, ForeignKey("department.id"))
backrefは、1対多、多対1、 many to many など、任意の関係に適用できます。
- bound parameter¶
- bound parameters¶
- bind parameter¶
- bind parameters¶
バウンドパラメータは、データが DBAPI データベースドライバに渡される主要な手段です。呼び出される操作はSQL文の文字列に基づいていますが、データ値自体は別々に渡されます。ドライバには、これらの文字列を安全に処理してバックエンドのデータベースサーバに渡すロジックが含まれています。これには、パラメータをSQL文字列自体にフォーマットするか、別のプロトコルを使用してデータベースに渡す必要があります。
データベースドライバがこれを行う特定のシステムは、呼び出し元には関係ありません。重要なのは、外部では、データはSQL文字列自体の一部としてではなく、 常に 別々に渡されるべきであるということです。これは、SQLインジェクションに対して適切なセキュリティを確保するためにも、ドライバが最高のパフォーマンスを発揮できるようにするためにも不可欠です。
- candidate key¶
relational algebra 用語で、一意に識別されるキーを形成するアトリビュートまたはアトリビュートのセットを指します。1つのローは複数の候補キーを持つことができ、それぞれがそのローのプライマリ・キーとして使用されます。テーブルのプライマリ・キーは常に候補キーです。
- cartesian product¶
2つの集合AとBが与えられた場合、直積はすべての順序付けられた対(a, b)の集合であり、aはAにあり、bはBにあります。
SQLデータベースに関して言えば、直積は、2つ以上のテーブル(またはその他のサブクエリ)から、あるテーブルのローと別のテーブルのローとの間に(直接的または間接的に)何の種類の基準も確立せずに選択する場合に発生します。テーブルAとテーブルBから同時にSELECTを実行すると、AのすべてのローがBの最初のローに一致し、AのすべてのローがBの2番目のローに一致し、AのすべてのローがBのすべてのローとペアになるまで続きます。
デカルト積は膨大な結果セットを生成し、防止しなければクライアント・アプリケーションを簡単にクラッシュさせる可能性があります。
See also
- cascade¶
SQLAlchemyで使用される用語で、特定のオブジェクトに対して行われるORMパーシステンスアクションが、そのオブジェクトに直接関連付けられた他のオブジェクトにどのように拡張されるかを記述します。SQLAlchemyでは、これらのオブジェクトの関連付けは
relationship()構文を使用して設定されます。relationship()にはrelationship.cascadeというパラメータが含まれていて、特定のパーシステンス操作がどのようにカスケードされるかについてのオプションを提供します。SQLAlchemyにおけるこのシステムの一般的なアーキテクチャと同様に、”カスケード”という用語は、良くも悪くも、Hibernate ORMから借りました。
See also
- check constraint¶
チェック制約は、リレーショナル・データベースのテーブル内のエントリを追加または更新するときに有効なデータを定義する条件です。チェック制約はテーブル内の各行に適用されます。(Wikipediaより)
A check constraint can be added to a table in standard SQL using DDL like the following:
ALTER TABLE distributors ADD CONSTRAINT zipchk CHECK (char_length(zipcode) = 5);
See also
- columns clause¶
結果セットに返されるSQL式を列挙する
SELECT文の部分です。式はSELECTキーワードの直後に続き、カンマで区切られた個々の式のリストです。例: .. sourcecode:: sql
SELECT user_account.name, user_account.email FROM user_account WHERE user_account.name = ‘fred’
上記の
user_acount.name、user_account.email列のリストは、SELECTのcolumns節です。- composite primary key¶
複数の列を持つ primary key 。特定のデータベース行は、単一の値ではなく、複数の列に基づいて一意です。
See also
- consistency¶
一貫性は ACID モデルの構成要素の1つであり、任意のトランザクションがデータベースをある有効な状態から別の有効な状態にすることを保証します。データベースに書き込まれるデータはすべて、定義されたすべてのルールに従って有効でなければなりません。これには constraints 、cascade、triggers、およびそれらの任意の組み合わせが含まれますが、これらに限定されません。(Wikipediaより)
- constraint¶
- constraints¶
- constrained¶
データの有効性と一貫性を保証する、リレーショナルデータベース内で確立された規則。制約の一般的な形式には、primary key constraint 、 foreign key constraint 、および check constraint があります。
- correlates¶
subquery は、それを囲む
SELECT内のデータに依存する場合に相関があります。以下では、サブクエリが
email_addressテーブルから集約値MIN(a.id)を選択し、user_account.idの各値に対して呼び出され、この列の値をemail_address.user_account_id列に関連付けます。SELECT user_account.name, email_address.email FROM user_account JOIN email_address ON user_account.id=email_address.user_account_id WHERE email_address.id = ( SELECT MIN(a.id) FROM email_address AS a WHERE a.user_account_id=user_account.id )
上記のサブクエリは、このネストされたクエリの
FROM節にはないuser_accountテーブルを参照しています。代わりに、user_accountテーブルは、それを囲むクエリから受信されます。user_accountから選択された各行は、サブクエリの明確な実行につながります。ほとんどの場合、相関サブクエリは、ORDER BY句やHAVING句だけでなく、すぐ外側の
SELECT文の WHERE clause や columns clause にも存在します。あまり一般的ではありませんが、相関する副問い合わせが、囲んでいる
SELECTの FROM clause に存在することがあります。このような場合、相関は通常、囲んでいるSELECT自体が、次のような別のSELECTのWHERE、ORDER BY、カラム、またはHAVING句で囲まれていることに起因します。SELECT parent.id FROM parent WHERE EXISTS ( SELECT * FROM ( SELECT child.id AS id, child.parent_id AS parent_id, child.pos AS pos FROM child WHERE child.parent_id = parent.id ORDER BY child.pos LIMIT 3) WHERE id = 7)
1つの
SELECTから、そのFROM節を介して相関された問い合わせを囲む直接の相関は不可能です。なぜなら、相関は、囲んでいる文のFROM節から元のソース行が利用可能になって初めて実行されるからです。- crud¶
- CRUD¶
“Create, Update, Delete”を意味する頭字語。SQLにおけるこの用語は、データベースからデータを作成、変更、削除する操作の集合を指し、 DML としても知られています。また、一般的には、
INSERT、UPDATE、DELETE文を指します。- cursor¶
データベース内のレコードの走査を可能にする制御構造です。Python DBAPIでは、カーソル・オブジェクトは実際に文の実行の開始点であり、結果のフェッチに使用されるインタフェースでもあります。
- cyclomatic complexity¶
プログラムのソースコード内の可能なパスの数に基づくコードの複雑さの尺度。
See also
- DBAPI¶
- pep-249¶
DBAPIは”Python Database API Specification”の省略形です。これは、すべてのデータベース接続パッケージに共通の使用パターンを定義するために、Python内で広く使用されている仕様です。DBAPIは”低レベル”のAPIで、通常はPythonアプリケーションでデータベースと通信するために使用される最低レベルのシステムです。SQLAlchemyの dialect システムはDBAPIの操作を中心に構築されており、特定のデータベースエンジン上で特定のDBAPIを提供する個々のダイアレクトクラスを提供します。たとえば、
create_engine()のURLpostgresql+psycopg2://@localhost/testはpsycopg2DBAPI/ダイアレクトの組み合わせを参照し、URLMySQL+mysqldb://@localhost/testはMySQL for PythonDBAPI/ダイアレクトの組み合わせを参照します。- DDL¶
Data Definition Language の頭字語です。DDLは、リレーショナル・データベースがデータベース・スキーマ内の表、制約およびその他の永続オブジェクトを構成するために使用するSQLのサブセットです。SQLAlchemyは、DDL式を構築および出力するための豊富なAPIを提供します。
- deleted¶
これは、オブジェクトが Session 内で持つことができる主要なオブジェクト状態の1つを記述します。削除されたオブジェクトとは、以前は永続的であったオブジェクトで、その行を削除するためにフラッシュ内でデータベースにDELETE文が発行されました。セッションのトランザクションがコミットされると、オブジェクトは detached 状態に移動します。あるいは、セッションのトランザクションがロールバックされると、DELETEは元に戻され、オブジェクトは persistent 状態に戻ります。
See also
- descriptor¶
- descriptors¶
Pythonでは、記述子は”バインド動作”を持つオブジェクト属性であり、その属性アクセスは descriptor protocol. のメソッドによってオーバーライドされています。これらのメソッドは、
__get__()、__set__()、および__delete__()です。これらのメソッドのいずれかがオブジェクトに対して定義されている場合、それは記述子であると言われます。SQLAlchemyでは、記述子は、マップされたクラスに対して属性の動作を提供するために頻繁に使用されます。クラスが次のようにマップされる場合:
class MyClass(Base): __tablename__ = "foo" id = Column(Integer, primary_key=True) data = Column(String)
定義が完了すると、
MyClassクラスは mapped になります。その時点で、Columnオブジェクトから始まるid属性とdata属性は、InstrumentedAttributeのインスタンスを持つ instrumentation システムに置き換えられます。これは、前述の__get__()、__set__()、__delete__()メソッドを提供する記述子です。InstrumentedAttributeをクラスレベルで使用すると、SQL式が生成されます:>>> print(MyClass.data == 5)
data = :data_1インスタンスレベルでは値の変更を追跡し、lazy loads はデータベースからアンロードされた属性も追跡します:
>>> m1 = MyClass() >>> m1.id = 5 >>> m1.data = "some data" >>> from sqlalchemy import inspect >>> inspect(m1).attrs.data.history.added "some data"
- detached¶
これは、オブジェクトが Session 内で持つことができる主要なオブジェクト状態の1つを記述します。デタッチされたオブジェクトとは、データベースID(すなわち主キー)を持つが、どのセッションにも関連付けられていないオブジェクトです。以前 persistent であったオブジェクトが、削除されたか、所有しているセッションが閉じられたためにセッションから削除された場合、デタッチ状態に移行します。デタッチ状態は一般に、オブジェクトがセッション間で移動されるとき、または外部オブジェクトキャッシュとの間で移動されるときに使用されます。
See also
- dialect¶
SQLAlchemyでは、”ダイアレクト”は、特定の種類のデータベースバックエンドと、そのデータベースの特定の種類のPythonドライバ(または DBAPI )でデータベース操作を進めるための情報とメソッドを表すPythonオブジェクトです。SQLAlchemyダイアレクトは、
Dialectクラスのサブクラスです。See also
- discriminator¶
- DML¶
Data Manipulation Language* の頭字語。DMLは、リレーショナル・データベースが表内のデータを*変更*するために使用するSQLのサブセットです。DMLは通常、INSERT、UPDATE、DELETEの3つの一般的な文を指します。これらは CRUD (“Create, Read, Update, Delete”の頭字語)としても知られています。
- domain model¶
問題解決とソフトウェアエンジニアリングにおけるドメインモデルは、特定の問題に関連するすべてのトピックの概念モデルです。さまざまなエンティティ、その属性、役割、関係、および問題ドメインを管理する制約を記述します。(Wikipediaより)
See also
- DQL¶
Data Query Language の頭字語です。DQLは、リレーショナル・データベースが表内のデータを*読み取る*ために使用するSQLのサブセットです。DQLは、ほとんどの場合、使用中の最上位レベルのSQL文としてSQL SELECT構文を参照します。
- durability¶
耐久性は ACID モデルの特性であり、一度コミットされたトランザクションは、停電、クラッシュ、エラーが発生した場合でもコミットされたままになることを意味します。例えば、リレーショナルデータベースでは、SQL文のグループが実行されると、その結果を永続的に保存する必要があります(その直後にデータベースがクラッシュした場合でも)。(Wikipediaより)
- eager load¶
- eager loads¶
- eager loaded¶
- eager loading¶
- eagerly load¶
オブジェクトリレーショナルマッピングでは、”eager load”とは、オブジェクト自体がデータベースからロードされるのと同時に、データベース側の値が入力される属性を指します。SQLAlchemyでは、”eager loading”という用語は通常、
relationship()構文を使用してマッピング間でリンクされたオブジェクトの関連するコレクションとインスタンスを指しますが、 inheritance マッピングを使用する場合など、クエリされている特定のテーブルに関連する他のテーブルからロードされる追加の列属性を指すこともあります。Eager loadingは lazy loading の反対です。
See also
- executemany¶
この用語は、 PEP 249 DBAPI仕様の一部で、複数のパラメータセットを持つデータベース接続に対して呼び出すことができる単一のSQL文を示します。この特定のメソッドは cursor.executemany() として知られており、単一文の呼び出しに使用される cursor.execute() メソッドと比較して、多くの動作上の違いがあります。”executemany”メソッドは、渡されたパラメータセットごとに1回ずつ、指定されたSQL文を複数回実行します。executemanyを使用する一般的な理由は、パフォーマンスを向上させるためです。DBAPIは、事前に1回だけ文を準備したり、同じ文を複数回呼び出すように最適化するなどのテクニックを使用できます。
パラメータ辞書のリストが渡されたところで
Connection.execute()メソッドが使われると、SQLAlchemyは通常自動的にcursor.executemany()メソッドを利用します。これはSQLAlchemy Coreに対して、SQL文と処理されたパラメータセットをcursor.executemany()に渡す必要があることを示します。この場合、ドライバはパラメータ辞書ごとに個別にこの文を呼び出します。既知のすべてのDB APIで使用されている
cursor.executemany()メソッドの主な制限は、このメソッドを使用したときにcursorが行を返すように設定されていないことです。 ほとんどの バックエンド(cx_Oracle、/OracleDB DB APIは顕著な例外です)では、これはINSERT.RETURNINGのような文は通常cursor.executemany()と直接使用できないことを意味します。なぜなら、DB APIは通常、各INSERT実行から単一の行を集約しないからです。この制限を克服するために、2.0シリーズのSQLAlchemyは “Insert Many Values” Behavior for INSERT statements として知られる別の形式の”executemany”を実装しています。この機能は、
cursor.execute()を使用して、1回のラウンドトリップで複数のパラメータセットを処理するINSERT文を呼び出します。したがって、RETURNINGをサポートしながら、cursor.executemany()を使用した場合と同じ効果が得られます。See also
Sending Multiple Parameters - “executemany”のチュートリアル入門
“Insert Many Values” Behavior for INSERT statements - RETURNINGを”executemany”で使用できるようにするSQLAlchemyの機能
- expire¶
- expired¶
- expires¶
- expiring¶
- Expiring¶
SQLAlchemyのORMでは、 persistent オブジェクトや、時には detached オブジェクトのデータがいつ消去されるかを参照します。オブジェクトの属性が次にアクセスされたとき、現在進行中のトランザクションに格納されているこのオブジェクトのデータを更新するために、 lazy load SQLクエリが発行されます。
See also
- facade¶
より複雑な基礎または構造コードをマスクする、前面のインタフェースとして機能するオブジェクト。
See also
- flush¶
- flushing¶
- flushed¶
See also
- foreign key constraint¶
2つのテーブル間の参照制約です。外部キーは、他のテーブルの candidate key と一致するリレーショナルテーブル内のフィールドまたはフィールドのセットです。外部キーは、テーブルを相互参照するために使用できます。(Wikipediaより)
以下のように DDL を使用して、標準SQLのテーブルに外部キー制約を追加することができます。
ALTER TABLE employee ADD CONSTRAINT dep_id_fk FOREIGN KEY (employee) REFERENCES department (dep_id)
See also
- FROM clause¶
行の初期ソースを示す
SELECT文の部分です。単純な
SELECTは、FROM句の中に1つ以上のテーブル名を持ちます。複数のソースはコンマで区切られます。SELECT user.name, address.email_address FROM user, address WHERE user.id=address.user_id
FROM句は、明示的な結合が指定される場所でもあります。2つのテーブルの
JOINからなる単一のFROM要素を使って、上記のSELECTを書き直すことができます。SELECT user.name, address.email_address FROM user JOIN address ON user.id=address.user_id
- identity key¶
ORMマップされたオブジェクトに関連付けられたキーで、データベース内での主キーのIDと、
Session、 identity map 内での一意のIDを識別します。SQLAlchemyでは、
inspect()APIを使ってInstanceState追跡オブジェクトを返し、InstanceState.key属性を見ることで、ORMオブジェクトのIDキーを見ることができます:>>> from sqlalchemy import inspect >>> inspect(some_object).key (<class '__main__.MyTable'>, (1,), None)
See also
- identity map¶
PythonオブジェクトとそのデータベースID間のマッピングです。IDマップはORM Session オブジェクトに関連付けられたコレクションで、そのIDにキー付けされた各データベースオブジェクトの単一のインスタンスを保持します。このパターンの利点は、特定のデータベースIDに対して行われるすべての操作が、単一のオブジェクトインスタンスに透過的に調整されることです。IDマップを isolated トランザクションと組み合わせて使用する場合、特定の主キーを持つことがわかっているオブジェクトへの参照を持つことは、実際のデータベース行へのプロキシであると実用的な観点から考えることができます。
- imperative¶
- declarative¶
SQLAlchemy ORMでは、これらの用語はPythonクラスをデータベース・テーブルにマッピングする2つの異なるスタイルを指します。
- insertmanyvalues¶
これはSQLAlchemy特有の機能で、INSERT文が1つの文の中で何千もの新しい行を出力できるようにすると同時に、パフォーマンスを最適化する目的で、サーバが生成した値をRETURNINGなどを使用して文からインラインで返すことができます。この機能は、選択されたバックエンドで透過的に使用できるように意図されていますが、いくつかの設定オプションを提供します。この機能の詳細な説明については “Insert Many Values” Behavior for INSERT statements を参照してください。
- instrumentation¶
- instrumented¶
- instrumenting¶
インストルメンテーションとは、特定のクラスの機能と属性セットを拡張するプロセスを指します。理想的には、クラスの動作は、追加の動作と機能が利用可能になることを除いて、通常のクラスに近い状態を維持する必要があります。SQLAlchemy mapping プロセスは、特に、データベース対応の descriptors を、それぞれが特定のデータベース列または関連クラスとの関係を表すマップされたクラスに追加します。
- isolation¶
- isolated¶
- isolation level¶
ACID モデルの独立性プロパティは、トランザクションの同時実行が、トランザクションが連続して実行された場合、つまり次々に実行された場合に得られるシステム状態になることを保証します。各トランザクションは完全に分離して実行する必要があります。つまり、T1とT2が同時に実行される場合、それぞれが互いに独立している必要があります。(Wikipediaより)
- lazy initialization¶
オブジェクトの作成、データの取り込み、または他のサービスへの接続の確立などの初期化アクションを、それらのリソースが必要になるまで遅延させる戦術。
See also
- lazy load¶
- lazy loads¶
- lazy loaded¶
- lazy loading¶
オブジェクト・リレーショナル・マッピングでは、”遅延ロード”とは、通常はオブジェクトが最初にロードされるときに、ある期間データベース側の値を含まない属性を指します。その代わりに、属性は メモ化 を受け取り、データベースに送信され、最初に使用されたときにデータをロードします。このパターンを使用すると、関連するテーブルの属性をすぐに処理する必要がないため、オブジェクト・フェッチの複雑さと時間を削減できる場合があります。
遅延読み込みは eager loading の反対です。
SQLAlchemyでは、遅延読み込みはORMの重要な機能であり、ユーザ定義クラスの mapped 属性に適用されます。データベース列や関連するオブジェクトを参照する属性がアクセスされ、その属性にロードされた値が存在しない場合、ORMは現在のオブジェクトが persistent 状態で関連付けられている
Sessionを利用し、現在のトランザクションでSELECT文を発行し、進行中でなければ新しいトランザクションを開始します。オブジェクトが detached 状態で、どのSessionとも関連付けられていない場合、これはエラー状態とみなされ、 informational exception が発生します。See also
Lazy Load (via Martin Fowler) N plus one problem
Column Loading Options - ORMマップされた列の遅延読み込みに関する情報を含みます
Relationship Loading Techniques - ORM関連オブジェクトの遅延読み込みに関する情報を含んでいます
Preventing Implicit IO when Using AsyncSession - Asynchronous I/O (asyncio) 拡張を使用する際に遅延読み込みを避けるためのヒント
- many to many¶
sqlalchemy.orm.relationship()のスタイルで、中間のテーブルを介して2つのテーブルをリンクします。この設定を使用すると、左側の任意の数の行が右側の任意の数の行を参照することができ、その逆も可能です。従業員をプロジェクトに関連付けることができるスキーマ:
CREATE TABLE employee ( id INTEGER PRIMARY KEY, name VARCHAR(30) ) CREATE TABLE project ( id INTEGER PRIMARY KEY, name VARCHAR(30) ) CREATE TABLE employee_project ( employee_id INTEGER PRIMARY KEY, project_id INTEGER PRIMARY KEY, FOREIGN KEY employee_id REFERENCES employee(id), FOREIGN KEY project_id REFERENCES project(id) )
上の例では、
employee_projectテーブルは多対多のテーブルであり、関連する各テーブルのプライマリキーからなる複合主キーを自然に形成します。SQLAlchemyでは、
SQLAlchemy.orm.relationship()関数はこのスタイルの関係をほとんど透過的に表現することができ、多対多のテーブルは普通のテーブルメタデータを使って指定されます:class Employee(Base): __tablename__ = "employee" id = Column(Integer, primary_key=True) name = Column(String(30)) projects = relationship( "Project", secondary=Table( "employee_project", Base.metadata, Column("employee_id", Integer, ForeignKey("employee.id"), primary_key=True), Column("project_id", Integer, ForeignKey("project.id"), primary_key=True), ), backref="employees", ) class Project(Base): __tablename__ = "project" id = Column(Integer, primary_key=True) name = Column(String(30))
上記では、
Employee.projectsコレクションと後方参照Project.employeesコレクションが定義されています。proj = Project(name=”Client A”)
emp1 = Employee(name=”emp1”) emp2 = Employee(name=”emp2”)
proj.employees.extend([emp1, emp2])
- many to one¶
relationship()のスタイルで、親マッパーのテーブル内の外部キーを関連するテーブルのプライマリキーにリンクします。各親オブジェクトは、正確に0個または1個の関連するオブジェクトを参照できます。関連するオブジェクトは、それらを参照する任意の数の親オブジェクトに対して、暗黙的または明示的な one to many 関係を持ちます。
多対1スキーマの例(これは one to many スキーマと同じであることに注意してください):
CREATE TABLE department ( id INTEGER PRIMARY KEY, name VARCHAR(30) ) CREATE TABLE employee ( id INTEGER PRIMARY KEY, name VARCHAR(30), dep_id INTEGER REFERENCES department(id) )
employeeからdepartmentへの関係は、多数の従業員レコードを1つの部署に関連付けることができるため、多対1です。SQLAlchemyマッピングは次のようになります:class Department(Base): __tablename__ = "department" id = Column(Integer, primary_key=True) name = Column(String(30)) class Employee(Base): __tablename__ = "employee" id = Column(Integer, primary_key=True) name = Column(String(30)) dep_id = Column(Integer, ForeignKey("department.id")) department = relationship("Department")
- mapping¶
- mapped¶
- mapped class¶
- ORM mapped class¶
クラスが
Mapperクラスのインスタンスに関連付けられている場合、そのクラスは”マップされている”と言います。このプロセスはクラスをデータベーステーブルや他の selectable 構成体に関連付け、そのインスタンスがSessionを使って永続化されロードされるようにします。See also
- marshalling¶
- data marshalling¶
コンピュータプログラムの異なる部分間で、またはあるプログラムから別のプログラムにデータを移動する必要がある場合に、オブジェクトのメモリ表現を、システムの別の部分への格納または転送に適したデータ形式に変換するプロセス。SQLAlchemyに関しては、リレーショナル・データベースに渡すのに適した形式にデータを”マーシャリング”する必要があります。
See also
Augmenting Existing Types - SQLAlchemyの
TypeDecoratorは、データがINSERT文とUPDATE文のためにデータベースに送られるときのデータのマーシャリングと、SELECT文を使って取得されるときのデータの”アンマーシャリング”によく使われます。- metadata¶
- database metadata¶
- table metadata¶
“メタデータ”という用語は、一般に”データを記述するデータ”、つまり、それ自体が何らかの他の種類のデータのフォーマットおよび/または構造を表すデータを指します。SQLAlchemyでは、”メタデータ”という用語は通常、特定のデータベースに存在する可能性のあるテーブル、カラム、制約、およびその他の DDL オブジェクトに関する情報のコレクションである
MetaData構造を指します。- method chaining¶
- generative¶
SQLAlchemyドキュメント内で”ジェネレーティブ”と呼ばれる”メソッドチェーニング”は、オブジェクト上のメソッドを呼び出すことによってオブジェクトの状態を構築するオブジェクト指向のテクニックです。オブジェクトには任意の数のメソッドがあり、それぞれが新しいオブジェクト(場合によっては同じオブジェクト)を返し、オブジェクトに追加の状態が追加されます。
メソッドチェーニングを最大限に活用している2つのSQLAlchemyオブジェクトは、
SelectオブジェクトとQueryオブジェクトです。例えば、Selectオブジェクトは、Select.where()メソッドとSelect.order_by()メソッドを呼び出すことで、WHERE句とORDER BY句に2つの式を割り当てることができます:stmt = ( select(user.c.name) .where(user.c.id > 5) .where(user.c.name.like("e%")) .order_by(user.c.name) )
上記の各メソッド呼び出しは、元の
Selectオブジェクト追加の修飾子が追加されたコピーを返します。- mixin class¶
- mixin classes¶
他のクラスによって使用されるメソッドまたは属性を含むクラスが、それらの他のクラスの親クラスである必要がない、共通のオブジェクト指向パターン。
See also
- N plus one problem¶
- N plus one¶
N+1の問題は、 lazy load パターンの一般的な副作用です。このパターンでは、アプリケーションはオブジェクトの結果セットの各メンバの関連する属性またはコレクションを繰り返し処理し、その属性またはコレクションは遅延ロードパターンを介してロードされるように設定されます。最終的には、親オブジェクトの最初の結果セットをロードするためにSELECTステートメントが発行されます。次に、アプリケーションが各メンバを繰り返し処理すると、そのメンバの関連する属性またはコレクションをロードするために、各メンバに対して追加のSELECTステートメントが発行されます。最終的には、N個の親オブジェクトの結果セットに対して、N+1個のSELECTステートメントが発行されます。
The N plus one problem is alleviated using eager loading.
- one to many¶
relationship()のスタイルで、親マッパーのテーブルの主キーを関連テーブルの外部キーにリンクします。それぞれの一意の親オブジェクトは、0個以上の一意の関連オブジェクトを参照できます。関連するオブジェクトは、親オブジェクトに対して暗黙的または明示的な many to one 関係を持ちます。
1対多のスキーマの例(これは many to one スキーマと同じであることに注意してください:
CREATE TABLE department ( id INTEGER PRIMARY KEY, name VARCHAR(30) ) CREATE TABLE employee ( id INTEGER PRIMARY KEY, name VARCHAR(30), dep_id INTEGER REFERENCES department(id) )
1つの部署に複数の従業員レコードを関連付けることができるので、
部署から従業員への関係は1対多になります。SQLAlchemyマッピングは次のようになります:class Department(Base): __tablename__ = "department" id = Column(Integer, primary_key=True) name = Column(String(30)) employees = relationship("Employee") class Employee(Base): __tablename__ = "employee" id = Column(Integer, primary_key=True) name = Column(String(30)) dep_id = Column(Integer, ForeignKey("department.id"))
- ORM-annotated¶
- annotations¶
“ORM-annotated”というフレーズは、SQLAlchemyの内部的な側面を指します。ここでは、
ColumnオブジェクトのようなCoreオブジェクトは、特定のORMマッピングに属することを示す追加の実行時情報を持つことができます。この用語は、 PEP 484 で紹介された静的型付けに使用されるPythonソースコードの”型ヒント”を指す一般的なフレーズ”型アノテーション”と混同しないでください。SQLAlchemyの文書化されたコード例のほとんどは、”Annotated Example”または”Non-annotated Example”に関する小さな注記でフォーマットされています。これは例が PEP 484 注釈付きであるかどうかを示し、”ORM-annotated”というSQLAlchemyの概念とは関係ありません。
ドキュメントに”ORM-annotated”というフレーズがある場合、これは
Table、Column、SelectオブジェクトなどのコアSQL式オブジェクトを参照しています。これらのオブジェクトは、1つまたは複数のORMマッピングから生成されるか、またはORMマッピングから生成されるサブ要素を参照します。したがって、Session.execute()などのORMメソッドに渡されると、ORM固有の解釈や動作が行われます。たとえば、 ORM Tutorial に示されているUserクラスのようなORMマッピングからSelectオブジェクトを構築する場合:>>> stmt = select(User)
上記の
Selectの内部状態は、”User”がマップされているTableを参照しています。”User”クラス自体はすぐには参照されません。このようにして、Select構文はコアレベルのプロセスと互換性を保っています(Selectの._raw_columnsメンバーはprivateであり、エンドユーザコードからはアクセスできないことに注意してください):>>> stmt._raw_columns [Table('user_account', MetaData(), Column('id', Integer(), ...)]
しかし、
SelectがORMSessionに渡されると、オブジェクトに間接的に関連付けられたORMエンティティが、このSelectをORMコンテキストで解釈するために使用されます。実際の”ORMアノテーション”は、別のプライベート変数._annotationsで確認することができます:>>> stmt._raw_columns[0]._annotations immutabledict({ 'entity_namespace': <Mapper at 0x7f4dd8098c10; User>, 'parententity': <Mapper at 0x7f4dd8098c10; User>, 'parentmapper': <Mapper at 0x7f4dd8098c10; User> })
したがって、ここでは
stmtを ORMアノテーション付きのselect() オブジェクトと呼びます。これはSelect文で、Session.execute()のようなメソッドに渡されたときにORM固有の方法で解釈される追加情報を含んでいます。- pending¶
これは、オブジェクトが Session 内で持つことができる主要なオブジェクト状態の1つを記述します。pendingオブジェクトとは、データベースIDを持たないが、最近セッションに関連付けられた新しいオブジェクトです。セッションがフラッシュを発行し、行が挿入されると、オブジェクトは persistent 状態に移行します。
See also
- persistent¶
これは、オブジェクトが Session 内で持つことができる主要なオブジェクト状態の1つを記述します。永続オブジェクトとは、データベースID(すなわち主キー)を持ち、現在セッションに関連付けられているオブジェクトです。以前 pending であったオブジェクトが現在挿入されている場合は、データベースからセッションによってロードされたオブジェクトと同様に永続状態になります。永続オブジェクトがセッションから削除された場合、それは detached と呼ばれます。
See also
- plugin¶
- plugin-enabled¶
- plugin-specific¶
“plugin-enabled”または”plugin-specific”は一般に、SQLAlchemy Coreの関数またはメソッドがORMコンテキストで使用された場合の動作が異なることを示します。
SQLAlchemyでは、
SelectオブジェクトのようなCore構成体を”プラグイン”システムに参加させることができ、デフォルトでは存在しない追加の振る舞いや機能をオブジェクトに注入することができます。具体的には、主要な”プラグイン”は”orm”プラグインであり、SQLAlchemy ORMがORM結果を返すSQLクエリを作成して実行するためにCoreコンストラクトを利用するシステムのベースにあります。
See also
- polymorphic¶
- polymorphically¶
一度に複数の型を処理する関数を指します。SQLAlchemyでは、この用語は通常、ORMマップされたクラスの概念に適用されます。これにより、クエリ操作は結果セット内の情報に基づいて、通常は discriminator として知られる結果内の特定の列の値をチェックすることによって、異なるサブクラスを返します。
SQLAlchemyにおけるポリモーフィックなロードは、クラスの階層をマップするために、”joined”、”single”、”concrete”の3つの異なるスキームの1つまたは組み合わせが使用されることを意味します。セクション Mapping Class Inheritance Hierarchies では、継承マッピングについて詳しく説明しています。
- primary key¶
- primary key constraint¶
テーブル内の各行の特性を一意に定義する constraint 。主キーは、他の行では複製できない特性で構成されている必要があります。主キーは、単一の属性または組み合わせた複数の属性で構成できます。(Wikipediaより)
テーブルのプライマリキーは、必ずではありませんが、一般的には
CREATE TABLEDDL 内で定義されます。CREATE TABLE employee ( emp_id INTEGER, emp_name VARCHAR(30), dep_id INTEGER, PRIMARY KEY (emp_id) )
- read committed¶
4つのdatabase isolation レベルの1つで、コミットされた読み込み機能は、まだコミットされていない他の同時実行中のトランザクションからのいかなるデータにもトランザクションがさらされないようにし、いわゆる”ダーティリード”を防ぎます。しかし、コミットされた読み込みでは、繰り返し不可能な読み込みがある可能性があります。つまり、別のトランザクションが変更をコミットした場合、2回目の読み込み時に行内のデータが変更される可能性があります。
- read uncommitted¶
4つのdatabase isolation レベルの1つで、トランザクション内でデータベースデータに加えられた変更が、トランザクションがコミットされるまで永続的にならないread uncommitted機能です。しかし、read uncommittedでは、他のトランザクションでコミットされていないデータが、別のトランザクションのスコープ内で表示される可能性があります。これは”ダーティリード”と呼ばれます。
- reflection¶
- reflected¶
SQLAlchemyでは、この用語は、既存のテーブル、列、制約、およびその他の構成体に関する情報をロードするために、データベースのスキーマカタログを照会する機能を指します。SQLAlchemyには、この情報の生データを提供する機能と、データベーススキーマカタログからCore/ORMで使用可能な
Tableオブジェクトを自動的に構築する機能の両方が含まれています。See also
Reflecting Database Objects - データベースリフレクションのバックグラウンドです。
Mapping Declaratively with Reflected Tables - ORMマッピングとリフレクトされたテーブルの統合に関するバックグラウンドです。
- registry¶
通常はグローバルにアクセス可能なオブジェクトで、プログラムの多くの部分で一般的に有用な、プログラムの状態に関する長期にわたる情報を含みます。
See also
- relational¶
- relational algebra¶
リレーショナル・データベースに格納されたデータのモデリングとクエリーに使用される、Edgar F. Coddによって開発された代数的システム。
See also
- relationship¶
- relationships¶
データベース内の2つのテーブル間の関係に対応する、2つのマップされたクラスを接続するユニットです。
関係はSQLAlchemy関数
relationship()を使用して定義されます。一度作成されると、SQLAlchemyは関係を3つのタイプ one to many , many to one , many to many のいずれかに分類するために、関連する引数と基礎となるマッピングを検査します。この分類では、関係構造は、メモリー内のオブジェクトの関連付けに応じてデータベース内に適切なリンクを保持するタスクと、データベース内の現在のリンクに基づいてオブジェクト参照とコレクションをメモリーにロードするジョブを処理します。See also
- release¶
- releases¶
- released¶
SQLAlchemyの文脈では、”release”という用語は、特定のデータベース接続の使用を終了するプロセスを指します。SQLAlchemyは、接続プールの使用を特徴とし、データベース接続の寿命に関して構成可能性を可能にします。プールされた接続を使用する場合、それを”閉じる”プロセス、すなわち
connection. close()のような文を呼び出すプロセスは、接続が既存のプールに戻される効果を持つこともあれば、その接続によって参照される基礎となるTCP/IP接続を実際にシャットダウンする効果を持つこともあります。どちらが行われるかは、構成とプールの現在の状態に依存します。そのため、代わりに”接続の使用が終了したら、接続に対して行うことは何でも行う”という意味で”release”という用語を使用しました。この用語は、”トランザクションリソースを解放する”というフレーズで使用されることがあります。これは、実際に”解放”しているものが、接続時に蓄積されたトランザクション状態であることをより明確に示すためです。ほとんどの場合、テーブルから選択したり、更新を発行したりするプロセスなどは、その接続時に isolated 状態と、潜在的なローまたはテーブルロックを取得します。この状態はすべて、接続上の特定のトランザクションに対してローカルであり、ロールバックを発行すると解放されます。接続プールの重要な機能は、接続をプールに戻すときに、DBAPIの
connection. rollback()メソッドも呼び出されることです。これにより、接続が再度使用されるように設定されると、前の一連の操作への参照が保持されない”クリーン”状態になります。See also
- repeatable read¶
4つのdatabase isolation レベルの1つであるrepeatable readは、 read committed のすべての独立性を特徴とし、さらに、トランザクション内で読み取られる特定の行は、その時点から、そのトランザクションの間、値が外部から変更されないこと(つまり、他の同時UPDATE文から)が保証されるという特徴があります。
- RETURNING¶
これは、特定のバックエンドによってさまざまな形式で提供される非SQL標準句で、INSERT、UPDATE、またはDELETE文の実行時に結果セットを返すサービスを提供します。SELECT文から生成されたかのように、一致したローから任意のカラムのセットを返すことができます。
RETURNING句を使用すると、インラインまたはデフォルトで生成されたプライマリ・キー値とデフォルト値をそれらが作成された時点で取得するなど、一般的な更新/選択シナリオのパフォーマンスが大幅に向上します。また、サーバで生成されたデフォルト値をアトミックな方法で取得することもできます。
PostgreSQLの慣用表現であるRETURNINGの例は以下のようになります:
INSERT INTO user_account (name) VALUES ('new name') RETURNING id, timestamp
上の例では、INSERT文は実行時に結果セットを提供します。この結果セットには、
user_account.id列とuser_account.timestamp列の値が含まれています。これらの列は、他の方法では含まれないので、デフォルト値として生成されるはずです(ただし、デフォルト値の列だけでなく、任意の列やSQL式をRETURNINGに入れることができることに注意してください)。現在RETURNINGまたは同様の構文をサポートしているバックエンドは、PostgreSQL、SQL Server、Oracle、およびFirebirdです。PostgreSQLおよびFirebirdの実装は一般的にフル機能ですが、SQL ServerおよびOracleの実装には注意事項があります。SQL Serverでは、この句はINSERT文およびUPDATE文の場合は”OUTPUT INSERTED”、DELETE文の場合は”OUTPUT DELETED”と呼ばれます。重要な注意事項は、このキーワードと一緒にトリガを使用できないことです。Oracleでは、これは”RETURNING…INTO”と呼ばれ、値をOUTパラメータに入れる必要があります。これは構文が厄介であるだけでなく、一度に1つの行にしか使用できないことを意味します。
SQLAlchemyの
UpdateBase.returning()システムは、これらのバックエンドのRETURNINGシステムの上に抽象層を提供して、列を返すための一貫したインターフェースを提供します。ORMには、利用可能な場合にRETURNINGを利用する多くの最適化も含まれています。- selectable¶
SQLAlchemyで使用される用語で、行の集合を表すSQL構文を表します。 relational algebra の”リレーション”の概念とほぼ同じです。SQLAlchemyでは、
Selectableクラスをサブクラス化したオブジェクトは、SQLAlchemy Coreを使用するときに”selectables”として使用できると見なされます。最も一般的な2つの構文は、TableとSelect文の構文です。- sentinel¶
- insert sentinel¶
これはSQLAlchemy特有の用語で、
Columnを参照します。これはバルクの insertmanyvalues 操作で使用でき、RETURNINGなどを使用して返された行に対して挿入されたデータレコードを追跡します。このような列設定は、 insertmanyvalues 機能が一度に多くの行に対して最適化されたINSERT.RETURNING文を実行し、返された行の順序が入力データと一致することを保証できる場合に必要です。典型的なユースケースでは、SQLAlchemy SQLコンパイラは自動的に”insert sentinel”としてサロゲート整数のプライマリキー列を使用することができ、ユーザによる設定は必要ありません。他の種類のサーバ生成プライマリキー値を使用するあまり一般的でないケースでは、一度に多くの行を挿入するINSERT文を最適化するために、 table metadata 内で明示的な”insert sentinel”列をオプションで設定できます。
See also
Correlating RETURNING rows to parameter sets - このセクションにあります。 “Insert Many Values” Behavior for INSERT statements
- serializable¶
4つのデータベース isolation レベルの1つであるシリアライザブル機能は、 repeatable read のすべての独立性を備えています。さらに、ロックベースのアプローチでは、いわゆる”phantom reads”が発生しないことが保証されています。つまり、他のトランザクションのスコープ内で挿入または削除された行は、このトランザクション内では検出できません。このトランザクション内で読み取られた行は存在し続けることが保証され、存在しない行は他のトランザクションから表示または挿入されないことが保証されます。
シリアライズ可能な分離は、通常、この効果を達成するために行または行の範囲のロックに依存しており、デッドロックの可能性を高め、パフォーマンスを低下させる可能性があります。ロックベースでないスキームもあるが、これらは、書き込み衝突が検出された場合にトランザクションを拒否することに必然的に依存します。
- Session¶
ORMデータベース操作のコンテナまたはスコープです。セッションは、データベースからインスタンスをロードし、マップされたインスタンスへの変更を追跡し、フラッシュ時に単一の作業単位で変更を保持します。
See also
- subquery¶
- scalar subquery¶
囲んでいる
SELECT文内に埋め込まれたSELECT文を参照します。副問い合わせには2つの一般的な形式があります。1つは厳密に1つのローと1つのカラムを返さなければならない”スカラーselect”と呼ばれる形式で、もう1つは”導出表”として動作し、別のselectのFROM句のソースとして機能します。スカラーselectは、それを囲むselectの WHERE clause、 columns clause 、ORDER BY clause、またはHAVING clauseに配置できます。一方、導出表形式は、それを囲む
SELECTのFROM句に配置できます。例:
包含する
SELECTの columns clause に置かれたスカラー副問い合わせ。この例の副問い合わせは correlated subquery です。なぜなら、副問い合わせが選択する行の一部は、包含する文によって与えられるからです。SELECT id, (SELECT name FROM address WHERE address.user_id=user.id) FROM user
包含する
SELECTの WHERE clause に置かれたスカラー副問い合わせ。この例の副問い合わせは、固定された結果を選択するので、相関はありません。SELECT id, name FROM user WHERE status=(SELECT status_id FROM status_code WHERE code='C')
包含する
SELECTの FROM clause に置かれた導出表副問い合わせ。このような副問い合わせには、ほとんどの場合エイリアス名が与えられます。SELECT user.id, user.name, ad_subq.email_address FROM user JOIN (select user_id, email_address FROM address WHERE address_type='Q') AS ad_subq ON user.id = ad_subq.user_id
- transient¶
これは、オブジェクトが Session 内で持つことができる主要なオブジェクト状態の1つを記述します。一時オブジェクトとは、データベースIDを持たず、まだセッションに関連付けられていない新しいオブジェクトです。オブジェクトがセッションに追加されると、 pending 状態に移行します。
See also
- unique constraint¶
- unique key index¶
一意キーインデックスは、データベーステーブル内のデータ値の各行を一意に識別できます。一意キーインデックスは、単一のデータベーステーブル内の単一の列または列のセットで構成されます。NULL値が使用されていない場合、データベーステーブル内の2つの異なる行またはデータレコードが、それらの一意キーインデックス列内で同じデータ値(またはデータ値の組み合わせ)を持つことはできません。データベーステーブルの設計によっては、多くの一意キーインデックスを持つことができますが、主キーインデックスは多くても1つです。(Wikipediaより)
See also
- unit of work¶
オブジェクト・リレーショナル・マッパーなどのパーシスタンス・システムが、一連のオブジェクトに対して行われた変更のリストを保持し、保留中のすべての変更を定期的にデータベースにフラッシュするソフトウェア・アーキテクチャー。
SQLAlchemyの
Sessionは作業単位パターンを実装しており 、Session.add()のようなメソッドを使ってSessionに追加されたオブジェクトは、作業単位スタイルの永続化に参加します。SQLAlchemyでの作業持続性の単位がどのように見えるかのウォークスルーについては、 SQLAlchemy Unified Tutorial の Data Manipulation with the ORM セクションから始めてください。その後、詳細については、一般的なリファレンスドキュメントの Basics of Using a Session を参照してください。
- version id column¶
SQLAlchemyでは、これは、行が値を変更するときに、特定の行の”バージョン”を追跡する特定のテーブル列の使用を指します。”バージョンID列”をさまざまな方法で使用するさまざまな種類のリレーショナル・パターンがありますが、SQLAlchemyのORMには、行が新しい情報で更新されるときに古いデータをテストする手段として、そのような列を構成できる特別な機能が含まれています。新しいデータを行に入れようとしたときに、この列の最後の既知の”バージョン”が行のバージョンと一致しない場合は、古い情報に基づいて動作していることがわかります。
データベースに”バージョン管理された”行を保存する方法は他にもあり、これはしばしば”一時的な”データと呼ばれます。SQLAlchemyのバージョン管理機能に加えて、さらにいくつかの例がドキュメントに記載されています。以下のリンクを参照してください。
See also
Configuring a Version Counter - SQLAlchemyの組み込みバージョンID機能です。
Versioning Objects - 行を一時的にバージョン化するマッピングの他の例です。
- WHERE clause¶
SELECT文の中で、行をフィルタする条件を示す部分。キーワードWHEREの後に続く1つのSQL式です。SELECT user_account.name, user_account.email FROM user_account WHERE user_account.name = 'fred' AND user_account.status = 'E'
上の例では、
WHERE user_account.name='fred'AND user_account.status='E'というフレーズが、SELECTのWHERE句を構成しています。