Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ИТ. 2 часть_ шпоры.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
506.37 Кб
Скачать

18.Концептуальное проектирование, его цель, процедуры

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

Концептуальн проектир-ние:

1. Анализ требований к БД: выявление представлений конечных пользователей и требований к обработке транзакций.

2. Моделир-ние связей сущностей и нормализация; определение сущностей, атрибутов и связей, построение ER-диаграмм, нормализация таблиц.

3. Проверка модели данных: правила ввода, обновления и удаления, проверка отчетов, запросов, представлений.

4. Проектирование распределенной БД: определение местополож-я таблиц, требований доступа и стратегии фрагментирования.

Процедуры: 1. определение сущностей и их документирование: для идентификации сущностей определяются объекты, которые существуют независимо от других. Такие объекты являются сущностями. Каждой сущности присваивается осмысленное имя, понятное пользователям. Имена и описания сущностей заносятся в словарь данных.

2. создание семантической модели предметной области

3. определение связей между сущностями и их документирование:

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

4. обсуждение концептуальной модели данных с конечными пользователями - если будут обнаружены несоответствия предметной области, то в модель вносятся изменения до тех пор, пока пользователи не подтвердят, что предложенная им модель адекватно отображает их личные представления.

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

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

Результат: - логич структура БД, которая представляет собой схему, описанную в терминах языка описания данных.

- функционирование спецификации программных модулей и набор возможных запросов к БД.

Процедуры: 1. определение набора таблиц из ER-модели и их документирование - для каждой сущности ER-модели создается таблица. Имя сущности – имя таблицы. Устанавливаются связи между таблицами посредством механизма первичных и внешних ключей. Структуры таблиц и установленные связи между ними документируются.

2. проверка логической модели данных на предмет выполнения всех транзакций, предусмотренных пользователями. Транзакция – набор действий, выполняемых отдельным пользователем или прикладной программой с целью изменения содержимого БД.

3. определение требований поддержки целостности данных и их документирование – эти требования представляют собой ограничения, которые вводятся с целью предотвратить помещение в БД противоречивых данных.

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