Базы данных: практикум по проектированию реляционных баз данных

ИНСТИТУТ ТЕХНИКИ И ЦИФРОВЫХ ТЕХНОЛОГИЙ 

ФАКУЛЬТЕТ  
ИНФОКОММУНИКАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ 

КАФЕДРА ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И УПРАВЛЯЮЩИХ СИСТЕМ 

Н. П. Сидорова 

БАЗЫ ДАННЫХ 

ПРАКТИКУМ ПО ПРОЕКТИРОВАНИЮ 
РЕЛЯЦИОННЫХ БАЗ ДАННЫХ 

Учебное пособие 

Москва 
Берлин 
2020 

УДК 004.65(076) 
ББК 32.972.34я7+16.3я7 
  С 34 

Рецензенты: 
Хорев П. Б., профессор кафедры Прикладной математики НИУ МЭИ,  
кандидат технических наук, доцент; 
Погодин А. В., кандидат технических наук, доцент 

Сидорова, Н. П. 
С 34        Базы данных: практикум по проектированию реляционных баз данных : 
 учебное пособие / Н. П. Сидорова. — Москва ; Берлин : Директ-Медиа, 
 2020. — 92 с. 

ISBN 978-5-4499-0799-8 

Учебное пособие включает восемь практических работ, отражающих основные 
этапы проектирования реляционных баз данных: инфологическое проектирование, 
логическое проектирование на основе реляционной модели данных, реализацию базы 
данных средствами СУБД. Каждая работа содержит необходимые теоретические 
сведения, используемые для выполнения работы. Построение моделей баз данных 
предполагает применение CASE-средств. Для реализации базы данных используется 
СУБД Access. 
Практикум 
предназначен 
студентам, 
обучающимся 
по 
направлениям 
подготовки «Прикладная информатика», «Информационные системы и технологи» 
очной и заочной форм обучения. Практические задания, включенные в учебное 
пособие, будут полезны студентам и других направлений подготовки при изучении 
вопросов, связанных с проектированием и реализацией реляционных баз данных.  

УДК 004.65(076) 
ББК 32.972.34я7+16.3я7 

ISBN 978-5-4499-0799-8 
© Сидорова Н. П., текст, 2020
© Издательство «Директ-Медиа», оформление, 2020 

ОГЛАВЛЕНИЕ 

ВВЕДЕНИЕ .................................................................................................................. 5

Практическая работа 1.  ПРОЕКТИРОВАНИЕ ER-МОДЕЛИ БД ......................... 8

Практическая работа 2.   РАЗРАБОТКА РЕЛЯЦИОННОЙ 
МОДЕЛИ БД .............................................................................................................. 26

Практическая работа 3.  ПРОЕКТИРОВАНИЕ ПРАВИЛ 
ЦЕЛОСТНОСТИ БД  И ФИЗИЧЕСКОЙ МОДЕЛИ БД ........................................ 33

Практическая работа 4.  СОЗДАНИЕ ТАБЛИЦ БД В СУБД ACCESS ............... 42

Практическая работа 5.    СОЗДАНИЕ ЗАПРОСОВ В СУБД ACCESS .............. 51

Практическая работа 6.   СОЗДАНИЕ ОТЧЕТОВ В СУБД ACCESS.................. 63

Практическая работа 7.  СОЗДАНИЕ ИНТЕРФЕЙСА К БД ACCESS ............... 69

Практическая работа 8.  ЦЕЛОСТНОСТЬ ДАННЫХ 
В БАЗЕ ДАННЫХ ..................................................................................................... 79

ЗАКЛЮЧЕНИЕ ......................................................................................................... 84

ЛИТЕРАТУРА ........................................................................................................... 85

Приложение.  ВАРИАНТЫ ПРЕДМЕТНОЙ ОБЛАСТИ 
 ДЛЯ ПРАКТИЧЕСКИХ ЗАДАНИЙ ...................................................................... 86

ВВЕДЕНИЕ 

