Глоссарий¶

ACID¶

Модель ACID¶

Акроним «Atomicity, Consistency, Isolation, Durability»; набор свойств, гарантирующих надежную обработку транзакций базы данных. (через Википедию)

См.также

atomicity

consistency

isolation

durability

ACID Model (via Wikipedia)

DBAPI¶

пеп-249¶

DBAPI - это сокращение фразы «Python Database API Specification». Это широко используемая спецификация в Python для определения общих шаблонов использования для всех пакетов подключения к базе данных. DBAPI - это API «низкого уровня», который обычно является системой самого низкого уровня, используемой в приложении Python для связи с базой данных. Система SQLAlchemy dialect построена вокруг работы DBAPI, предоставляя отдельные классы диалектов, которые обслуживают конкретный DBAPI поверх конкретного движка базы данных; например, URL create_engine() postgresql+psycopg2://@localhost/test относится к комбинации DBAPI/диалекта psycopg2, тогда как URL mysql+mysqldb://@localhost/test относится к комбинации DBAPI/диалекта MySQL for Python.

См.также

PEP 249 - Python Database API Specification v2.0

DDL¶

Аббревиатура от Data Definition Language. DDL - это подмножество SQL, которое реляционные базы данных используют для конфигурирования таблиц, ограничений и других постоянных объектов в схеме базы данных. SQLAlchemy предоставляет богатый API для построения и создания выражений DDL.

См.также

Описание баз данных с помощью метаданных

DDL (via Wikipedia)

DML

DQL

DML¶

Акроним для Язык манипулирования данными. DML - это подмножество SQL, которое реляционные базы данных используют для изменения данных в таблицах. DML обычно относится к трем широко известным операторам INSERT, UPDATE и DELETE, иначе известным как CRUD (сокращение от «Create, Read, Update, Delete»).

См.также

DML (via Wikipedia)

DDL

DQL

DQL¶

Акроним для Язык запросов к данным. DQL - это подмножество SQL, которое реляционные базы данных используют для чтения данных в таблицах. DQL почти исключительно ссылается на конструкцию SQL SELECT как на используемый оператор SQL верхнего уровня.

См.также

DQL (via Wikipedia)

DML

DDL

FROM пункт¶

Часть оператора SELECT, которая указывает на начальный источник строк.

Простой SELECT будет содержать одно или несколько имен таблиц в предложении FROM. Несколько источников разделяются запятой:

SELECT user.name, address.email_address
FROM user, address
WHERE user.id=address.user_id

Предложение FROM также является тем местом, где задаются явные соединения. Мы можем переписать вышеприведенный SELECT, используя один элемент FROM, который состоит из JOIN двух таблиц:

SELECT user.name, address.email_address
FROM user JOIN address ON user.id=address.user_id

N плюс одна проблема¶

N плюс один¶

Проблема N плюс один является распространенным побочным эффектом шаблона lazy load, когда приложение хочет выполнить итерацию по связанному атрибуту или коллекции на каждом члене результирующего набора объектов, где этот атрибут или коллекция установлены для загрузки с помощью шаблона ленивой загрузки. В итоге выполняется оператор SELECT для загрузки начального результирующего набора родительских объектов; затем, по мере итерации приложения по каждому члену, для каждого члена выполняется дополнительный оператор SELECT для загрузки связанного атрибута или коллекции для этого члена. В итоге для результирующего набора из N родительских объектов будет выполнено N + 1 оператор SELECT.

Проблема N плюс один снимается с помощью eager loading.

См.также

Стратегии работы погрузчика

Техники загрузки отношений

активная нагрузка¶

большие нагрузки¶

активная нагрузка¶

активная загрузка¶

В реляционном отображении объектов «нетерпеливая загрузка» относится к атрибуту, который заполняется своим значением со стороны базы данных в то же время, когда сам объект загружается из базы данных. В SQLAlchemy «ускоренная загрузка» обычно относится к связанным коллекциям объектов, которые отображаются с помощью конструкции relationship(). Нетерпеливая загрузка является противоположностью lazy loading.

См.также

Техники загрузки отношений

аннотации¶

Аннотации - это концепция, используемая внутри SQLAlchemy для хранения дополнительной информации вместе с объектами ClauseElement. С экземпляром объекта ассоциируется словарь Python, который содержит пары ключ/значение, значимые для различных внутренних систем, в основном в рамках ORM:

some_column = Column("some_column", Integer)
some_column_annotated = some_column._annotate({"entity": User})

Система аннотаций отличается от общедоступного словаря Column.info тем, что приведенная выше операция аннотации создает копию нового Column, а не рассматривает все значения аннотации как часть единой единицы. ORM создает копии объектов выражения для применения аннотаций, специфичных для их контекста, например, для разграничения столбцов, которые должны отображаться относительно объединенного объекта наследования, и столбцов, которые должны отображаться относительно только их непосредственной родительской таблицы, а также для разграничения столбцов в «условии присоединения» отношения, где столбец в некоторых случаях должен быть выражен в терминах одного конкретного псевдонима таблицы или другого, основываясь на его положении в выражении присоединения.

ассоциативные отношения¶

