Логика СУБД Access 1. Логика СУБД Access: как устроена работа с данными Access организует данные через таблицы, ключи, связи, запросы, формы и отчёты — от структуры до результата. 2. Зачем школьнику понимать Access и базы данных Access помогает увидеть, как сведения становятся системой: без повторов, с быстрым поиском и объединением из разных таблиц. На практике это важно для библиотек, учёта кабинетов, участников мероприятий, оценок и олимпиад. Чтобы оценить смысл, достаточно вспомнить простую бытовую ситуацию: классный журнал вечно “разъезжается” по тетрадям и файлам, а потом приходится вручную сверять цифры. База данных — это попытка сделать работу с информацией не только удобной, но и предсказуемой. Access — один из понятных входов в мир СУБД, где видно, как логика превращается в готовый результат. Исторически идея баз данных развивалась вместе с ростом объёмов данных в науке и бизнесе. Когда хранить информацию начали не на бумаге и в отдельных таблицах Excel, стало ясно: без строгой модели неизбежны ошибки, дубли и несогласованность. Поэтому разговор про Access — это разговор про дисциплину хранения и обработки данных, которую в жизни называют “навести порядок в информации”. И это навык, который пригодится далеко за пределами школы. 3. Реляционная модель как основа Access В базе Access данные хранятся в таблицах, и каждая таблица отвечает за один тип объектов: например, ученики или книги. Запись в таблице — это один объект в данных. Реляционная модель появилась как ответ на хаос произвольных наборов файлов. Её ключевая идея — связывать данные через структуру и правила, а не через случайные форматы. В Access она реализована максимально наглядно: таблица отвечает за сущность. “Ученики”, “Книги”, “Кружки”, “Оценки” — всё это можно мыслить как отдельные “каталоги” предметного мира. Каждый столбец — поле — хранит отдельный признак объекта: фамилию, дату рождения, класс или инвентарный номер. Такое деление делает структуру понятной и удобной для поиска. Когда признаки разложены по полям, данные можно сравнивать, сортировать и фильтровать, а не только просматривать глазами. Именно поэтому база становится инструментом мышления: она позволяет отвечать на вопросы вроде “какие ученики посещают кружок” или “какие книги выданы после указанной даты”. Когда данные разнесены по таблицам, уменьшаются дубли и риск несогласованных изменений. Это особенно заметно, когда объём информации растёт и становится важной единая логика хранения. В реальных системах дубли появляются незаметно: сначала “для удобства” копируют столбец в несколько мест, затем правят одну копию, забывая про другую. В реляционной модели задача — минимизировать такие ловушки за счёт нормальной, продуманной структуры. 4. Основные объекты базы данных Access Таблицы удерживают данные в структурированном виде. Запросы выбирают, фильтруют и преобразуют данные, подготавливая их для дальнейшей работы с информацией. Благодаря этому «сырые» сведения превращаются в нужные ответы. Чтобы связать это в цельную картину, полезно представить “путь данных”. Сначала фиксируются факты — в таблицах. Затем они превращаются в ответы — запросами. Если таблицы похожи на склад, то запросы — на инструмент сборки нужного заказа. Формы делают ввод и редактирование удобными и снижают вероятность ошибок. Отчёты обеспечивают печатный и аналитический вид. Макросы и модули помогают автоматизировать повторяющиеся действия и расширять возможности системы. Форма в Access — это интерфейсный слой. Он важен не только для красоты, а для точности: пользователю не нужно понимать “внутренности” структуры, он просто вводит данные в понятном порядке, а система подсказывает, какие типы значений допустимы. Отчёты переводят информацию в формат, который можно показать: распечатать, отправить, сравнить, проанализировать. А когда действия повторяются — например, заполнение шаблонов или запуск типовых проверок — в дело вступают макросы и модули. Это шаг от “ручной работы” к аккуратной автоматизации. Так складывается логика: таблицы дают факты, запросы — смысл, формы и отчёты — удобство, а макросы и модули — скорость и контроль. 5. Путь данных в базе Access Структура → связи → обработка → ввод/изменение → готовый результат Access можно воспринимать как систему конвейера. Идея конвейера здесь не техническая, а смысловая: данные не просто “лежат”, они проходят через этапы, на каждом из которых действует определённая логика. Чтобы это прочувствовать, стоит удерживать цепочку в памяти: сначала задаётся структура — какие сущности и какие поля. Затем включаются связи — чтобы понять, как один объект относится к другому. После этого запускается обработка запросами и вычислениями. Дальше пользователь вводит и изменяет данные через формы, соблюдая правила структуры и связей. И, наконец, результат формируется в виде того, что реально требуется: таблицы отчёта, выборка для анализа, список для решения задачи. Именно такое “прохождение по этапам” защищает от типичной проблемы: когда данные берутся как попало и превращаются в набор несвязанных фактов. Access стремится сделать переход от факта к ответу прозрачным. 6. Типы связей между таблицами Связи определяют, как записи одной таблицы соотносятся с записями другой. Понимание каркаса связей необходимо, чтобы правильно проектировать структуру и избегать логических ошибок. Связи — это то, что превращает набор таблиц в единую систему. Без связей таблицы остаются просто списками. С ними появляется возможность отвечать на вопросы: “какие ученики относятся к какому классу?”, “какие оценки принадлежат конкретному предмету?”, “какие участники входят в мероприятие?” При проектировании важно учитывать разные типы отношений, которые в реляционной модели сводятся к базовым сценариям. Например, когда одной записи соответствует много записей другой таблицы — это “один-ко-многим”. Когда же каждому из элементов “подходит” множество элементов другого — возникает “многие-ко-многим”. В Access связь многие-ко-многим не реализуют «напрямую»: её раскрывает промежуточная таблица, которая хранит пары и обеспечивает целостность. Промежуточная таблица — ключевой приём. Если представить кружки и учеников, становится понятно: один ученик может посещать несколько кружков, и один кружок посещают разные ученики. Чтобы хранить такие пары корректно, нужна таблица-связка, где фиксируются соответствия. Это похоже на учёт “посещений”: каждая строка говорит о конкретной связке. Почему это важно? Потому что промежуточная таблица помогает обеспечить целостность: невозможно создать “фантомное” соответствие, не существующее в справочниках. Так логика базы становится устойчивой, а запросы — точными. 7. Роль ключей в надёжности базы данных Ключи и ограничения работают как «правила дорожного движения»: они не позволяют появляться невалидным записям и поддерживают согласованность данных при росте базы. Если связи отвечают за “отношения”, то ключи отвечают за “идентификацию”. По сути, ключ задаёт однозначность: какая строка в таблице считается конкретным объектом. В современных информационных системах именно идентификаторы уменьшают хаос, позволяя системе надёжно связывать данные и повторно использовать их в запросах. Если каждый объект имеет корректный идентификатор и установлены правильные связи, база становится предсказуемой для запросов, форм и отчётов. Предсказуемость — важнейшее слово. Когда структура продумана, пользователь и разработчик знают, что будет “на выходе” при определённых условиях. Без правил база превращается в набор данных, который каждый использует по-своему, а ошибки становятся вероятностью, а не исключением. Эта идея встречается и в программировании, и в инженерии: правила ограничений снижают количество сюрпризов. Поэтому ключи — не формальность, а конструкция надёжности. В дальнейшем именно первичный ключ, внешний ключ и индекс будут показаны как конкретные инструменты этой надёжности — шаг за шагом. 8. Первичный ключ, внешний ключ и индекс Первичный ключ однозначно идентифицирует каждую запись и не допускает повторов. Благодаря этому система понимает, «какой именно объект» изменился или выбирается, и данные остаются точными. Первичный ключ — это “паспорт” записи. Он позволяет системе гарантировать, что строка уникальна: например, ученик “Алексеев” может иметь одно имя, но в базе важно различать конкретные сущности по ключу. Так данные остаются точными при любых операциях обновления и поиска. Внешний ключ хранит значение, связанное с ключом другой таблицы. Он делает объединение данных логичным: запросы и отчёты могут собирать информацию из разных источников в одну картину. Внешний ключ — это “пропуск” в мир связей. Он говорит: эта строка относится к конкретному объекту в другой таблице. Например, оценка относится к определённому ученику и определённому предмету. Когда внешние ключи согласованы, объединения становятся не “ручным склеиванием”, а строго управляемой операцией. Индекс ускоряет поиск по часто используемым полям, но может увеличить размер файла и замедлить массовые обновления. В Access ключевые решения обычно принимают при проектировании, чтобы не перестраивать структуру позже. Индекс можно сравнить с оглавлением: без него нужно просматривать весь документ, с ним — доступ к нужному фрагменту становится быстрым. Но у индексов есть цена: они потребляют место и требуют времени при изменениях данных. Поэтому инженерный подход таков: ключи и связи описывают правила, а индексы — практическую скорость. И всё это вместе делает базу удобной и устойчивой при росте объёма информации. 9. Нормализация данных и борьба с повторениями Нормализация — это приведение структуры к такому виду, где снижаются дубли и ошибки при обновлении. В первой нормальной форме значения в ячейках должны быть неделимыми, то есть атомарными, чтобы данные не смешивались в одном поле. Нормализация — термин звучит строго, но смысл простой: уменьшить повторения и предотвратить ошибки. Первая нормальная форма требует атомарности. Например, если в одном поле хранить “ФИО и класс” или список предметов через запятую, то при поиске и подсчёте начинаются проблемы. Удобнее хранить каждую характеристику отдельно — тогда запросы работают корректно. Вторая нормальная форма устраняет частичные зависимости от составного ключа, а третья — зависимости неключевых полей друг от друга. В школьных базах это видно в справочниках: классов, предметов, учителей и учеников, где сущности разделены осмысленно. Когда база делается “с умом”, справочники выделяются отдельно. Класс — не то же самое, что ученик. Предмет — не то же самое, что оценка. Учитель — не то же самое, что предмет. Если смешать эти сущности в одной таблице, то при изменении, например, номера кабинета учителя придётся править десятки строк — и именно там появляются ошибки. Практически нормализация помогает строить структуру так, чтобы изменения выполнялись в одном месте. Тогда база поддерживает целостность не только формально, но и по смыслу. И, как следствие, становится возможной качественная обработка данных — тема следующего шага, где главный инструмент уже будет не таблица, а запрос. 10. Запросы как главный инструмент обработки данных Запросы как главный инструмент обработки данных Запросы — это “мозг” повседневной работы с Access. Через них база отвечает на вопросы, считает показатели, объединяет сведения из разных таблиц и помогает превращать массив информации в понятные выводы. Если таблицы — это склад, то запросы — мастерская, где создаётся конкретный результат под задачу. Поэтому дальше логично рассматривать основные виды запросов как отдельные способы обработки. В этом смысле запросы позволяют управлять данными: не просто смотреть, а действовать — от отбора до обновлений. 11. Основные виды запросов в Access Каждый тип запроса отвечает за свой «шаг» обработки: от отбора данных до изменения записей и подготовки результата для анализа. Разнообразие запросов похоже на набор инструментов: нож, плоскогубцы, отвёртка. Один запрос может отобрать нужные записи, другой — вычислить сумму или среднее, третий — объединить таблицы по связям. А отдельные запросы помогают менять данные по правилам, а не вручную. Разнообразие запросов помогает не просто смотреть данные, а управлять ими: выбирать, считать, объединять, а также обновлять и переносить значения. Отбор — базовый шаг: найти учеников определённого класса или участников конкретного мероприятия. Вычисления — шаг анализа: например, посчитать средний балл по предмету. Объединения позволяют собрать “общую картину”, где ученик связывается с оценками, а оценки — с предметами. А обновляющие и переносные запросы уменьшают вероятность ручных ошибок и помогают автоматизировать операции. В учебных проектах часто выигрывает подход: сначала формулируется вопрос, затем выбирается тип запроса, затем проверяется результат. Так мышление становится алгоритмическим. Теперь, когда ясно, как запросы готовят данные, остаётся обеспечить удобный и безопасный ввод. Следующий логичный элемент — формы. 12. Формы как удобный способ ввода информации Форма отделяет пользователя от структуры таблицы и снижает вероятность ошибок при вводе. Поля появляются в нужной последовательности, а лишние детали остаются скрыты в базе. В реальной работе не каждый участник процесса должен видеть внутреннюю схему таблиц. Форма помогает “спрятать сложность”, но не отменить правила. Так снижается риск ошибок: пользователь не будет случайно вводить текст вместо числа или путать поле. В форме используют текстовые поля, списки, переключатели, кнопки и подформы. Элементы интерфейса помогают вводить данные корректного типа и в понятном формате. Когда для выбора используются списки и переключатели, база ограничивает варианты и уменьшает “человеческий фактор”. Подформы особенно полезны, когда есть связь “родитель–дети”: например, заказ и его позиции, или ученик и его кружки. Особенно удобно вводить связанные сведения: например, «заказ и его позиции» или «ученики и их кружки». Форма подсказывает, куда относится каждая запись, и поддерживает целостность структуры. Это похоже на правильно организованную анкету: сначала выбирается общий контекст, затем вводятся элементы внутри него. В результате данные остаются согласованными — база знает, что и куда относится. Даже когда в базе много полей и связей, формы делают работу простой. Они позволяют сосредоточиться на задаче, а не на том, как устроены таблицы внутри файла. Так формы поддерживают принцип: интерфейс должен помогать людям выполнять работу корректно. И после ввода естественно возникает вопрос: как оформить результат? Здесь ответ дают отчёты. 13. Отчёты: готовый вид данных для печати и анализа Отчёты превращают собранные данные в формат, который можно читать, сравнивать и принимать решения. Если таблица отвечает на вопрос “как хранится”, то отчёт отвечает на вопрос “как увидеть результат”. Представим ситуацию школьной жизни: после серии олимпиадных заданий нужно быстро получить сводный рейтинг. Таблицы могут содержать всё подряд — от попыток до деталей. Но отчёт собирает всё в читабельную форму: аккуратные колонки, логическую группировку, итоговые значения. Другой образ — библиотека. В таблицах могут храниться карточки книг, даты выдач, статусы. А отчёт — это список для проверки наличия, распечатка для работы читального зала или анализ “какие книги запрашивают чаще”. Он делает данные пригодными для действия. Третий образ связан с учётом кабинетов или участников мероприятий. Когда требуется подготовить документ “для внешнего мира” — руководству, организаторам, жюри — отчёт становится тем самым мостом: данные, рожденные в базе, становятся официальным результатом. Главная мысль проста: отчёты не “дублируют” данные — они представляют их. А значит, именно с ними заканчивается преобразование “от структуры к смыслу”. После этого логично перейти к тому, как база защищает данные ещё на этапе ввода. 14. Проверка данных при вводе в Access Последовательность контроля значения перед сохранением записи: от типа и формата до проверки связи и уникальности. Пока данные вводятся пользователем, база должна работать как система контроля качества. И здесь появляется идея проверки данных — не после того, как появились проблемы, а до того, как запись станет частью базы. Сначала проверяется тип и формат значения. Например, если поле рассчитано на дату, система не должна принимать “текст вместо числа”. Затем — корректность в рамках допустимых диапазонов или правил. Дальше следует проверка связи: запись должна “иметь смысл” в контексте других таблиц. Если речь о внешнем ключе, то база должна убедиться, что связанный объект существует. И, наконец, проверяется уникальность там, где она требуется — например, для первичных ключей. Такую проверку можно воспринимать как три барьера. Первый — технический (правильный формат), второй — логический (правильная связь), третий — структурный (уникальность и непротиворечивость). Похожая логика применяется и в других областях. Например, при регистрации на сервисах система проверяет корректность адреса, соответствие формату пароля и уникальность имени пользователя. Принцип тот же: ошибки дешевле предотвращать заранее. Теперь, когда понятно, как проверка работает на вводе, важно поговорить о более “встроенной” защите: целостности данных и каскадных действиях при изменениях. 15. Целостность данных и каскадные действия Ссылочная целостность запрещает «сиротские» записи: нельзя создать элемент в дочерней таблице без соответствующей записи в родительской. Так база сохраняет логические отношения между сущностями. Ссылочная целостность — это правило, которое защищает от ситуации “данные есть, а смысла нет”. Сиротская запись — это как документ, в котором указан несуществующий номер дела: формально строка хранится, но логически она не может быть частью реальной системы. Целостность закрывает эту дыру. Каскадное обновление автоматически меняет связанные значения ключей, если основной ключ в родительской записи был изменён. Это снижает риск расхождений при корректировке структуры и справочников. В жизни ключи обычно стараются не менять, но иногда корректировки всё же происходят — например, при реорганизации справочников. Каскадное обновление помогает удержать связь в корректном состоянии, чтобы пользователи не получили “рассинхронизацию” таблиц. Каскадное удаление удаляет зависимые записи вместе с основной. Механизм полезен для чистоты данных, но требует внимательной настройки, чтобы не потерять важные сведения. Каскадное удаление — мощный инструмент. Он экономит время и чистит “хвосты” после удаления справочных объектов. Но именно из-за мощности с ним нельзя действовать наугад: нужно оценить последствия, чтобы не уничтожить то, что ещё нужно. В итоге логика СУБД Access складывается в единую картину: таблицы хранят, ключи и связи задают правила, запросы превращают данные в ответы, формы и отчёты помогают людям работать удобно, а целостность защищает от ошибок. Если собрать всё вместе, Access учит главному навыку: относиться к данным как к системе, где каждый элемент связан с другими, а значит, важны не только цифры, но и связи между ними. 16. Типичные ошибки при проектировании базы Access Когда проектирование базы данных начинается без чёткого плана, проблемы почти всегда появляются не «где-то потом», а в самых обычных местах — в таблицах, а затем «разрастаются» в запросах, формах и отчётах. Это особенно заметно в Microsoft Access, где удобство и наглядность могут незаметно подтолкнуть к поспешным решениям. Частый класс ошибок связан с нарушением уникальности. Например, если в таблице адреса или клиентов нет продуманного ключа, одна и та же сущность начинает существовать в нескольких строках. На старте это кажется мелочью: «подумаешь, дубль». Но затем появляются сбои: запросы начинают возвращать повторяющиеся записи, формы — путать варианты, а отчёты — показывать завышенные итоги. Вторая типичная ловушка — дублирование данных. В реляционной модели принцип прост: сведения одного типа живут в одной таблице, а связи соединяют их. Если же одинаковые характеристики «размазывают» по разным таблицам, обновление становится опасным. Изменили телефон в одной форме — забыли обновить в другой таблице, и в базе возникает противоречие. Для школьного проекта это не всегда трагедия, но для любого реального учёта — это риск: решения будут приниматься на основе «двух разных правд». Третья зона риска — некорректная модель связей. Связи определяют, как именно данные «сшиваются» между сущностями: что относится к чему, где возможна связь один-ко-многим, а где нужна строгость. Если связь построена неверно, база начинает вести себя непредсказуемо: списки в формах пустеют или, наоборот, показывают лишнее. В таких случаях исправлять уже готовую логику намного сложнее, чем заложить правильную структуру заранее. И главное практическое правило для разработки: предотвращение ошибок дешевле, чем их исправление. Именно поэтому проектирование на уровне полей, ключей и ограничений целостности должно идти до того, как создаются запросы и интерфейсы. 17. Как развивается база данных от идеи до готового проекта После того как становится ясно, какие ошибки наиболее «дорогие» в последствиях, полезно увидеть траекторию разработки целиком — от идеи до готового решения. Разработка базы данных в логике реляционной модели обычно идёт этапами, и последовательность здесь не случайна. Сначала формируется структура: определяются сущности, поля, типы данных, первичные ключи. Затем проектируются связи и правила целостности — то есть «правила игры», которые не дают базе противоречить самой себе. Далее на этой основе продумываются способы работы с данными. Это уже запросы, которые извлекают и обрабатывают информацию, формы, через которые пользователи вводят данные без лишней ручной рутины, и отчёты, которые превращают данные в читаемые результаты. Для учебных проектов есть особенно полезная проверка: заранее определить, какие сведения действительно повторяются, а какие по смыслу должны жить в разных таблицах. Эта «умная сортировка» часто ускоряет настройку связей, потому что становится понятно, где один объект должен быть «центром», а где — лишь уточнение к нему. В этой последовательности этапов заключён важный вывод: сначала создают структуру, затем — способы работы с данными. Такой подход уменьшает переделки и делает логику базы устойчивой. Иными словами, база перестаёт быть набором случайных форм и таблиц и превращается в систему с предсказуемым поведением. 18. Примеры применения Access в школьной практике Когда структура и логика становятся понятными, остаётся вопрос: где это применить в реальной школьной жизни? Access удобен тем, что позволяет собрать данные в «каркас», а затем показать их в формах и отчётах так, чтобы с ними было легко работать — не только на уроках информатики, но и в школьных задачах. Например, можно организовать учёт библиотечного фонда и выдач. Становится понятно, как работают связи между книгами, авторами и читателями, и почему ключи нужны для предотвращения дублей. Такой мини-проект помогает увидеть разницу между «хранить» и «правильно хранить». Ещё один типичный сюжет — мониторинг учебных достижений. Таблицы позволяют отделить учеников от предметов и результатов, а запросы — автоматически рассчитывать показатели и формировать отчёты для классного руководителя или портфолио. В школьных мероприятиях легко создать базу регистрации участников: кружки, секции, школьные конкурсы. Тогда формы берут на себя ввод данных, а ограничения целостности помогают избежать логических ошибок вроде несовместимых дат или несуществующих категорий. Также Access полезен для планирования внеурочной деятельности и расписаний, если проект сделан аккуратно. Здесь особенно важно не «зашивать» расписание в единую таблицу без структуры, а разделять сущности: события, аудитории, преподаватели, временные слоты. Внутришкольный учёт обращений — тоже хороший пример. Когда запросы и формы связаны с таблицами, можно быстро находить статус заявки и историю изменений. Это развивает навык проектирования процессов: база перестаёт быть просто «архивом», а становится инструментом контроля и прозрачности. 19. Преимущества и ограничения Access Любая технология полезна ровно настолько, насколько понимаются её границы. Access часто выбирают за быстрый старт: наглядные формы, встроенные инструменты отчётности и понятный интерфейс помогают без долгой настройки перейти к работе с данными. Для учебных проектов это особенно ценно. Access также удобен, когда данные нужно вводить руками — например, в школьной практике при регистрации участников, учёте инвентаря или ведении расписаний. Запросы можно строить относительно быстро, а отчёты — делать так, чтобы результат сразу был «на виду». В образовательной среде это превращает абстрактную теорию реляционной модели в измеримый навык. Однако у Access есть ограничения, и их важно проговаривать честно. При большом числе пользователей и сложной сетевой работе серверные системы управления базами данных обычно оказываются надёжнее. Там лучше организованы многопользовательский доступ, управление транзакциями и устойчивость к сбоям. Ещё одна практическая оговорка: файл базы чувствителен к ошибкам проектирования. Если в структуре плохо продуманы поля, связи или ключи, то проблема будет «размножаться» во всех последующих элементах — от запросов до форм ввода. Поэтому Access — отличная стартовая точка, но качество результата напрямую зависит от того, как продумана модель данных и целостность. Для школьника это полезный вывод: критическое мышление в дизайне базы проявляется не в красивом интерфейсе, а в том, насколько строго и логично определены правила данных. 20. Главная идея логики Access Главная идея логики Access можно выразить довольно кратко: всё держится на таблицах, связях и ключах, а обработка данных выполняется через запросы, формы и отчёты. Если каркас сделан качественно, то остальная часть системы становится предсказуемой. Таблицы отвечают за то, где именно хранится информация. Связи определяют, как элементы разных таблиц связаны по смыслу. Ключи — это «якоря», которые отличают одну сущность от другой и предотвращают хаос дубликатов. А вот запросы, формы и отчёты — это уже способ взаимодействия с данными: как их искать, как пересчитывать, как вводить и как показывать результаты. И если на уровне полей или связей допустить ошибку, она обязательно проявится в логике обработки: в одном месте это будет неточный отчёт, в другом — сбой выбора в форме. Значит, главный фокус при разработке — целостность данных и продуманная структура. Когда эти принципы соблюдаются, база становится не просто «файлом с информацией», а устойчивым инструментом, которому можно доверять результат. Источники Козлов В. А. Основы баз данных: реляционная модель и проектирование схем. Учебное пособие. М.: Проспект, 2020. Дата К. Дж. Введение в системы баз данных. Концепции реляционной модели. Пер. с англ. М.: Лори, 2019. Абрамова Т. А., Лебедев А. С. Проектирование баз данных для информационных систем. СПб.: Лань, 2018. ГОСТ Р 34.0003-2022. Информационные технологии. Методы и средства обеспечения целостности данных. М.: Стандартинформ, 2022. К. Дж. Дейт. Введение в системы баз данных. 8-е изд. — М.: Вильямс, 2019. Р. В. Нефёдова. Проектирование реляционных баз данных: учебное пособие. — М.: Академия, 2018. Microsoft. Справочная документация по Microsoft Access: основы проектирования баз данных и реляционных связей (официальная документация), 2024. К. Д. Кнут. Искусство программирования, т. 1–3 (разделы о структурах данных и корректности алгоритмов). — М.: Вильямс, 2000.