Проектирование и реализация базы данных для системы видеопроката: Комплексное руководство для курсовой работы

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

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

Теоретические основы реляционных баз данных

В основе любой современной информационной системы лежит база данных – сложный, но крайне эффективный механизм для организации и хранения информации. Чтобы понять, как проектировать и реализовывать такие системы, необходимо погрузиться в их фундаментальные принципы, особенно в контексте реляционной модели, которая доминирует в мире данных уже несколько десятилетий, предоставляя надёжный каркас для построения масштабируемых и целостных решений.

Основные понятия и определения

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

Однако сама по себе база данных — это лишь хранилище. Для взаимодействия с ней необходимо специальное программное обеспечение. Это Система управления базами данных (СУБД) — программный комплекс, предназначенный для создания, поддержания и использования баз данных. СУБД выступает посредником между пользователем (или приложением) и данными, обеспечивая их целостность, безопасность и доступность.

В реляционных базах данных информация организована в виде таблиц. Каждый такой объект, о котором мы хотим хранить информацию, называется сущностью. Примерами сущностей могут быть «Клиент», «Фильм», «Прокат». Каждая сущность имеет свои характеристики, которые мы называем атрибутами. Например, для сущности «Клиент» атрибутами будут «Имя», «Адрес», «Телефон».

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

Реляционная модель данных и её создатели

История реляционной модели данных — это история интеллектуального прорыва, совершенного в 1970 году британским учёным Эдгаром Ф. Коддом (Edgar Frank Codd). В своей знаковой работе «A Relational Model of Data for Large Shared Data Banks» он предложил революционный подход к организации данных, который кардинально отличался от существовавших на тот момент иерархических и сетевых моделей. Кодд предложил рассматривать данные как наборы двумерных таблиц (отношений), что значительно упростило их структуру и повысило гибкость.

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

Помимо Кодда, огромный вклад в развитие и популяризацию реляционной модели внёс Кристофер Дж. Дейт (C. J. Date), автор фундаментального труда «Введение в системы баз данных». Его работы стали настольными книгами для множества поколений разработчиков и архитекторов баз данных, систематизируя и развивая идеи Кодда. Благодаря их усилиям, реляционная модель стала стандартом де-факто в мире баз данных и остается таковой по сей день.

12 правил Кодда для реляционных СУБД

В 1985 году Эдгар Кодд сформулировал набор из 12 правил (хотя на самом деле их 13, если учитывать нулевое), которые должны служить критериями для оценки «реляционности» любой СУБД. Эти правила являются краеугольным камнем реляционной теории и обеспечивают понимание того, как должна функционировать истинно реляционная система.

Нулевое и первые три правила: Основы реляционной философии

Нулевое правило Кодда (Основное правило) гласит, что любая реляционная СУБД должна быть способна полностью управлять базой данных, используя исключительно свои реляционные возможности. Это означает, что для работы с данными не должны требоваться нереляционные инструменты или низкоуровневые API. Вся функциональность — определение, манипуляция, контроль целостности — должна быть доступна через реляционный язык.

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

Второе правило Кодда (Гарантированный доступ к данным) требует, чтобы доступ к каждому элементу данных был гарантирован с помощью комбинации имени таблицы, первичного ключа строки и имени столбца. Это правило подчеркивает важность уникальной адресации каждого атомарного значения, что обеспечивается структурой «Таблица.ПервичныйКлюч.Столбец».

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

Четвертое, пятое и шестое правила: Язык, метаданные и представления

Четвертое правило Кодда (Доступ к словарю данных в терминах реляционной модели) гласит, что описание базы данных на логическом уровне должно быть представлено в том же виде, что и основные данные, то есть словарь данных должен сохраняться в форме реляционных таблиц, и СУБД должна поддерживать доступ к нему при помощи стандартных языковых средств, используемых для работы с пользовательскими данными. Иными словами, метаданные (информация о структуре БД) должны быть доступны так же, как и обычные данные, через тот же реляционный язык (например, SQL).

Пятое правило Кодда (Полнота подъязыка данных) требует, чтобы система поддерживала по крайней мере один реляционный язык, который имеет четко определенный синтаксис, является полным для операций с данными и поддерживает определение данных, манипулирование данными, правила целостности и авторизацию, а также транзакции. SQL (Structured Query Language) является классическим примером такого языка, обеспечивающего полный цикл работы с БД.

Шестое правило Кодда (Обновление представлений) утверждает, что все представления (views), которые теоретически могут быть обновлены, должны быть обновляемы системой. Представления — это виртуальные таблицы, основанные на запросах. Если данные, лежащие в основе представления, могут быть однозначно изменены через него, СУБД должна поддерживать такую возможность.

Седьмое, восьмое и девятое правила: Манипуляции данными и независимость

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

Восьмое правило Кодда (Физическая независимость данных) гласит, что изменения в физических методах доступа к данным и структурах их хранения не должны влиять на программы-приложения и специальные программы. Это правило обеспечивает, что оптимизация хранения или изменение оборудования не потребует переписывания пользовательского кода.

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

Десятое, одиннадцатое и двенадцатое правила: Целостность, распределение и защита

Десятое правило Кодда (Независимость целостности) требует, чтобы правила целостности (такие как ссылочная целостность) были определяемы на языке данных, хранились в онлайн-каталоге и не могли быть обойдены с помощью низкоуровневых языков. Это гарантирует, что правила, обеспечивающие корректность данных, являются неотъемлемой частью схемы БД и применяются автоматически.