Двухуровневое отношение relationship, которое связывает две таблицы вместе с помощью таблицы ассоциации в середине. Ассоциативное отношение отличается от отношения 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"),
    ]
)

См.также

many to many

атомарность¶

Атомарность является одним из компонентов модели ACID, и требует, чтобы каждая транзакция была «все или ничего»: если одна часть транзакции не работает, вся транзакция не работает, а состояние базы данных остается неизменным. Атомарная система должна гарантировать атомарность в любой ситуации, включая сбои питания, ошибки и аварии. (через Википедию)

См.также

ACID

Atomicity (via Wikipedia)

в ожидании¶

Это описывает одно из основных состояний объекта, которое объект может иметь в пределах Session; ожидающий объект - это новый объект, который не имеет идентификатора базы данных, но недавно был связан с сессией. Когда сессия выдает команду flush и строка вставляется, объект переходит в состояние persistent.

См.также

Краткое введение в состояния объектов

ВОЗВРАЩЕНИЕ¶

Это нестандартное предложение, предоставляемое в различных формах некоторыми бэкендами, которое обеспечивает возврат набора результатов при выполнении оператора INSERT, UPDATE или DELETE. Может быть возвращен любой набор столбцов из сопоставленных строк, как если бы они были получены в результате выполнения оператора SELECT.

Предложение RETURNING обеспечивает значительное увеличение производительности в распространенных сценариях обновления/выбора, включая получение значений первичного ключа, сгенерированных в строке или по умолчанию, и значений по умолчанию в момент их создания, а также способ получения значений по умолчанию, сгенерированных сервером, атомарным способом.

Пример RETURNING, идиоматичный для PostgreSQL, выглядит так:

INSERT INTO user_account (name) VALUES ('new name') RETURNING id, timestamp

Выше, оператор INSERT предоставит после выполнения набор результатов, который включает значения столбцов user_account.id и user_account.timestamp, которые выше должны были быть сгенерированы как значения по умолчанию, поскольку в противном случае они не включаются (но обратите внимание, что в RETURNING можно поместить любую серию столбцов или SQL-выражений, а не только столбцы со значениями по умолчанию).

Бэкенды, которые в настоящее время поддерживают RETURNING или аналогичную конструкцию, - это PostgreSQL, SQL Server, Oracle и Firebird. Реализации PostgreSQL и Firebird обычно являются полнофункциональными, в то время как реализации SQL Server и Oracle имеют оговорки. В SQL Server этот пункт известен как «OUTPUT INSERTED» для операторов INSERT и UPDATE и «OUTPUT DELETED» для операторов DELETE; главная оговорка заключается в том, что триггеры не поддерживаются в сочетании с этим ключевым словом. В Oracle он известен как «RETURNING…INTO» и требует, чтобы значение было помещено в параметр OUT, что означает не только неудобный синтаксис, но и то, что его можно использовать только для одного ряда за раз.

Система SQLAlchemy UpdateBase.returning() предоставляет уровень абстракции поверх систем RETURNING этих бэкендов, чтобы обеспечить согласованный интерфейс для возврата столбцов. ORM также включает в себя множество оптимизаций, которые используют RETURNING, когда он доступен.

выбираемый¶

Термин, используемый в SQLAlchemy для описания конструкции SQL, которая представляет собой коллекцию строк. Он во многом схож с понятием «отношение» в relational algebra. В SQLAlchemy объекты, являющиеся подклассами класса Selectable, считаются пригодными для использования в качестве «выбираемых» при использовании SQLAlchemy Core. Две наиболее распространенные конструкции - это конструкция Table и конструкция Select.

выпуск¶

выпускает¶

выпущено¶

В контексте SQLAlchemy термин «освобождение» относится к процессу завершения использования конкретного соединения с базой данных. В SQLAlchemy предусмотрено использование пулов соединений, что позволяет настраивать продолжительность жизни соединений с базой данных. При использовании пула соединений, процесс «закрытия» соединения, т.е. вызов оператора типа connection.close(), может иметь эффект возврата соединения в существующий пул, или эффект фактического закрытия основного TCP/IP соединения, на которое ссылается это соединение - что именно происходит, зависит от конфигурации, а также от текущего состояния пула. Поэтому мы использовали термин released, означающий «делайте все, что вы делаете с соединениями, когда мы закончили их использовать».

Иногда этот термин используется во фразе «освободить транзакционные ресурсы», чтобы более четко указать, что на самом деле мы «освобождаем» любое транзакционное состояние, которое накопилось на соединении. В большинстве ситуаций процесс выбора из таблиц, выпуска обновлений и т.д. приобретает состояние isolated на этом соединении, а также потенциальные блокировки строк или таблиц. Все это состояние является локальным для конкретной транзакции на соединении и освобождается, когда мы выполняем откат. Важной особенностью пула соединений является то, что когда мы возвращаем соединение в пул, также вызывается метод connection.rollback() DBAPI, так что когда соединение устанавливается для повторного использования, оно находится в «чистом» состоянии без ссылок на предыдущую серию операций.

См.также

Объединение соединений

генеративный¶

Термин, который SQLAlchemy использует для обозначения того, что обычно известно как method chaining; подробнее см. этот термин.

