Базы данных

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ 

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ  
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ  
«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ «МИСиС» 

 

 
 
 

 

 

 

 
 

 

№ 104 

Кафедра автоматизированных систем управления

Е.А. Морозов 
 
 

Базы данных

 

Методические указания 

Рекомендовано редакционно-издательским 
советом университета 

Москва  2011 

УДК 004.6 
 
М80 

Р е ц е н з е н т  
канд. техн. наук А.И. Широков 

Морозов, Е.А. 
М80  
Базы данных : метод. указ. / Е.А. Морозов. – М. : Изд. Дом 
МИСиС, 2011. – 38 с. 
 

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

 
© Е.А. Морозов, 2011 

Оглавление 

1. Теоретические сведения.......................................................................4 
1.1. Общие положения..........................................................................4 
1.2. Концептуальное проектирование баз данных.............................5 
1.3. Логическое проектирование баз данных...................................11 
1.4. Физическое проектирование баз данных ..................................16 
2. Пример проектирования базы данных..............................................17 
2.1. Анализ предметной области.......................................................17 
2.2. Концептуальное проектирование баз данных...........................18 
2.3. Логическое проектирование баз данных...................................20 
2.4. Физическое проектирование баз данных ..................................29 
2.5. Примеры реализации запросов к базам данных .......................30 
3. Выполнение курсовой работы...........................................................31 
4. Варианты заданий на курсовую работу............................................32 
Список рекомендуемой литературы .....................................................37 
 

Цель данной работы – применение на практике знаний, полученных в процессе изучения дисциплины «Базы данных», и получение 
навыков создания автоматизированных информационных систем 
(АИС), основанных на базах данных. 

1. ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ 

1.1. Общие положения 

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

не полностью. Тогда основное внимание уделяется исследованию 
предметной области и наиболее адекватному ее отображению в БД с 
учетом самого широкого спектра информационных запросов к ней. 
Вне зависимости от используемого подхода весь процесс проектирования условно разбивается на три этапа (рис. 1.1): 
1. Концептуальное проектирование БД. 
2. Логическое проектирование БД. 
3. Физическое проектирование БД. 

 

Рис. 1.1. Этапы проектирования баз данных 

1.2. Концептуальное проектирование баз данных 

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

ционных потребностей пользователей в терминах, понятных пользователю и независимых от реализации БД. Это описание выражается в 
терминах не отдельных объектов предметной области и связей между ними, а их типов, связанных с ними ограничений целостности и 
тех процессов, которые приводят к переходу предметной области из 
одного состояния в другое. 
В настоящее время концептуальное проектирование, как правило, 
выполняется с использованием метода «сущность–связь» и выполняется в 2–3 этапа (в зависимости от масштаба предметной области): 
1) определение сущностей (состава атрибутов и ключей); 
2) определение связей между сущностями; 
3) синтез глобальной концептуальной схемы (для масштабной 
предметной области). 
Проектирование начинается с моделирования предметной области. Если она очень большая, то разбивается на ряд локальных областей, каждая из которых (в идеале) включает в себя информацию, достаточную для обеспечения запросов отдельной группы будущих 
пользователей или решения отдельной задачи (подзадачи). Каждое 
локальное представление моделируется отдельно, затем они объединяются. 
Выбор локального представления зависит от масштабов предметной области. Обычно она разбивается на локальные области таким 
образом, чтобы каждая из них соответствовала отдельному внешнему приложению и содержала не более 6–7 сущностей. 

Первый этап – определение сущностей 
Сущность – это объект, о котором в системе будет накапливаться 
информация. Сущности бывают как физически существующие (например, СОТРУДНИК или АВТОМОБИЛЬ), так и абстрактные (например, ЭКЗАМЕН или ДИАГНОЗ). 
Для сущностей различают тип сущности и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр – конкретными 
значениями свойств. 
Типы сущностей можно классифицировать как сильные и слабые. 
Сильные сущности существуют сами по себе, а существование слабых сущностей зависит от существования сильных. Например, читатель библиотеки – сильная сущность, а абонемент этого читателя – 
слабая, которая зависит от наличия соответствующего читателя. Слабые сущности называют подчиненными (дочерними), а сильные – базовыми (основными, родительскими). 

