4. Инфологическое
моделирование
Цель инфологического моделирования
– обеспечение наиболее естественных
для человека способов сбора и представления
той информации, которую предполагается
хранить в создаваемой базе данных. Для
построения инфологической модели, я воспользовалась
приложением Erwin Data Modeler r7.
Различают три уровня логической
модели отличающихся глубиной представления
информации о данных:
- Диаграмма
сущность-связь (Entity Relationship Diagram, ERD);
- Модель
данных, основанная на ключах (Key Based model,
KB);
- Полная
атрибутивная модель (Fully Attributed model, FA);
1. Диаграмма сущность-связь
представляет собой модель данных верхнего
уровня. Она включает сущности и взаимосвязи,
отражающие основные
бизнес-правила предметной области. Такая
диаграмма не слишком детализирована,
в нее включаются основные сущности и
связи между ними, которые удовлетворяют
основным требованиям, предъявляемым
к ИС. Диаграмма сущность-связь может включать
связи многие-ко-многим и не включать описание
ключей. Как правило, ERD используется для
презентаций и обсуждения структуры данных
с экспертами предметной области.
2. Модель данных, основанная
на ключах, - более подробное представление
данных. Она включает описание всех сущностей
и первичных ключей и предназначена для
представления структуры данных и ключей,
которые соответствуют предметной области.
3. Полная атрибутивная
модель – наиболее детальное представление
структуры данных: представляет данные
в третьей нормальной форме и включает
все сущности, атрибуты и связи.
Основные компоненты инфологической
модели – это сущности, атрибуты и связи.
Сущность (Entity) – реальный
либо воображаемый объект, имеющий существенное
значение для рассматриваемой предметной
области, информация о котором подлежит
хранению.
Каждая сущность должна обладать
уникальным идентификатором. Каждый экземпляр
сущности должен однозначно идентифицироваться
и отличаться от всех других экземпляров
данного типа (сущности). Каждая сущность
в модели данных должна обладать некоторыми
свойствами:
- Иметь уникальное
имя; причем к этому имени должна всегда
применяться одна и та же интерпретация
(определение сущности). И наоборот: одна
и та же интерпретация не может применяться
к различным именам, если только они не
являются псевдонимами.
- Обладать одним или
несколькими атрибутами, которые либо
принадлежат сущности, либо наследуются
ею через связь.
- Обладать одним или
несколькими атрибутами, которые однозначно
идентифицируют каждый экземпляр сущности.
Сущность может быть независимой
либо зависимой. Признаком зависимой сущности
служит наличие у нее наследуемых через
связь атрибутов.
Связь (Relationship) – поименованная ассоциация между
двумя сущностями, значимая для рассматриваемой
предметной области.
Одна из участвующих в связи
сущностей - независимая, называется родительской
сущностью, другая – зависимая, называется
дочерней или сущностью-потомком.
Как правило, каждый экземпляр
родительской сущности ассоциирован с
произвольным (в том числе нулевым) количеством
экземпляров дочерней сущности. Каждый
экземпляр сущности-потомка ассоциирован
в точности с одним экземпляром сущности-родителя.
Таким образом, экземпляр сущности-потомка
может существовать только при существовании
сущности родителя.
Связи дается имя, выражаемое
грамматическим оборотом глагола и помещаемое
возле линии связи. Имя каждой связи между
двумя данными сущностями должно быть
уникальным, но имена связей в модели не
обязаны быть уникальными.
Атрибут (Attribute) – любая характеристика
сущности, значимая для рассматриваемой
предметной области. Он предназначен для
квалификации, идентификации, классификации,
количественной характеристики или выражения
состояния сущности.
Атрибут представляет тип
характеристик (свойств), ассоциированных
с множеством реальных или абстрактных
объектов (людей, мест, событий, состояний,
идей, предметов и т.д.).
Экземпляр атрибута – это
определенная характеристика конкретного
экземпляра сущности. Экземпляр атрибута
определяется типом характеристики (например
– "Цвет") и ее значением (например
– "лиловый"), называемым значением
атрибута.
Инфологическая модель имеет
два уровня представления - логический
и физический.
Логический уровень – это абстрактный
взгляд на данные, на нем данные представляются
так, как выглядят в реальном мире, и могут
называться так, как они называются в реальном
мире. Объекты модели, представляемые
на логическом уровне, называются сущностями
и атрибутами. Логическая модель данных
может быть построена на основе другой
логической модели, например на основе
модели потоков данных. Логическая модель
данных является универсальной и никак
не связана с конкретной реализацией СУБД.
Физическая модель данных, напротив,
зависит от конкретной СУБД, фактически
являясь отображением системного каталога.
В физической модели содержится информация
обо всех объектах БД. Поскольку стандартов
на объекты БД не существует (например,
нет стандарта на типы данных), физическая
модель зависит от конкретной реализации
СУБД. Разделение модели данных на логические
и физические позволяет решить несколько
важных задач проектирования данных.
На логическом уровне можно
установить идентифицирующую связь один-ко-многим,
связь многие-ко-многим или неидентифицирующую
связь один-ко-многим. Тип сущности определяется
ее связью с другими сущностями. Идентифицирующая
связь устанавливается между независимой
(родительский конец связи) и зависимой
(дочерний конец связи) сущностями. Экземпляр
зависимой сущности определяется только
через отношение к родительской сущности.
При установлении идентифицирующей связи
атрибуты первичного ключа родительской
сущности автоматически переносятся программой
Database Designer в состав первичного ключа дочерней
сущности.
Операция дополнения дочерней
сущности атрибутами при создании связи
называется миграцией атрибутов. В дочерней
сущности такие атрибуты помечаются как
внешний ключ – (FK)
При установлении неидентифицирующей
связи дочерняя сущность остается независимой,
а атрибуты первичного ключа родительской
сущности мигрируют в состав неключевых
атрибутов родительской сущности. Неидентифицирующая
связь служит для связывания независимых
сущностей. [4]
Инфологическая модель находится
в Приложении 1.
База данных (БД) – информационная
модель, позволяющая в упорядоченном виде
хранить данные о группе объектов с одинаковым
набором свойств или поименованную совокупность
структурированных данных.
По модели представления данных
БД классифицируются:
- Картотеки;
- Иерархические;
- Сетевые;
- Реляционные;
- Многомерные;
- Объектно-ориентированные.
На уровне физической
модели электронная БД представляет собой
файл или их набор в формате TXT, CSV, Excel, DBF,
XML либо в специализированном формате
конкретной СУБД. Также в СУБД в понятие
физической модели включают специализированные
виртуальные понятия, существующие в её
рамках — таблица, табличное пространство,
сегмент, куб, кластер и т.д.
В настоящее время
наибольшее распространение получили
реляционные базы данных. Картотеками
пользовались до появления электронных
баз данных. Сетевые и иерархические базы
данных считаются устаревшими, объектно-ориентированные
пока никак не стандартизированы и не
получили широкого распространения. Некоторое
возрождение получили иерархические базы
данных в связи с появлением и распространением
XML.
Система управления базами
данных (СУБД) — специализированная программа
(чаще комплекс программ), предназначенная
для организации и ведения базы данных.
Для создания и управления информационной
системой СУБД необходима в той же степени,
как для разработки программы на алгоритмическом
языке необходим транслятор.
База данных для SpeechPad написана
на языке SQL. В качестве СУБД использована
MySQL.
Пример кода таблиц базы данных.
БД: `Speechpad`
-- --------------------------------------------------------
-- Структура таблицы `comusers`
--
CREATE TABLE IF NOT EXISTS `comusers` (
`user_id` varchar(40) NOT NULL DEFAULT '',
`upassword` varchar(20) NOT NULL DEFAULT '',
`email` varchar(40) NOT NULL DEFAULT '',
`uname` varchar(40) NOT NULL DEFAULT '',
`phone` varchar(20) NOT NULL DEFAULT '',
`regdate` date NOT NULL DEFAULT '0000-00-00',
`lastdate` date NOT NULL DEFAULT '0000-00-00',
`colvisit` smallint(5) NOT NULL DEFAULT '0',
`news` tinyint(1) NOT NULL DEFAULT '1',
`limited` tinyint(1) NOT NULL DEFAULT '1',
PRIMARY KEY (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
-- --------------------------------------------------------
-- Структура таблицы `texts`
--
CREATE TABLE IF NOT EXISTS `texts` (
`id_txt` int(11) NOT NULL AUTO_INCREMENT,
`txtname` varchar(40) NOT NULL,
`txtbody` text NOT NULL,
`user_id` varchar(40) NOT NULL,
PRIMARY KEY (`id_txt`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=35
;
-- --------------------------------------------------------
-- Структура таблицы `uielems`
--
CREATE TABLE IF NOT EXISTS `uielems` (
`ui_id` int(11) NOT NULL,
`uiname` varchar(120) NOT NULL,
`uidesc` varchar(255) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
-- --------------------------------------------------------
-- Структура таблицы `uisetting`
--
CREATE TABLE IF NOT EXISTS `uisetting` (
`uiset_id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` varchar(40) NOT NULL,
`ui_id` int(11) NOT NULL,
`vidid` tinyint(4) NOT NULL,
`uival` int(11) NOT NULL,
PRIMARY KEY (`uiset_id`),
UNIQUE KEY `user_id` (`user_id`,`ui_id`,`vidid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=10
-- --------------------------------------------------------
-- Структура таблицы `zamena`
--
CREATE TABLE IF NOT EXISTS `zamena` (
`id_zam` int(11) NOT NULL AUTO_INCREMENT,
`word_from` varchar(255) CHARACTER SET cp1251
NOT NULL,
`word_to` varchar(255) CHARACTER SET cp1251
NOT NULL,
`user_id` varchar(40) CHARACTER SET cp1251
NOT NULL,
PRIMARY KEY (`id_zam`)
- ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=4 ;
Разработка структурно-функциональной
схемы
SADT - методология структурного
анализа и проектирования, интегрирующая
процесс моделирования, управление
конфигурацией проекта, использование
дополнительных языковых средств.
Процесс моделирования может
быть разделен на несколько
этапов: опрос экспертов, создание
диаграмм и моделей, распространение
документации, оценка адекватности
моделей и принятие их для
дальнейшего использования. Методология
возникла в конце 60-х годов
в ходе революции, вызванной появления
структурного программирования. Когда
большинство специалистов билось
над созданием программного обеспечения,
немногие старались разрешить
более сложную задачу – задачу
создания крупномасштабных систем,
включающих как людей и машины,
так и программное обеспечение,
аналогичных системам, применяемым
в телефонной связи, промышленности,
управлении и контроле за вооружением.
В то время специалисты, традиционно занимавшиеся
созданием крупномасштабных систем, стали
осознавать необходимость большей упорядоченности.
Поэтому разработчики систем начали формализовать
процесс создания системы, разбивая его
на следующие фазы:
- Анализ — определение
того, что система будет делать
- Проектирование
— определение подсистем и их взаимодействие
- Реализация — разработка
подсистем по отдельности, объединение
— соединение подсистем в единое целое
- Тестирование —
проверка работы системы
- Установка — введение
системы в действие
- Эксплуатация —
использование системы
В процессе проведения
обследования построена структурно-функциональная
модель системы (набор диаграмм). Исходная
диаграмма (TOP) отображает взгляд на
систему в целом. На ней изображена работа
«Приемной комиссии» и данные, которые
она использует и создает. Работы изображаются
прямоугольниками. Прямоугольник с косой
чертой для работы выполнена декомпозиция.
Работу декомпозируют до тех пор, пока
она не станет элементарной. Прямоугольник
без черты – работа не декомпозируется,
то есть она является элементарной работой.
Ниже приведен пример:
Рис.1
а) декомпозированная работа; б) декомпозиция
у работы отсутствует
а) б)
Работы на диаграмме
декомпозиции располагаются по диагонали
от верхнего левого угла к нижнему правому.
Такое расположение показывает подчиненность
(порядок проведения) работ. В этом же порядке
они нумеруются. Нумерация производится
автоматически. К каждой работе проводят
стрелки. Они описывают взаимодействия
работ с внешним миром и между собой. Различают
следующие стрелки:
1. Вход (Input) –
материал или информация, которая преобразуется
работой для получения результата (выхода).
Стрелки входа подводятся к работе слева.
Работа может не иметь входов, если это
создание каких-либо новых понятий, создающихся
на основе умозаключений (Например, новая
теорема).
2. Управление (Control)
– инструкции, правила или стандарты,
которыми руководствоваться исполнители
работы. Стрелки управления входят в работу
сверху. Каждая работа должна иметь управление
– правила, которые обеспечили бы стабильность
ее выполнения.
3. Выход (Output)
– материал или информация, которые создаются
в процессе выполнения работы. Каждая
работа должна иметь выход. Стрелки выхода
выводят из работы справа.
4. Механизм
(Mechanism) – ресурсы, используемые работой
при ее выполнении: персонал, помещение,
орудия труда, энергетические ресурсы.
Стрелки механизмов подходят к работе
снизу. Механизмы опускают на диаграммах
декомпозиции, если их использование очевидно.
Но это должно быть указано в описании
родительской работы.[5]
Рис.2 Пример блока структурно
- функциональной модели
При разработке структурно-функциональной
модели использовалось инструментальное
CASE-средство "AllFusion Process Modeler r7". В ходе
анализа была построена функциональная
модель (см. Приложение 2 «Функциональная
модель» рис. 1).
Диаграмма декомпозиции первого
уровня в модели идет под номером 2 (Приложение
2 «Функциональная модель» рис. 2).
- Описание форм «Кабинета
пользователя»