Егоров А.В. Методические указания к выполнению курсовой работы по курсу Базы данных и системы управления базами данных

Подождите немного. Документ загружается.

681.301 (07)

М545

№ 1618

Министерство общего и профессионального образования

Российской Федерации

Таганрогский государственный радиотехнический университет

Кафедра Экономической информатики и коммерции

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

к выполнению курсовой работы

по курсу

Базы данных и системы управления базами данных

Для специальностей: 0614, 0618, 071901.

ФЭМП

Таганрог 1998

УДК 681.016Б3 (07.07)

Составитель А.В. Егоров

Методические указания к выполнению курсовой раб оты по курсу «Базы данных

и системы управления базами данных». Таганрог: Изд-во ТРТУ, 1998 г.

Изложены методические рекомендации по выполнению курсовой работы. При-

ведены основные теоретические положения, задания к выполнению и пример

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

Рецензент: Беляков С.Л., доцент кафедры ЭИиК, ТРТУ

Содержание

Введение

Цель раб оты

1. Теоретические положения

1.2. Основные понятия БД и СУБД

1.3. Этапы проектирования БД

1.4. Модели данных

1.5. Нормальные формы

2. Задания к выполнению курсовой раб оты

2.1. Перечень заданий

2.2. Варианты заданий

3. Содержание курсовой работы

4. Пример проектирования

Список литературы

Введение.

Современные информационные системы, основанные на концепции банков

данных и баз знаний, характеризуются большими объемами хранимой инфор-

мации, их сложной организацией, необходимостью удовлетворять разнообраз-

ные требования пользователей. Важным компонентом этой концепции является

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

мационной моделью непре рывно ме ня ющегося реального мира, также должны

меняться, чтобы адекватно отображать действительность. Поэтому для сопро-

вождения и эксплуатации информационных систем требуется постоянное ис-

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

Методология проектирования автоматизированных банков данных может

рассматриваться как совокупность методов и средств, последовательное приме-

нение которых обеспечивает разработку проекта баз данных, удовлетворяющего

заданным целям. Рассматриваемая методология позволяет пользователю лучше

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

Следуя этой методологии, проектировщик может выполнять более глубо-

кий и содержательный анализ требований к данным, осуществлять контроль и

управление кодом проектирования.

Цель работы.

Целью курсовой работы является изучение основ проектирования баз дан-

ных в экономических приложениях. В процессе изучения дисциплины и выпол-

нения курсовой работы студенты должны усвоить теоретические основы орга-

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

ческом и физическом уровнях, научиться ставить и решать практические задачи

проектирования и эксплуатации баз данных.

1. Теоретические положения

1.1. Основные понятия БД и СУ БД

Взаимосвязанные данные, которые позволяют описать ту или иную реаль-

ную систему, называются информационной системой. Каждая информационная

система ориентирована на конкретную предметную область, которую она опи-

сывает.

Существует понятие объекта предметной области. Каждый объект пред-

метной области характеризуется конечным набором атрибутов (элементов дан-

ных, реквизитов). Количество и форма представления атрибутов определяется

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

•

именем;

•

формой представления (алфавитная, алфавитно-цифровая, дата);

•

длиной, т.е. количеством символов, выделяемых для конкретных данных

Среди элементов, характеризующих объект предметной области, присутст-

вуют ключевые элементы данных (ключи).

К ключевым элементам данных относятся такие элементы данных, по зна-

чениям которых можно идентифицировать значения остальных элементов дан-

ных. На практике часто встречаются такие ситуации, когда в качестве ключа

выступает не один, а несколько элементов данных совместно.

Совокупность значений элементов данных, связанных определенным по-

рядком, называется записью.

Упорядоченная совокупность элементов множества называется картежом.

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

База данных представляет собой совокупность связанных данных в кон-

кретной предметной области и различного назначения.

Программное обеспечение, аппаратные средства, программ ируемая логика

и процедуры, осуществляющие управление базами данных, называются систе-

мой управления базами данных (СУБД).

Структурой БД является СУБД, ориентированное описание данных или

схема, обычно выраженная в терминах языка описания данных.

1.2. Этапы проектирования БД

Жизненный цикл БД представляет собой концепцию, в рамках которой

рассматривается ра звитие БД во времени. Жизненный цикл БД делится на две

фазы:

•

фаза анализа и проектирования,

•

фаза эксплуатации.

В течение 1-ой фазы происходит сбор требований пользователей и проек-

тирование БД. В течение 2-ой фазы происходит машинная реализация (создание

и отладка программ, проектирование входных и выходных форм и т.д.). После-

довательность выполнения этапов и решения задач представлена на рис. 1:

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

Формулировка и анализ требований относится к первой фазе и является

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

Однако он является наиболее важным, т.к. на его базе строится большинство

проектных решений. Основной задачей является сбор требований, предъявляе-

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

ней. Анализ требований обеспечивает согласованность целей пользователей, а

также согласованность их представлений об информационных потоках. На ос-

нове анализа требований устанавливаются цели организации, определяются

требования к БД, вытекающие из основных задач. Эти требования документи-

руются в форме доступной пользователям и проектировщикам БД. Для более