грубый¶

CRUD¶

Акроним, означающий «Create, Update, Delete». Этот термин в SQL относится к набору операций, которые создают, изменяют и удаляют данные из базы данных, также известных как DML, и обычно относится к операторам INSERT, UPDATE и DELETE.

дескриптор¶

дескрипторы¶

В Python дескриптор - это атрибут объекта с «поведением связывания», доступ к атрибуту которого переопределен методами в descriptor protocol. Такими методами являются __get__(), __set__() и __delete__(). Если любой из этих методов определен для объекта, то говорят, что это дескриптор.

В SQLAlchemy дескрипторы активно используются для того, чтобы обеспечить поведение атрибутов для сопоставленных классов. Когда класс сопоставлен как:

class MyClass(Base):
    __tablename__ = "foo"

    id = Column(Integer, primary_key=True)
    data = Column(String)

Класс MyClass будет mapped после завершения его определения, и тогда атрибуты id и data, начинающиеся как объекты Column, будут заменены системой instrumentation экземплярами InstrumentedAttribute, которые являются дескрипторами, предоставляющими вышеупомянутые методы __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"

диалект¶

В SQLAlchemy «диалект» - это объект Python, который представляет информацию и методы, позволяющие выполнять операции с базой данных на определенном типе бэкенда базы данных и определенном типе драйвера Python (или DBAPI) для этой базы данных. Диалекты SQLAlchemy являются подклассами класса Dialect.

См.также

Конфигурация двигателя

дискриминатор¶

Столбец набора результатов, который используется во время загрузки polymorphic для определения того, какой сопоставленный класс должен быть применен к конкретной входящей строке результатов. В SQLAlchemy классы всегда являются частью иерархического отображения с использованием отображения наследования.

См.также

Сопоставление иерархий наследования классов

долговечность¶

Долговечность - это свойство модели ACID, которое означает, что после фиксации транзакции она останется таковой даже в случае потери питания, сбоев или ошибок. В реляционной базе данных, например, после выполнения группы операторов SQL результаты должны храниться постоянно (даже если сразу после этого произойдет сбой базы данных). (через Википедию)

См.также

ACID

Durability (via Wikipedia)

единица работы¶

Архитектура программного обеспечения, при которой система персистентности, например, объектно-реляционный картограф, ведет список изменений, внесенных в серию объектов, и периодически сбрасывает все эти изменения в базу данных.

SQLAlchemy’s Session реализует модель единицы работы, где объекты, добавленные в Session с помощью методов типа Session.add(), будут участвовать в персистенции в стиле единицы работы.

Для ознакомления с тем, как выглядит персистентность единиц работы в SQLAlchemy, начните с раздела Манипулирование данными с помощью ORM в Самоучитель SQLAlchemy 1.4 / 2.0. Затем для получения более подробной информации смотрите Основы использования сеанса в общей справочной документации.

См.также

Unit of Work (via Martin Fowler)

Манипулирование данными с помощью ORM

Основы использования сеанса

идентификационный ключ¶

Ключ, связанный с объектами ORM-mapped, который идентифицирует их первичный ключ в базе данных, а также их уникальную идентичность в рамках Session identity map.

изоляция¶

изолированный¶

Изоляция¶

уровень изоляции¶

Свойство изоляции модели ACID гарантирует, что одновременное выполнение транзакций приводит к такому состоянию системы, которое было бы получено, если бы транзакции выполнялись последовательно, т.е. одна за другой. Каждая транзакция должна выполняться в полной изоляции, т.е. если T1 и T2 выполняются одновременно, то каждая из них должна оставаться независимой от другой. (через Википедию)

См.также

ACID

Isolation (via Wikipedia)

read uncommitted

read committed

repeatable read

serializable

императив¶

декларативный¶

В SQLAlchemy ORM эти термины относятся к двум различным стилям отображения классов Python на таблицы базы данных.

См.также

Декларативное отображение

Императивное картирование

истекает¶

истек срок действия¶

истекает¶

истекающий¶

Истекающий¶

В SQLAlchemy ORM означает, когда данные в объекте persistent или иногда detached стираются, так что при следующем обращении к атрибутам объекта будет выдан SQL-запрос lazy load, чтобы обновить данные для этого объекта, хранящиеся в текущей транзакции.

См.также

Обновление / истечение срока действия

карта идентичности¶

Отображение между объектами Python и их идентификаторами в базе данных. Карта идентификации - это коллекция, связанная с объектом ORM Session, в которой хранится единственный экземпляр каждого объекта базы данных, ключ которого соответствует его идентификатору. Преимущество этого шаблона заключается в том, что все операции, выполняемые для определенного идентификатора базы данных, прозрачно координируются на одном экземпляре объекта. При использовании карты идентичности в сочетании с транзакцией isolated наличие ссылки на объект, который, как известно, имеет определенный первичный ключ, с практической точки зрения можно рассматривать как прокси к реальной строке базы данных.

См.также

Identity Map (via Martin Fowler)

картезианское произведение¶

Если даны два множества A и B, то картезианское произведение - это множество всех упорядоченных пар (a, b), где a находится в A, а b - в B.