Широкое 
применение 
информационных 
систем 
вызывает 
большой интерес к вопросам проектирования баз данных (БД), 
которые являются их основой [4, 5, 11]. Качество полученной БД во 
многом определяется результатами её проектирования. В настоящее 
время широко используются БД, основанные на реляционной модели 
данных ‒ реляционные базы данных (РБД). Проектирование модели 
РБД предполагает определение набора таблиц БД и формирование 
структуры каждой таблицы. Модели БД должны удовлетворять 
следующим свойствам [5, 6, 10]: 
− представление 
семантики 
предметной 
области, 
которое 
предполагает отражение в модели реально существующих в 
предметной области объектов; 
− поддержка эффективного управления данными, связанного с 
их хранением во внешней памяти и обработкой;  
− устранение избыточности данных, которая обусловлена 
дублированием данных в БД; 
− поддержка целостности данных. 
Модель БД играет особую роль в процессе проектирования, т.к. 
представляет информационную модель предметной области [4, 7]. 
Понятие предметной области, как и многие понятии, используемые в 
информатике, не имеет точного формального определения. Однако 
оно широко применяется для того, чтобы ограничить область 
использования данных из БД. Выделение предметной области БД 
позволяет сформировать перечень тех сведений об объектах 
реального мира (сущностей), данные о которых будет содержать БД. 
Анализ предметной области БД позволяет выделить в ней 
информационные объекты [7], сведения о которых будут храниться и 
обрабатываться в БД. 
Построение модели БД является непростой задачей, поэтому её 
решение разбивается на несколько этапов. На каждом этапе 
разрабатываются модели различного уровня: 
1) семантическая модель предметной области формируется на 
основе основных понятий, используемых в ней, определяет уровень 
инфологического моделирования;  
2) логическая модель строится в терминах абстрактных 
моделях данных и формирует концептуальное представление БД; 

5 

3) физическая модель определяет, как будут храниться данные
во внешней памяти, какие управляющие элементы необходимо 
предусмотреть для обеспечения эффективной работы с нею. 
Такой подход определяет следующие этапы проектирования БД. 
1. Проектирование инфологической модели. Оно выполняется
на основе анализа предметной области. Анализ предметной области 
позволяет выделить основные информационные объекты, правила их 
взаимодействия, 
информационные 
процессы. 
Как 
правило, 
результатом анализа является формализованное описание процессов 
предметной области, которое служит основой для построения 
инфологической модели.  
2. Разработка логической модели связана, в первую очередь, с
выбором типа логической модели. 
3. Проектирование физической модели позволяет определить
способы размещения элементов логической модели во внешней 
памяти таким образом, чтобы их хранение и управлении ими было 
оптимально. 
Для 
проектирования 
БД 
в 
настоящее 
время 
широко 
применяются 
специальные 
программные 
средства, 
автоматизирующие разработку моделей различного уровня ‒ 
CASE-средства 
(Computer 
Aided 
Software 
Engineering 
‒ 
компьютерные средства разработки программного обеспечения). 
CASE-средства позволяют применять современные подходы к 
процессу проектирования программного обеспечения, применять 
методологию нисходящего проектирования: 
− широко 
использовать 
автоматизацию 
для 
разработки, 
визуализации и документирования моделей различного уровня; 
− создавать библиотеку (репозиторий) моделей, в которой 
хранятся их описания, на основе репозитория можно создавать новые 
модели посредством изменения или доработки уже созданных; 
− организовывать одновременную работу с моделью БД 
нескольких разработчиков; 
− автоматизировать стандартные процедуры, связанные с 
документированием, проверкой, интеграцией модели БД. 
CASE-средства позволяют решать следующие задачи в процессе 
проектирования БД. 
1.Разработка моделей процессов обработки информации в
предметной области. Такие модели, как правило, представляются в 
виде структурных моделей. Они позволяют представить процессы в 

6 

виде иерархических диаграмм, задающих функции процесса. Анализ 
полученных моделей позволяет сформировать состав информационных 
объектов и определить функции обработки данных. Эта информация 
является основой для разработки  инфологической модели БД. 
2. Разработка 
инфологической 
модели 
базируется 
на
использовании 
модели 
«сущность-связь». 
Она 
позволяет 
конкретизировать набор характеристик каждого объекта и определить 
связи между ними. 
3. Преобразование модели «сущность-связь» в реляционную
модель БД. 
4. Автоматическое создание описания БД на языке SQL
выбранной СУБД. 
5. Автоматическое
создание 
описаний 
на 
языке 
программирования программных компонентов (описание структуры 
таблиц БД, создание индексов и триггеров БД, экранные формы).  
Для 
анализа 
информационных 
процессов 
могут 
быть 
использованы такие программные продукты, как AllFusion Process 
Modeler, Microsoft Visio, Modelio Open Source.  
Для проектирования моделей БД при выполнении практических 
работ используется CASE-средств AllFusion ERwin Data Modeler или 
Microsoft Visio. Физическая модель при выполнении практических 
заданий основывается на модели выбранной СУБД. Для создания БД 
на основе разработанных моделей при выполнении практических 
заданий используется СУБД Access.  
Практические работы 1–3 позволяют приобрести навыки 
использования 
CASE-средств 
построения 
моделей 
БД. 
В 
практической работе 1 студенты получают навыки проектирования 
ER-модели заданной предметной области. В практической работе 2 
проводится проектирование реляционной модели БД. В практической 
работе 3 приобретаются навыки проектирования статических и 
ссылочных правил целостности для реляционной модели. 
Практические работы 4–8 позволяют приобрести навыки 
использования СУБД Access для реализации БД. В практической 
работе 4 изучается технология переноса разработанной модели БД в 
СУБД Access. Практическая работа 5 посвящена приобретению 
навыков разработки QBE-запросов в СУБД Access. Практическое 
занятие 
6 
позволяет 
приобрести 
навыки 
использования 
инструментальных средств СУБД Access для разработки интерфейса 
с объектами БД. 