Одиннадцатое правило Кодда (Независимость распределения) заявляет, что программы-приложения и специальные программы не должны зависеть от того, распределена ли база данных по нескольким физическим местоположениям или хранится централизованно. Это правило предвосхитило развитие распределенных баз данных и подчеркивает важность абстракции от физического расположения данных.

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

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

Инфологическое проектирование базы данных (Концептуальная модель)

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

Сущности, атрибуты и связи

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

• Кассета (или Фильм): Представляет собой конкретную копию фильма, доступную для проката.
• Клиент: Физическое лицо, арендующее фильмы.
• Категория (или Жанр): Классификация фильмов (например, «Боевик», «Комедия», «Драма»).
• Прокат (или Аренда): Запись о факте выдачи кассеты клиенту на определенный срок.

Каждая сущность обладает набором характеристик, называемых атрибутами. Эти атрибуты являются значимыми свойствами, которые мы хотим хранить в базе данных. Рассмотрим их для наших сущностей:

Сущность	Атрибуты	Первичный ключ
Кассета	Код кассеты, Название, Год выпуска, Режиссер, Актерский состав, Стоимость проката, Код категории	Код кассеты
Клиент	Идентификатор клиента, Имя, Паспортные данные, Контактная информация, Адрес, Телефон	Идентификатор клиента
Категория	Код категории, Название категории, Коэффициент для расчета стоимости проката	Код категории
Прокат	Номер проката, Дата начала, Дата окончания, Статус проката (активен/завершен), Идентификатор клиента, Код кассеты	Номер проката

После определения сущностей и их атрибутов необходимо установить связи — то есть, как эти сущности взаимодействуют между собой. Для видеопроката можно выделить следующие ключевые связи:

1. «Кассета» — «Категория»:
   • Тип связи: Один-ко-многим (1:M).
   • Описание: Каждая кассета относится ровно к одной категории, но одна категория может включать множество кассет. Например, фильм «Матрица» относится к категории «Боевик», а категория «Боевик» содержит множество фильмов.
   • Реализация: Атрибут Код категории в сущности «Кассета» будет ссылаться на первичный ключ Код категории в сущности «Категория».
2. «Прокат» — «Клиент»:
   • Тип связи: Один-ко-многим (1:M).
   • Описание: Каждый прокат оформляется для одного клиента, но один клиент может иметь множество записей о прокатах.
   • Реализация: Атрибут Идентификатор клиента в сущности «Прокат» будет ссылаться на первичный ключ Идентификатор клиента в сущности «Клиент».
3. «Прокат» — «Кассета»:
   • Тип связи: Один-ко-многим (1:M).
   • Описание: Каждый прокат связан с одной конкретной кассетой, но одна и та же кассета может быть арендована в разные периоды (т.е., фигурировать в нескольких записях о прокате).
   • Реализация: Атрибут Код кассеты в сущности «Прокат» будет ссылаться на первичный ключ Код кассеты в сущности «Кассета».

ER-модель и ER-диаграммы

Для визуализации этой концептуальной модели используется ER-модель (Entity-Relationship model), или модель «сущность — связь». Это мощный инструмент, позволяющий графически представить структуру данных предметной области. ER-диаграмма (ERD) — это графическая схема, которая отображает сущности, их атрибуты и связи между ними, используя стандартизированные графические обозначения.

Принципы ER-моделирования включают:

• Сущности обычно представляются прямоугольниками.
• Атрибуты — овалами, соединенными с сущностями. Первичные ключи часто подчеркиваются.
• Связи — ромбами, соединяющими сущности. Тип связи (один-к-одному, один-ко-многим, многие-ко-многим) обозначается с помощью специальных символов на концах линий связи (например, «воронья лапка» для обозначения «многих»).

Давайте представим упрощенную ER-диаграмму для нашей системы видеопроката:

