29. Процедуры концептуального проектирования. Цель- создание концепт модели данных исходя из представл пользоват о предметной области.

1. Определение сущностей и их документирование – определ сущностей.

2. Определение связей между сущ и их документирование- опред только те связи сущ, кот необходимы для удовлетв требований к проекту БД.

3. Создание ER-модели предметной области.

4. Определение атрибутов и их документирование.-выявл все атриб, описыв сущности созданной ЕКмодели.Каждому атриб присваив осмысленное имя,понятное пользователю

5. Определение значе атрибутов и их документирование-опред набора допустимых знач, кот присвается имя.

6. Опред первичных ключей для сущностей и их документиров.

7. Обсуждение концептуальной м дан с конечными пользовател

31. Процедуры физического проектирования – описание конкретной реализацц БД, размещаемо во внешн памяти копма

1. Выбор СУБД

2. Проектирование таблиц БД средствами выбранной СУБД.

3. Реализация бизнес-правил (установки, правила и технол приемы, принятые в предмет обл) в среде выбранной СУБД.

4. Проектирование физической организации БД.-выбир наилуч файловая организ, выявл транзакции

5. Разработка стратегии защиты БД.

6. Организация мониторинга ф-рования БД и ее настройка.

30. Процедуры логического проектирования- преобраз концеп на основе выбранной мод данных в лог модель, не завис от особенностей использ в дальнейшем субд для физ реализ бд.

1. Выбор модели данных. Чаще реляц.

2. Определ набора таблиц исходя из ER-модел и их документи.

3. Нормализация таблиц

3. Проверка лог модели данных на предмет возможности выполнени всех операций, предусмотренных пользователям.

5. Определение требований поддержки целостности данных и их документир.

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

33. CASE. ER-модели получили широкое распространение в CASE-средствах, кот предназначены для автоматизированного проектирования реляц БД. Широко распространены CASE-системы Erwin, Design/IDEF, Power Designer.

Графич средства моделировани предм-ой обл дают возможност наглядно изучать концеп мод дан и перестраивать ее соотв-но поставленным целям и имеющимся ограничениям. Проект БД готовится в реальном масштабе времени. Особенности…

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

28. Нормализация таблиц - процесс, позволяющий мin-ть избыточность данных, мин испол отсутству значений, предотвращение потери информации. Реляц БД считается эф-ной, если все ее табл находятся как мин в 3НФ.

Определен 1НФ Таблица находится в 1НФ, если все ее поля содержат только неделимые значения.

На практике. Если в клетках столбца содержится несколько значений, то каждое из них следует представить отдел записью.

Определен 2НФ. Табл находится в 2НФ, если она удовлетворя требованиям 1НФ и неключевые поля функционально полно зависят от первичного ключа. Функциональная зависимость (ФЗ)–отображает опр семантич связь между полями таблицы.Пусть (Х₁, Х₂,…,Х_к) – множество полей, образующих первичный ключ. Неключевое поле А ф-но зависит от ключа, если каждой комбинации знач полей данного множества соотв-т 1 и только 1 значение поля А. ФЗ обознач так(Х₁, Х₂,…,Х_к)®А

Неключевое поле А ф-но полно зависит от ключа, если оно ф-но зависит от ключа и не существует ФЗ А ни от какого подмножества множества (Х₁, Х₂,…,Х_к).

Если существует ФЗ А от к-л подмножества этого множества, то А находится в частичной ф-ной зависимост от первичного

На практике. Неключевые поля, наход в частичной ФЗ от некоторого подмножества первичного ключа, удаляются из таблицы и помещаются в новую таблицу совместно с подмножеством первичного ключа, от кот они зависят.