Для каждой сущности выбираются свойства (атрибуты). Различают идентифицирующие и описательные атрибуты.  
Идентифицирующие атрибуты имеют уникальное значение для 
сущностей данного типа и являются потенциальными ключами. Они 
позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ. В качестве первичного ключа обычно выбирается потенциальный ключ, по которому 
чаще происходит обращение к экземплярам. Кроме того, первичный 
ключ должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными и заключают в себе интересующие свойства сущности. 
Составные и простые атрибуты. Простой атрибут состоит из 
одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных (например, ФИО или адрес). Решение о 
том, использовать составной атрибут или разбивать его на компоненты, зависит от характера его обработки и формата пользовательского 
представления этого атрибута. 
Однозначные и многозначные атрибуты (могут иметь соответственно одно или много значений для каждого экземпляра сущности). 
Основные и производные атрибуты. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута 
вычисляется на основе значений других атрибутов (например, возраст 
студента вычисляется на основе даты его рождения и текущей даты). 
Спецификация атрибута состоит из его названия, указания типа 
данных и описания ограничений целостности – множества значений 
(или домена), которые может принимать данный атрибут. Для формирования сущности используют точное описание объекта и на его 
основании выбирают атрибуты. 
В большинстве случаев операция по определению сущностей 
проходит успешно (на основании одного или нескольких точных документов). Но бывают ситуации, когда описание дано расплывчато – 
в документе не отражен сам объект. 
Рассмотрим пример, когда один и тот же объект описывается 
двумя документами по-разному. 

Документ 1 
Прибор X имеет название А. Модификация прибора – М1. Номинальное напряжение – 220 В. Потребляемая мощность – 330 Вт. Масса прибора не более 50 кг. Сила тока на выходе: 

– при режиме 1 – 16 А; 
– при режиме 2 – 20 А. 

Документ 2 
Прибор X имеет название В. Модификация прибора – М2. Прибор 
работает от сети переменного тока с напряжением 220 В. Потребляемая мощность, не более: 
– при режиме 1 – 400 Вт; 
– при режиме 2 – 200 Вт. 
На основе этой документации необходимо определить сущности. 
В табл. 1.1 приведен перечень атрибутов, полученный в результате 
анализа двух документов. 

Таблица 1.1 

Перечень атрибутов (первый вариант) 

Имя атрибута 
Комментарий 
Номер сообщения, 
документа 

Тип изделия 
Прибор Х 
1, 2 

Модификация 
М1 и М2 
1, 2 

Наименование 
А и В 
1, 2 

Питание 
От сети переменного тока 
1, 2 

Напряжение 
220 В 
1, 2 

Потребляемая мощность 
330 Вт 
1 

Минимальная мощность 
200 Вт 
2 

Максимальная мощность 
400 Вт 
2 

Минимальная сила тока 
16 А 
1 

Максимальная масса 
50 кг 
1 

Недостатком полученной сущности является то, что она содержит 
много атрибутов, которые не всегда имеют значения. Переделаем 
(воспользуемся методом обобщения) структуру сущности (табл. 1.2). 

Таблица 1.2 

Перечень атрибутов (второй вариант) 

Имя атрибута 
Комментарий 
Номер сообщения, документа 

Тип изделия 
Прибор Х 
1, 2 

Модификаця 
М1 и М2 
1, 2 

Наименование 
А и В 
1, 2 

Параметр 
Имя параметра, т.е. питание, напряжение, мощность, сила тока и т.д. 
1, 2 

Единица измерения 
В, Вт, А и т.д. 
1, 2 

Значение параметра 
Числовое значение соответствующего 
параметра 
1, 2 

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

