DB_l07

Лекция 7
Назначение, подходы и этапы
проектирования БД.
Модели многоуровневой архитектуры
систем баз данных.
Средства автоматизации проектирования
Инфологические модели
Модели представления
хорошо структурированной
информации
Модели представления
слабо структурированной
информации
IDEF-модели
Дескрипторные
модели
Диаграммы потоков
данных
Семантические
сети. Тезаурусы
ER-модели
Фреймы
Даталогические модели
Модели представления
фактографической
информации
Модели представления
документальной
информации
Объектно
ориентированные
Инвертированная
организация
Теоретикографовые
Прямая
организация
Иерархические
Теоретикомножественные
Сетевые
Реляционные
Бинарных отношений
Схемноопределяемая
структура
Контекстноопределяемая
структура
Физические модели
Модели, основанные на
файловых структурах
Модели, имеющие
страничную организацию
Page 1
Данные
Page 2
БД
БД
…
Индексы
…
Page N
Стадии и объекты процесса проектирования
Системный анализ
Объекты и связи
Предметной области
Определение парадигмы информационной модели (структурированность и динамичность информации; способ предст-ия инф-ции)
парадигма информационной модели
Инфологическое проектирование
Прикладные
задачи
пользователей
Определение системы атрибутов; типовых запросов; типовых
процедур обработки.
Инфологическая модель
Выбор парадигмы модели данных
(иерархическая/ сетевая/
реляционная/ объектная и т.п.).
Выбор методики (средств)
моделирования.
Логика СУБД
(модель данных)
Даталогическое проектирование
Разработка концептуальной схемы БД; внешних схем; правил
семантической целостности.
Даталогическая модель
Физическое проектирование
ЯОД и ЯМД
конкретной СУБД
Отображение даталогической модели в модель данных
выбранной СУБД: проектирование структур данных и связей.
Физическая модель БД
«Не исключено, что у читателя создалось впечатление, будто мы уже владеем
современной методологией или, по крайней мере, близки к этому, что, к сожалению,
не так, и, может быть, мы никогда ничего подобного не добьемся. Всегда несложно
охарактеризовать методологию на концептуальном уровне, весьма трудно применить
ее на практике. Камень преткновения – сложность проникновения в существо
предметной области (например, сложности понимания механизма деятельности
организации) и адаптации ее к новым, возможно лучшим, условиям
функционирования.
Аналогичные проблемы характерны и для СУБД в целом. Система баз данных
должна стать органическим элементом системы управления организацией - вот залог
ее успешного применения. Однако процесс ее внедрения связан с определенными
изменениями в самой организации и в деятельности ее сотрудников, и мы всегда
будем сталкиваться с естественной инертностью людей, когда речь идет о восприятии
изменений....
Весьма важно, чтобы средства СУБД были адекватны потребностям
пользователей. Поскольку разным пользователям могут понадобиться разные модели
данных, языки данных и схемы, желательно, чтобы СУБД поддерживала множество
средств, а пользователь мог выбирать из них наиболее подходящие. ...
Можно, конечно, поставить под сомнение ценность таких исследований.
Действительно, каким бы плохим ни был язык программирования, его, в конце
концов, все-таки можно выучить. Точно также и средства СУБД можно освоить за
определенный период времени. Но проблема состоит не в освоении средств, а в
эффективности их использования!…»
Цикритзис Д., Лоховский Ф. «Модели данных», 1985 г.
Подходы к проектированию БД
Восходящий группировка
атрибутов в
отношения,
представляющие
типы сущностей и
связи между ними
Нисходящий –
приоритетность
разработки
концептуальной
модели ПрО
(выделение
сущностей и связей)
Ограниченность реляционной модели
• реляционная модель не предоставляет достаточных
средств для фиксации смысла данных, т.е. семантика
предметной области не фиксируется непосредственно в
отношениях;
• для многих приложений трудно моделировать предметную
область на основе плоских таблиц;
• хотя весь процесс проектирования происходит на основе
учета зависимостей, реляционная модель не имеет средств
представления (отражения семантики) этих зависимостей;
• несмотря на то, что процесс проектирования начинается с
выделения некоторых существенных для приложения
объектов предметной области ("сущностей") и выявления
связей между этими сущностями, реляционная модель
данных не предлагает какого-либо аппарата для
различения сущностей и связей.
Системный анализ предметной
области
Функциональный
подход
Объектный
(предметный) подход
Управление
Объект
Вход
Функция
Выход
Связ
ь
Объект
Механизм
исполнения
Группы CASE-средств
•
•
•
•
•
•
•
•
•
средства анализа, предназначенные для построения и анализа моделей предметной
области (Design/IDEF, BPwin);
средства анализа и проектирования, поддерживающие наиболее распространенные
методологии проектирования и использующиеся для создания проектных
спецификаций компонентов и интерфейсов системы, алгоритмов и структур данных
(Designer/2000 ORACLE, Silverrun, CASE.Аналитик).;
средства проектирования баз данных, обеспечивающие моделирование данных и
генерацию схем баз данных (как правило, на языке SQL) для наиболее
распространенных СУБД. К ним относятся ERwin, DataBase Designer. Средства
проектирования баз данных имеются также в составе CASE-средств, Designer/2000,
Silverrun;
средства разработки приложений. К ним относятся средства 4GL (Uniface,
PowerBuilder, Developer/2000, SQL Windows, Delphi и др.) и генераторы кодов,
входящие в состав Vantage Team Builder, PRO-IV;
средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз
данных и формирование на их основе различных моделей и проектных спецификаций.
Средства анализа схем БД и формирования ERD входят в состав PRO-IV, Silverrun,
Designer/2000, ERwin и S-Designer. В области анализа программных кодов наибольшее
распространение получают объектно-ориентированные CASE-средства,
обеспечивающие реинжиниринг программ на языке С++ (Rational Rose, Object Team);
средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
средства конфигурационного управления (PVCS);
средства тестирования (Quality Works);
средства документирования (SoDA).