Содержание
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.
|
|
