Текстовые фрагменты публикации
Фрагмент текстового слоя документа размещен для индексирующих роботов.
Для полноценной работы с документом, пожалуйста, перейдите в
ридер.
№ 104
Е.А. Морозов
Базы данных
Методические указания
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ «МИСиС»
№ 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-диаграммы с однозначными
и многозначными атрибутами
Третий этап – синтез глобальной концептуальной схемы
Этот этап на практике используется сравнительно редко: в случа-
ях описания масштабной предметной области. Суть этого этапа со-
стоит в том, что различные фрагменты (подсхемы) описания пред-
метной области формально объединяются в единую схему.
При небольшом количестве подсхем (обычно не более пяти) они
объединяются за один шаг. В противном случае выполняется после-
довательное объединение за несколько шагов.
При объединении проектировщик может формировать конструк-
ции, производные по отношению к тем, которые были использованы
в локальных представлениях. Такой подход может преследовать сле-
дующие цели:
• объединение в единое целое фрагментарных представлений о
различных свойствах одного и того же объекта;
• введение абстрактных понятий, удобных для решения задач
системы, установление их связи с конкретными понятиями, исполь-
зованными в модели;
• образование классов и подклассов подобных объектов (напри-
мер, класс ИЗДЕЛИЕ и подклассы типов изделий, производимых на
предприятии).
На этапе объединения необходимо выявить и устранить все про-
тиворечия. Например, одинаковые названия семантически различных
объектов или связей или несогласованные ограничения целостности
на одни и те же атрибуты в разных приложениях.
По завершении объединения результаты проектирования являют
собой концептуальную схему (модель) предметной области.