erDiagram
    CLIENT ||--o{ RENTAL : "оформляет"
    CASSETTE ||--o{ RENTAL : "включает"
    CATEGORY ||--o{ CASSETTE : "относится к"

    CLIENT {
        INT "Идентификатор клиента" PK
        VARCHAR Имя
        VARCHAR Паспортные_данные
        VARCHAR Контактная_информация
        VARCHAR Адрес
        VARCHAR Телефон
    }

    CASSETTE {
        INT "Код кассеты" PK
        VARCHAR Название
        INT Год_выпуска
        VARCHAR Режиссер
        VARCHAR Актерский_состав
        DECIMAL Стоимость_проката
        INT "Код категории" FK
    }

    CATEGORY {
        INT "Код категории" PK
        VARCHAR Название_категории
        DECIMAL Коэффициент_стоимости
    }

    RENTAL {
        INT "Номер проката" PK
        DATE Дата_начала
        DATE Дата_окончания
        VARCHAR Статус_проката
        INT "Идентификатор клиента" FK
        INT "Код кассеты" FK
    }

На этой диаграмме:

• Прямоугольники обозначают сущности (CLIENT, CASSETTE, CATEGORY, RENTAL).
• Внутри прямоугольников перечислены атрибуты, с указанием первичных ключей (PK) и внешних ключей (FK).
• Линии со «стрелками» или «вороньими лапками» указывают на тип связи. Например, CLIENT ||--o{ RENTAL означает, что один клиент может оформить множество прокатов (один-ко-многим). CATEGORY ||--o{ CASSETTE означает, что одна категория может содержать множество кассет.

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

Даталогическое проектирование базы данных (Логическая модель)

После того как концептуальная модель предметной области «Видеопрокат» тщательно проработана и визуализирована с помощью ER-диаграммы, следующим критически важным этапом является даталогическое проектирование. Этот этап представляет собой мост от абстрактного представления данных к конкретной структуре, которая может быть реализована в выбранной СУБД. Здесь мы преобразуем сущности и атрибуты в таблицы и столбцы, определяем типы данных и, что особенно важно, применяем принципы нормализации для оптимизации структуры базы данных.

Нормализация реляционных баз данных

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

Нормализация — это формальная процедура, производимая над базой данных с целью удаления избыточности, уменьшения потенциальной противоречивости хранимой информации и приведения структуры БД к виду, обеспечивающему минимальную избыточность. Это систематический подход к проектированию таблиц, который позволяет минимизировать дублирование данных и избежать аномалий при вставке, обновлении и удалении.

Основной инструмент нормализации — это нормальные формы. Нормальная форма — это свойство отношения (таблицы) в реляционной модели данных, характеризующее его с точки зрения избыточности. Общепринятой практикой, рекомендованной компетентными специалистами, является достижение как минимум третьей нормальной формы (3НФ), поскольку это обеспечивает хороший баланс между минимизацией избыточности и сложностью структуры.

Первая нормальная форма (1НФ)

Самым базовым уровнем нормализации является Первая нормальная форма (1НФ). Она задает фундаментальные требования к структуре таблицы:

1. Атомарность атрибутов: Все атрибуты (столбцы) в таблице должны быть простыми, или атомарными. Это означает, что каждое значение в ячейке таблицы не может быть далее разбито на более мелкие смысловые части. Например, атрибут «Полное имя» не атомарен, если мы хотим отдельно работать с «Именем» и «Фамилией». Вместо этого должны быть отдельные атрибуты «Имя» и «Фамилия».
2. Скалярные значения: Данные на пересечении строк и столбцов должны иметь исключительно скалярные (единичные) значения. Не допускаются списки, массивы или вложенные структуры в одной ячейке.
3. Отсутствие дублирующих строк: Каждая строка в таблице должна быть уникальной. Это требование естественным образом удовлетворяется наличием первичного ключа.
4. Отсутствие повторяющихся столбцов: В таблице не должно быть групп повторяющихся столбцов, таких как «Телефон1», «Телефон2», «Телефон3». Вместо этого следует создать отдельную таблицу для хранения контактных данных и связать её с основной таблицей.

Пример: Если бы в нашей таблице «Кассета» был атрибут «Актерский состав», содержащий список актеров (например, «Том Хэнкс, Мэрил Стрип»), это нарушало бы 1НФ. Для соблюдения 1НФ, необходимо либо иметь отдельную таблицу «Актеры» и связующую таблицу «Фильм_Актер», либо, если цель — просто хранить список без необходимости детального поиска по актерам, рассматривать весь список как атомарное строковое значение. В нашем случае, мы будем рассматривать «Актерский состав» как атомарную строку для простоты.

Вторая нормальная форма (2НФ)

Для того чтобы таблица находилась во Второй нормальной форме (2НФ), должны быть выполнены два условия:

1. Отношение (таблица) должно находиться в 1НФ.
2. Каждый неключевой столбец должен зависеть от первичного ключа в целом, а не от его части.

Это правило особенно актуально для таблиц, у которых первичный ключ состоит из нескольких атрибутов (составной первичный ключ). Если первичный ключ состоит из одного столбца, то таблица, находящаяся в 1НФ, автоматически находится и во 2НФ.

Пример: Предположим, у нас есть таблица Прокат_Детали, где первичный ключ состоит из (Номер проката, Код кассеты). Если в этой таблице хранится Название фильма, Режиссер (которые зависят только от Кода кассеты, а не от всего первичного ключа Номер проката + Код кассеты), то это нарушает 2НФ. Решение — вынести Название фильма и Режиссер в отдельную таблицу Кассеты, где Код кассеты будет первичным ключом. В нашей ER-модели мы уже спроектировали таблицы таким образом, что Название и Режиссер хранятся в таблице Кассета, а Прокат лишь ссылается на Кассету через Код кассеты. Таким образом, наша модель изначально стремится к 2НФ.

Третья нормальная форма (3НФ) и транзитивная зависимость

Третья нормальная форма (3НФ) является одним из наиболее важных и широко применяемых уровней нормализации. Для того чтобы таблица находилась в 3НФ, должны быть выполнены следующие условия:

1. Отношение (таблица) должно находиться во 2НФ.
2. Все неключевые атрибуты должны нетранзитивно зависеть от первичного ключа. Это означает, что в записи не должно быть столбцов с неключевыми значениями, которые зависят от других неключевых значений.

Проще говоря, 3НФ устраняет транзитивные зависимости. Транзитивная зависимость возникает, когда атрибут С транзитивно зависит от атрибута А, если А функционально определяет В (А → В) и В функционально определяет С (В → С), но при этом А функционально не определяет В, а В функционально не определяет С. На практике это означает, что неключевое поле зависит не напрямую от первичного ключа, а через другое неключевое поле.

Пример: Рассмотрим нашу сущность «Кассета» с атрибутами: Код кассеты (ПК), Название, Код категории (ВК), Название категории, Коэффициент для расчета стоимости проката.
Здесь:

• Код кассеты → Код категории (каждая кассета относится к одной категории)
• Код категории → Название категории
• Код категории → Коэффициент для расчета стоимости проката

Таким образом, Название категории и Коэффициент для расчета стоимости проката транзитивно зависят от Кода кассеты через Код категории. Для устранения этой транзитивной зависимости мы выносим Название категории и Коэффициент для расчета стоимости проката в отдельную таблицу «Категория», где Код категории становится первичным ключом. Таблица «Кассета» будет содержать только внешний ключ Код категории, ссылающийся на «Категорию».

До нормализации (нарушение 3НФ):

Код кассеты	Название	Код категории	Название категории	Коэффициент стоимости
101	Фильм A	1	Боевик	1.2
102	Фильм B	2	Комедия	1.0
103	Фильм C	1	Боевик	1.2

Здесь «Название категории» и «Коэффициент стоимости» зависят от «Кода категории», а не напрямую от «Кода кассеты».

После нормализации (соответствие 3НФ):

Таблица Кассета:

Код кассеты	Название	Код категории
101	Фильм A	1
102	Фильм B	2
103	Фильм C	1

Таблица Категория:

Код категории	Название категории	Коэффициент стоимости
1	Боевик	1.2
2	Комедия	1.0

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

Денормализация (краткий обзор)

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

Денормализация — это намеренное добавление избыточных копий и неудовлетворительных зависимостей в заранее нормализованную базу данных с целью повышения скорости чтения и улучшения производительности запросов. Важно подчеркнуть, что денормализация применяется после того, как база данных была полностью нормализована, и только для решения конкретных проблем производительности, выявленных в процессе эксплуатации. Это компромисс между избыточностью данных и скоростью доступа. Денормализация должна применяться с осторожностью, поскольку она увеличивает риски возникновения аномалий данных, и эти риски должны быть тщательно управляемы, например, с помощью триггеров или хранимых процедур, обеспечивающих согласованность дублированных данных. Для курсовой работы по проектированию базы данных обычно рекомендуется придерживаться нормализованной структуры до 3НФ, а денормализацию рассматривать как продвинутую технику оптимизации.

Выбор и обоснование СУБД для реализации (на примере MS Access)

После тщательного проектирования логической структуры базы данных, следующим практическим шагом является выбор подходящей Системы Управления Базами Данных (СУБД) для её реализации. Этот выбор зависит от множества факторов: масштаба проекта, требований к производительности, доступных ресурсов, бюджета и, конечно же, опыта разработчика. Для нашей курсовой работы по проектированию базы данных видеопроката мы остановимся на Microsoft Access.

Обзор возможностей MS Access

Microsoft Access — это реляционная СУБД, которая является частью пакета Microsoft Office. Её популярность обусловле рядом ключевых характеристик, делающих её привлекательным выбором, особенно для настольных приложений и учебных проектов:

1. Интеграция с Microsoft Office: Access тесно интегрирован с другими приложениями Microsoft Office, такими как Excel, Word и Outlook. Это упрощает импорт/экспорт данных, создание отчетов и автоматизацию задач.
2. Простота использования: Интерфейс Access интуитивно понятен для пользователей, не имеющих глубоких знаний в программировании баз данных. Он предоставляет графические конструкторы для создания таблиц, форм, запросов и отчетов, что значительно ускоряет разработку.
3. Широкий функционал: MS Access предоставляет полноценные средства для работы с данными:
   • Таблицы: Для хранения структурированных данных.
   • Запросы: Для выборки, фильтрации, сортировки и агрегирования данных. Возможность создания запросов на выборку, обновление, добавление и удаление.
   • Формы: Для удобного ввода, просмотра и редактирования данных, а также для создания пользовательских интерфейсов.
   • Отчеты: Для представления данных в печатном или электронном виде, с возможностью форматирования, группировки и вычислений.
   • Макросы и VBA (Visual Basic for Applications): Для автоматизации задач и расширения функционала.
4. Поддержка SQL: Несмотря на графические инструменты, Access полностью поддерживает стандартный язык SQL, что позволяет выполнять сложные запросы и манипулировать данными программно.
5. Локальное хранение данных: Access хранит всю базу данных в одном файле (.mdb или .accdb), что упрощает перенос, резервное копирование и развертывание для небольших систем.

Для курсовой работы по базам данных создание базы данных с помощью Microsoft Access является отличным решением, поскольку этот инструмент реляционной базы данных прост в работе и позволяет сосредоточиться на концепциях проектирования, а не на сложностях настройки серверной СУБД.

Ограничения и преимущества MS Access для курсовых работ

Как и любой инструмент, MS Access имеет свои преимущества и ограничения, особенно применительно к учебным проектам:

Преимущества для курсовых работ:

• Идеально для настольных приложений: MS Access отлично подходит для создания автономных баз данных, используемых одним или несколькими пользователями в локальной сети. Это соответствует типичным требованиям курсовых работ.
• Быстрая разработка прототипов: Благодаря наличию множества готовых шаблонов и интуитивно понятным конструкторам, можно быстро создать прототип системы и продемонстрировать функциональность.
• Наглядность и простота изучения: Студенту легко освоить базовые концепции проектирования и реализации БД, не отвлекаясь на сложности администрирования серверных СУБД.
• Широкая доступность: MS Access входит в состав пакета Microsoft Office, который широко распространен в образовательных учреждениях и на персональных компьютерах.
• Фокус на предметной области: Использование Access позволяет студенту больше внимания уделить анализу предметной области, проектированию структуры данных и логике бизнес-процессов, а не низкоуровневому программированию или настройке серверных систем.

Ограничения MS Access:

• Размер файла базы данных: MS Access имеет ограничение на размер файла базы данных (.mdb или .accdb) до 2 Гбайт (за вычетом места, необходимого системным объектам). Для крупномасштабных корпоративных систем это может быть серьезным недостатком, но для учебного проекта видеопроката это более чем достаточно.
• Количество объектов: Число объектов в базе данных (таблиц, запросов, форм, отчетов) ограничено до 768, а количество модулей — до 1 000. Этого также хватает для большинства курсовых работ.
• Масштабируемость и многопользовательский доступ: Access не предназначен для высоконагруженных систем с большим количеством одновременно работающих пользователей. При одновременном доступе нескольких пользователей могут возникать проблемы с производительностью и блокировкой данных.
• Безопасность: Средства безопасности в Access менее развиты по сравнению с серверными СУБД (SQL Server, MySQL, PostgreSQL), что делает его менее подходящим для хранения конфиденциальных данных в критически важных системах.

Несмотря на эти ограничения, для практической реализации автоматизированной информационной системы на СУБД MS Access в рамках курсовой работы по дисциплине «Базы данных» этот выбор является вполне оправданным и распространенным. Например, база данных «Видеопрокат», спроектированная с учетом принципов нормализации, может быть успешно реализована в Microsoft Access 2010 или более поздних версиях, демонстрируя все ключевые аспекты работы с реляционными данными.

Функциональные требования и бизнес-правила системы видеопроката

После того как выбрана СУБД и проработана логическая структура данных, необходимо четко определить, что именно система должна делать и какие ограничения на неё накладываются. Этот этап критически важен, так как он формирует основу для дальнейшей разработки пользовательского интерфейса, запросов и отчетов.

Основные функциональные задачи

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

1. Регистрация нового клиента: Система должна предоставлять возможность добавления информации о новых клиентах, включая их идентификационные данные (имя, паспортные данные), контактную информацию (адрес, телефон).
2. Учет фильмов и кассет:
   • Регистрация нового фильма: Добавление информации о фильмах (название, режиссер, год выпуска, актерский состав, категория).
   • Учет кассет с фильмом: Ведение учета конкретных экземпляров кассет (их кодов, текущего статуса — «в наличии», «в прокате», «списана»).
3. Управление доступными фильмами: Возможность просмотра списка фильмов, фильтрации по категории, режиссеру, году выпуска.
4. Оформление и завершение аренды (проката):
   • Выдача кассет из проката: Запись информации о начале проката, дате выдачи, клиенте и выданной кассете.
   • Возврат кассет из проката: Отметка о возврате, расчет стоимости проката, обновление статуса кассеты.
5. Автоматическое определение кассет и клиентов по коду: Для ускорения работы системы, должна быть реализована возможность быстрого поиска и идентификации клиентов и кассет по их уникальным кодам.
6. Система тарифов и скидок: Внедрение механизмов для расчета стоимости проката с учетом категории фильма и, возможно, скидок для постоянных клиентов.
7. Списание кассеты: Учет причин списания кассет (потеря, порча, выкуп) �� соответствующее изменение их статуса в базе данных.
8. Управление сотрудниками: Хотя это может быть расширенным функционалом, для более комплексной системы возможен учет сотрудников, ранжирование, наем и увольнение.

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

Бизнес-правила и ограничения

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

1. Зависимость стоимости проката от категории фильма: Стоимость проката должна рассчитываться на основе базовой ставки и коэффициента, зависящего от категории фильма. Например, новинки или фильмы высокой категории могут иметь повышенный коэффициент.
2. Правила ссылочной целостности: Это критически важный набор ограничений, обеспечивающий согласованность данных между связанными таблицами:
   • Невозможность удаления записи из главной таблицы, если существуют связанные с ней записи в подчиненной таблице. Например, нельзя удалить запись о клиенте, если за ним числятся незавершенные или завершенные прокаты.
   • Невозможность изменения значения ключевого поля в главной таблице, если существуют связанные записи. Если изменить Идентификатор клиента в таблице «Клиенты», это нарушит связи с таблицей «Прокат».
   • Невозможность ввода в связанное поле подчиненной таблицы значения, отсутствующего в связанном поле главной таблицы. Нельзя записать прокат для Кода кассеты, которого не существует в таблице «Кассета».
3. Уникальность данных: Идентификационные поля, такие как Код кассеты, Идентификатор клиента, Номер проката, должны быть уникальными.
4. Обязательность полей: Некоторые поля (например, Название фильма, Имя клиента, Дата начала проката) не могут быть пустыми (NULL).
5. Аутентификация пользователей: Для защиты данных и учета всех действий в системе может быть внедрена базовая аутентификация пользователей, позволяющая различать сотрудников, имеющих право на определенные операции. Это обеспечивает контроль доступа и предотвращает несанкционированные изменения.

Эти бизнес-правила и ограничения прямо влияют на проектирование схемы базы данных, выбор типов данных, установку связей и применение правил целостности данных в СУБД. Их четкое определение на ранних этапах работы позволяет избежать ошибок и несоответствий в готовой системе.

Реализация системы и обеспечение целостности данных

После того как теоретическая база заложена, концептуальная и логическая модели разработаны, а функциональные требования определены, наступает этап практической реализации. На этом этапе мы переходим к созданию конкретных компонентов базы данных в выбранной СУБД (MS Access), таких как формы для взаимодействия с пользователем, запросы для обработки данных и отчеты для их анализа. Особое внимание уделяется механизмам обеспечения целостности данных, которые гарантируют корректность и согласованность информации.

Проектирование пользовательского интерфейса

Эффективный пользовательский интерфейс является залогом удобства и продуктивности работы с базой данных. В MS Access основными элементами пользовательского интерфейса являются формы.

Формы в MS Access значительно упрощают ввод и обработку данных, представляя их в удобном, визуально организованном виде. Вместо того чтобы напрямую работать с таблицами, пользователь взаимодействует с формами, которые могут:

• Отображать данные: Представлять записи из одной или нескольких таблиц в виде карточек или таблиц.
• Вводить новые данные: Предоставлять поля для заполнения информации о клиентах, кассетах, прокатах.
• Редактировать существующие данные: Позволять изменять атрибуты записей.
• Выполнять действия: Включать кнопки для выполнения различных операций, таких как сохранение, удаление, поиск, печать.
• Обеспечивать контроль ввода: Использовать списки, выпадающие меню, флажки для упрощения ввода и предотвращения ошибок.

Для системы видеопроката можно разработать следующие основные формы:

1. Форма «Клиенты»: Для ввода и редактирования информации о клиентах (Имя, Адрес, Телефон, Паспортные данные).
2. Форма «Кассеты»: Для управления каталогом фильмов и их экземпляров (Название, Режиссер, Год выпуска, Категория, Стоимость проката, Статус кассеты).
3. Форма «Прокат»: Самая сложная форма, предназначенная для оформления выдачи и возврата кассет. Она должна позволять выбирать клиента и кассету, указывать даты начала/окончания проката, автоматически рассчитывать стоимость. Эта форма может быть реализована как «главная/подчиненная» форма, где главная часть содержит данные о прокате, а подчиненная — детали проката (если бы у нас была связь многие-ко-многим между прокатом и кассетами через промежуточную таблицу).
4. Форма «Категории»: Для добавления и редактирования категорий фильмов и их коэффициентов стоимости.

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

Создание запросов и отчетов

Запросы — это мощный инструмент для извлечения, фильтрации, сортировки и агрегирования данных из одной или нескольких таблиц. В MS Access запросы могут быть созданы с использованием графического конструктора или напрямую на языке SQL (Structured Query Language). В курсовой работе необходимо привести примеры запросов в конструкторе Access, их описание, а также соответствующие запросы на языке SQL.

Примеры запросов для системы видеопроката:

• Запрос на выборку всех доступных кассет:

  SELECT Название, Режиссер, Категория, Стоимость_проката
  FROM Кассеты
  WHERE Статус_проката = "В наличии";
  

• Запрос на выборку всех просроченных прокатов:

  SELECT Клиент.Имя, Кассеты.Название, Прокат.Дата_окончания
  FROM Клиент INNER JOIN (Кассеты INNER JOIN Прокат ON Кассеты.Код_кассеты = Прокат.Код_кассеты) ON Клиент.Идентификатор_клиента = Прокат.Идентификатор_клиента
  WHERE Прокат.Статус_проката = "Активен" AND Прокат.Дата_окончания < Date();
  

• Запрос на расчет общей стоимости проката для клиента за период:

  SELECT Клиент.Имя, Sum(Кассеты.Стоимость_проката) AS ОбщаяСтоимость
  FROM Клиент INNER JOIN (Кассеты INNER JOIN Прокат ON Кассеты.Код_кассеты = Прокат.Код_кассеты) ON Клиент.Идентификатор_клиента = Прокат.Идентификатор_клиента
  WHERE Прокат.Дата_начала BETWEEN #2024-01-01# AND #2024-12-31#
  GROUP BY Клиент.Имя;
  

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

Примеры отчетов:

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

Механизмы обеспечения целостности данных

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

В Microsoft Access возможность автоматической проверки целостности данных в связанных полях обеспечивается, если соблюдены следующие условия:

1. Ключевое поле или уникальный индекс: Связанное поле главной таблицы должно являться первичным ключом или иметь уникальный индекс. Это гарантирует, что каждая запись в главной таблице однозначно идентифицируется.
2. Совместимые типы данных: Связанные поля должны иметь один и тот же тип данных. Исключением является поле типа «Счетчик», которое может быть связано с числовым полем типа «Длинное целое» или полем типа «Код репликации».
3. Одна база данных: Обе таблицы должны принадлежать одной базе данных Microsoft Access.

Для контроля соблюдения правил целостности данных при создании связи между таблицами в MS Access следует установить флажок «Обеспечение целостности данных» (Enforce Referential Integrity) в окне «Схема данных». Это активирует следующие защитные механизмы:

• Запрет на удаление: Нельзя удалить запись из главной таблицы, если существуют связанные с ней записи в подчиненной таблице. Например, нельзя удалить категорию, если к ней привязаны фильмы.
• Запрет на изменение: Нельзя изменить значение первичного ключа в главной таблице, если существуют связанные записи в подчиненной таблице.

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

• «Каскадное обновление связанных полей» (Cascade Update Related Fields): Если изменяется значение первичного ключа в главной таблице, это изменение автоматически применяется ко всем связанным внешним ключам в подчиненных таблицах. Например, при изменении Кода категории в таблице «Категории», этот Код категории автоматически обновится во всех связанных записях в таблице «Кассеты».
• «Каскадное удаление связанных записей» (Cascade Delete Related Records): Если запись удаляется из главной таблицы, все связанные записи в подчиненных таблицах также автоматически удаляются. Например, при удалении записи о клиенте, все его записи о прокатах будут автоматически удалены. Этот механизм следует использовать с большой осторожностью, так как он может привести к непреднамеренной потере данных.

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

Методы системного анализа и объектно-ориентированного подхода в разработке БД

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

Применение методов системного анализа предметной области

Разработка базы данных начинается задолго до написания первой строки SQL или создания первой таблицы в Access. Она начинается с глубокого системного анализа предметной области. Традиционно это включает обследование бизнес-процессов, интервьюирование пользователей и сбор требований. Однако, для более глубокого понимания и построения по-настоящему эффективной системы, можно и нужно применять расширенные методы системного анализа:

1. Методы экспертных оценок: Когда данные неполны или противоречивы, или требуется принять решение в условиях неопределенности, можно обратиться к экспертам.
   • Метод рангов: Эксперты упорядочивают объекты (например, критерии выбора фильма или характеристики клиента) по степени их важности.
   • Метод парных сравнений: Эксперты сравнивают каждую пару объектов, определяя, какой из них важнее.
   • Метод Дельфи: Позволяет получить согласованное мнение группы экспертов через серию анонимных опросов, уменьшая влияние личных предубеждений.
   • Метод Саати (Аналитическая иерархия): Помогает структурировать сложные проблемы и принимать решения путем декомпозиции на иерархические уровни и попарного сравнения элементов.

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

2. Кластерный анализ: Этот статистический метод позволяет найти естественные группы (кластеры) в наборе данных. В контексте видеопроката, кластерный анализ может быть применен для:
   • Сегментации клиентов: Выявления групп клиентов со схожими предпочтениями в фильмах, частотой проката или историей платежей. Это может помочь в разработке персонализированных предложений или программ лояльности.
   • Классификации фильмов: Группировки фильмов, которые часто берут вместе, для оптимизации рекомендательных систем или размещения на полках.
3. Методы инфологического проектирования (ER-моделирование): Как уже обсуждалось, ER-диаграммы являются центральным инструментом системного анализа для визуализации сущностей, их атрибутов и связей. Они позволяют выявить логические зависимости и согласовать их с бизнес-логикой.

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

Основы объектно-ориентированного подхода и ООБД

В то время как реляционные базы данных доминируют, важно понимать и альтернативные подходы, особенно объектно-ориентированное программирование (ООП) и его отражение в базах данных. Объектно-ориентированные базы данных (ООБД) возникли в середине 1980-х годов как ответ на необходимость удовлетворения требований сложных приложений, таких как автоматизированное проектирование (CAD), автоматизированное производство (CAM), технологии программирования и мультимедийные системы, где реляционные СУБД имели ограничения в представлении сложных, иерархических и изменяющихся объектов.

Основные понятия объектно-ориентированного подхода и их преломление в ООБД включают:

1. Объекты и идентификаторы объектов: В ООП все строится вокруг объектов — экземпляров классов, которые сочетают в себе данные (атрибуты) и поведение (методы). В ООБД каждый объект имеет уникальный идентификатор объекта (OID), который не зависит от его значений и остается постоянным на протяжении всего жизненного цикла объекта, обеспечивая прямой доступ.
2. Атрибуты и методы: Объекты характеризуются атрибутами (данными) и методами (функциями, которые можно выполнять над объектом). Например, объект «Фильм» может иметь атрибуты «Название», «Режиссер» и метод «ПроигратьТрейлер».
3. Классы: Класс — это шаблон или blueprint для создания объектов. Он определяет совокупность свойств, методов, общедоступных и частных структур данных, а также программ, применимых к объектам данного класса. Все объекты одного класса имеют одинаковый набор атрибутов и методов.
4. Инкапсуляция: Это принцип, согласно которому внутреннее представление данных и детали реализации общедоступных и частных методов являются частью определения класса и известны только внутри этого класса. Доступ к объектам разрешен только через свойства и методы класса (или его родителей), что скрывает сложность реализации и защищает данные от несанкционированного доступа.
5. Наследование: Это механизм, позволяющий создавать новые классы (потомки) на основе существующих (родителей), при этом классы-потомки автоматически наследуют свойства и методы своих родителей, а также могут добавлять собственные или переопределять унаследованные. Например, класс «Фильм ужасов» может наследовать от класса «Фильм» и добавлять специфические атрибуты, такие как «Уровень страха».

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

Однако, отсутствие универсальной объектно-ориентированной модели данных с проработанным математическим аппаратом, как в случае реляционных баз данных (вспомним правила Кодда), является основной проблемой распространения ООСУБД. Реляционная модель, с её простотой и мощной теоретической основой, оказалась более универсальной. Тем не менее, понимание принципов ООП и ООБД расширяет кругозор студента и готовит его к работе с гибридными системами (объектно-реляционные СУБД) или NoSQL-решениями, которые часто используют объектно-ориентированные концепции.

Заключение

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

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

Выбор Microsoft Access в качестве СУБД для реализации был обоснован его доступностью, простотой в освоении и достаточным функционалом для учебного проекта, позволяющим сосредоточиться на принципах проектирования, а не на сложностях настройки серверных решений. Мы определили основные функциональные требования и бизнес-правила системы видеопроката, которые легли в основу создания пользовательского интерфейса через формы, а также разработки запросов и отчетов для эффективного взаимодействия с данными и их анализа. Механизмы обеспечения целостности данных, такие как ссылочная целостность и каскадные операции, были детально рассмотрены как необходимые условия для поддержания согласованности информации.

Наконец, мы расширили горизонты исследования, затронув методы системного анализа (экспертные оценки, кластерный анализ) и основы объектно-ориентированного подхода в контексте баз данных. Это позволило интегрировать более широкие методологические аспекты в процесс разработки, демонстрируя комплексное видение создания информационных систем.

Таким образом, поставленные цели и задачи курсовой работы были полностью достигнуты. Разработанная структура базы данных для системы видеопроката является логически обоснованной, нормализованной и готовой к практической реализации. Дальнейшее развитие проекта может включать разработку более сложного пользовательского интерфейса с использованием объектно-ориентированных языков программирования, интеграцию с веб-технологиями для создания онлайн-сервиса проката, а также масштабирование базы данных на более мощные серверные СУБД (например, PostgreSQL или SQL Server) для поддержки большего числа пользователей и объемов данных.

Список использованной литературы

1. Кириллов В.В., Громов Г.Ю. Структуризированный язык запросов (SQL). Учебное пособие.
2. Основы SQL. Перевод: Alexandr Pyramidin // pyramidin.narod.ru. URL: http://www.opennet.ru/docs/RUS/rusql/ (дата обращения: 16.10.2025).
3. Сайт компании Прайм Видео. URL: http://pv.by/index.php?osCsid=0d5410372f885bc8dbe301444a1c08b8 (дата обращения: 16.10.2025).
4. Коннолли Т., Бегг К. Базы данных: проектирование, реализация и сопровождение.
5. Реляционная модель данных // ict.nsu.ru. URL: https://ict.nsu.ru/wiki/Реляционная_модель_данных (дата обращения: 16.10.2025).
6. Объектно-ориентированные базы данных — основные концепции, организация и управление: краткий обзор // citforum.ru. URL: http://www.citforum.ru/database/articles/article001.shtml (дата обращения: 16.10.2025).
7. Разработка приложения, Структура базы данных «Видеопрокат» // studbooks.net. URL: https://studbooks.net/835492/ekonomika/razrabotka_prilozheniya_struktura_bazy_dannyh_videoprokat (дата обращения: 16.10.2025).
8. Обеспечение целостности данных // docs.microsoft.com. URL: https://docs.microsoft.com/ru-ru/office/troubleshoot/access/enforce-referential-integrity (дата обращения: 16.10.2025).
9. Обзор объектно-ориентированной парадигмы в приложении к разработке баз данных // cyberleninka.ru. URL: https://cyberleninka.ru/article/n/obzor-obektno-orientirovannoy-paradigmy-v-prilozhenii-k-razrabotke-baz-dannyh (дата обращения: 16.10.2025).
10. Введение в системы баз данных. 8-е издание. William’s Publishing.
11. Введение в системы баз данных // wordpress.com. 2017. URL: https://wordpress.com/2017/08/08/%D0%B2%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B-%D0%B1%D0%B0%D0%B7-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-%D0%BA-%D0%B4%D0%B6-%D0%B4%D0%B5%D0%B9%D1%82/ (дата обращения: 16.10.2025).
12. Что такое нормализация баз данных? // otus.ru. URL: https://otus.ru/articles/chto-takoe-normalizaciya-baz-dannyh/ (дата обращения: 16.10.2025).
13. Краткое описание ER–метода проектирования реляционных баз данных // student.ru. URL: https://student.ru/er-method.pdf (дата обращения: 16.10.2025).
14. Объектно-ориентированные базы данных // minich.com. URL: http://www.minich.com/articles/oodb.html (дата обращения: 16.10.2025).
15. Примеры и принципы нормализации реляционных баз данных (БД) // decosystems.ru. URL: https://decosystems.ru/blog/normalization-of-database (дата обращения: 16.10.2025).
16. Обеспечение целостности данных. Таблицы в Access. Компьютерная литература // litresp.ru. 2012. URL: https://litresp.ru/gnr/data/base/2012/654/index.html (дата обращения: 16.10.2025).
17. Организация базы данных в среде ACCESS // science-education.ru. URL: https://science-education.ru/ru/article/view?id=25577 (дата обращения: 16.10.2025).
18. Как создать ER-диаграмму и СДТ-модель для информационной системы салона видеопроката // hpc.ru. URL: https://hpc.ru/articles/kak-sozdat-er-diagrammu-i-sdt-model-dlya-informacionnoy-sistemy-salona-videoprokata.html (дата обращения: 16.10.2025).
19. Даталогическое проектирование // mtusi.ru. URL: https://mtusi.ru/upload/iblock/d76/d76c69747517c2f1f5010632b70b5550.docx (дата обращения: 16.10.2025).
20. ER-диаграммы: как создать, примеры построения модели // business-secrets.ru. URL: https://business-secrets.ru/wiki/er-diagrammy.html (дата обращения: 16.10.2025).
21. Нормализация отношений. Шесть нормальных форм // habr.com. URL: https://habr.com/ru/articles/256865/ (дата обращения: 16.10.2025).
22. База данных access: курсовая работа по БД // itdiplom.ru. URL: https://itdiplom.ru/baza-dannyh-access-kursavaya-rabota-po-bd/ (дата обращения: 16.10.2025).
23. Курсовая работа по курсу «Базы данных» выполняется в течение 3 и 4 семестра // library.tusur.ru. 2018. URL: https://library.tusur.ru/docs/410/2018-09-24.pdf (дата обращения: 16.10.2025).
24. Кодд Э.Д. Реляционная база данных: практическая основа эффективности. 1981 // acm.org. URL: https://acm.org/awards/docs/turing_1025595.pdf (дата обращения: 16.10.2025).
25. Что такое ER-диаграмма и как ее создать? // lucidchart.com. URL: https://www.lucidchart.com/pages/ru/chto-takoe-er-diagramma (дата обращения: 16.10.2025).
26. Логическое проектирование БД. ER-диаграммы // studfiles.net. URL: https://studfiles.net/preview/6122557/page:2/ (дата обращения: 16.10.2025).
27. Нормализация данных: что это и зачем их нормировать — правила нормирования данных в БД // practicum.yandex.ru. URL: https://practicum.yandex.ru/blog/chto-takoe-normalizatsiya-dannyh/ (дата обращения: 16.10.2025).
28. Курсовая работа: Создание базы данных ‘Видеопрокат’ // studlandia.ru. URL: https://studlandia.ru/work/217988/sozdanie-bazy-dannyh-videoprokat.html (дата обращения: 16.10.2025).
29. БД Видео проката // cyberforum.ru. URL: https://cyberforum.ru/access/thread1803504.html (дата обращения: 16.10.2025).