С точки зрения баз данных SQL, картезианское произведение возникает, когда мы выбираем из двух или более таблиц (или других подзапросов) без установления какого-либо критерия между строками одной таблицы и другой (прямо или косвенно). Если мы одновременно выбираем из таблицы A и таблицы B, мы получим каждую строку из A, сопоставленную с первой строкой из B, затем каждую строку из A, сопоставленную со второй строкой из B, и так далее, пока каждая строка из A не будет сопоставлена с каждой строкой из B.

Декартовы продукты вызывают генерацию огромных наборов результатов и могут легко вывести клиентское приложение из строя, если не принять меры.

См.также

Cartesian Product (via Wikipedia)

картирование¶

отображено на карте¶

сопоставленный класс¶

Мы говорим, что класс «сопоставлен», когда он был передан через функцию mapper(). Этот процесс связывает класс с таблицей базы данных или другой конструкцией selectable, так что его экземпляры могут быть сохранены и загружены с помощью Session.

См.также

Обзор сопоставленных классов ORM

каскад¶

Термин, используемый в SQLAlchemy для описания того, как действие ORM по сохранению, происходящее с определенным объектом, распространяется на другие объекты, которые непосредственно связаны с этим объектом. В SQLAlchemy эти ассоциации объектов настраиваются с помощью конструкции relationship(). relationship() содержит параметр relationship.cascade, который предоставляет опции того, как определенные операции персистенции могут каскадироваться.

Термин «каскады», а также общая архитектура этой системы в SQLAlchemy были заимствованы, к лучшему или худшему, из Hibernate ORM.

См.также

Каскады

ключ кандидата¶

Термин relational algebra, обозначающий атрибут или набор атрибутов, которые образуют уникальный идентифицирующий ключ для строки. Строка может иметь более одного ключа-кандидата, каждый из которых подходит для использования в качестве первичного ключа этой строки. Первичный ключ таблицы всегда является ключом-кандидатом.

См.также

primary key

Candidate key (via Wikipedia)

https://www.databasestar.com/database-keys/

консистенция¶

Согласованность является одним из компонентов модели ACID и гарантирует, что любая транзакция переведет базу данных из одного допустимого состояния в другое. Любые данные, записанные в базу данных, должны быть действительными в соответствии со всеми определенными правилами, включая, но не ограничиваясь constraints, каскады, триггеры и любые их комбинации. (через Википедию)

См.также

ACID

Consistency (via Wikipedia)

корреляции¶

коррелированный подзапрос¶

коррелированные подзапросы¶

Код subquery является коррелированным, если он зависит от данных в объемлющем SELECT.

Ниже подзапрос выбирает агрегированное значение MIN(a.id) из таблицы email_address таким образом, что он будет вызываться для каждого значения 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
 )

Приведенный выше подзапрос обращается к таблице user_account, которая сама не входит в предложение FROM этого вложенного запроса. Вместо этого таблица user_account получена из вложенного запроса, где каждая строка, выбранная из user_account, приводит к отдельному выполнению подзапроса.

Коррелированный подзапрос в большинстве случаев присутствует в WHERE clause или columns clause непосредственно заключающего оператора SELECT, а также в предложении ORDER BY или HAVING.

В менее распространенных случаях коррелированный подзапрос может присутствовать в FROM clause вложенного SELECT; в этих случаях корреляция обычно обусловлена тем, что вложенный SELECT сам вложен в предложение WHERE, ORDER BY, columns или HAVING другого SELECT, например:

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)

Корреляция от одного оператора SELECT непосредственно к другому, который включает коррелируемый запрос через свой пункт FROM, невозможна, потому что корреляция может быть продолжена только после того, как исходные строки источника из пункта FROM включающего оператора станут доступны.

курсор¶

Управляющая структура, позволяющая обходить записи в базе данных. В Python DBAPI объект курсора фактически является отправной точкой для выполнения оператора, а также интерфейсом, используемым для получения результатов.

См.также

Cursor Objects (in pep-249)

Cursor (via Wikipedia)

ленивая загрузка¶

ленивые нагрузки¶

ленивая загрузка¶

ленивая загрузка¶

В реляционном отображении объектов «ленивая загрузка» относится к атрибуту, который не содержит своего значения со стороны базы данных в течение некоторого периода времени, обычно при первой загрузке объекта. Вместо этого атрибут получает память, которая заставляет его обратиться к базе данных и загрузить свои данные при первом использовании. Используя этот шаблон, можно иногда уменьшить сложность и время, затрачиваемое на поиск объектов, поскольку атрибуты для связанных таблиц не требуют немедленного обращения. Ленивая загрузка является противоположностью eager loading.

См.также

Lazy Load (via Martin Fowler)

N plus one problem

Техники загрузки отношений

ленивая инициализация¶

Тактика задержки некоторых действий по инициализации, таких как создание объектов, заполнение данных или установление связи с другими службами, до тех пор, пока эти ресурсы не потребуются.

См.также

Lazy initialization (via Wikipedia)

маршаллинг¶

сортировка данных¶

