30. Логич. Проект-е, его цель и процедуры.

Цель этапа логич. проект-я – преобраз-е концепт. модели на основе выбранной модели данных в логич. модель, не завис-ю от ос-тей исп-й в дальнейш. СУБД для физ. реализ-ии БД. Для ее достижения выполняются следующие процедуры. 1. Выбор модели данных. Чаще выбир-ся реляц. модель данных в связи с наглядностью табл. предст-я данных и удобства работы с ними. 2. Опр-е набора таблиц исходя из ER-модели и их док-ние. Для каждой сущности ER-модели создается таблица. Имя сущности – имя таблицы. Осущ-ся форм-ние структуры таблиц. Устанавливаются связи между таблицами посредством мех-зма первичных и внешних ключей. Стр-ры таблиц и установл-е связи между ними док-ся. 3. Нормализация таблиц. На этом шаге коррект-щик проверяет корректность стр-ры таблиц, созданных на предыдущем шаге, посредством прим-я к ним процедуры нормализации. Она закл-ся в приведении каждой из таблиц, по крайней мере, к 3НФ. 4. Проверка логич. модели данных на предмет возм-сти вып-я всех транзакций, предусм-ных польз-ми. Транзакция – это набор действий, выполняемых отдельным польз-лем или прикладной программой с целью изм-я содержимого БД. 5. Опр-е требований поддержки целостности данных и их док-ние. Эти треб-я предст-ют собой ограничения, к. вводятся с целью предотвратить помещение в БД противоречивых данных. Д. б. рассм-ны след. типы ограничений: 1)обязательные данные. Выясняется, есть ли атрибуты, к. не м. иметь Null-знач-й; 2)ограничения для значений атрибутов. Опр-ся допустимые знач-я для атрибутов; 3)целостность сущностей. Она достигается, если первичный ключ сущности не содержит Null-значений; 4)ссылочная целостность. Она понимается так, что значение внешнего ключа должно обязательно присутствовать в первичном ключе одной из строк таблицы для родительской сущности; 5) ограничения, накладываемые бизнес-правилами. Например, в случае с проектом БАНК может быть принято правило, запрещающее клиенту распоряжаться, скажем, более чем тремя счетами. Сведения обо всех установленных ограничениях целостности данных помещаются в словарь данных.

6. Создание окончательного варианта логической модели данных и обсуждение его с пользователями. На этом шаге подготавливается окончательный вариант ER-модели, представляющей логическую модель данных. Сама модель и обновленная документация, включая словарь данных и реляционную схему связи таблиц, представляется для просмотра и анализа пользователям, которые должны убедиться, что она точно отображает предметную область.

31.Физическое проектирование, его цель и процедуры.

Цель– описание конкретной реализации БД, размещаемой во внешней памяти компьютера, структуры хранения данных и эффективных методов доступа к ним. При лог-ом проект-ии отвечают на вопрос- что надо сделать, при физ-ом- выбирается сп-б, как это сделать. Процедуры физ-го проект-я следующие:

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

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