тщательного анализа требований используется методика тестирования или ан-

кетирования пользователя различного уровня. Результатом этого этапа являет-

ся определение ф ормата и семантики данных.

Концептуальное проектирование имеет своей целью построение незави-

симой от СУБД информационной структуры путем объединения информаци-

онных требований пользователя. Результатом этого этапа является представле-

ние информационных требований в виде диаграмм «сущность-связь». Основу

этой диаграммы представляет набор сущностей, который моделирует опред е-

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

Формулировка и анализ

требований (I)

Концептуальное

проектирование (II)

Проектирование

реализации(III)

Физическое проектирование

(

)

Требования

пользователя

Требования

об

аботки

Характеристики

СУБД

спе

ика т

ебований

ин

ома

ионная

ст

ру

кт

ур

логическая ст

ру

кт

ур

Характеристика ОС

физическая структура

Сущность представляет собой основное содержание того явления или

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

точкой сбора д анных). Необходимо различать тип сущности и экземпляр сущ-

ности. Тип сущности - это наб ор однородных вещей, предметов, явлений, вы-

ступающих как единое целое. Экземпляр сущности относится к конкретной

вещи, т.е. когда вместо общих характеристик появляются конкретные данные.

Сущность является наиболее общим поня тием по сравнению с объектом

предм етной области. При построении диаграмм «сущность-связь» возникают

некоторые сложности, связанные с тем, что одни и те же пользователи БД

имеют различные представления одних и тех же фактов.

Проектирование реализации также относится к 1-ой фазе жизненного цик-

ла и состоит из двух компонент:

•

проектирование БД на уровне логической структуры,

•

проектирование программ.

Структурой БД является СУБД, ориентированное описание данных или

схема, обычно выраженная в терминах языка описания данных.

Проектирование программного обеспечения имеет целью создание струк-

турированных программ, использующих язык программ ирования и язык мани-

пулирования данными.

Язык манипулирования данными - это ничто иное как набор команд, осу-

ществляющих ра зличные процед уры манипулирования д анными.

Физическое проектирование относится к 1-ой фазе и делится на три кате-

гории:

•

Проектирование формата хранимых записей (сюда включаются виды

представления и сжатия данных в записи), распределение элементов данных за-

писей по различным участкам физической памяти в зависимости от их разм еров

и характеристик использования.

•

Анализ и проектирование кластеров. Кластеризацией записей называется

такое объединение записей различного типа в физические группы, которое по-

зволяет эффективно использовать преимущество последовательного размеще-

ния данных.

•

Проектирование путей доступа к данным (сюда включаются такие пара-

метры и методы, тот которых в значительной степени зависит время доступа и

время обработки запросов. Иногда эти параметры называют производительно-

стью системы или производительностью СУБД).

Результатом физического проектирования является физическая структура

БД, ф орм аты и размещение в памяти записей и методы доступа к данным .

1.3. Модели данных

Любая СУБД основывается на конкретной модели д анных

Модель данных

отражает взаимосвязи между объектами, описываемыми в БД. Компонентами в

модели данных являются объекты и их взаимосвязи. В настоящее время имеет-

ся три основные модели данных:

•

иерархическая,

•

сетевая,

•

реляционная.

Основное различие между указанными выше типами моделей данных со-

стоит в способах представления взаимосвязей:

•

между объектами,

•

между атрибутами одного и того же объекта,

•

между атрибутами различных объектов.

Различают четыре основных типа взаимосвязей:

•

"один к одному" (1:1),

•

"один к многим" (1:М),

•

"многие к одному" (М:1),

•

"многие к многим" (М:М).

Связь "од ин к од ному" имеет место тогда, когда значению од ного атрибута

соответствует одно значение другого атрибута.

Связь "один к многим" существует тогда, когда одному значению одного

атрибута соответствует множество значений другого атрибута.

Связь "многие к одному" устанавливается тогда, когда множество значений

одного атрибута однозначно определяет значение другого атрибута.

Связь "многие к многим" означает, что множество значений одного атри-

бута соответствует множеству значений другого атрибута.

Все рассмотренные выше взаимосвязи могут использоваться для случая,

когда атрибуты не единичные, а представляют собой наборы атрибутов.

При установлении взаимосвязи между элементами данных нужно учиты-

вать реальный их смысл.

Иерархическая модель данных (ИМД) имеет аналогичную структуру де-

ревьев и состоит из узлов и ветвей. Узел представляет собой совокупность эле-

менты данных (или элемент данных), описывающих некоторый объект. В каче-

стве ветвей выступают взаимосвязи одного из четырех видов. Зависимые узлы

располагаются на более низких уровнях и удовлетворяют схеме "исходный -

порожденный".

Иерархическая модель данных организовывает данные в виде некоторой

иерархии, причем каждый экземпляр корневого узла образует начало записи ло-

гической структуры БД, т.е. ИМД будет состоять из нескольких деревьев. В

ИМД узлы, находящиеся на i+1 - ом уровне называются порожденными узлами

на i-ом уровне. А узел, находящийся на i-ом уровне, является исходным для уз-

лов i+1-го уровня.