Второй этап – определение связей между сущностями 
Далее осуществляется спецификация связей между сущностями 
(строится ER-диаграмма). При этом обычно используется модель 
«сущность–связь». 
Каждая связь в этой модели характеризуется именем, обязательностью, типом и степенью. Различают факультативные и обязательные связи. Если вновь порожденный объект одного типа оказывается 
по необходимости связанным с объектом другого типа, то между 
этими типами объектов существует обязательная связь (обозначается 
двойной линией). Иначе связь является факультативной. 
По типу различают множественные связи «один к одному» (1:1), 
«один ко многим» (1 : N) и «многие ко многим» (M : N). ERдиаграмма, содержащая различные типы связей, приведена на рис. 1.2. 
Обратите внимание на то, что обязательные связи на рис. 1.2 выделены двойной линией. 

 

Рис. 1.2. ER-диаграмма с примерами типов множественных связей 

Степень связи определяется количеством сущностей, которые охвачены данной связью. Пример бинарной связи – связь между отделом и сотрудниками, которые в нем работают. Примером тернарной 
связи 
является 
связь 
типа 
ЭКЗАМЕН 
между 
сущностями 
ДИСЦИПЛИНА, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ. Из последнего 
примера видно, что связь также может иметь атрибуты (в данном 
случае это Дата проведения и Оценка). Пример ER-диаграммы с указанием сущностей, их атрибутов и связей приведен на рис. 1.3. 

Рис. 1.3. Пример ER-диаграммы с однозначными 
и многозначными атрибутами 

Третий этап – синтез глобальной концептуальной схемы 
Этот этап на практике используется сравнительно редко: в случаях описания масштабной предметной области. Суть этого этапа состоит в том, что различные фрагменты (подсхемы) описания предметной области формально объединяются в единую схему. 
При небольшом количестве подсхем (обычно не более пяти) они 
объединяются за один шаг. В противном случае выполняется последовательное объединение за несколько шагов. 
При объединении проектировщик может формировать конструкции, производные по отношению к тем, которые были использованы 
в локальных представлениях. Такой подход может преследовать следующие цели: 
• объединение в единое целое фрагментарных представлений о 
различных свойствах одного и того же объекта; 
• введение абстрактных понятий, удобных для решения задач 
системы, установление их связи с конкретными понятиями, использованными в модели; 
• образование классов и подклассов подобных объектов (например, класс ИЗДЕЛИЕ и подклассы типов изделий, производимых на 
предприятии). 
На этапе объединения необходимо выявить и устранить все противоречия. Например, одинаковые названия семантически различных 
объектов или связей или несогласованные ограничения целостности 
на одни и те же атрибуты в разных приложениях.  
По завершении объединения результаты проектирования являют 
собой концептуальную схему (модель) предметной области.  

1.3. Логическое проектирование баз данных 

На первом этапе логического проектирования должен производиться выбор СУБД для поддержки проектируемой БД. Однако на 
практике это выполняется сравнительно редко: обычно предпочтение 
отдается хорошо известной СУБД или требуемой заказчиком. После 
этого разрабатывается логическая структура БД, учитывающая особенности и ограничения выбранной СУБД. 
Одной из основных задач этапа логического проектирования для 
СУБД, поддерживающих реляционную модель данных, является 
отображение сущностей в таблицы. 
В большинстве случаев каждая сущность отображается в одну реляционную таблицу. Но возможны еще два варианта: 
1) сущность отображается в две или более таблицы; 
2) несколько сущностей отображаются в одну таблицу. 
Первый случай возможен, например, при использовании ранних 
версий СУБД ORACLE, если сущность имеет более одного атрибута 
с типом данных Long. 
Пример 
Сущность Публикация: 
Название 
Вид публикации (статья, книга) 
Аннотация – Long 
ФИО автора 
Текст публикации – Long 
Наличие двух длинных полей вынуждает отобразить эту сущность 
в двух таблицах: 
Таблица PublMain: 
PublId – Integer (идентификатор публикации) 
PublType – Char (1) 
Announce – Long 
Family – Varchar (60) 
Таблица PublText: 
PiblId 
PublText – Long 
Другие причины разбивки сущности могут быть связаны с особенностями обработки данных в приложении. Например, в распределенной БД нужно только часть данных отсылать в другую БД. Тогда неотсылаемые атрибуты можно выделить в отдельную таблицу.