Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
СУПЕРОТВЕТЫ.docx
Скачиваний:
3
Добавлен:
01.04.2025
Размер:
4 Мб
Скачать
☆

32. Проектирование бд: жизненный цикл бд, схема, подходы к проектированию.

    1. Анализ и проектирование.

- формирование и анализ требования пользователя к будущей работе (сбор и анализ сведений о предметной области).

- концептуальное проектирование (построение СУБД независимой структуры, не зависит от конкретных программных средств, но отвечает машинной обработке)

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

Если физическая структура не удовлетворяет работника, то физическое проектирование:

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

Далее идет проектирование прикладных программ на языке выбранной СУБД.

РЕЗУЛЬТАТ: полностью готовая к загрузке БД или готовые к загрузке реляционные таблицы с заполненными строками.

    1. Реализация и функционирование.

- загрузка БД

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

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

Подходы к проектированию.

Даталогический – если известна СУБД.

Инфологический – если не известна СУБД для предметной области.

Объектный – ПО на этапе сбора и анализа описывается след образом:

1. описание объекта

2. описание свойств объекта (наименование св-ва, диапазон значений, коэф повторений, вероятность существования).

3. описание связей (имя связи, объекты, которые участвуют в связи, мощность, вероятность связи, кардинальность).

Документальный (на основе документа):

  1. описание процесса (наименование, частота, вероятность применения, приоритет, требуемые данные, объем данных).

  2. описание оператора (наименование, критерий поиска, количество поисковых образов, вероятность событий, вероятность использования поискового образа).

Схема проектирования баз данных.

Есть реальный мир, т.е. конкретная предметная область

1) Описание ПО – это информационное пространство. Если нет описания, то оно проводится. На основе инф. пространства проводим структуризацию ПО, а также исследование инф. потребностей (конкретные процедуры – сбор сведений о ПО и анализ этих сведений). Итог – Проект структуризации ПО на содержательном уровне.

1.1.Сбор сведений о пред обл. А) «От объекта к информации» - ИС нет или она не удовл. требованиям польз. Б) «От управляющей системы к информации». ИС существует

1.2 Анализ и описание предметной области на содержательном уровне.

Описание ПО на содержательном уровне. Составляется перечень реквизитов, включаемых в БД с указанием кода, наименования, типа (числовой, символьный, логический), количества символов для символьного реквизита, является ли реквизит исходным или производным.

- Семантический анализ: составление общего списка реквизитов по каждом документу.

- Прагматический анализ: из общего списка реквизитов исключаются повторяющиеся реквизиты.

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

2) Инфологическое концептуальное проектирование (проектируется СУБД с независимой структурой). Результат – модель «сущность-связь», композиционная модель.

3) Далее выбирается СУБД. Результат – конкретное наименование СУБД.

4) Даталогическое проектирование. Осуществляется переход от модели «сущность – связь» к реляционной структуре данных и осуществляется нормализация реляционной структуры. Результат – реляционные таблицы выбранной СУБД. Реляционная структура данных - совокупность отношений, т.е. таблиц, для которых выполнены требования: а) любой столбец таблицы представляет только 1 элемент данных; б) в таблице нет 2 одинаковых строк или 2 одинаковых столбцов; в) порядок расположения столбцов и строк в таблице не имеет значения; г) внутри таблицы запрещены связи тип одни ко многим (1: М), т.е. запрещены множественные поля.

5) Далее проводится физическое проектирование. Результат – физический проект.

Выбор схемы зависит от требований заказчика к БД, неоднократности и степени структуризации информационного пространства ПО.