Процесс преобразования представления объекта в памяти в формат данных, подходящий для хранения или передачи в другую часть системы, когда данные должны быть перемещены между различными частями компьютерной программы или из одной программы в другую. С точки зрения SQLAlchemy, нам часто требуется «маршалинг» данных в формат, подходящий для передачи в реляционную базу данных.

См.также

Marshalling (via Wikipedia)

Дополнение существующих типов - TypeDecorator в SQLAlchemy обычно используется для маршалинга данных при отправке их в базу данных для операторов INSERT и UPDATE, а также для «размаршалинга» данных при их извлечении с помощью операторов SELECT.

метаданные¶

метаданные базы данных¶

метаданные таблицы¶

Термин «метаданные» обычно относится к «данным, которые описывают данные»; данные, которые сами по себе представляют формат и/или структуру какого-либо другого вида данных. В SQLAlchemy термин «метаданные» обычно относится к конструкции MetaData, которая представляет собой набор информации о таблицах, столбцах, ограничениях и других DDL объектах, которые могут существовать в конкретной базе данных.

См.также

Metadata Mapping (via Martin Fowler)

многие к одному¶

Стиль relationship(), который связывает внешний ключ в таблице родительского картографа с первичным ключом связанной таблицы. Каждый родительский объект может ссылаться ровно на ноль или один связанный объект.

Связанные объекты, в свою очередь, будут иметь неявные или явные отношения one to many к любому количеству родительских объектов, которые ссылаются на них.

Примеров много для одной схемы (которая, заметим, идентична схеме 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 является отношением многие к одному, поскольку с одним отделом может быть связано много записей о сотрудниках. Сопоставление 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")

См.также

relationship

one to many

backref

многие ко многим¶

Стиль 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,
    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])

См.также

association relationship

relationship

one to many

many to one

модель домена¶

Модель домена в решении проблем и программной инженерии - это концептуальная модель всех тем, связанных с конкретной проблемой. Она описывает различные объекты, их атрибуты, роли и отношения, а также ограничения, которые регулируют проблемную область.

(через Википедию)

См.также

Domain Model (via Wikipedia)

обратная ссылка¶

двунаправленные отношения¶

Расширение системы relationship, при котором два разных объекта relationship() могут быть взаимно связаны друг с другом, так что они координируются в памяти при изменениях, происходящих с каждой из сторон. Наиболее распространенным способом построения этих двух отношений является использование функции relationship() явно для одной стороны и указание ключевого слова backref для нее, так что другая relationship() создается автоматически. Мы можем проиллюстрировать это на примере, который мы использовали в 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"))

Обратную ссылку можно применять к любым отношениям, включая отношения один ко многим, многие к одному и many to many.

См.также

relationship

one to many

many to one

many to many

ограничение¶

ограничения¶

ограниченный¶

Правила, установленные в реляционной базе данных, которые обеспечивают достоверность и согласованность данных. Общие формы ограничений включают primary key constraint, foreign key constraint и check constraint.

ограничение внешнего ключа¶

Ссылочное ограничение между двумя таблицами. Внешний ключ - это поле или набор полей в реляционной таблице, которые совпадают с candidate key другой таблицы. Внешний ключ можно использовать для перекрестных ссылок между таблицами. (через Википедию)

Ограничение внешнего ключа может быть добавлено к таблице в стандартном SQL с помощью DDL, как показано ниже:

ALTER TABLE employee ADD CONSTRAINT dep_id_fk
FOREIGN KEY (employee) REFERENCES department (dep_id)

См.также

Foreign Key Constraint (via Wikipedia)

один ко многим¶

Стиль relationship(), который связывает первичный ключ родительской таблицы отображения с внешним ключом связанной таблицы. Каждый уникальный родительский объект может ссылаться на ноль или более уникальных связанных объектов.

Связанные объекты, в свою очередь, будут иметь неявное или явное отношение many to one к своему родительскому объекту.

Пример схемы один ко многим (которая, заметим, идентична схеме 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)
)

Отношение от department к employee - один ко многим, поскольку многие записи сотрудников могут быть связаны с одним отделом. Сопоставление 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"))

См.также

relationship

many to one

backref

отдельно стоящий¶

Это описывает одно из основных состояний объекта, которое объект может иметь в пределах Session; отсоединенный объект - это объект, который имеет идентификатор базы данных (т.е. первичный ключ), но не связан ни с какой сессией. Объект, который ранее был persistent и был удален из своей сессии либо потому, что он был удален, либо потому, что принадлежащая ему сессия была закрыта, переходит в состояние detached. Состояние detached обычно используется при перемещении объектов между сессиями или при перемещении в/из внешнего кэша объектов.

См.также

Краткое введение в состояния объектов

отношения¶

отношения¶

Соединительный блок между двумя сопоставленными классами, соответствующий некоторой связи между двумя таблицами в базе данных.

Отношение определяется с помощью функции SQLAlchemy relationship(). После создания SQLAlchemy проверяет аргументы и основные сопоставления, чтобы классифицировать отношение как один из трех типов: one to many, many to one или many to many. При такой классификации конструкция отношения выполняет задачу сохранения соответствующих связей в базе данных в ответ на ассоциации объектов в памяти, а также задачу загрузки ссылок на объекты и коллекций в память на основе текущих связей в базе данных.

