Дипломная работа

от 20 дней
от 9999 рублей

Заказать

Курсовая работа

от 10 дней
от 1999 рублей

Заказать

Реферат

от 3 дней
от 699 рублей

Заказать

Контрольная работа

от 3 дней
от 99 рублей
за задачу

Заказать

Диссертация

Сроки и стоимость индивидуальные

Заказать

Главная - Базы данных - Этапы проектирования базы данных и их процедуры

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

  • Тема: Этапы проектирования базы данных и их процедуры
  • Автор: Юлия
  • Тип работы: Курсовая
  • Предмет: Базы данных
  • Страниц: 7
  • Год сдачи: 2008
  • ВУЗ, город: Москва
  • Цена(руб.): 1500 рублей

Заказать персональную работу

Выдержка

3. Проектирование физической организации базы данных. На этом шаге выбирается наилучшая файловая организация для таблиц. Выявляются транзакции, которые будут выполняться в проектируемой базе данных, и вы-деляются наиболее важные из них. Анализируется пропускная способность транзакций - количество транзакций, которые могут быть обработаны за за-данный интервал времени, и время ответа - промежуток времени, необхо-димый для выполнения одной транзакции. Стремятся к повышению пропу-скной способности транзакций и уменьшению времени ответа. На основании указанных показателей принимаются решения об оптимизации производи-тельности базы данных путем определения индексов в таблицах, ускоряю-щих выборку данных из базы, или снижения требований к уровню нормали-зации таблиц. Проводится оценка дискового объема памяти, необходимого для размещения создаваемой базы данных. Стремятся к его минимизации.
Принятые решения по изложенным вопросам документируются.
4. Разработка стратегии защиты базы данных. База данных пред-ставляет собой ценный корпоративный ресурс, и организации ее защиты уде-ляется большое внимание. Для этого проектировщики должны иметь полное и ясное представление обо всех средствах защиты, предоставляемых выбран-ной СУБД.
5. Организация мониторинга функционирования базы данных и ее на¬стройка. После создания физического проекта базы данных организуется не¬прерывное слежение за ее функционированием. Полученные сведения об уровне производительности базы данных используются для ее настройки. Для этого привлекаются и средства выбранной СУБД.
Решения о внесении любых изменений в функционирующую базу дан-ных должны быть обдуманными и всесторонне взвешенными.

Содержание

Содержание

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. Проектирование таблиц базы данных средствами выбранной СУБД. Осуществляется выбор реляционной СУБД, которая будет использо-ваться для создания базы данных, размещаемой на машинных носиелях. Глубоко изуча¬ются ее функциональные возможности по проектированию таблиц. Затем вы¬полняется проектирование таблиц и схемы их связи в среде СУБД. Подготов¬ленный проект базы данных описывается в сопровождаемой документации.

Литература

1. Базы данных. Учбник./Под ред. А.Д. Хомоненко. СПб, Корона, 2002 г.
2. К.Дж. Дейт. Введение в системы баз данных. 6-е издание. М.: «Вильмс», 99.
3. Роланд Фред Д. Основные концепции баз данных. М.: Вильямс, 2002.

Форма заказа

Заполните, пожалуйста, форму заказа, чтобы менеджер смог оценить вашу работу и сообщил вам цену и сроки. Все ваши контактные данные будут использованы только для связи с вами, и не будут переданы третьим лицам.

Тип работы *
Предмет *
Название *
Дата Сдачи *
Количество Листов*
уточните задание
Ваши Пожелания
Загрузить Файлы

загрузить еще одно дополнение
Страна
Город
Ваше имя *
Эл. Почта *
Телефон *
  

Название Тип Год сдачи Страниц Цена
Учет кадров БД Курсовая 2010 33 1500
Разработка базы данных Курсовая 2008 36 1500
Проектирование базы данных компьютерного магазина. Курсовая 2008 37 1000
Глобальная сеть Интернет, как способ организации межкультурного общения. Курсовая 2007 23 1000
Базы данных и знаний Курсовая 2001 27 1000
Системы данных для крупнейшего производителя молочной продукции в Северо Казахстанской области консорциума «Молсервис». Курсовая 2001 26 1000
ИС сотрудника почтового отделения по оформлению подписки Курсовая 2006 45 1000
Структуры данных Курсовая 2009 42 1500
Проектирование информационно-логической модели предметной области Курсовая 2009 14 1500
Преимущества и недостатки реляционных баз данных Курсовая 2009 24 1000
курсовые, дипломные, контрольные на заказ скидки на курсовые, дипломные, контрольные на заказ

© 2010-2016, Все права защищены. Принимаем заказы по всей России.