Проектные решения по информационному обеспечению решаемой задачи
Раздел является обязательным при разработке программного продукта и решений по информационному обеспечению ИС.
Проектные решения по информационному обеспечению включают в себя: общее описание информационного обеспечения (состав, структура и принципы организации информационного обеспечения, обоснование выбора носителей данных и принципы распределения информации по типам данных, перечни источников, носителей информации, оценка интенсивности и объема информации, описание общих требований к организации сбора и передачи информации), описание организации информационной базы (инфологическая и даталогическая модели баз данных), описание технологического процесса обработки данных содержит описания структуры таблиц БД (наименования полей, типов данных, уровень валидации, пример данных) и иллюстрацию схемы данных, выполненную в среде СУБД.
Пример общего описания информационного обеспечения ИС учета персональных данных.
1 Состав информационного обеспечения
Информационное обеспечение ИС ООО «ООО» представляет собой комплекс нормативной, справочной документации, внутренней информации, который необходим для осуществления все деятельности ООО «ООО» и его филиалов. Оно представляет собой совокупность массивов информации в электронном и документированном виде.
В состав информационного обеспечения ИС ООО «ООО» входит:
1) внутримашинная база:
а) базы данных информационной системы;
б) индивидуальные данные: файлы данных, программы;
2) внемашинная база:
а) нормативно-справочная документация;
б) документационное обеспечение процессов ООО «ООО» по видам деятельности.
Обследование объекта проектирования показывает, что база данных информационной системы включает в себя следующую информацию:
· фамилия, имя, отчество;
· пол;
· дата рождения;
· место рождения;
· гражданство;
· военкомат;
· серия и номер паспорта или удостоверения личности, дата выдачи указанных документов, наименование выдавшего их органа;
· дата регистрации по месту жительства;
· ИНН;
· Свидетельство пенсионного страхования;
· Свидетельство медицинского страхования;
· Почтовый индекс;
· Регион, населенный пункт, улица, дом, корпус, строение, квартира;
· Семейное положение;
· Дети;
· Особое семейное положение;
· Образование (указать учебное заведение);
· Наличие профессии;
· Коренные народы;
· Убеждения/религия;
· Годность к военной службе и состояние здоровья;
· Категория годности;
· Показатель предназначения, номер, наименование;
· Статус;
· Период призыва.
Объем обрабатываемых в ИС данных менее чем 100 000 субъектов персональных данных…
2 Организация информационного обеспечения
Организация информационного обеспечения имеет структуру, приведенную на рисунке 17.
Рисунок 17 – Структура информационного обеспечения
Информационное обеспечение построено в виде централизовано управляемого массива данных. Управление осуществляется посредством отдельно устанавливаемой СУБД. В ИС применяется СУБД MySQL 5.0, которая управляет отдельным экземпляром базы данных.
База данных ИС является реляционной и состоят из метаданных и таблиц основной базы. Метаданные описывают структуру БД и обеспечивают ее работу.
Доступ к объектам базы банных из приложения производится из оконных форм. Соединение БД с приложением осуществляется посредством драйвера доступа OLE DB и компонентов, встраиваемых в приложение…
… В качестве основного носителя данных в ИС применяются встроенные серверные накопители на жестких магнитных дисках с интерфейсом SATA Revision 1.0 (до 1,5 Гбит/с).
Выбор данного носителя обоснован лучшим соотношением по следующим параметрам:
· высокая производительность;
· высокая надежность;
· приемлемая стоимость.
Для хранения основных данных и их резервных копий применяются отдельные носители. Для обеспечения защиты данных от сбоев отдельных дисковых накопителей используется технология избыточного хранения данных на нескольких носителях одновременно – RAID (Redundant Array of Inexpensive Disks). Необходимым и достаточным уровнем RAID является 5: распределение данных по блокам; контрольные суммы распределены по всем дискам массива. Требует использования в массиве не менее трех носителей, скорость чтения растет с увеличением количества носителей…
… Контроль данных в ИС осуществляется при обновлении метаданных и оперативных баз с помощью программного обеспечения информационной системы и СУБД.
Контроль данных представляет собой:
· проверку непротиворечивости – позволяет отследить файлы, которые были повреждены при формировании или пересылке;
· семантическую проверку – дает возможность сопоставить атрибуты сформированных оператором файлов обновлений атрибутам эталонного файла, для выявления ошибок формирования;
· проверку целостности – представляет собой поиск потерянных данных в соответствии со схемой базы данных.
При обнаружении нарушений непротиворечивости, семантики и целостности данных выполняется их восстановление. Восстановление данных осуществляется путем применения «откатов» по записям журналов транзакций…
… Система взаимодействует с информационными ресурсами филиалов.
Взаимодействие между ИС и информационными базами филиалов осуществляется путем соединения с соответствующими БД выполнением репликации данных…
… Информационное взаимодействие ИС ООО «ООО» осуществляется путем файлового обмена по защищенным каналам коммуникаций VPN…
ИС разрабатывается с учетом возможности осуществления идентификации и аутентификации пользователей с использованием системы идентификации и аутентификации СУБД и программного приложения.
Совместимость и взаимодействие ИС ООО «ООО» с другими системами реализуется на основе общего формата данных – MySQL.
3 Организация сбора и передачи информации
Источниками информации в ИС являются:
· заказчики – физические и юридические лица производящие заказ продукции ООО «ООО»;
· поставщики – предлагающие комплектующие и материалы, необходимые для производства продукции ООО «ООО»;
· учреждения статистического учета – запросы сведений о видах и объемах производства и реализации продукции;
· автоматизированные системы налогового учета – данные о бухгалтерско-финансовой деятельности ООО «ООО»…
… Основным носителем информации являются диски типа «HDD» с интерфейсами IDE и SATA. На дисковых накопителях хранятся файлы базы данных, текстовые файлы отчетов, электронные документы пользователей, файлы системных журналов и протоколов, почтовые сообщения, личные файлы пользователей.
В отдельных случаях предусматривается использование Flesh-накопителей.
Сбор информации и ее ввод в БД происходит в автоматизированном режиме в процессе эксплуатации системы путем формирования пользователями (операторами) наборов информации в экранных формах и их сохранения в базе данных ИС.
Передача информации из клиентского приложения в БД осуществляется посредством программных интерфейсов, предоставляемых приложением или программой «Проводник» операционный системы.
Подсистемы, входящие в состав ИС также обеспечивают загрузку данных посредством Web-интерфейсов.
Корректировка данных, загруженных в ИС, осуществляется ответственными лицами, участвующими в сборе отчетности, с помощью прикладного программного обеспечения системы.
5 Организация внутримашинной информационной базы
Внутримашинные информационные базы построены по принципу реляционных баз данных. Для обеспечения гибкости, в том числе, системы и возможности связи с другими ИС, данные хранятся в третьей нормальной форме.
Каждый объект системы представлен отдельной сущностью в базе данных и имеет уникальный идентификатор.
Права пользователей системы определяются на уровне подсистемы каталога пользователей.
Объем информации в информационной базе для каждого пользователя, определяется объемом инициализируемых данных системы и возрастает в прогрессивном порядке с течением времени эксплуатации...
Отдельные данные хранятся в файлах пользователей, размещаемых в «Общих папках» на сетевом диске. Общие файлы пользователей хранятся на специально выделенном сервере файлов. Обозначение сетевого пути доступа к таким файлам имеет вид:
\\Srv-file:\Общие папки\[имя папки пользователя].
Общая структура внутримашинной информационной базы приведена на рисунке 18.
Рисунок 18 – Структура внутримашинной информационной базы
Элементы информационной базы ООО «ООО» размещаются (рис. 19):
1) на сервере системы хранения данных;
2) на сервере базы данных ИС.
Рисунок 19 – Элементы размещения информационной базы…
Автоматизированная система разрабатывается, как правило, на основе баз данных (БД). БД является отражением информационной модели предметной области и представляет собой совокупность связанных данных, организованных по определенным правилам.
Проекты БД могут быть ориентированы на объектные, реляционные модели данных, хранилища данных (многомерная модель данных), модель «NonSQL».
При проектировании реляционных баз данных могут быть использован метод нисходящей или восходящей разработки выбор метода производится студентом самостоятельно.
Проектирование БД начинается с разработки спецификаций внешнего уровня. Внешний уровень – обобщенное представление базы данных всеми пользователями АС. При разработке БД на внешнем уровне необходимо изучить функционирование объекта управления, для которого разрабатывается база данных, входные и выходные документы (фрагменты документов), подлежащие обработке средствами разрабатываемой АС. Внешний уровень архитектуры БД, как правило, представляется описанием иерархии функций АС, уровней доступа пользователей, классов объектов предметной области и связей между ними.
Примериерархии функций автоматизированной системы учета продаж
… Иерархия функций автоматизированной системы разрабатывается на основе функциональной модели предметной области, диаграммы вариантов использования и функциональной схемы работы системы. На рисунке 20 представлен пример фрагмента иерархии функций, реализуемых в системе.
Рисунок 20 –Иерархия функций автоматизированной системы (фрагмент)
Формализованное описание предметной области представляется в виде классов объектов (КО) и отношений между ними. Класс объектов – совокупность объектов с одинаковым набором свойств. Для каждого класса объектов определяются свойства, характеристики значений свойств:
· физические – тип, длина;
· логические ограничения – диапазон, список, значения по умолчанию;
· опциональность – признак того, что значение может быть или должно быть определено;
· процессы – генерация, ввод, обновление, просмотр значения.
Связи между классами объектов обычно двусторонние и характеризуются следующими признаками: имя связи; мощность, опциональность.
Пример формализованного описания КО представлен в таблице 1
Таблица 1 – Классы объектов и их свойства
| Класс объектов/ Свойство | Ключ | Физические характеристики | Опциональность | Логические ограничения | Процессы |
| РЕЖИМ РАБОТЫ | |||||
| код | УК1, ПК | Число, 8 | д.б. | >0 | Г, Пр |
| название | УК2 | Строка, 50 | д.б. | Первая буква заглавная | Вв, О, Пр |
| краткое название | Строка, 12 | м.б. | Вв, О, Пр | ||
| ТАБЛИЦА ЛАПЛАСА | |||||
| код | УК,ПК | Число, 8 | д.б. | >0 | Вв, Пр |
| значение Х | Число, 16 | д.б. | Вв, Пр | ||
| значение функции | Число, 16 | д.б. | Вв, Пр | ||
| РЕЗУЛЬТАТ АНАЛИЗА | |||||
| код | УК,ПК | Число, 8 | д.б. | >0 | Вв, Пр |
| дата | Дата | д.б. | Вв, Пр | ||
| значение 1 | Число, 8 | д.б. | =2n , n≥3 | Вв, Пр | |
| значение 2 | Число, 8 | д.б. | >0 | Вв, Пр |
В таблице использованы сокращения: УК – уникальный ключ, ПК – первичный ключ (главный уникальный), Г – генерация данных, Вв – ввод данных, Пр – просмотр данных, О – обновление, м.б. – необязательное значение свойства, д.б. – обязательное значение свойства.
Для адекватного представления предметной области необходимо определить связи между классами объектов. Пример описания связей (отношений) между классами объектов предметной области приведен в таблице 2.
Таблица 2 – Связи между классами объектов
| Имя КО | Опциональноcть связи | Имя связи | Тип связи | ||||
| главн.КО | подч.КО | главн.КО | подч.КО | главн.КО | подч.КО | главн. КО | подч. КО |
| ТИП УЛИЦЫ | УЛИЦА | м.б. | д.б. | соответст. | относится | 1 | М |
| УЛИЦА | АДРЕС | м.б. | д.б. | указана в | относится | 1 | 1 |
| ТИП УСЛУГИ | УСЛУГА | м.б. | д.б | указан в | относится | 1 | M |
| Единица измерния | услуга | м.б. | д.б. | использу- ется для | измеря- ется в | 1 | М |
| ЮР. ЛИЦО | АДРЕС | м.б. | д.б. | имеет | зафикси-рован для | 1 | М |
В таблице использованы сокращения: КО – класс объектов, главн. - главный, подч. – подчиненный, 1 – тип (мощность) связи «один», М – тип связи «много», «д.б.» – связь обязательная, «м.б.» – связь необязательная.
В результате анализа предметной области выявляются роли пользователей АС. В таблице 3. представлен фрагмент формализованного описания прав доступа пользователей АС «Центр продаж».
Таблица 3 – Уровни доступа пользователей
| Классы объектов/ свойства | Роли пользователей | |||
| Технический персонал | Конечные пользователи | |||
| АБД | Прикладной программист | Конечный пользователь – менеджер | Конечный пользователь – исполнительный директор | |
| ДОГОВОР ПРОДАЖИ | ||||
| номер | RIUD | RIU | RI | |
| дата начала | RIUD | RIU | RI | R |
| дата окончания | RIUD | RIU | R | R |
| ПОЗИЦИЯ ДОГОВОРА | ||||
| номер | RIUD | RIU | RI | |
| сумма | RIUD | RIU | RI | R |
В таблице использованы сокращения операций, производимых со значениями свойств классов объектов: R – read (чтение); I – insert (добавление); U – update (обновление); D – delete (удаление).
Максимальный уровень доступа имеет АБД. Конечные пользователи не могут видеть (читать) сгенерированные данные, удалять сведения из базы данных.
Концептуальный уровень проекта базы данных может быть представлен инфологической моделью предметной области.
Информационно-логическая модель (ИЛМ) предметной области является проблемно-ориентированной и системно-независимой, она не зависит СУБД, операционной системы и аппаратного обеспечения АС. Назначение ИЛМ предметной области – адекватное, единое, интегрированное и непротиворечивое отображение предметной области посредством информационных объектов, из которых она состоит, в рамках решаемой задачи автоматизации; отражение информационных потребностей пользователей разрабатываемой АС.
Графическое представление ИЛМ предметной области осуществляется в виде ER-модели. Основными элементами ER-модели в нотации Ричарда Баркера являются: класс объектов; свойство класса объектов; уникальный идентификатор; опциональность свойства, связь; опциональность и переносимость связи; уникальность объекта из связи; супертипы, подтипы, арки и др. На диаграмме используются следующие соглашения:
КО отображается в виде четырехугольника с закругленными углами. Имя КО указывается внутри четырехугольника, это имя существительное в единственном числе, отображенное заглавными буквами;
свойства КО записываются внутри четырехугольника, отображающего КО, строчными буквами: имя существительное в единственном числе;
четырехугольники, отображающие КО, могут иметь разные размеры;
опциональность свойства помечается: обязательное свойство – звездочкой (*), необязательное – кружочком (о);
уникальный идентификатор КО помечается #, если уникальных идентификаторов в КО выявлено несколько, тогда каждый помечается номером, указанным в скобках, например, #(1), #(2);
обязательная связь помечается сплошной линией, необязательная – пунктирной;
тип связи «один» помечается линией, «много» – «вороньей лапой».
Пример ИЛМ предметной области, отображенной в виде ER-диаграммы по методологии Ричарда Баркера, представлен на рисунке 21.
Рисунок 21 – ER-диаграмма предметной области
После построения ИЛМ предметной области необходима проверка полученной модели на соответствие выполнения заданных функций АС. Фрагмент результата перекрестной проверки приведен в таблице 4.
В таблице 4 использованы сокращения: I – операция добавления; U – операция обновления, R – операция чтения (выборки), Ф – конечная функция иерархии функций АС.
Таблица 4 – Перекрестная проверка иерархии функций АС и ИМЛ
| Классы объектов | |||||||
| Элементарные функции | Модель оборудования | Паспорт оборудования | Единица измерения | Характеристика | Параметр | Гпуппа оборудования | Тип оборудования |
| Ф1 | I, U | ||||||
| Ф2 | R | ||||||
| Ф3 | R | I, U | R | R | |||
| Ф4 | R | R | R | R | |||
| Ф5 | I, U | ||||||
| Ф6 | R | ||||||
| Ф7 | I, U | ||||||
| Ф8 | R | ||||||
| Ф9 | R | R | I, U | ||||
| Ф10 | R | R | R | ||||
| Ф11 | I, U | ||||||
| Ф12 | R | ||||||
| Ф13 | R | I, U | |||||
| Ф14 | R | R |
Такая перекрестная проверка иерархии функций и модели данных позволяет выявить избыточность или недостаточность построенной модели данных. Если в таблице присутствует пустой столбец, это означает, что модель избыточна, если же пустая строка, то модель недостаточная. Если в полученной таблице пустых строк и столбцов нет, построенная модель полностью отвечает функциональным требованиям разрабатываемой системы.
Следующим этапом проектирования БД является разработка даталогической модели базы данных.
Даталогическая модель (ДЛМ) базы данных является моделью логического уровня и представляет собой отображение логических связей между элементами данных безотносительно к их содержанию и среды хранения. Эта модель строится в терминах информационных единиц, допустимых в среде выбранной СУБД. Этап создания ДЛМ называется даталогическим проектированием. Описание логической структуры базы данных на языке заданной модели данных (например, реляционной) называется схемой базы данных.
При формировании логической структуры реляционной базы данных (РБД), осуществляется преобразование исходной инфологической модели предметной области в структуру, описываемую терминами реляционной модели данных. По определению схема РБД представляет собой совокупность связанных между собой схем реляционных отношений (РО). Получить логическую структуру РБД означает определить все схемы РО, задать их имена, задать имена атрибутов РО, определить первичные ключи каждого РО, внешние ключи, реализующие связи между схемами реляционных отношений.
Пример графического представления даталогической модели РБД приведен на рисунке 22.
Рисунок 22 – Даталогическая модель базы данных
Полученная схема логической структуры РБД должна соответствовать, как минимум, третьей нормальной форме (3НФ) для избегания избыточности данных, ведущей к аномалиям при добавлении, обновлении и удалении данных. Схема РБД находится в 3НФ, если все входящие в неё схемы отношений соответствуют 3НФ.
Завершающим этапом проектирования БД является разработка физической модели базы данных.
Физическая модель базы данных описывается на языке определения данных (ЯОД) выбранной СУБД.
Физическое проектирование базы данных заключается в преобразовании даталогической модели РБД данных в такую форму, которая позволит реализовать проект в среде выбранной СУБД. Техническое описание реляционной таблицы «Адрес» на ЯОД СУБД MS SQL 2008 R2 представлено в таблице 5.
Таблица 5 – Реляционная таблица «Address»
| Имя поля | Ключ | Тип и длина | Опциональность | Логическое ограничение | Примеры данных |
| id_adres | primary key | bigint | Not Null | >0 | 1 |
| dom | varchar(4) | Not Null | 34 | ||
| korpus | varchar(4) | 1 | |||
| kvartira | varchar(4) | 23 | |||
| id_ylits_v | foreign key | bigint | Not Null | 1 | |
| id_ur_lico | foreign key | int | Null | 3 | |
| id_fiz_lico | foreign key | bigint | Null | 2 |
Техническое описание таблиц БД позволяет реализовать SQL-команды для создания таблиц РБД.
Результат создания БД иллюстрируется схемой данных, созданной в среде СУБД.
Пример схемы данных формата MySQL с помощью CASE-средства MySQL Workbench приведен на рисунке 23.
Рисунок 23 – Схема данных
Отдельным видом проектных работ является разработка мероприятий по защите данных в БД.
При физическом проектировании необходимо помнить о реализации ограничений целостности РБД. Целостность данных – это поддержка точности и корректности данных, хранящихся в БД.
Поддержка целостности РБД рассматривается в 3-х аспектах:
1. Целостность таблицы. Обязательно должны поддерживаться:
a) уникальность строк таблицы. Должен быть определен первичный ключ таблицы, и значение его должно быть определено;
b) все уникальные (потенциальные) ключи, выявленные в ходе анализа предметной области.
Эти ограничения реализуются в командах создания и модификации таблиц. Например, в языке SQL это команды Create Table, Alter Table. В этих командах для описания полей – первичных ключей используется конструкция «primary key», для описания полей – уникальных ключей конструкция «unique», обязательность значений полей задается конструкцией «not null».
2. Декларативные ограничения данных. Так называют ограничения РБД, объявленные предметной областью и выявленные в ходе её анализа. Это ограничения на свойства объекта предметной области, далее атрибута реляционного отношения или поля таблицы: обязательность значения поля; тип, длина, диапазон значения поля (например, значение должно быть целым и положительным), вхождение значения в заданный список и др.
Такие ограничения рекомендуется задавать на уровне домена в командах Create Domain, Alter Domain. Кроме того, ограничения могут быть заданы в командах создания и модификации таблиц - Create Table, Alter Table при описании поля таблицы.
3. Ссылочная целостность. Каждая таблица РБД должна быть связана с другими посредством соответствующих первичных и внешних ключей, т.е. быть либо главной по отношению к другим таблицам, либо подчиненной, либо той и другой для разного уровня связей.
Физическое проектирование базы данных включает в себя также определение уровней доступа пользователей. Привилегии доступа устанавливает АБД или другой пользователь (прикладной программист), которому АБД предоставил такое право. Для реализации привилегии доступа к таблице используется SQL-команда «Grant», при этом необходимо указать как минимум следующие параметры: ключевое слово, обозначающее вид привилегии доступа; имя таблицы; имя пользователя. Например, предоставление пользователю с именем «Пользователь1» права на выполнение поиска данных в таблице «Адрес» осуществляется посредством команды: Grant Select On Адрес To Пользователь1.
Отменить назначенные привилегии можно с использованием команды «revoke»: Revoke all on адрес from пользователь1.