См.также

Конфигурация отношений

отражение¶

отраженный¶

В SQLAlchemy этот термин относится к возможности запроса каталогов схем базы данных для загрузки информации о существующих таблицах, столбцах, ограничениях и других конструкциях. SQLAlchemy включает функции, которые могут как предоставлять исходные данные для этой информации, так и автоматически конструировать объекты Core/ORM, пригодные для использования Table, из каталогов схем баз данных.

См.также

Отражение объектов базы данных - полная информация об отражении баз данных.

первичный ключ¶

ограничение первичного ключа¶

Ключ constraint, который однозначно определяет характеристики каждой строки в таблице. Первичный ключ должен состоять из характеристик, которые не могут быть продублированы ни в одной другой строке. Первичный ключ может состоять из одного атрибута или нескольких атрибутов в комбинации. (через Википедию)

Первичный ключ таблицы обычно, хотя и не всегда, определяется в пределах CREATE TABLE DDL:

CREATE TABLE employee (
     emp_id INTEGER,
     emp_name VARCHAR(30),
     dep_id INTEGER,
     PRIMARY KEY (emp_id)
)

См.также

composite primary key

Primary key (via Wikipedia)

переходный¶

Это описывает одно из основных состояний объекта, которое объект может иметь в пределах Session; переходный объект - это новый объект, который не имеет идентификатора базы данных и еще не был связан с сеансом. Когда объект добавляется к сессии, он переходит в состояние pending.

См.также

Краткое введение в состояния объектов

плагин¶

с поддержкой плагинов¶

специфический для плагинов¶

«plugin-enabled» или «plugin-specific» обычно указывает на функцию или метод в SQLAlchemy Core, который будет вести себя по-другому при использовании в контексте ORM.

SQLAlchemy позволяет конструкциям Core, таким как объекты Select, участвовать в системе «плагинов», которые могут вводить в объект дополнительные поведения и возможности, не присутствующие по умолчанию.

В частности, основным «плагином» является плагин «orm», который лежит в основе системы, что SQLAlchemy ORM использует конструкции Core для составления и выполнения SQL-запросов, возвращающих результаты ORM.

См.также

ORM Query Unified с Core Select

повторяющееся чтение¶

Один из четырех уровней базы данных isolation, повторяемое чтение обладает всеми свойствами изоляции read committed, а также тем, что любой конкретный ряд, прочитанный в рамках транзакции, гарантированно не будет иметь никаких последующих внешних изменений значения (т.е. от других параллельных операторов UPDATE) в течение всей транзакции.

подзапрос¶

скалярный подзапрос¶

Относится к оператору SELECT, который встроен в объемлющий SELECT.

Подзапрос бывает двух видов: один известен как «скалярный select», который должен возвращать ровно одну строку и один столбец, а другой - как «производная таблица», служащая источником строк для пункта FROM другого select. Скалярный select может быть помещен в WHERE clause, columns clause, предложение ORDER BY или HAVING вложенного select, тогда как форма производной таблицы может быть помещена в предложение FROM вложенного SELECT.

Примеры:

1. скалярный подзапрос, помещенный в columns clause вложенного SELECT. Подзапрос в этом примере является correlated subquery, потому что часть строк, из которых он выбирает, задана через вложенный оператор.

   SELECT id, (SELECT name FROM address WHERE address.user_id=user.id)
   FROM user

2. скалярный подзапрос, помещенный в WHERE clause вложенного SELECT. Этот подзапрос в данном примере не является коррелированным, так как выбирает фиксированный результат.

   SELECT id, name FROM user
   WHERE status=(SELECT status_id FROM status_code WHERE code='C')

3. подзапрос производной таблицы, помещенный в FROM clause вложенного SELECT. Такому подзапросу почти всегда присваивается псевдоним.

   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

полиморфный¶

полиморфно¶

Относится к функции, которая обрабатывает несколько типов одновременно. В SQLAlchemy этот термин обычно применяется к концепции сопоставленного класса ORM, когда операция запроса возвращает различные подклассы на основе информации в наборе результатов, обычно путем проверки значения определенного столбца в результате, известного как discriminator.

Полиморфная загрузка в SQLAlchemy подразумевает, что для отображения иерархии классов используется одна или комбинация трех различных схем: «объединенная», «одиночная» и «конкретная». Раздел Сопоставление иерархий наследования классов полностью описывает отображение наследования.

постоянный¶

Это описывает одно из основных состояний объекта, которое объект может иметь в Session; постоянный объект - это объект, который имеет идентификатор базы данных (т.е. первичный ключ) и в настоящее время связан с сеансом. Любой объект, который ранее был pending и теперь вставлен, находится в состоянии персистентности, как и любой объект, который был загружен сеансом из базы данных. Когда постоянный объект удаляется из сессии, он известен как detached.

См.также

Краткое введение в состояния объектов

приборостроение¶

инструментальный¶

инструментарий¶

