Пример готовой курсовой работы по предмету: Базы данных
Содержание
Содержание
1 Этапы проектирования базы данных и их процедуры.2
1.1 Процедуры концептуального проектирования 2
1.2 Процедуры логического проектирования 3
1.3 Процедуры физического проектирования 5
Список использованной литературы.7
1 Этапы проектирования базы данных и их процедуры
Проектирование базы данных осуществляется в три этапа:
1)концептуальное проектирование;
2)логическое проектирование;
3)физическое проектирование.
1.1 Процедуры концептуального проектирования
Цель этапа концептуального проектирования — создание концептуаль-ной модели данных исходя из представлений пользователей о предметной области. Для ее достижения выполняется ряд последовательных процедур.
1.Определение сущностей и их документирование. Для идентифи-кации сущностей определяются объекты, которые существуют независимо от других. Такие объекты являются сущностями. Каждой сущности присваива-ется осмысленное имя, понятное пользователям. Имена и описания сущно-стей заносятся в словарь данных. Если возможно, то устанавливается ожи-даемое количество экземпляров каждой сущности.
2.Определение связей между сущностями и их документирование. Определяются только те связи между сущностями, которые необходимы для удовлетворения требований к проекту базы данных. Устанавливается тип каждой из них. Выявляется класс принадлежности сущностей. Связям при-сваиваются осмысленные имена, выраженные глаголами. Развернутое описа-ние каждой связи с указанием ее типа и класса принадлежности сущностей, участвующих в связи, заносится в словарь данных.
3.Создание ER-модели предметной области. Для представления сущностей и связей между ними используются ER-диаграммы. На их основе создается единый наглядный образ моделируемой предметной области — ER-модель предметной области.
4.Определение атрибутов и их документирование. Выявляются все атрибуты, описывающие сущности созданной ER-модели. Каждому атрибуту присваивается осмысленное имя, понятное пользователям. О каждом атрибу-те в словарь данных помещаются следующие сведения:
имя атрибута и его описание;
тип и размерность значений;
значение, принимаемое для атрибута по умолчанию (если такое имеется);
может ли атрибут иметь Null-значения;
является ли атрибут составным, и если это так, то из каких простых атрибутов он состоит. Например, атрибут «Ф.И.О. клиента» может состоять из простых атрибутов «Фамилия», «Имя», «Отчество», а может быть простым, содержащим единые значения, как-то «Сидорский Евгений Михайлович». Если пользователь не нуждается в доступе к отдельным элементам «Ф.И.О.», то атрибут представляется как простой;
является ли атрибут расчетным, и если это так, то как вычисляются его значения.
5.Определение значений атрибутов и их документирование. Для каждого атрибута сущности, участвующей в ER-модели, определяется набор допустимых значений и ему присваивается имя. Например, атрибут «Тип сче-та» может иметь только значения «депозитный», «текущий», «до востребова-ния», «карт-счет». Обновляются записи словаря данных, относящиеся к атри-бутам, -в них заносятся имена наборов значений атрибутов.
6.Определение первичных ключей для сущностей и их докумен-тирование. На этом шаге руководствуются определением первичного ключа — как атрибута или набора атрибутов сущности, позволяющего уникальным образом идентифицировать ее экземпляры. Сведения о первичных ключах помещаются в словарь данных.
7.Обсуждение концептуальной модели данных с конечными поль-зователями. Концептуальная модель данных представляется ER-моделью с сопроводительной документацией, содержащей описание разработанной мо-дели данных. Если будут обнаружены несоответствия предметной области, то в модель вносятся изменения до тех пор, пока пользователи не подтвердят, что предложенная им модель адекватно отображает их личные представле-ния.
1.2 Процедуры логического проектирования
Цель этапа логического проектирования — преобразование концепту-альной модели на основе выбранной модели данных в логическую модель, не зависимую от особенностей используемой в дальнейшем СУБД для физиче-ской реализации базы данных. Для ее достижения выполняются следующие процедуры.
1.Выбор модели данных. Чаще всего выбирается реляционная модель данных в связи с наглядностью табичного представления данных и удобства работы с ними.
2.Определение набора таблиц исходя из ER-модели и их докумен-тирование. Для каждой сущности ER-модели создается таблица. Имя сущ-ности — имя таблицы. Осуществляется формирование структуры таблиц на основании изложенных в параграфе 1.4 правил. Устанавливаются связи меж-ду таблицами посредством механизма первичных и внешних ключей. Струк-туры таблиц и установленные связи между ними документируются.
3.Нормализация таблиц. Для правильного выполнения нормализации проектировщик должен глубоко изучить семантику и особенности использо-вания данных. На этом шаге он проверяет корректность структуры таблиц, созданных на предыдущем шаге, посредством применения к ним процедуры нормализации. Эта процедура была описана в параграфе 1.5. Она заключает-ся в приведении каждой из таблиц, по крайней мере, к ЗНФ. В результате нормализации получается очень гибкий проект базы данных, позволяющий легко вносить в нее нужные расширения.
4.Проверка логической модели данных на предмет возможности выполнения всех транзакций, предусмотренных пользователями. Тран-закция это набор действий, выполняемых отдельным пользователем или прикладной программой с целью изменения содержимого базы данных. Так, примером транзакции в проекте БАНК может быть передача права распоря-жаться счетами некоторого клиента другому клиенту. В этом случае в базу данных потребуется внести сразу несколько изменений. Если во время вы-полнения транзакции произойдет сбой в работе компьютера, то база данных окажется в противоречивом состоянии, так как некоторые изменения уже бу-дут внесены, а остальные еще нет. Поэтому все частичные изменения долж-ны быть отменены для возвращения базы данных в прежнее непротиворечи-вое состояние.
Перечень транзакций определяется действиями пользователей в предметной области. Используя ER-модель, словарь данных и установленные связи между первичными и внешними ключами, производится попытка вы-полнить все необходимые операции доступа к данным вручную. Если какую-либо операцию выполнить вручную не удается, то составленная логическая модель данных является неадекватной и содержит ошибки, которые надо устранить. Возможно, они связаны с ропуском в модели сущности, связи или атрибута.
5.Определение требований поддержки целостности данных и их документирование. Эти требования представляют собой ограничения, кото-рые вводятся с целью предотвратить помещение в базу данных противоречи-вых данных. На этом шаге вопросы целостности данных освещаются безот-носительно к конкретным аспектам ее реализации. Должны быть рассмотре-ны следующие типы ограничений:
обязательные данные. Выясняется, есть ли атрибуты, которые не могут иметь Null-значений;
ограничения для значений атрибутов. Определяются допустимые значе-ния для атрибутов;
целостность сущностей. Она достигается, если первичный ключ сущности не содержит Null-значений;
ссылочная целостность. Она понимается так, что значение внешнего клю-ча должно обязательно присутствовать в первичном ключе одной из строк таблицы для родительской сущности;
ограничения, накладываемые бизнес-правилами. Например, в случае с проектом БАНК может быть принято правило, запрещающее клиенту рас-поряжаться, скажем, более чем тремя счетами.
Сведения обо всех установленных ограничениях целостности данных помещаются в словарь данных.
5.Создание окончательного варианта логической модели данных и обсуждение его с пользователями. На этом шаге подготавливается оконча-тельный вариант ER-модели, представляющей логическую модель данных. Сама модель и обновленная документация, включая словарь данных и реля-ционную схему связи таблиц, представляется для просмотра и анализа поль-зователям, которые должны убедиться, что она точно отображает предмет-ную область.
1.3 Процедуры физического проектирования
Цель этапа физического проектирования — описание конкретной реали-зации базы данных, размещаемой во внешней памяти компьютера. Это опи-сание структуры хранения данных и эффективных методов доступа к данным базы. При логическом проектировании отвечают на вопрос — что надо сде-лать, а при физическом — выбирается способ, как это сделать. Процедуры фи-зического проектирования следующие.
1.Проектирование таблиц базы данных средствами выбранной СУБД. Осуществляется выбор реляционной СУБД, которая будет использо-ваться для создания базы данных, размещаемой на машинных носиелях. Глубоко изучаются ее функциональные возможности по проектированию таблиц. Затем выполняется проектирование таблиц и схемы их связи в среде СУБД. Подготовленный проект базы данных описывается в сопровождаемой документации.
Выдержка из текста
3. Проектирование физической организации базы данных. На этом шаге выбирается наилучшая файловая организация для таблиц. Выявляются транзакции, которые будут выполняться в проектируемой базе данных, и вы-деляются наиболее важные из них. Анализируется пропускная способность транзакций — количество транзакций, которые могут быть обработаны за за-данный интервал времени, и время ответа — промежуток времени, необхо-димый для выполнения одной транзакции. Стремятся к повышению пропу-скной способности транзакций и уменьшению времени ответа. На основании указанных показателей принимаются решения об оптимизации производи-тельности базы данных путем определения индексов в таблицах, ускоряю-щих выборку данных из базы, или снижения требований к уровню нормали-зации таблиц. Проводится оценка дискового объема памяти, необходимого для размещения создаваемой базы данных. Стремятся к его минимизации.
Принятые решения по изложенным вопросам документируются.
4. Разработка стратегии защиты базы данных. База данных пред-ставляет собой ценный корпоративный ресурс, и организации ее защиты уде-ляется большое внимание. Для этого проектировщики должны иметь полное и ясное представление обо всех средствах защиты, предоставляемых выбран-ной СУБД.
5. Организация мониторинга функционирования базы данных и ее настройка. После создания физического проекта базы данных организуется непрерывное слежение за ее функционированием. Полученные сведения об уровне производительности базы данных используются для ее настройки. Для этого привлекаются и средства выбранной СУБД.
Решения о внесении любых изменений в функционирующую базу дан-ных должны быть обдуманными и всесторонне взвешенными.
Список использованной литературы
1.Базы данных. Учбник./Под ред. А.Д. Хомоненко. СПб, Корона, 2002 г.
2.К.Дж. Дейт. Введение в системы баз данных. 6-е издание. М.: «Вильмс», 99.
3.Роланд Фред Д. Основные концепции баз данных. М.: Вильямс, 2002.
