Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Ответы Bd_Ekzamen.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
1.44 Mб
Скачать
          1. Приведите общую схему инфологического проектирования. Дайте понятие по- и пп-информации и поясните смысл их использовании для процесса проектирования.

Этап инфологического проектирования. Задачей этапа является формирование и анализ требования к базе данных. Этап включает 2 шага:1-ое сбор и анализ определёной информации о предметной области.2-ой анализ и синтаксис инфологической модели. Структура этого этапе можно представить следущей схемой. Общая схема построения инфологической модели предметной области с учетом целей конечных пользователей и информационных требований прилоложений изображена. В этой схеме предусмотрено построение инфологической модели путем объединения информационного описания предметной области (ПО-информация) и информационных требований прикладных программ (ПП-информация). Следовательно, в инфологической модели объединяются два представления:объективно существующей ПО,субъективных информационных требований прикладных программистов, выраженных в запросах к базе данных, запланированных в приложениях. ПО-информация отображает объекты (процессы, явления, предметы) реального мира как составные части ПО (элементы ПО), их существенные свойства, а также взаимосвязи между этими элементами. Эта ПО-информация не связана ни с конкретными приложениями, ни с конкретным способом обработки, а описывает естественные концептуальные связи всех данных в БД. ПП-информация описывает данные и связи, используемые в приложениях. В общем случае в методологии построения инфологических моделей ПО-информация должна использоваться для построения первоначальной инфологической модели данных, а ПП-информация – для совершенствования последней с целью повышения эффективности обработки данных.

(писать после схемы)

БGroup 565 ез включения ПО-информации созданная БД обеспечивает, в лучшем случае, лишь объединение нескольких пользователей, занятых формированием собственных файлов.

.

3 Приведите общую схему концептуального проектирования.

4.3 Привидите общую схему концептуального проектирования.

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

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

Общая структура процесса логического проектирования (включая этап инфологического проектирования) представлена схемой.

На основании этой схемы можно определить следующие основные этапы процесса концептуального проектирования.

Этап 1. Обзор предметной области

  • Определение целей создания информационной системы.

  • Определение специфических требований к БД, вытекающих из этих целей и/или сформулированных персоналом.

Этап 2.

  • Определение (идентификация) сущностей (объектов).

  • Определение атрибутов сущностей.

  • Идентификация ключевых атрибутов сущностей.

  • Определение связей между сущностями.

  • Формирование инфологической модели.

Формирование и анализ требований (инфологическое проектирование)

Выбор СУБД

Проектирование реализации

Group 726 .

Структура процесса концептуального проектирования

Этап 3. Проектирование реализации

  • Преобразование инфологической схемы в концептуальную.

  • Установка (формулировка) ограничений целостности.

  • Обеспечение средств защиты.

  • Разработка (проектирование) приложений.

4.4 Привидите общую схему процесса проектирования. Исторически поддерживаемые СУБД модели данных, описанные в литературе, традиционно разбивают на реляционные и навигационные (иерархические и сетевые). Следует заметить, что эта классификация весьма условна, поскольку каждая конкретная СУБД поддерживает собственную оригинальную модель данных. Однако, рассмотрение каждой из классических видов моделей данных в «чистом виде» представляется достаточно полезным. Доказано, что все классические модели данных эквивалентны в том смысле, что любая из трех видов концептуальных моделей может быть преобразована в концептуальную модель любого другого вида, адекватно представляющую предметную область.

Group 757