Инструментарий - это процесс расширения функциональности и набора атрибутов определенного класса. В идеале, поведение класса должно оставаться близким к обычному классу, за исключением того, что становятся доступными дополнительные поведения и возможности. Процесс SQLAlchemy mapping, помимо прочего, добавляет в сопоставленный класс descriptors с поддержкой базы данных, каждый из которых представляет определенный столбец базы данных или отношение к связанному классу.

прилагается¶

Указывает на объект ORM, который в настоящее время связан с конкретным Session.

См.также

Краткое введение в состояния объектов

проверка ограничений¶

Контрольное ограничение - это условие, определяющее допустимые данные при добавлении или обновлении записи в таблице реляционной базы данных. Контрольное ограничение применяется к каждой строке таблицы.

(через Википедию)

Контрольное ограничение может быть добавлено к таблице в стандартном SQL с помощью DDL, как показано ниже:

ALTER TABLE distributors ADD CONSTRAINT zipchk CHECK (char_length(zipcode) = 5);

См.также

CHECK constraint (via Wikipedia)

реестр¶

Объект, обычно глобально доступный, который содержит долгоживущую информацию о некотором состоянии программы, которая обычно полезна для многих частей программы.

См.также

Registry (via Martin Fowler)

реляционный¶

реляционная алгебра¶

Алгебраическая система, разработанная Эдгаром Ф. Коддом, которая используется для моделирования и запроса данных, хранящихся в реляционных базах данных.

См.также

Relational Algebra (via Wikipedia)

связанный параметр¶

связанные параметры¶

параметр привязки¶

параметры привязки¶

Связанные параметры являются основным средством передачи данных драйверу базы данных DBAPI. Хотя вызываемая операция основывается на строке оператора SQL, сами значения данных передаются отдельно, где драйвер содержит логику, которая безопасно обрабатывает эти строки и передает их на внутренний сервер базы данных, что может включать либо форматирование параметров в саму строку SQL, либо передачу их в базу данных с помощью отдельных протоколов.

Конкретная система, с помощью которой драйвер базы данных делает это, не должна иметь значения для вызывающей стороны; суть в том, что со стороны данные всегда должны передаваться отдельно, а не как часть самой строки SQL. Это необходимо как для обеспечения адекватной защиты от SQL-инъекций, так и для обеспечения наилучшей производительности драйвера.

См.также

Prepared Statement - в Википедии

bind parameters - в Use The Index, Luke!

Параметры отправки - в Самоучитель SQLAlchemy 1.4 / 2.0

сериализуемый¶

Один из четырех уровней базы данных isolation, сериализуемый, обладает всеми свойствами изоляции repeatable read, и дополнительно в рамках подхода, основанного на блокировке, гарантирует, что так называемые «фантомные чтения» не могут произойти; это означает, что строки, которые INSERTed или DELETEd в рамках других транзакций, не будут обнаружены в данной транзакции. Строка, прочитанная в рамках данной транзакции, гарантированно продолжает существовать, а несуществующая строка гарантированно не может появиться при вставке из другой транзакции.

Сериализуемая изоляция обычно опирается на блокировку строк или диапазонов строк для достижения этого эффекта, что может увеличить вероятность возникновения тупиковых ситуаций и снизить производительность. Существуют также схемы, не основанные на блокировке, однако они обязательно предполагают отказ от транзакций при обнаружении коллизий записи.

Сессия¶

Контейнер или область действия для операций с базой данных ORM. Сессии загружают экземпляры из базы данных, отслеживают изменения в сопоставленных экземплярах и сохраняют изменения в единой единице работы при сбросе.

См.также

Использование сессии

составной первичный ключ¶

Строка primary key, имеющая более одного столбца. Конкретная строка базы данных уникальна на основе двух или более столбцов, а не только одного значения.

См.также

primary key

стиль 1.x¶

стиль 2.0¶

1.x-стиль¶

2.0-стиль¶

Эти термины являются новыми в SQLAlchemy 1.4 и относятся к плану перехода SQLAlchemy 1.4 -> 2.0, описанному в Переход на SQLAlchemy 2.0. Термин «стиль 1.x» относится к API, используемому в том виде, в котором он был документирован в SQLAlchemy серии 1.x и более ранних версиях (например, 1.3, 1.2 и т.д.), а термин «стиль 2.0» относится к тому, как API будет выглядеть в версии 2.0. Версия 1.4 реализует почти все API версии 2.0 в так называемом «переходном режиме».

См.также

Переход на SQLAlchemy 2.0

Включение использования стиля 2.0.

При использовании кода из примера документации, который указывает 2.0-style, используемый Engine, а также Session должен использовать режим «будущего» с помощью флагов create_engine.future и Session.future:

from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker


engine = create_engine("mysql://user:pass@host/dbname", future=True)
Session = sessionmaker(bind=engine, future=True)

ORM-запросы в стиле 2.0.

Помимо описанных выше изменений в Engine и Session, вероятно, самым главным изменением API, подразумеваемым в 1.x->2.0, является переход от использования объекта Query для операторов ORM SELECT к использованию конструкции select() в сочетании с методом Session.execute(). Общее изменение выглядит следующим образом. Дается Session и Query против этого Session:

list_of_users = session.query(User).join(User.addresses).all()

