Инфологичекое проектирование

Инфологический подход к проектированию
ПО
Инфор. потребн.
польз-ля
Изучение и
описание ПО
Изучение и описание
инфор. потребностей
Проектирование внешней и концептуальной
инфологической моделей ПО
Инфологическое
проектирование
Инфологический подход к проектированию БД.
Проектирование БД начинается со структуризации предметной области (ПО), объекты
реального мира подвергаются классификации, фиксируется совокупность подлежащих
отображению в БД типов объектов, для каждого типа объекта фиксируется совокупность
свойств, которые будут описывать эти объекты, фиксируются связи между объектами.
Логическое
Проектирование внешней и концептуальной
проектирование
даталогической модели ПО
Физическое
Проектирование внутренней даталогической
проектирование
модели
Датологическое
проектирование
Выбор СУБД
В основе инфологического подхода лежит идея установления соответствий между
состоянием предметной области, его восприятием и представлением в БД.
Задача логического проектирования – организация данных, полученных на
предыдущем этапе, в форме принятой в выбранной СУБД. Задача физического
проектирования – выбор рациональной структуры хранения данных и доступ к ним. К
проектированию инфологической модели существует несколько подходов. Одним из таких
подходов является анализ сущности.
Основное назначение модели «сущность-связь» (МСС) – семантическое описание
предметной области и представления информации для обоснования выбора видов
модели и структур данных, которые в дальнейшем будут использоваться в системе.
Основные конструкционные элементы МСС:
1. Сущность – собирательное понятие, некоторая абстракция реально существующего
объекта, процесса или явления, о котором необходимо хранить информацию в системе.
Различают два понятия:
1) тип сущности – понятие относится к набору однородных предметов или вещей. Этот
набор выступает как единое целое. (Например, студент).
2) экземпляр сущности – понятие относится к конкретной вещи в наборе. (Например, ФИО
студента)
Разновидности объектов
Различают несколько разновидностей объектов. Прежде всего это простые и сложные
объекты. Объект называется простым, если он рассматривается в данном исследовании как
неделимый.
Сложный объект представляет собой объединение других объектов, простых или
сложных, также отображаемых в информационной системе. Понятия «простой» и «сложный»
объект являются относительными. В одном случае объект может считаться простым, а в
другом - этот же объект может рассматриваться как сложный. Так, например, объект
АУДИТОРИЯ, если АИС строится только для управления учебным процессом, будет
рассматриваться как простой. Если же АИС будет включать подсистемы для служб
энергетика, материально-технического снабжения и др., то АУДИТОРИЯ будет
рассматриваться как составной объект.
Выделяют несколько разновидностей сложных объектов: составные, обобщенные и
агрегированные объекты.
Составной объект соответствует отображению отношения «целое-часть». Примерами
составных объектов являются УЗЕЛ-ДЕТАЛИ, КЛАСС-УЧЕНИКИ и т.п.
Обобщенный объект отражает наличие связи «род-вид» между объектами предметной
области.
Например,
объекты
СТУДЕНТ,
ШКОЛЬНИК,
АСПИРАНТ,
УЧАЩИЙСЯ_ТЕХНИКУМА образуют обобщенный объект УЧАЩИЙСЯ. Объекты,
составляющие обобщенный объект, называются его категориями.
Как родовой объект, так и видовые объекты могут обладать определенным набором
свойств. Причем наблюдается так называемое наследование свойств, т.е. видовой объект
обладает всеми теми свойствами, которыми обладает родовой объект, плюс свойствами,
присущими только объектам этого вида.
Определение родовидовых связей означает классификацию объектов предметной
области по тем или иным признакам. Естественно, что классификация может быть
многоуровневой.
Агрегированные объекты соответствуют обычно какому-либо процессу, в который
оказываются вовлеченными другие объекты. Например, агрегированный объект ПОСТАВКА
объединяет в себе объекты ПОСТАВЩИК, ПОТРЕБИТЕЛЬ, а также саму поставляемую
ПРОДУКЦИЮ. Своеобразным объектом является ДАТА_ПОСТАВКИ. Агрегированный
объект может, так же как и простой объект, иметь характеризующие его свойства. В
рассматриваемом примере таким свойством может быть «Размер_поставки».
Агрегированные объекты обычно выражаются отглагольными существительными.
2. Атрибут – определяет свойство сущности с другой стороны это характеристика
сущности, которая имеет имя.
Среди всех атрибутов выделяется один (в некоторых случаях несколько), который однозначно
определяет сущность. Такой атрибут называется идентифицирующим.
Как указывалось выше, класс объектов представляет собой совокупность объектов,
обладающих одинаковым набором свойств. При описании предметной области нужно
изобразить набор свойств, фиксируемых для объектов каждого из представленных в модели
классов. Для обозначения свойств будем использовать прямоугольник, изображенный
пунктирной линией.
Связь между объектом и характеризующим его свойством изображается в виде линии,
соединяющей их обозначения. Характер связи между объектом и его свойством может быть
различный. Объект может обладать только одним значением какого-то свойства в каждый
момент времени. Например, каждый человек может иметь только одну «Дату_рождения» или
«Стаж_работы». Назовем такие свойства единичными. Для других свойств возможно
существование одновременно нескольких значений у одного и того же объекта (например,
свойство «Иностранный_язык» у объекта СОТРУДНИК, если СОТРУДНИК может владеть
несколькими иностранными языками). Такое свойство будем называть множественным. При
изображении связи между объектом и его свойствами для единичных свойств будем
использовать одинарную стрелку, а для множественных свойств - двойную стрелку на конце
линии, соединяющей объект с данным свойством (рис. 2.7, 2.8).
Значения некоторых свойств не может измениться с течением времени. Назовем такие
свойства статическими, а те свойства, значения которых могут изменяться со временем,
будем называть динамическими. Для обозначения динамических свойств будем использовать
букву «Д», а статических - «С» над соответствующей линией. Так, упомянутое выше
свойство «Дата_рождения» будет являться статическим, а «Стаж» - динамическим.
Другой характеристикой связи между объектом и его свойством является признак того,
присутствует ли это свойство у всех объектов данного класса либо оно может отсутствовать у
некоторых объектов. Например, для отдельных служащих может иметь место свойство
«Ученая_степень», а другие объекты этого класса могут не обладать указанным свойством.
Назовем свойства, присутствующие не у всех объектов данного класса, условными. При
изображении связи условного свойства с объектом будем использовать пунктирную линию, а
если свойство определено для всех экземпляров объектов данного класса - сплошную.
Иногда в ER-модели бывает полезно ввести понятие составного свойства. Примером
такого свойства могут быть «Адрес», состоящий из «Города», «Улицы», «Дома» и
«Квартиры». Будем использовать для обозначения составного свойства пунктирный квадрат,
из которого исходят линии, соединяющие его с обозначениями составляющих его элементов
(см. рис. 2.7, 2.11).
При проектировании БД определяются тип и длина полей. Для того чтобы иметь
возможность правильно выбрать эти характеристики, необходимо иметь соответствующую
информацию о типе представления атрибута в «немашинной» системе и требования/пожелания пользователей об их отображении в автоматизированной системе, может быть, даже с
предпочтениями. Например, предположим, что желательно было бы хранить в БД
изображение. Если целевая СУБД не позволяет это сделать, то возможны следующие
варианты:
поле, соответствующее данному атрибуту, не вводить;
связать БД с системой, которая может хранить рисунок;
заменить рисунок описанием.
Например, в «Листке по учету кадров» хранится фотография. Если есть возможность ее
сканирования и связи соответствующего файла с записями БД, то сделать это, если нет - то
все, что соответствует фотографии, не хранить в ИС.
Для всех реквизитов символьного типа должна быть указана их максимальная длина (а
лучше - не только максимальная, но и минимальная, и средневзвешенная).
Чтобы не загромождать ER-модель, подобные характеристики (табл. 2.1) рекомендуется
отображать в репозитории (в каталоге реквизитов).
Понятия «объект» и «свойство» являются относительными. Что в каждой из моделей
ПО следует считать самостоятельным объектом, а что - свойством другого объекта, будет
зависеть от аспекта рассмотрения данной предметной области. Например, пусть строится
АИС для управления конкретным учебным заведением. Для СОТРУДНИКОВ и УЧАЩИХСЯ
указывается, какое учебное заведение они закончили. Больше никакой информации об
учебных заведениях не хранится; никакой специальной обработки по этому признаку не проводится. В этом случае не стоит выделять отдельный объект «УЧЕБНОЕ_ЗАВЕДЕНИЕ», а
следует считать его свойством соответствующего объекта. Если же в предметной области
отражается дополнительная информация об учебных заведениях, например их адрес, тип и
т.п., то УЧЕБНОЕ_ЗАВЕДЕНИЕ следует рассматривать как самостоятельный объект.
Таблица 2.1
Пример*
Наименование
характеристики
Назначение
Что отражает?
Возможные значения
Что определяет?
ФИО
Пол Вес
Дата рождения
Фотография
Изменяемость
значения свойства
Может ли меняться в
течение жизненного
цикла объекта?
Может ли отсутствовать данное свойство
у объекта?
Возможность разбиения на составляющие элементы
Возможность наличия
нескольких значений
для данного свойства у
одного объекта
Идентификатор
(обозначает, называет
объект) Качественная характеристика
Количественная
характеристика
Дата/время совершения
события Изображение
Динамическое
Статическое
Обязательное
Необязательное
Дата рождения
Ученая степень
Простое Составное
Пол
Адрес
Единичное
Множественное
Дата рождения
Номера
телефонов
Форма отображения в
знаковой системе
Символьная Числовая
Дата Время
Изображение
Логическое
Способ получения
Датчики/счетчики Из
внешней среды
Производная информация
Адрес Вес
Дата рождения
Время прихода
на работу
Фотография сотрудника
Военнообязанны
й (да/нет)
Кардиограмма
Рекомендации с
прежней работы
Стаж работы
Обязательность
Элементарность
Множественность
Образование
Дата рождения
* Примеры приведены для класса объектов ЛИЧНОСТЬ.
3. Связи – выступают в качестве средств, с помощью которых представляются отношения
между сущностями.
Связи могут быть: 1) бинарные (между 2 сущностями); 2) тернарные (между 3-я); 3) nнарные (между n).
Бинарные связи можно классифицировать следующим образом:
1. связь 1:1. Один экземпляр одной сущности однозначно идентифицирует экземпляр другой
сущности;
2. связь 1:М. Одному экземпляру сущности типа А может соответствовать 0,1…n
экземпляров типа В. Однако одному экземпляру сущности типа В соответствует только один
экземпляр сущности типа А.
3. связь М:1. Обратная предыдущей связи. 1:М и М:1 зависит от подчиненности таблиц.
4. связь М:М. Каждому экземпляру сущности типа А может соответствовать 0,1…n
экземпляра сущности типа В и наоборот. (например, преподаватель <<->> читаемые
дисциплины).
Связи между сущностями устанавливаются при помощи отношений, в которых сущности
представлены своими идентифицирующими атрибутами. В ряде решаемых задач
принципиальное значение имеет не только сам факт отношения, но и свойства отношения.
МСС можно оформлять с помощью графических диаграмм. В этом случае могут
использоваться следующие обозначения
1. сущ ность
2. атриб ут
Кл ю чевой
атриб ут
3. свя зи
С теп ени свя зей:
- м ногие
- од инарны е
атриб ут
Для построения таких моделей успешно используются различные CASE- средства.
Например, ERWin 4.0. Vantage Team Builder, Silverrun и т.п. Они часто позволяют получить
не только модель «сущность-связь» но и её реляционную реализацию (физическую модель
данных) с последующим автоматическим созданием таблиц и связей в выбранной СУБД.
Пример диаграммы
Моделирование предметной области
Анализ сущности состоит из 2-х этапов:
1 этап Моделирование локальных представлений. Процесс состоит из следующих шагов:
1. Шаг 1. Идентификация локальных представлений. В любой предметной области
существуют слабо зависящие друг от друга группы данных (относящиеся к разным
функциональным областям), которые, как правило, выделяют в отдельные локальные
представления. Внутри каждого представления необходимо рассмотреть решаемые
задачи для формулировки сущностей и их описаний.
2. Шаг 2. Формулировка сущности. Для каждого локального представления необходимо
сформулировать сущности важные для его описания. Это связано с тем, что любая
порция информации может быть представлена любым набором конструктивных
элементов. В любом случае, независимо от сложности желательно рассматривать
несколько вариантов моделей и выбрать наиболее гибкий вариант. Для выбранной
сущности необходимо определить четкое наименование, опережающее смысл
вводимого понятия.
3. Шаг 3. Выбор идентифицирующего атрибута для каждой сущности – для
однозначного определения каждого экземпляра сущности. Идентификатор может
состоять из одного или нескольких атрибутов. По возможности в качестве ключевых
атрибутов должны выбираться атрибуты минимальные с точки зрения объема памяти.
4. Шаг 4. Назначение сущностям описательных атрибутов. При этом функциональная
зависимость описательных атрибутов от идентифицирующих является обязательным.
Как правило, один и тот же описательный атрибут не может принадлежать 2-м
сущностям сразу.
5. Шаг 5. Спецификация связей. На этом шаге осуществляется попарное объединение
всех сущностей, которые содержатся в данной локальной модели. Для установления
связей исследуются: 1) можно ли задать содержательный запрос, включающий обе
сущности; 2) могут ли быть обе сущности использованы в одной транзакции. Кроме
связей типа «сущность – сущность» выполняется спецификация связей типа
«сущность – атрибут» и «атрибут – атрибут».
2 этап Объединение моделей локальных представлений.
После того, как каждое локальное представление описано с помощью модели «сущностьсвязь», необходимо выполнить процесс объединения этих локальных представлений в
глобальную информационную структуру.
Существует три основополагающих концепции объединения локального представления:
1. Идентичность – 2 и более эл-ов модели считаются идентичными, если имеют одинак
семантическое или смысловое знач-е. При объед. локальных представлений нужно
проанализ. эти представления на наличие одинаковых понятий с т.з. смысла и написания.
Для такого анализа необходимо предварительное изучение ПО с целью выявления
возможных представлений (совпадений). Выявленные объекты рассматриваются на
возможность их содержания в модели только один раз. Если этот реально, то продумывается
единое название и определяется оптимальное количество атрибутов для описания данного
объекта.
2. Агрегация – позволяет рассматривать связь между элементами модели как новый элемент.
Три формы агрегации: При 1-й форме в 1-м представлении объект рассматривается как
единое целое, а во 2-м представлении рассматриваются составные части.
А:
П
редст.1
П
редст.2
(агрегация)
A1 …
…AN
G
A
Единое
целое
G
A
С
оставны
е
части
A1 …
…AN
G–глобальноепредставление
2-я форма: в этом случае агрегатный объект не определен как единое целое ни в одном
представлении, но в обоих представлениях рассматриваются его составные части.
В
:
П
р
е
д
с
т
.1
П
р
е
д
с
т
.2
A
A
В
1…
N В
1…
N