Практическая работа 1 
ПРОЕКТИРОВАНИЕ ER-МОДЕЛИ БД 

Цель работы – приобретение навыков разработки ER-модели 
заданной предметной области с помощью CASE-средств. 

1. Теоретические основы
Для концептуального описания предметной области при 
проектировании 
БД 
используют 
семантические 
модели. 
Они 
позволяют, с одной стороны, сохранить смысловое описание 
предметной области, а с другой – представить предметную область в 
виде формализованной модели. Такие модели используются на этапе 
инфологического 
моделирования. 
В 
них 
представляются 
те 
смысловые понятия, которые существуют в предметной области и 
будут отражаться в БД.  
Для решения проблемы представления семантики предметной 
области было создано несколько моделей. Наиболее популярной 
является модель, предложенная П. Ченом [2, 3], которая известна как 
модель «сущность-связь» (ER-модель). Её преимуществом является 
относительная 
простота, 
которая, 
тем 
не 
менее, 
позволяет 
разрабатывать большие и сложные семантические модели БД. 
Следует 
отметить, 
что 
существует 
большое 
количество 
CASE-средств, которые включают широкий набор инструментов для 
работы с такой моделью. При выполнении практической работы 
используется ER-модель. 
В 
основе 
построения 
ER-модели 
лежит 
представление 
предметной области в виде набора взаимосвязанных сущностей. 
Поэтому основными элементами модели являются сущность (Entity) 
и связь (Relationship). Каждый реально существующий объект 
предметной области обладает набором характеристик (свойств), 
которые необходимо представить в информационной модели. Для 
представления таких объектов в ER-модели используется сущность. 
Свойства 
сущности 
описывают 
характеристики 
реально 
существующего объекта, а связи определяют смысловые ассоциации, 
которые можно выделить между сущностями в предметной области. 
Сущность может определяться как для реально существующего 
объекта, так и для некоторого абстрактного понятия предметной 
области [5, 6, 7, 10, 11]. Конкретные значения характеристик каждого 
объекта будут храниться в БД. Реальный объект (например, 

8 

Преподаватель) задаёт физический объект, в то время как 
абстрактный объект (например Лекция) определяет некоторое 
абстрактное понятие, связанное с реальным объектом в предметной 
области. Все объекты предметной области, для которых можно 
определить общий набор характеристик, необходимо объединить в 
одну сущность-понятие (далее сущность). Характеристики сущностипонятия 
называются 
атрибутами. 
Они 
должны 
определять 
существенные для заданной предметной области свойства сущности 
и иметь уникальные (неповторяющиеся) имена. Задавая имена 
сущностей и атрибутов, следует придерживаться терминологии 
предметной области. При этом надо учитывать, что наименование 
характеристик разных сущностей в предметной области могут 
совпадать (например, свойство Фамилия можно определить для 
различных сущностей: преподаватель, студент, автор учебника, 
клиент и т.п.). Желательно, однако, определять имена атрибутов 
разных сущностей уникальными, это позволит легче понимать 
модель БД. 
Экземпляр сущности определяет отдельный объект из этого 
класса и задаётся конкретными значениями его атрибутов.  
При определении набора атрибутов сущности необходимо 
выделить идентифицирующий атрибут, значение которого позволяет 
определить конкретную сущность-экземпляр. 
В ER-модели можно использовать сущности различных типов: 
− сильные и слабые сущности, 
− простые и сложные сущности. 
Существование сильной сущности не зависит от наличия какихлибо других сущностей. Слабые сущности могут существовать 
только при наличии связи с некоторой сильной сущностью. 
Например, слабая сущность Кредит зависит от существования 
сильной сущности Клиент. 
Простая сущность содержит все свои характеристики. Для 
сложного объекта предметной области такие характеристики могут 
быть определены в нескольких сущностях. В этом случае для 
представления сложного объекта в ER-модели используется сложная 
сущность. 
Вторым элементом в ER-модели является связь. Связь в самом 
общем смысле определяет ассоциацию между сущностями. Связь 
задаёт смысловое взаимодействие сущностей. В ER-модели следует 
использовать только бинарные связи, т.е. связи только между двумя 

