Текст выступления:

Логика СУБД 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.