Иерархическая структура всегда удовлетворяет следующим требованиям:

Иерархия начинается с корневого узла.

Каждый узел может состоять из одного или нескольких элементов данных,

описывающих объект.

На низших уровнях всегда располагаются зависимые узлы.

Исходный узел может иметь в качестве зависимых один или несколько по-

рожденных узлов.

Пути доступа к каждому из узлов являются уникальными.

Описание логической структуры БД называется схемой БД. Она содержит

имена объектов, атрибуты и указывает на существующие взаимосвязи между

ними. Схема представляет структуру, в которую могут быть помещены значе-

ния элементов данных. Если схема содержит значения элементов д анных, то ее

называют экземпляр схемы.

Если порожденный элемент (узел) имеет более од ного исходного элемента,

то такое отношение нельзя описать с помощью ИМД, т.к. это противоречит

правилу построения ИМД (порожденный узел имеет более одного исходного).

Т.е. люб ой элемент сетевой структуры может быть связан с любым элементом

этой же структуры. Сетевая структура допускает наличие циклов между узлами,

что усложняет технологию поиска и обраб отки данных.

СМД, в которой связь между элементами в отношении "порожд енный - ис-

ходный" является однозначной (т.е. отсутствуют сдвоенные стрелки в обоих на-

правлениях) назыв ает ся простой, в против ном случае СМД назыв ается сложной.

Основу реляционной модели составляет совокупность данных, объединен-

ных в виде отношений (таблиц). Из теории множеств известно, что формальным

аналогом любой таблицы является отношение.

Пусть имеется некоторая совокупность множеств D1, D2, … DN. Отноше-

нием R на этих множествах называется подмножество их декартового произве-

дения, где N - это степень отношения. Картеж - это совокупность элементов

множеств, причем порядок имеет существенное значение, т.к. каждый элемент

множества должен принадлежать только своему домену. Запись вида R(A,B,C)

называется схемой отношения и наряду с названием отношения содержит име-

на атрибутов. Совокупность схем отношений составляет схему ре ляционной БД.

Количество картежей называется мощностью отношения.

1.4. Нормальные формы отнош ений

Для поддержания БД в согласованном состоянии необходимо правильно

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

висимость существует, когда один или более доменов отношения уникально

определяет один или более доменов этого же отношения. (Под словом "уни-

кально" понимается взаимооднозначное соответствие). Атрибуты, стоящие сле-

ва от стрелки называются областью опреде ления, а справа - областью значений.

Функциональная зависимость вида A

→

B называется полной функциональ-

ной зависимостью, если B зависит от всей группы значений атрибута A, а не от

ее части (подмножества).

Из определения ФЗ следует, что не т необходимости в том, чтобы какой-

либо атрибут появлялся дважды: либо с одной, либо с другой стороны от стрел-

ки, а также порядок появления этих атрибутов не имеет значения. Единствен-

ным существенным условием является то, что при построении ФЗ для конкрет-

ного отношения должны быть охвачены все принадлежащие этому отношению

атрибуты. Цель построения ФЗ для конкретного отношения - это нахождение

ключа отношения, точнее разновидности ключей.

Вероятным ключом отношения R называется такое подмножество атрибу-

тов R, что каждое сочетание их значений встречается только в одной строке от-

ношения и никакое подмножество K этим свойством не обладает.

Вероятных ключей в отношении может быть несколько, поэтому выбирают

один и называют его первичным ключом отношения R - это такой атрибут, по

значениям которого производится контроль достоверности д анных этого отно-

шения .

При нахождении функциональных зависимостей и определении первично-

го ключа существенную роль играют правила построения и преобразования

функциональных зависимостей, которые сформулированы в виде шести аксиом.

Они называются также правилами вывода, так как, используя их, можно вывес-

ти новые функциональные зависимости из уже имеющихся.

Рефлексивность.

Для любого X

∈

R справедливо X

→

Расширение.

Если X и Y

∈

R и X

→

Y, то для любого W

∈

R справедливо X,W

→

Аддитивность.

Если X,Y,Z

∈

R и X

→

Y, X

→

Z, то X

→

Y,Z.

Проективность (декомпозиция).

Если X,Y,Z

∈

R и X

→

Y,Z, то X

→

Y, X

→

Транзитивность.

Если X,Y,Z

∈

R и X

→

Y, Y

→

Z, то X

→

Псевдотранзитивность.

Если X,Y,Z,W

∈

R и X

→

Y, Y,W

→

Z, то X,W

→

Схема отношения R находится в 1НФ, если значения всех доменов являют-

ся атомарными для любого атрибута, принадлежащего этому отношению. Дру-

гими словами, домены не являются ни списками, ни множествами простых или

сложных значений.

Определить понятие атомарности трудно, т.к. значение, атомарное в одном

отношении, может быть не атомарным в другом отношении. Однако можно ру-

ководствоваться общим принципом, что значение не атомарно, если в приложе-

нии оно используется по частям.

Преимущество 1НФ состоит в том, что она позволяет выражать функцио-

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

торой требует пользователь.

Вторая и третья нормальные формы возникли в результате стремления из-

бежать аномалий при обновлении данных и избавиться от информационной из-