(а
г
р
е
г
а
ц
и
я
)
G
A
G
G
G
A
1…
A
NG
B
1…
B
N
3-я форма: один и тот же агрегатный объект рассматривается в обоих представлениях, но
составляющие этих агрегатных объектов различаются.
В
:
П
р
е
д
с
т
.
1
A
1
В
1
В
3
П
р
е
д
с
т
.
2
A
1
В
5
В
2
В
4

(
а
г
р
е
г
а
ц
и
я
)
G
A
G
G
B
1…
B
5
3. Обобщение. Позволяет трактовать классы различных подобных типов объектов, как один
поименованный обобщенный тип объекта. Отличительным признаком этой концепции
является то, что обобщение связано только с целым и не какие части она не рассматривает (в
этом состоит отличие от агрегации). Это понятие позволяет воспринимать группу подобных
элементов, как родовой элемент, а отличие каждого конкретного элемента от родового
образует дополнительные свойства. Одним из способов представления результатов
обобщения является введение в модель объекта, который определяет родовой элемент.
Вывод по объединению локальных представлений: процесс объединения носит
интерактивный характер. Причина этого состоит в том, что в процессе объединения
выявляются отдельные противоречия между локальными представлениями.
В реальных системах наиболее важным является вопрос: в каком порядке осуществлять
объединение с наибольшей эффективностью и минимальной потерей информации.
Существует 2 основных способа объединения:
1. бинарная асимметрическая структура объединения.
П1
П2
П3
П4
П 12
П 123
П 1234
П1
П2
2. бинарная симметрическая структура объединения.
П3
П 12
П4
П 34
П 1234
Наиболее эффективная структура объединения – бинарная структура с предварительным
упорядочением вершин дерева с целью максимизации совпадения объединяемых
представлений. Такое совпадение представлений на начальном этапе позволяет уменьшить
количество элементов, участвующих в объединении на следующих уровнях, т.е. имеет смысл
начинать объединение с тех подразделений (функциональных), которые имеют наиболее
тесное взаимодействие. После окончания процесса объединения результаты проектирования,
а именно концептуальная инфологическая модель и скорректированные локальные
представления (являющиеся внешними инфологическими моделями) поступают на этап
даталогического проектирования.
Логическое проектирование баз данных
Задача логического проектирования включает в себя разработку концептуальной и внешней
модели, ориентированной на конкретную СУБД. Эти модели должны удовлетворять
диапазону требований пользователя, начиная от целостности данных и заканчивая
показателями эффективности.
Процесс логического проектирования включает в себя решение следующих подзадач
(вопросов):
1. выявление среди исходных данных схем, независимых от СУБД;
2. сделать количественную оценку эксплуатационных характеристик, в которую входят: 1)
спецификация требований целостности, безопасности, восстанавливаемости, ограничений на
время отклика; 2) прогноз роста БД и т.д.;
3. сделать количественная оценка объема и частоты выполнения приложения, т.е.
определяется размер БД в количествах экземпляров данных и частота обращения
приложений к этим данным;
4. необходимо задать спецификации программ, разрабатываемых для создания интерфейса
пользователя, обработки его запросов, формирования выходных документов и т.д.;
5. необходимо задать характеристики выбранной СУБД, т.е. правила для определения
логических схем и те требования, которые накладывает СУБД на написание программ (тип
данных, использовать только систему запросов, запрет использования индексирования и т.д.);
6. определить конфигурацию вычислительных средств, на которых будет решаться задача.
Процесс логического проектирования состоит из ряда шагов, позволяющих оценить
эффективность каждого уровня создаваемой модели (от создания инфологической модели до
разработки алгоритмов решения задач).
Инфологическая модель
Пересмотр локальных структур
инфол. модели и их объединение
Формировка варианта СУБД
ориентированной схемы
Проектирование подсхем
Проектирование алгоритмов
для прикладных программ
Оценка характеристик системы
Процесс
завершен
да
Выход на уровень
физического
проектирования
нет
да
Нужна ли
коррекция
схемы
нет
Процесс логического проектирования завершается только в том случае, когда
характеристики системы удовлетворяют требованиям разработчика.
Эффективность логической структуры БД.
Эффективность логических структур БД может быть оценена следующими параметрами:
1. Количество обращений к логическим записям.
N
a) Ai Aij
j1
M
б) AAi Fi
i1
где Aij – количество обращений к логическим записям типа j в i-м приложении; N –
количество типов записей; Fi – частота выполнения i-го приложения; М – количество
приложений, обращающихся к БД.
Этот критерий должен стремиться к минимуму, но это может привести к появлению больших
по размеру записей, это увеличит объем передачи данных  может уменьшить скорость.
2. Объем передачи данных.
N
M
j
1
i1
A
Ti Fi
ijR
j б) T 
а) Ti 
где Rj – объем j-ой записи в байтах; Тi – объем передачи данных для i-го приложения.
Необходимо находить оптимальные варианты первых 2-х характеристик, их оценивают
вместе.
3. Объем занимаемой памяти.
N
D
Rj Kj
j
1
где Kj – количество экземпляров записи j-го типа в БД.м
При эфф. Физ.устройства к БД, т.е. при правильном выборе носителя рациональной системе
хранения и адресации все операции по манипулированию и обновлению производятся в
максимально короткое время. Рассмотрим схему физ. Доступа к данным. Для этого введем
след. понятия:
1. Стратегический селектор-это ПО, преобразующее требование пользователя в
эффективную для исполнения форму.
2. Буфф.диспетчер – это ПО, контролирующее перемещение данных м/у ОП и диском
3. Диспетчер файлов- это ПО, обеспечивающее управление размещением данных на диске
и структ. данных (управление структурой)
4. Словарь данных- содержится информация о ресурсах
Общая схема взаимодействия м.б.описана след. образом: стратегический селектор
преобразует(транслирует) пользовательскую команду в наиб. удобную форму для
выполнения преобразования требования активизирует буферный диспетчер, который
контролирует обмен данными м/у памятью и диском. Буферный диспетчер поддерживает
диспетчер файлов, который управляет размещением данных на диске, а также системой этих
данных. Пользовательские данные хранятся в виде совокупности записей или физ.БД. СУБД
занимается отбором из файла нужной инфо.
Физический уровень - требования и спецификации, формулируемые в терминах модулей,
таблиц, контейнеров, триггеров, COM-объектов и т.п.
Описание компонентов, сервисов и технологий в составе решения с точки зрения
разработчиков. Цель этого этапа - анализ логического проекта с учетом ограничений,
накладываемых существующими технологиями, включая соображения сложности
реализации и производительности продукта.
Результат
физического
проектирования
- совокупность компонентов, проект
пользовательского интерфейса для выбранной платформы и физический проект базы
данных.
Физический проект базы данных представляет собой спецификацию, по которой можно будет
производить развертывание этой базы. На данной стадии разработки уже необходимо знать,
какая платформа будет использована, – , SQL Server 7.0 под управлением Windows NT Server
4.0, или Microsoft Access на персональном компьютере, Oracle и др. Чтобы создать
физическую модель, надо собрать вместе все спецификации и модели, а затем приступить к
их модификации и оптимизации с учетом особенностей выбранной платформы. Например,
необходимо провести ревизию всех свойств, определенных для столбцов, включая типы
данных столбцов, проверяя их соответствие имеющимся в избранной среде типам данных.
Можно ввести дополнительные столбцы, не предусмотренные в концептуальной и
логической моделях. К таким вспомогательным столбцам относятся все те столбцы, которые
ускоряют и облегчают обработку данных, к примеру, столбцы, содержащие разнообразные
флаги и метки времени (timestamp). Помимо этого необходимо определить размер базы
данных, проанализировать объем информации, разработать планы распределения и
реплицирования баз данных, выбрать столбцы для создания индексов. Подготовить на этом
этапе для будущих пользователей перечня ролей (групп), идентификаторов и полномочия
пользователей для системы безопасности, требования к целостности данных (планы
архивирования), а также планы резервного копирования и восстановления при отказах и
сбоях.
Когда физическая модель готова, разрабатывается модель для анализа объемов данных, на ее
основе проводятся расчеты требуемого для размещения базы данных размера памяти.
Оценки размера базы данных основываются на подсчете среднего значения ожидаемого
числа событий, информацию о которых предполагается хранить
в базе данных.
Чтобы оценить, какой объем дискового пространства потребуется для хранения такого
количества записей, следует умножить предполагаемое число записей в таблице на длину
одной записи, выраженную в байтах. Длина строки находится суммированием размеров
полей, взятых из физической модели.