9 

сущностями, которые можно отнести к одному из допустимых типов 
связей [4, 5, 6].  
Связь 
ОДИН-К-ОДНОМУ 
(1:1) 
можно 
задать 
между 
сущностями тогда, когда в каждый момент времени один экземпляр 
родительской сущности (например Преподаватель) ассоциируется в 
предметной области с 1 (или 0) экземпляром дочерней сущности 
(например Кафедра).  
Связь 
ОДИН-КО-МНОГИМ 
(1:М) 
определяется 
между 
сущностями в том случае, когда один экземпляр родительской 
сущности связан с несколькими экземплярами дочерней сущности, 
например, между сущностями Преподаватель и Дисциплина. 
Связь 
МНОГИЕ-КО-МНОГИМ 
(М:N) 
определяет 
такое 
взаимодействие сущностей, при котором некоторое множество 
экземпляров 
родительской 
сущности 
связано 
с 
несколькими 
экземплярами дочерней сущности. Например, такую связь можно 
определить между сущностями Товар и Заказ в том случае, если в 
один заказ можно включить несколько товаров. 
Для однозначной интерпретации ER-модели все её элементы 
должны иметь описание: 
− сущность описывается именем, желательно также определить 
смысловую интерпретацию сущности, которая определяет её 
назначение в модели; 
− атрибут описывается своим именем, типом допустимых 
значений, описанием особенностей использования атрибута, также 
желательно привести краткую смысловую интерпретацию атрибута, 
которая позволит пояснить его появление в структуре сущности; 
− связь описывается именем, которое определяет его смысловую 
нагрузку, и типом.  
Одним из обязательных свойств БД является целостность 
данных. Целостность данных описывается набором правил, которое 
позволяет учесть специфику работы с данными в предметной 
области. 
Это 
позволяет 
защитить 
данные 
от 
потери 
или 
неправильных действий. В общем случае выделение смысловых 
правил 
целостности 
не 
является 
обязательным 
элементом 
проектирования ER-модели, но их выделение позволит в дальнейшем 
построить более качественную БД. 
Рассмотрим процесс разработки ER-модели для конкретного 
примера предметной области: работу курсов дополнительного 
обучения, в которой организуется работа по проведению групповых 

10 

занятий по различным дисциплинам. В этой предметной области 
можно 
выделить 
следующие 
сущности: 
Студент, 
Группа, 
Дисциплина, Преподаватель. 
Сущность Студент может быть задана следующим набором 
атрибутов: фамилия студента, номер зачётной книжки, дата 
рождения. Для конкретного студента эти атрибуты задаются 
конкретными значениями, например, Фамилия: Смирнов; номер 
зачётной книжки: 12345; дата рождения 12.10.2000. 
Для сущности Дисциплина определим следующие атрибуты: 
название, уровень подготовки, вид итогового документа. 
Для сущности Группа выделим следующие атрибуты: номер 
группы, дата формирования. 
Задавая связи между сущностями, необходимо основываться на 
тех правилах, которые существуют в предметной области. Например, 
если один студент может учиться только в одной группе, то между 
сущностью Студент (родительская сущность) и сущностью Группа 
(дочерняя сущность) определяется связь типа 1:1 (рис. 1.1). 
 

Студент
учится
группа

1
1

 

 

Рисунок 1.1 ‒ Пример связи 1:1 
 
С другой стороны, т.к. одна группа состоит из нескольких 
студентов, то между родительской сущностью Группа и дочерней 
сущностью Студент определена связь 1:М (рис. 1.2).  
 

Группа
состоит
Студент

1
М

 
 
Рисунок 1.2 ‒ Пример связи 1:М 
 
Каждый студент может изучать произвольное количество 
дисциплин, поэтому между сущностью Студент и Дисциплина 
следует определить связь типа M:N (рис. 1.3).  
 

Студент
изучает
дисциплина

M
N

 
 
Рисунок 1.3 ‒ Пример связи N:M 
 
 
 

11