В новом стиле запрос строится отдельно от Session с помощью конструкции select(); при заполнении сущностями ORM, такими как класс User из ORM Tutorial, полученная конструкция Select получает дополнительное состояние «плагина», которое позволяет ей работать как Query:

from sqlalchemy import select

# a Core select statement with ORM entities is
# now ORM-enabled at the compiler level
stmt = select(User).join(User.addresses)

session = Session(engine)

result = session.execute(stmt)

# Session returns a Result that has ORM entities
list_of_users = result.scalars().all()

столбец id версии¶

В SQLAlchemy это относится к использованию определенного столбца таблицы, который отслеживает «версию» конкретной строки, поскольку строка меняет значения. Хотя существуют различные виды реляционных моделей, которые по-разному используют «столбец с идентификатором версии», ORM SQLAlchemy включает в себя определенную функцию, которая позволяет настроить такой столбец в качестве средства проверки устаревших данных, когда строка обновляется новой информацией. Если последняя известная «версия» этого столбца не совпадает с версией строки, когда мы пытаемся поместить в нее новые данные, мы знаем, что действуем на устаревшей информации.

Существуют и другие способы хранения «версионных» строк в базе данных, часто называемые «временными» данными. В дополнение к возможности версионирования в SQLAlchemy, в документации есть еще несколько примеров, см. ссылки ниже.

См.также

Настройка счетчика версий - встроенная в SQLAlchemy функция идентификации версии.

Версионирование объектов - другие примеры отображений, которые временно версифицируют строки.

удалено¶

Это описывает одно из основных состояний объекта, которое объект может иметь в пределах Session; удаленный объект - это объект, который ранее был постоянным и имел оператор DELETE, отправленный в базу данных в рамках flush для удаления его строки. Объект перейдет в состояние detached после фиксации транзакции сессии; в противном случае, если транзакция сессии будет откатана, DELETE будет отменен и объект вернется в состояние persistent.

См.также

Краткое введение в состояния объектов

уникальное ограничение¶

уникальный ключевой индекс¶

Уникальный ключевой индекс может однозначно идентифицировать каждую строку значений данных в таблице базы данных. Уникальный ключевой индекс включает в себя один столбец или набор столбцов в одной таблице базы данных. Никакие две разные строки или записи данных в таблице базы данных не могут иметь одинаковое значение данных (или комбинацию значений данных) в столбцах уникального ключевого индекса, если не используются значения NULL. В зависимости от конструкции таблица базы данных может иметь множество уникальных ключевых индексов, но не более одного индекса первичного ключа.

(через Википедию)

См.также

Unique key (via Wikipedia)

условие ГДЕ¶

Часть оператора SELECT, которая указывает критерии, по которым следует фильтровать строки. Это одно выражение SQL, которое следует за ключевым словом WHERE.

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' включает в себя предложение WHERE для SELECT.

условие о столбцах¶

Часть оператора SELECT, в которой перечисляются выражения SQL, возвращаемые в набор результатов. Выражения следуют непосредственно за ключевым словом SELECT и представляют собой список отдельных выражений, разделенных запятыми.

Например:

SELECT user_account.name, user_account.email
FROM user_account WHERE user_account.name = 'fred'

Выше список столбцов user_acount.name, user_account.email является пунктом столбцов в SELECT.

фасад¶

Объект, который служит в качестве лицевого интерфейса, маскирующего более сложный базовый или структурный код.

См.также

Facade pattern (via Wikipedia)

цепочка методов¶

Объектно-ориентированная техника, при которой состояние объекта создается путем вызова методов объекта. Объект имеет любое количество методов, каждый из которых возвращает новый объект (или, в некоторых случаях, тот же объект) с дополнительным состоянием, добавленным к объекту.

Два объекта SQLAlchemy, которые наиболее часто используют цепочку методов, - это объект Select и объект Query. Например, объекту Select можно присвоить два выражения для пункта WHERE, а также пункт ORDER BY, вызвав методы Select.where() и Select.order_by():

stmt = select(user.c.name).\
            where(user.c.id > 5).\
            where(user.c.name.like('e%').\
            order_by(user.c.name)

Каждый вызов метода выше возвращает копию исходного объекта Select с добавленными дополнительными классификаторами.

См.также

generative

цикломатическая сложность¶

Мера сложности кода, основанная на количестве возможных путей через исходный код программы.

См.также

Cyclomatic Complexity

читать без фиксации¶

Один из четырех уровней базы данных isolation, read uncommitted означает, что изменения, внесенные в данные базы данных в рамках транзакции, не станут постоянными до тех пор, пока транзакция не будет зафиксирована. Однако в рамках read uncommitted возможно, что данные, не зафиксированные в других транзакциях, могут быть доступны для просмотра в рамках другой транзакции; такие случаи известны как «грязное чтение».

читать с полной отдачей¶

Один из четырех уровней базы данных isolation, read committed характеризуется тем, что транзакция не будет подвергаться воздействию данных из других параллельных транзакций, которые еще не были зафиксированы, предотвращая так называемое «грязное чтение». Однако при read committed возможны неповторяющиеся чтения, то есть данные в строке могут измениться при повторном чтении, если другая транзакция зафиксировала изменения.