Базы данных в структуре информационных систем

ЛЕКЦИЯ 1 ВВЕДЕНИЕ В БАЗЫ ДАННЫХ Базы данных в структуре информационных систем Информационная система представляет собой совокупность информации, математических методов и моделей, технических, программных, технологических средств и специалистов, предназначенную для обработки информации и принятия управленческих решений. АИС относятся к большим системам и требуют деления на отдельные части и элементы: подсистемы, набор задач, отдельные задачи. Подсистема – относительно самостоятельная часть системы, выделенная по определенному признаку. Подсистемы могут выделяться по функциональному или структурному признаку. Принято выделять две группы подсистем в структуре АИС: • функциональные подсистемы; • обеспечивающие подсистемы. Функциональные подсистемы составляют содержательную часть информационной системы. Именно в функциональных подсистемах сосредотачиваются задачи, реализующие конкретные функции информационных систем. Автоматизированные задачи объединяются в функциональные подсистемы исходя из принципа однотипности относительно реализуемых функций. Так в рамках корпоративных информационных систем чаще всего выделяют следующие функциональные подсистемы: технической подготовки производства, технико-экономического планирования, оперативного планирования и управления, материальнотехнического снабжения, бухгалтерского учета, управления сбытом, управления кадрами, управления качеством, управления финансами, управления вспомогательным производством. В рамках функциональных подсистем, как правило, выделяют подсистемы более низкого уровня. Таким образом реализуется иерархичность системы. Обеспечивающие подсистемы создают условия для работы функциональных подсистем. Выделяют следующие обеспечивающие подсистемы: • информационное обеспечение; • программное обеспечение; • техническое обеспечение; • организационно-правовое обеспечение. Информационное обеспечение (ИО) – это совокупность системы классификации и кодирования, системы технико-экономической информации, языков записи данных, унифицированных систем документации и массивов информации используемых в АИС. Программное обеспечение (ПО) – совокупность программ, позволяющая организовать решение задач на компьютере. Важнейшими классами ПО являются системное и специальное (прикладное), представленное, в частности, пакетами прикладных программ (ППП). Системное программное обеспечение организует процесс обработки информации в компьютере. Главную его часть составляет операционная система (ОС). ОС и средства, расширяющие ее возможности, включают: планировщики - программы, организующие распределение ресурсов вычислительной системы и связь с пользователем; супервизор, который обеспечивает организацию процессов обработки программ на ПК; сервисные обслуживающие программы, позволяющие рационально организовать процесс обработки программ (программных модулей). Прикладное ПО предназначено для решения функциональных задач и работы пользователей. Пакеты прикладных программ - комплекс программ, предназначенных для решения определенного класса задач, для оснащения АРМ и решения функциональных комплексов НС. Техническое обеспечение представлено совокупностью взаимосвязанных единым управлением автономных технических средств сбора, накопления, обработки, передачи, вывода и представления информации, средств обработки документов и оргтехники, а также средств связи для осуществления информационного обмена между различными техническими средствами. Таким образом, можно сказать, что функциональные подсистемы представляют комплекс математических моделей и методов для решения задач пользователей, а обеспечивающие подсистемы представляют собой комплекс технических средств, носителей информации, программ и различных инструктивно-методических документов, необходимых для реализации соответствующих функциональных подсистем. Информационное обеспечение Под информацией понимается совокупность различных сообщений об изменении, происходящих в системе и окружающей среде. Информационное обеспечение – это совокупность системы классификации и кодирования, системы технико-экономической информации, языков записи данных, унифицированных систем документации и массивов информации, используемых в АИС. Целью информационного обеспечения (ИО) является своевременная выдача необходимой и достоверной информации для реализации пользовательских функций. К основным задачам ИО относится: • классификация, формирование оптимального перечня и состава информации, ее кодирование; • разработка классификаторов; • создание информационной модели объекта автоматизации; • формирование информационной справочно-нормативной базы управления. Информационное обеспечение включает: • состав информации, т.е. перечень информационных единиц или информационных совокупностей – показателей, констант, переменных, документов и других сообщений необходимых для решения комплекса задач системы; • структуру информации и закономерности ее преобразования, т.е. правила построения показателей, документов, агрегации и декомпозиции информационных единиц; • характеристики движения информации, т.е. количественные оценки потоков информации (объем, интенсивность), определение маршрутов движения документов, построение схем документооборота, временные характеристики функционирования источников информации, получения первичных данных, использования исходных данных, продолжительн6ость хранения, старения и обновления данных; • характеристики качества информации, т.е. систему количественных оценок полезности, значимости, полноты, своевременности информации; • способы преобразования информации, т.е. методы отбора, распределения информации, схемы обеспечения информацией подразделений системы управления. ИО должно быть организовано в соответствии со следующими требованиями: • представление информации о состоянии объекта по всем управляемым параметрам; • представление необходимой, достоверной и достаточной информации; • обеспечение защиты данных; • обеспечение своевременного сбора и передачи информации для обработки; • установление определенной периодичности поступления информации в соответствии с режимом управления; • применение совершенных носителей, способов нанесения и обработки информации с использованием современных технических средств; • использование интегрированных систем обработки информации; • обеспечение сжатия информации при переходе от низших уровней управления к высшим. Информационное обеспечение ИС включает два комплекса: внемашинное информационное обеспечение (классификаторы техникоэкономической информации, документы, методические инструктивные материалы); внутримашинное информационное обеспечение (макеты/экранные формы для ввода первичных данных в ЭВМ или вывода результатной информации, структуры информационной базы: входных, выходных файлов, базы данных). Таким образом, являясь неотъемлемой часть информационной системы, базы данных ориентированы на конкретную предметную область, являющуюся объектом автоматизации. Понятие баз данных Предметная область (ПрО) – часть реального мира, подлежащая изучению с целью реализации процессов для получения результата. Предметная область может быть разделена (декомпозирована) на фрагменты: например, предприятие – это дирекция, плановые отделы, бухгалтерия, цеха, отделы маркетинга, логистики и продаж, клиенты, поставщики и т. д. Каждый фрагмент предметной области характеризуется множеством объектов и процессов, использующих объекты, а также множеством пользователей, характеризуемых различными взглядами на предметную область и данными, которые описывают указанные составляющие предметной области. Эти данные отражают динамичную внешнюю и внутреннюю среды организации, поэтому в специальных разделах информационной системы необходимо создавать динамически обновляемые модели отражения внешнего мира с использованием единого хранилища – базы данных. Под базой данных (БД, Data Base) понимается «совокупность данных, организованных по определённым правилам, предусматривающим общие принципы описания, хранения и манипулирования данными, независимая от прикладных программ. Эти данные относятся к определённой предметной области и организованы таким образом, что могут быть использованы для решения многих задач многими пользователями» [1]. Другими словами: База данных – структурированный организованный набор данных, объединенных в соответствии с некоторой выбранной моделью и описывающих характеристики какой-либо физической или виртуальной системы. База данных является информационной моделью предметной области и к ней предъявляются требования адекватности (отражение основных свойств и характеристик процессов, реализуемых в предметной области) и актуальности (обновление БД в соответствии с изменением состояния ПрО). База данных – это некоторая целевая модель предметной области (ПрО), т.е. в базе данных находят отражение только те факты о ПО, которые необходимы для функционирования автоматизированной системы, в состав которой входит БД. При проектировании БД проектировщик должен выделить и описать эти ожидаемые факты, тем самым определяются границы ПО, затем необходимо выполнить интерпретацию описание этих фактов с помощью допустимых конкретной СУБД структур данных. Рисунок 1 – Общая схема базы данных Предметная область БД определена, если известны существующие в ней объекты, их свойства и отношения. При проектировании БД начинают с предварительной структуризации предметной области: объекты реального мира подвергают классификации, фиксируют совокупность объектов, подлежащих отображению в БД. Для каждого типа объектов фиксируется совокупность свойств, посредством которых описываются конкретные объекты этого типа, виды отношений (взаимосвязей) между этими объектами. Затем решается вопрос о том, какая информация об этих объектах должна быть представлена в БД и как ее представить с помощью данных. Сущность инфологического подхода к проектированию информационных систем заключается в установлении соответствия между состоянием ПрО, его восприятием и представлением в БД. В настоящее время при описании ПрО данные представляются в виде трехуровневой схемы1: ❖ Внешнее (с точки зрения конечного пользователя и прикладного программиста); ❖ Концептуальное (с точки зрения администратора БД); ❖ Внутреннее (с точки зрения системного программиста). Трёхуровневая архитектура для описания базы данных была предложена инициативной группой ANSI/SPARC (Американский национальный институт стандартов/Комитет по требованиям и планированию стандартов) в 1970-x гг. 1 Рисунок 2 – Общая схема концептуального моделирования С базами данных работают различные категории пользователей: прикладные программисты, конечные пользователи, администраторы базы данных. Конечные пользователи – это основная категория пользователей. Конечные пользователи работают с базами данных через рабочую станцию или терминал, используя при этом либо приложения, либо интерфейс СУБД. В зависимости от особенностей создаваемой базы данных круг конечных пользователей может существенно различаться. Прикладные программисты разрабатывают внешние приложения, которые позволяют выполнять над данными все стандартные операции: выборку, удаление и изменение существующей информации, вставку новой информации. Администратор базы данных (АБД) – под этим понятием подразумевается лицо (или группа лиц, возможно, целое штатное подразделение), на которое возложено управление средствами базы данных организации. В его функции входит: − координировать все действия по проектированию, реализации и ведению базы данных; учитывать перспективные и текущие требования пользователей; следить, чтобы база данных удовлетворяла актуальным информационным потребностям; − анализировать существующие программные средства и возможность их использования в базе данных, разрабатывать программно-технические мероприятия по развитию базы данных; − разрабатывать и реализовывать меры по обеспечению защиты данных от некомпетентного их использования, от сбоев технических средств, по обеспечению секретности определённой части данных и разграничению доступа к данным; − выполнять работы по ведению словаря данных; контролировать избыточность и противоречивость данных, их достоверность; − следить за тем, чтобы БД отвечала заданным требованиям по производительности, т.е. чтобы обработка запросов выполнялась за приемлемое время; выполнять при необходимости изменения методов хранения данных, путей доступа к ним, связей между данными, форматов данных; определять степень влияния изменений в данных на всю БД; координировать вопросы технического обеспечения системы аппаратными средствами исходя из требований, предъявляемых БД к оборудованию; − координировать работы системных программистов, разрабатывающих дополнительное программное обеспечение для улучшения эксплуатационных характеристик системы; − координировать работы прикладных программистов, разрабатывающих новые приложения и выполнять проверку и включение прикладных программ в состав программного обеспечения системы; − работать с конечными пользователями, в том числе и по вопросам обучения и консультирования и т.п. Программное обеспечение включает, прежде всего, систему управления базами данных (СУБД) – комплекс программных средств, «предназначенный для создания и хранения базы данных на основе некоторой модели данных, обеспечения логической и физической целостности содержащихся в ней данных, надёжного и эффективного использования ресурсов (данных, пространства памяти, вычислительных ресурсов), предоставления к ней санкционированного доступа для приложений и конечных пользователей, а также для поддержки функций администратора баз данных». Рассмотрим функции СУБД подробнее: − СУБД должна предоставлять пользователям и программам два типа языков: язык описания данных (для описания логической структуры данных) и язык манипулирования данными (для выполнения запросов пользователя на выборку, изменение, удаление данных); − СУБД должна контролировать пользовательские запросы и следить за выполнением правил безопасности и целостности, определённых администратором БД; − в СУБД должен быть предусмотрен механизм восстановления данных; − СУБД должна обеспечить функцию словаря данных. Словарь данных содержит «данные о данных», так называемые метаданные. Метаданные словаря предоставляются в виде, удобном для восприятия человеком, и характеризуют состав и структуру пользовательских данных в базе данных. Словарь данных предназначен для документирования разработки системы базы данных, справочного обслуживания её пользователей, а также для персонала, администрирующего БД. СУБД является важнейшим, но не единственным компонентом программного обеспечения. Другие программные компоненты: средства разработки приложений, средства проектирования, утилиты, генераторы отчётов и т.д. Процесс проектирования базы данных Проектирование баз данных неразрывно связано с процессом проектирования информационных систем. Проектирование базы данных начинается с определения информационных потребностей пользователей, создания модели данных и заканчивается утилизацией базы данных. Процедура создания концептуальной схемы базы данных, определения данных, включаемых в базу данных, создание программ обновления и обработки данных называется жизненным циклом базы данных (ЖЦ). Жизненный цикл включает в себя процессы проектирования, реализации и поддержания системы базы данных и состоит из следующих этапов [1]: − предварительное планирование; − проверка осуществимости; − определение требований; − концептуальное проектирование; − реализация; − оценка работы и поддержка базы данных; − снятие с эксплуатации. Рисунок 3 – Жизненный цикл БД Предварительное планирование выполняется в процессе разработки стратегического плана базы данных. Стратегический план предполагает количество и вид баз данных, которые требуется создать для организации. Когда начинается разработка проекта реализации, общая информационная модель, созданная в процессе планирования базы данных, пересматривается и уточняется. Предварительное планирование предполагает определение функций и количества используемых прикладных программ, приложений, находящихся в процессе создания. Эта информация помогает установить связи между текущими приложениями и определить, каким образом используется информация приложений, а также сформулировать будущие требования к системе. Проверка осуществимости определяет технологическую, операционную и экономическую осуществимость плана создания базы данных. Технологическая осуществимость предполагает определение доступности необходимого оборудования и программного обеспечения, необходимых для работы базы данных: имеются ли в наличии данные ресурсы, или необходимо их приобретение. Операционная осуществимость связана с определением квалификации и опыта специалистов, работающих с БД. Экономическая целесообразность предполагает получение определённой выгоды от внедрения базы данных. Этап определения требований включает выбор целей базы данных, выяснение информационных потребностей различных подразделений и требований к оборудованию и программному обеспечению. Информационные потребности могут выясняться с помощью анкет, опросов менеджеров и работников компании, а также на основе документов компании. Общая информационная модель, созданная на этапе планирования базы данных, разделяется на модели для каждого отдела компании, являющиеся основой для создания проекта следующего этапа. Этап концептуального проектирования включает создание концептуальной схемы базы данных. На этом же этапе создаются подробные модели пользовательских представлений, которые затем преобразуются в концептуальную модель, фиксирующую все элементы данных, которые будет содержать база данных. В процессе реализации базы данных выбирается и приобретается СУБД. Затем концептуальная модель преобразуется в проект реализации базы данных, создаётся словарь данных, база данных заполняется данными, создаются прикладные программы и обучаются пользователи. Построение словаря данных как центрального хранилища определений структуры данных – ключевой шаг в реализации базы данных. Словарь данных предназначен для системного персонала администрирования данных, прикладных программистов и конечных пользователей. Оценка базы данных включает опросы пользователей в целях выяснения неучтённых информационных потребностей. При необходимости вносятся изменения, обеспечивается поддержка системы путём добавления новых программ. Последний этап – снятие с эксплуатации базы данных. Рисунок 4 – Этапы проектирования БД Системы управления базами данных Функции и структура СУБД Система управления базами данных, СУБД (Data Base Management System) - специализированная программа или комплекс программ, предназначенные для манипулирования базой данных. Для создания информационной системы и управления ею СУБД необходима в той же степени, как для разработки программы на алгоритмическом языке необходим транслятор. СУБД часто упрощенно или ошибочно называют "базой данных". Нужно различать набор данных (собственно БД) и программное обеспечение, предназначенное для организации и ведения баз данных (СУБД). Отличительной чертой баз данных следует считать то, что данные хранятся совместно с их описанием, а в прикладных программах описание данных не содержится. Независимые от программ пользователя данные обычно называются метаданными или данными о данных. В ряде современных систем метаданные, содержащие также информацию о пользователях, форматы отображения, статистику обращения к данным и др. сведения, хранятся в специальном словаре базы данных. В общем плане можно выделить следующие функции, реализуемые СУБД: – организация и поддержание логической структуры данных (схемы базы данных); – организация и поддержание физической структуры данных во внешней памяти; – организация доступа к данным и их обработка в оперативной и внешней памяти. Организация и поддержание логической структуры данных (схемы базы данных) обеспечивается средствами модели организации данных. Модель данных определяется способом организации данных, ограничениями целостности и множеством операций, допустимых над объектами организации данных. Соответственно модель данных разделяют на три составляющие — структурную, целостную и манипуляционную. Известны три основные модели организации данных: – иерархическая; – сетевая; – реляционная. Организация структуры БД формируется исходя из следующих соображений: адекватность описываемому объекту/системе на уровне концептуальной и логической моделей; удобство использования для ведения учета и анализа данных - на уровне так называемой физической модели. Виды концептуальных и логических моделей БД: – сетевые; – иерархические; – реляционные. Реляционная база данных - база данных, основанная на реляционной модели. Слово "реляционный" происходит от английского "relation" (отношение). Теория реляционных баз данных была разработана доктором Эдгаром Коддом из компании IBM в 1970 году и регламентируется теорией реляционной алгебры. В реляционных базах данных все данные представлены в виде простых таблиц, разбитых на строки и столбцы, на пересечении которых расположены данные. Запросы к таким таблицам возвращают таблицы, которые сами могут становиться предметом дальнейших запросов. Каждая база данных может включать несколько таблиц. Кратко особенности реляционной базы данных можно сформулировать следующим образом: данные хранятся в таблицах, состоящих из столбцов ("атрибутов") и строк ("записей"); на пересечении каждого столбца и строчки стоит в точности одно значение; у каждого столбца есть свое имя, которое служит его названием, и все значения в одном столбце имеют один тип; запросы к базе данных возвращают результат в виде таблиц, которые тоже могут выступать как объект запросов; строки в реляционной базе данных неупорядочены. Модель данных, реализуемая СУБД, является одной из основных компонент, определяющих функциональные возможности СУБД по отражению в базах данных информационно-логических схем предметных областей автоматизированной информационной системы (АИС). Модель организации данных, по сути, определяет внутренний информационный язык автоматизированного банка данных, реализующего автоматизированную информационную систему. Модели данных, поддерживаемые СУБД, довольно часто используются в качестве критерия для классификации СУБД. Исходя из этого, различают иерархические СУБД, сетевые СУБД и реляционные СУБД. Другой важной функцией СУБД является организация и поддержание физической структуры данных во внешней памяти. Эта функция включает организацию и поддержание внутренней структуры файлов базы данных, иногда называемой форматом файлов базы дачных, а также создание и поддержание специальных структур (индексы, страницы) для эффективного и упорядоченного доступа к данным. В этом плане эта функция тесно связана с третьей функцией СУБД — организацией доступа к данным. Организация и поддержание физической структуры данных во внешней памяти может производиться как на основе штатных средств файловых систем, так и на уровне непосредственного управления СУБД устройствами внешней памяти. Организация доступа к данным и их обработка в оперативной и внешней памяти осуществляется через реализацию процессов, получивших название транзакций. Транзакцией называют последовательную совокупность операций, имеющую отдельное смысловое значение по отношению к текущему состоянию базы данных. Так, например, транзакция по удалению отдельной записи в базе данных последовательно включает определение страницы файла данных, содержащей указанную запись, считывание и пересылку соответствующей страницы в буфер оперативной памяти, собственно удаление записи в буфере ОЗУ, проверку ограничений целостности по связям и другим параметрам после удаления и, наконец, «выталкивание» и фиксацию в файле базы данных нового состояния соответствующей страницы данных. Транзакции принято разделять на две разновидности — изменяющие состояние базы данных после завершения транзакции и изменяющие состояние БД лишь временно, с восстановлением исходного состояния данных после завершения транзакции. Совокупность функций СУБД по организации и управлению транзакциями называют монитором транзакций. Транзакции в теории и практике СУБД по отношению к базе данных выступают внешними процессами, отождествляемыми с действиями пользователей банка данных. При этом источником, инициатором транзакций может быть как один пользователь, так и несколько пользователей сразу. По этому критерию СУБД классифицируются на однопользовательские (или так называемые «настольные») и многопользовательские («тяжелые», «промышленные») СУБД. Соответственно в многопользовательских СУБД главной функцией монитора транзакций является обеспечение эффективного совместного выполнения транзакций над общими данными сразу от нескольких пользователей. Непосредственная обработка и доступ к данным в большинстве СУБД осуществляется через организацию в оперативной памяти штатными средствами операционной системы или собственными средствами системы буферов оперативной памяти, куда на время обработки и доступа помещаются отдельные компоненты файла базы данных (страницы). Поэтому другой составной частью функций СУБД по организации доступа и обработки данных является управление буферами оперативной памяти. Еще одной важной функцией СУБД с точки зрения организации доступа и обработки данных является так называемая журнализация всех текущих изменений базы данных. Журнализация представляет собой основное средство обеспечения сохранности данных при всевозможных сбоях и разрушениях данных. Во многих СУБД для нейтрализации подобных угроз создается журнал изменений базы данных с особым режимом хранения и размещения. Вместе с установкой режима периодического сохранения резервной копии БД журнал изменений при сбоях и разрушениях данных позволяет восстанавливать данные по произведенным изменениям с момента последнего резервирования до момента сбоя. Во многих предметных областях АИС (например, БД с финансово-хозяйственными данными) такие ситуации сбоя и порчи данных являются критическими и возможности восстановления данных обязательны для используемой СУБД. Резервная копия БД и журнал изменений, как правило, размещаются на отдельных от основного файла БД носителях. Таким образом, функция «Организация доступа к данным и их обработка в оперативной и внешней памяти» реализуется через следующие механизмы: монитор транзакций, управление буферами оперативной памяти, журнализация. Исходя из рассмотренных функций, в структуре СУБД в современном представлении можно выделить следующие функциональные блоки: – процессор описания и поддержания структуры базы данных; – процессор запросов к базе данных; – монитор транзакций; – интерфейс ввода данных; – интерфейс запросов; – интерфейс выдачи сведений; – генератор отчетов. Как правило, в однопользовательских СУБД монитор транзакций в виде отдельного функционального элемента СУБД не реализуется и не выделяется. Схематично взаимодействие компонент СУБД представлено на рис. 5. Ядром СУБД является процессор описания и поддержания структуры базы данных. Он реализует модель организации данных, средствами которой проектировщик строит логическую структуру (схему) базы данных, соответствующую инфологической схеме предметной области АИС, и обеспечивает построение и поддержание внутренней схемы базы данных. Процессором описания и поддержания структуры данных в терминах используемой модели данных (иерархическая, сетевая, реляционная) обеспечиваются установки заданной логической структуры базы данных, а также трансляция (перевод) структуры базы данных во внутреннюю схему базы данных (в физические структуры данных). В АИС на базе реляционных СУБД процессор описания и поддержания структуры базы данных реализуется на основе языка базы данных, являющегося составной частью языка структурированных запросов (SQL). Интерфейс ввода данных СУБД реализует входной информационный язык банка данных, обеспечивая абонентам-поставщикам информации средства описания и ввода данных в информационную систему. Одной из современных тенденций развития СУБД является стремление приблизить входные информационные языки и интерфейс ввода к естественному языку общения с пользователем в целях упрощения эксплуатации информационных систем так называемых «неподготовленными» пользователями. Данная проблема решается через применение диалоговых методов организации интерфейса и использование входных форм. Входные формы, по сути, представляют собой электронные аналоги различного рода анкет, стандартизованных бланков и таблиц, широко используемых в делопроизводстве и интуитивно понятных большинству людей (неподготовленных пользователей). Интерфейс ввода при этом обеспечивает средства создания, хранения входных форм и их интерпретацию в терминах описания логической структуры базы данных для передачи вводимых через формы сведений процессору описания и поддержания структуры базы данных. Рисунок 5 – Структура и взаимодействие компонент СУБД Интерфейс запросов совместно с процессором запросов обеспечивает концептуальную модель использования информационной системы в части стандартных типовых запросов, отражающих информационные потребности пользователей-абонентов системы. Интерфейс запросов предоставляет пользователю средства выражения своих информационных потребностей. Современной тенденцией развития СУБД является использование диалоговонаглядных средств в виде специальных «конструкторов» или пошаговых «мастеров» формирования запросов. Процессор запросов интерпретирует сформированные запросы в терминах языка манипулирования данными и совместно с процессором описания и поддержания структуры базы данных собственно и исполняет запросы. В реляционных СУБД основу процессора запросов составляет язык манипулирования данными, являющийся основной частью языка SQL. Тем самым на базе процессора запросов и процессора описания и поддержания структуры базы данных образуется низший уровень оперирования данными в СУБД, который иногда называют машиной данных. Стандартные функции и возможности машины данных используют компоненты СУБД более высокого порядка, что позволяет разделить и стандартизировать компоненты СУБД и банка данных на три уровня — логический уровень, машина данных и собственно сами данные. Функции монитора транзакции, как уже отмечалось, заключаются в организации совместного выполнения транзакций от нескольких пользователей над общими данными. При этом дополнительной функцией, неразрывно связанной, в том числе и с основной функцией, является обеспечение целостности данных и ограничений над данными, определяемыми правилами предметной области АИС. Интерфейс выдачи СУБД получает от процессора запросов результаты исполнения запросов (обращений к базе данных) и переводит эти результаты в форму, удобную для восприятия и выдачи пользователю-абоненту информационной системы. Для отображения результатов исполнения запросов в современных СУБД используются различные приемы, позволяющие «визуализировать» данные в привычной и интуитивно понятной неподготовленному пользователю форме. Обычно для этого применяются табличные способы представления структурированных данных, а также специальные формы выдачи данных, представляющие также, как и формы ввода, электронные аналоги различных стандартизованных бланков и отчетов в делопроизводстве. Формы выдачи лежат также и в основе формирования так называемых «отчетов», выдающих результаты поиска и отбора информации из БД в письменной форме для формализованного создания соответствующих текстовых документов, т. е. для документирования выводимых данных. Для подобных целей в состав современных СУБД включаются генераторы отчетов. В заключение по структуре и составу СУБД следует также добавить, что современные программные средства, реализующие те или иные СУБД, представляют собой совокупность инструментальной среды создания и использования баз данных в рамках определенной модели данных (реляционной, сетевой, иерархической или смешанной) и языка СУБД (язык описания данных, язык манипулирования данными, язык и средства создания интерфейса). На основе программных средств СУБД проектировщики строят в целях реализации конкретной информационной системы (инфологическая схема предметной области, задачи и модель использования, категории пользователей и т. д.) автоматизированный банк данных, функционирование которого в дальнейшем поддерживают администраторы системы и услугами которого пользуются абоненты системы. Структура файлов и их взаимодействие в процессе функционирования СУБД представлена на рис. 6. Рисунок 6 – Информационное взаимодействие в СУБД Внутренняя схема баз данных Изначально и по сей день программное обеспечение АИС (СУБД) в качестве места физического размещения данных ориентировано на внешнюю (дисковую) память. Как уже отмечалось, размещение данных во внешней памяти, точнее эффективность доступа к ним во внешней памяти, существенно влияет на эффективность обработки данных. В результате важным аспектом АИС является внутренняя схема базы данных, которую организует и поддерживает СУБД. В общем плане внутренняя схема базы данных включает три основных компонента, представленные на рис. 7. Центральным компонентом внутренней схемы являются информационные массивы, включающие собственно данные (информационных объектов логической схемы БД, т.е. в реляционных СУБД таблиц), и массивы индексов, являющихся специальными дополнительными конструкциями для ускорения доступа к данным основных информационных объектов. Информационные массивы в большинстве СУБД состоят из одной или нескольких так называемых страниц, каждая из которых содержит совокупность некоторых единичных элементов, называемых физическими записями. В результате, единичным элементом внутренней схемы баз данных АИС является физическая запись, в большинстве случаев совпадающая по смыслу с логической записью, т. е. в реляционных СУБД с табличной строкой. Способы организации записей в страницах (расположение, добавления, корректировка, удаление) составляют физические структуры данных, которые образуют третий (низший) уровень представления информации в информационной системе. Важным компонентом внутренней структуры является каталог БД, в котором размещается системная информация по логической структуре БД, включающая описание основных информационных объектов (имена, структура, параметры, связи) и ограничения целостности данных. Организация системной информации БД определяется особенностями конкретной СУБД, а сам каталог может входить непосредственно в файлы данных (область описателей данных) или составлять отдельный информационный массив. Как уже отмечалось, в состав автоматизированного банка данных АИС помимо самой базы данных входит и прикладной компонент, образуемый совокупностью интерфейсных элементов представления, ввода и обработки данных, типовых запросов и процедур обработки данных, а также «событий» и «правил», отражающих правила и специфику предметной области АИС (так называемые «правила бизнеса»). Соответственно во внутренней схеме БД выделяется специальная область, в которой размещается информация по прикладному компоненту АИС. Все три части внутренней структуры и их составные элементы (например, информационные массивы отдельных информационных объектов БД) могут размещаться в одном едином файле базы данных или в разных файлах. Во втором случае внутренняя схема БД определяется совокупностью и порядком расположения данных файлов. Рисунок 7 – Cocтав внутренней схемы базы данных Физические структуры данных Страничная организация информационных массивов БД определяется общей спецификой доступа к данным больших объемов. Доступ к физическим записям во внешней памяти в большинстве СУБД осуществляется через считывание в оперативную память страниц файла данных, содержащих соответствующие записи. Непосредственная обработка записей производится в оперативной памяти, для чего СУБД образует и поддерживает, как уже отмечалось, специальные буферы, в которых временно размещаются страницы, содержащие обрабатываемые записи. После завершения обработки страница с соответствующими записями «выталкивается» из буфера и фиксируется в дисковом файле. Аналогичным образом осуществляется размещение и доступ к индексным массивам. В итоге общий принцип организации доступа к данным во внешней памяти можно проиллюстрировать схемой, приведенной на рис. 8. Физические структуры организации файлов данных подразделяются на линейные и нелинейные. В линейных структурах в одну страницу файла базы данных объединяются записи-кортежи одной таблицы (информационного объекта), которые располагаются в последовательном (линейном) порядке друг за другом. Каких-либо ссылок, указателей на связи между записями не предусматривается. Если не применяется специального порядка размещения записей в страницах (так называемая «расстановка» записей), то при добавлении записей в большинстве случаев в линейных структурах каждая новая запись помещается непосредственно за последней записью. Если страница файла данных заполняется, то для соответствующей таблицы выделяется дополнительная страница. Рисунок 8 – Общий принцип организации внутренней схемы базы данных Классификация СУБД По типу управляемой базы данных СУБД разделяются на иерархические, реляционные, объектно-реляционные, объектноориентированные, сетевые. По архитектуре организации хранения данных: локальные СУБД (все части локальной СУБД размещаются на одном компьютере); распределенные СУБД (части СУБД могут размещаться на двух и более компьютерах). Классификация СУБД по способу доступа к БД: файл-серверные; клиент-серверные; трехзвенные; встраиваемые. Файл-серверные СУБД. Архитектура "файл-сервер" не имеет сетевого разделения компонентов диалога и использует компьютер для функции отображения, что облегчает построение графического интерфейса. "Файлсервер" только извлекает данные из файлов, так что дополнительные пользователи добавляют лишь незначительную нагрузку на центральный процессор, и каждый новый клиент добавляет вычислительную мощность сети. Минус - высокая загрузка сети. На данный момент файл-серверные СУБД считаются устаревшими. Примеры: Microsoft Access, MySQL (до версии 5.0). Клиент-серверные СУБД. Такие СУБД состоят из клиентской части (которая входит в состав прикладной программы) и сервера. Клиентсерверные СУБД, в отличие от файл-серверных, обеспечивают разграничение доступа между пользователями и меньше загружают сеть и клиентские машины. Сервер является внешней по отношению к клиенту программой, и по мере надобности его можно заменить другим. Недостаток клиент-серверных СУБД - в самом факте существования сервера (что плохо для локальных программ - в них удобнее встраиваемые СУБД) и больших вычислительных ресурсах, потребляемых сервером. Примеры: Firebird, Interbase, MS SQL Server, Oracle, DB2, PostgreSQL, MySQL (старше версии 5.0). Существенным недостатком клиент-серверной архитектуры является необходимость установления прямого соединения между клиентским компьютером и базой данных. При трехзвенной архитектуре пользовательское приложение (клиент) соединяется со специально выделенным сервером приложений, и только он уже соединяется с базой данных. Кроме повышения уровня безопасности трехзвенная архитектура позволяет более гибко модернизировать приложения. Как правило, в массовой клиентской части оставляют только минимальный набор функций по доступу и отображению информации, а основную бизнес-логику реализуют в программах, запускаемых на серверах приложений. При этом модернизация обычно затрагивает только сервер приложений, а на массовых клиентских местах переустанавливать ПО не приходится. Встраиваемая СУБД - это, как правило, "библиотека", которая позволяет унифицированным образом хранить большие объемы данных на локальной машине. Доступ к данным может происходить через SQL либо через особые функции СУБД. Встраиваемые СУБД быстрее обычных клиентсерверных и не требуют установки сервера, поэтому востребованы в локальном ПО, которое имеет дело с большими объемами данных - например, геоинформационные системы (Geographic Informational System - GIS). Примеры: SQLite, BerkeleyDB, один из вариантов Firebird, один из вариантов MySQL. Общепринятым стандартом языка работы с реляционными базами данных в настоящее время является язык структурированных запросов (Structured Query Language - SQL). Это универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных. Вопреки существующим заблуждениям, SQL является информационно-логическим языком, а не языком программирования. SQL основывается на реляционной алгебре. Язык SQL делится на три части: операторы определения данных; операторы манипуляции данными (Insert, Select, Update, Delete); операторы определения доступа к данным. Основные функции системы управления базами данных: управление данными во внешней памяти (на различных носителях); управление данными в оперативной памяти; журналирование изменений и восстановление базы данных после сбоев; поддержка языков БД (язык определения данных, язык манипулирования данными, язык определения доступа к данных). Функции администратора баз данных Администратор базы данных– это лицо (или группа лиц), на которое возложено управление средствами базы данных организации. ❖ координация всех действия по проектированию, реализации и ведению базы данных; учет перспективных и текущих требований пользователей; мониторинг удовлетворения актуальных информационных потребностей; ❖ анализ существующих программных средств и возможности их использования в базе данных, разработка программно-технические мероприятия по развитию базы данных; ❖ разработка и реализация мер по обеспечению защиты данных от некомпетентного их использования, от сбоев технических средств, обеспечение секретности определённой части данных и разграничение доступа к данным; ❖ выполнение работ по ведению словаря данных; контроль избыточности и противоречивости данных, их достоверности; ❖ Обеспечение удовлетворения БД требованиям по производительности, т.е. чтобы обработка запросов выполнялась за приемлемое время; ❖ изменение необходимости методов хранения данных, путей доступа к ним, связей между данными, форматов данных; определение степени влияния изменений в данных на всю БД; ❖ координация вопросов технического обеспечения системы аппаратными средствами исходя из требований, предъявляемых БД к оборудованию; ❖ координация работы системных программистов, разрабатывающих дополнительное программное обеспечение для улучшения эксплуатационных характеристик системы; ❖ координация работы прикладных программистов, разрабатывающих новые приложения и выполнять проверку и включение прикладных программ в состав программного обеспечения системы; ❖ работа с конечными пользователями, в том числе и по вопросам обучения и консультирования и т.п. ЛЕКЦИЯ 2 ИНФОЛОГИЧЕСКИЙ ПОДХОД Инфологический подход База данных – это некоторая целевая модель предметной области (ПрО), т.е. в базе данных находят отражение только те факты о ПрО, которые необходимы для функционирования автоматизированной системы, в состав которой входит БД. При проектировании БД проектировщик должен выделить и описать эти ожидаемые факты, тем самым определяются границы ПрО, затем необходимо выполнить интерпретацию описание этих фактов с помощью допустимых конкретной СУБД структур данных. Предметная область БД определена, если известны существующие в ней объекты, их свойства и отношения. При проектировании БД начинают с предварительной структуризации предметной области: объекты реального мира подвергают классификации, фиксируют совокупность объектов, подлежащих отображению в БД. Для каждого типа объектов фиксируется совокупность свойств, посредством которых описываются конкретные объекты этого типа, виды отношений (взаимосвязей) между этими объектами. Затем решается вопрос о том, какая информация об этих объектах должна быть представлена в БД и как ее представить с помощью данных. Сущность инфологического подхода к проектированию информационных систем заключается в установлении соответствия между состоянием ПрО , его восприятием и представлением в БД. В настоящее время при описании ПрО данные представляются в виде трехуровневой схемы2: ❖ Внешнее ( с точки зрения конечного пользователя и прикладного программиста); ❖ Концептуальное (с точки зрения администратора БД); ❖ Внутреннее (с точки зрения системного программиста). Внешнее представление данных является совокупностью требований к данным некоторой конкретной задачи или программы. Оно определяет совокупность внешних представлений, соответствующих отдельным задачам и перекрывающих друг друга по некоторым данным. С точки зрения конечного пользователя внешнее представление является совокупностью требований к данным, определенными функциональными спецификациями (реальными форматами) и отражает конкретные информационные потребности. С точки зрения прикладного программиста внешнее представление заключается в наборе элементов данных и их взаимосвязи для обеспечения конкретной задачи. Различия между этими представлениями: Трёхуровневая архитектура для описания базы данных была предложена инициативной группой ANSI/SPARC (Американский национальный институт стандартов/Комитет по требованиям и планированию стандартов) в 1970-x гг. 2 ❖ Для пользователя многие сведения определяются путем обработки данных в представлении системного программиста; ❖ Представления программиста могут содержать много дополнительной информации. Концептуальное представление данных связано с отображением знаний о ПрО. Структура данных на концептуальном уровне называется концептуальной схемой. Под концептуальным представлением понимается интегральное определение данных, которое основано на объединении всех внешних представлений для всей совокупности приложений. Другими словами, концептуальное представление данных является совокупностью всех требований к данным полученным из пользовательских внешних представлений. Существует и другой подход, по которому концептуальное представление формируется в результате непосредственного анализа ПрО с учетом информационных потребностей пользователей. Элементарными единицами концептуального представления являются : ❖ Элементы (объекты, предметы, процессы); ❖ Связи элементов; ❖ Свойства элементов. Схема концептуального моделирования приведена на рис. 2. В этой схеме предусмотрено построение концептуальной модели путем объединения информационного описания ПрО (ПрО-информации) и информационных требований прикладных программ (ПП-информация). ПрО-Информация отображает объекты, процессы и предметы реального мира как составные части ПрО, их существенные свойства, а также взаимосвязи этих элементов. Эта информация не связана ни с конкретными приложениями, ни с конкретными способами обработки, а описывает естественные концептуальные связи всех данных в базе данных. Пример ПрО-информации: ❖ Описание элемента ПрО: Наименование - СТУДЕНТ Количество - 25 ❖ Описание атрибутов элементов ПрО: Наименование - НОМЕР ЗАЧ. КНИЖКИ Длина - десятичных знаков Диапазон изменения - 000001-999999 ❖ Описание связей элементов ПО: Наименование - УЧИТСЯ В Определяемые элементы - СТУДЕНТ, ГРУППА Количество - 25 Отображение - 1:1 ПП-информация описывает данные и связи, используемые в приложениях. Она отображает требования конечных пользователей к обработке используемых текущих приложений и предполагаемые требования планируемых в будущем приложений. Пример ПП-информации: ❖ Описание процесса: Наименование - Экземпляр ведомости Частота применения - 2 раза в год Требуемые данные - СТУДЕНТ, НОМЕР ЗАЧ. КНИЖКИ ГРУППА ПРЕПОДАВАТЕЛЬ Объем данных - 25 ❖ Оператор: Наименование - найти Критерий поиска - СТУДЕНТ Кол-во поисковых образов - все Используемые ассоциации – успеваемость. Рисунок 1 – Общая схема концептуального моделирования Внутреннее (физическое) представление выражает представление данных системными программистами и связано с организацией хранения данных на физических носителях информации. Практически внутреннее представление интегрированная база данных. Элементами внутреннего представления являются: ❖ Физические блоки; ❖ Хранимые записи; ❖ Указатели; ❖ Данные переполнения; ❖ Межблочные промежутки. Внешнее представление 1 Концептуальное представление Внутреннее представление Внешнее представление n Рисунок 2 – Трехуровневое представление данных Согласно инфологическому подходу при проектировании БД различают: 1. Явления реального мира; 2. Информация об этих явлениях; 3. Представление этой информации посредством данных. Соответственно выделяют сферы: 1. Объектная система; 2. Информационная сфера; 3. Датологическая сфера. Объектная система. Объектная система имеет следующие составляющие: ❖ Объект; ❖ Свойство; ❖ Связь; ❖ Время. Объект – это то о чем должна накапливаться информация в АС. Выбор объектов производится в соответствии с целевым назначением информационной системы. Объекты могут быть составными и атомарными. Для составного объекта должно быть определено его внутреннее строение, структура, порядок композиции составляющих. Каждый объект в конкретный момент времени характеризуется определенным состоянием. Это состояние описывается с помощью ограниченного набора свойств и связей (отношений) с другими объектами. Свойства могут быть: ❖ Локальными, независимыми от других объектов; ❖ Реляционными. Связь между объектами характеризуется степенью n, в зависимости от входящих в нее объектов. Время также рассматривается в качестве основной составляющей. В отдельные моменты времени или в течении некоторых временных интервалов объекты могут иметь определенное состояние. Использование временных характеристик позволяет строить динамические модели. Основные составляющие объектной системы комбинируются в базисные структуры, которые называются элементарными ситуациями. Элементарной ситуацией называется структура описываемая выражением  o, y, t , где o – объект y – свойство t – время. Элементарные ситуации, существующие в некоторый момент времени для конкретной области называется элементарными фактами. Множество всех объектов, имеющих общее свойство у называется объектной группой. Они могут быть пересекающейся и непересекающейся. Информационная сфера. Информационная сфера определяется понятиями, с помощью которых можно формально описать и проанализировать информацию об объектах системы. Основные понятия информационной сферы сведения. Для каждого сведения всегда определена его предметная цель, т.е. указано к чему оно относится: объекту, объектной группе, атрибуту, связи, времени, ситуации. Сведения представляют собой смысловые, концептуальные образы составляющих, которые используются человеком при восприятии и осмыслении реальных объектов. Однозначные сведения обозначаются универсальным именем, неоднозначные, локальным именем. Сведения представляются выражениями, основу которых составляют элементарные сведения. Структура элементарного сообщения соответствует структуре элементарной ситуации  x, y, z , где x – сведения об объекте y – сведения о свойстве z – сведения о времени. Тройка  x, y, z  , называется полным элементарным сообщением. Множеству допустимых элементарных ситуаций соответствует множеству возможных полных элементарных сообщений. Датологическая сфера. В датологической сфере рассматриваются вопросы представления данных выделенных информационных структур. Методология системного анализа и синтеза СИСТЕМЫ. ХАРАКТЕРИСТИКИ. СВОЙСТВА Понятие системы Система - множество составляющих единство элементов, связей и взаимодействий между ними и внешней средой, образующие присущую данной системе целостность, качественную определенность и целенаправленность. По определению элемент - это составная часть сложного целого. Сложное целое - это система, которая представляет собой целостный комплекс взаимосвязанных элементов. Элемент - неделимая часть системы. Элемент - часть системы, обладающая самостоятельностью по отношению ко всей системе и неделимая при данном способе выделения частей. Неделимость элемента рассматривается как нецелесообразность учета в пределах модели данной системы его внутреннего строения. Сам элемент характеризуется только его внешними проявлениями в виде связей и взаимосвязей с остальными элементами и внешней средой. Рисунок 3 – Понятие системы Состояние элемента, в зависимости от различных факторов (времени, пространства, внешней среды и т.д.), может изменяться. Последовательные изменения состояния элемента будем называть движением элемента. Связь - совокупность зависимостей свойств одного элемента от свойств других элементов системы. Установить связь между двумя элементами - это значит выявить наличие зависимостей их свойств. Зависимость свойств элементов может иметь односторонний и двусторонний характер. Взаимосвязи - совокупность двухсторонних зависимостей свойств одного элемента от свойств других элементов системы. Взаимодействие - совокупность взаимосвязей и взаимоотношений между свойствами элементов, когда они приобретают характер взаимосодействия друг другу. Структура системы - совокупность элементов системы и связей между ними в виде множества. Структура является статической моделью системы и характеризует только строение системы и не учитывает множества свойств (состояний) ее элементов. Система существует среди других материальных объектов, которые не вошли в систему и которые объединяются понятием «внешняя среда» объекты внешней среды. Вход характеризует воздействие внешней среды на систему, выход воздействие системы на внешнюю среду. По сути дела, очерчивание или выявление системы есть разделение некоторой области материального мира на две части, одна из которых рассматривается как система - объект анализа (синтеза), а другая - как внешняя среда. Внешняя среда - набор существующих в пространстве и во времени объектов (систем), которые, как предполагается, оказывают действие на систему. Внешняя среда - это совокупность естественных и искусственных систем, для которых данная система не является функциональной подсистемой. Для данной системы внешняя среда (окружение) есть множество предметов вне системы: 1) изменение признаков которых влияет на систему; 2) признаки которых изменяются вследствие поведения системы. Решение задачи отнесения предметов к самой системе или к ее окружению является в значительной мере произвольной и зависит от целей изучения системы. Общая проблема выделения окружения весьма сложна. Для того, чтобы указать окружение полностью, необходимо знать все факторы, воздействующие на систему или испытывающие воздействие с ее стороны. Это задача также сложна, как и указание самой системы. При определении границ системы и ее окружения часто используют метод абстрагирования или идеализации. При использовании этого метода в систему и ее окружение включают те предметы, которые кажутся наиболее важными, описывают связи между ними возможно точнее и исследуют наиболее интересные признаки, пренебрегая теми, которые не играют существенной роли. Этот метод широко используется в физических и химических исследованиях. Например, пружины без массы, воздух без трения, идеальные газы и т.п. При создании технических систем в окружение системы включаются следующие универсальные факторы: - состояние технологии; - естественное окружение; - политика организации; - экономические условия для новых технологий; - человеческий фактор. Характеристики системы Структура системы есть устойчивая упорядоченность в пространстве и во времени ее элементов и связей. Структура системы отражает порядок вхождения элементов в подсистемы, а затем последовательное объединение подсистем в целостную систему. Эта структура всегда парно-иерархического типа и имеет не менее двух уровней: старший уровень - система; младший уровень - элемент. Классификация видов структур: 1). В зависимости от характера организации в системе элементов и их связей выделяют три типа структур: сетевую, иерархическую, скелетную. 2). В плане пространственной организации различают структуры: плоские; - объемные; - рассредоточенные, когда элементы равномерно распределены в пространстве; - локально сосредоточенные. 3). По временному признаку выделяют: - Экстенсивные структуры, в которых с течением времени происходит рост числа элементов; интенсивные структуры, в которых происходит рост числа связей и их мощи при неизменном числе элементов; - редуцирующие, противоположные экстенсивным; - деградирующие, противоположные интенсивным; стабильные. Структура является наиболее консервативной характеристикой системы. Функция есть действие, поведение, деятельность системы Функция элемента возникает как реализация его системоопределенных свойств и при формировании элемента и его связей в системе. Функция системы или набор функций возникает как специфическое для каждой системы порождение всего комплекса функций и дисфункций элементов ее составляющих. Любой элемент обладает огромным количеством свойств. Одни из этих свойств при формировании связей подавляются, другие приобретают ярко выраженных характер. Однако степень подавления системонезначащих свойств элементов, как правило, не бывает полной. В связи с этим при формировании системы возникают не только «полезные функции», обеспечивающие сохранение системой ее качественной особенности, но и дисфункции, негативно влияющие на функционирование системы. Основными системными характеристиками функций являются: - совместимость на элементном уровне; изменчивость (лабильность); возможность активизации на свойствах элементов; - интенсивность ( выраженность); - степень детерминированности. ПРОЦЕСС ФУНКЦИОНИРОВАНИЯ СИСТЕМЫ Состояние системы Состояние системы - совокупность состояний ее n элементов и связей между ними (двухсторонних связей не может быть более чем n(n - 1) в системе с n элементами). Задание конкретной системы сводится к заданию ее состояний, начиная с зарождения и кончая гибелью или переходом в другую систему. Реальная система не может находиться в любом состоянии. На ее состояние накладывают ограничения - некоторые внутренние и внешние факторы (например, человек не может жить 1000 лет). Возможные состояния реальной системы образуют в пространстве состояний системы некоторую подобласть (подпространство) - множество допустимых состояний системы. Входы системы - различные точки приложения влияния (воздействия) внешней среды на систему называются входами Х; системы. Входами системы являются информация, вещество, энергия, которые подлежат преобразованию. Входные воздействия, изменяющиеся с течением времени, образуют входной процесс. Входной процесс можно задать, если каждому моменту времени поставить в соответствие, по определенному правилу, входное воздействие. Обобщенным входом Х называют некоторое (любое) состояние всех r входов системы, которое можно представить в виде вектора: Х = (X1, Х2, Х3, ..., Xk, ..., Хr). Выходы системы - различные точки приложения влияния (воздействия) системы на внешнюю среду называются выходами Yj системы. Выход системы - это результат преобразования информации, вещества и энергии. Выходные величины изменяются с течением времени, образуя выходной процесс. Обратная связь - то, что соединяет выход со входом системы и используется для контроля за изменением выхода. Ограничения системы - то, что определяет условия реализации процесса (процесс - последовательность операций по преобразованию чеголибо, т.е. то, что преобразует вход и выход). Ограничения бывают внутренними и внешними. Одним из внешних ограничений является цель функционирования системы. Примером внутренних ограничений могут быть ресурсы, обеспечивающие реализацию того или иного процесса. Движение системы - процесс последовательного изменения состояния системы. Вынужденное движение - движение системы под влиянием внешней среды, которое приводит к изменению ее состояния. Вынужденное движение (пример) - перемещение ресурсов под действием приказа (поступившего в систему извне). Собственное движение - движение системы без воздействия внешней среды (только под действием внутренних причин). Собственным движением человека будет его жизнь как биологического (а не общественного) индивида, т.е. питание, сон, размножение. Понятие процессов системы Процесс - совокупность последовательных изменений состояния системы для достижения цели. Входной процесс - множество входных воздействий, которые изменяются с течением времени. Функции входных процессов - задание, по определенному правилу, в определенные моменты времени, управляющих воздействий. Выходной процесс множество выходных воздействий на окружающую среду, которые изменяются с течением времени. Воздействие системы на окружающую среду определяется выходными величинами (реакциями). Выходные величины изменяются с течением времени, образуя выходной процесс, представляющий определенную функцию. Функции выходных процессов - задание, по определенному правилу, в определенные моменты времени, выходных величин (реакций) системы. Изменение состояния происходит с течением времени, образуя движение системы. Функцией входа является возбуждение той силы, которая обеспечивает систему энергией, материалом, информацией, поступающей в процесс. Пример входных процессов показан на рис. 4. Рисунок 4 – Процессы системы Обратная связь Назначение подсистем обратной связи - изменение идущего процесса. Рисунок 5 – Обратная связь СИСТЕМНЫЙ СИСТЕМ ПОДХОД – МЕТОДОЛОГИЯ ИЗУЧЕНИЯ Специфические принципы системного подхода 1) принцип системности – любой объект рассматривается как система; 2) принцип иерархичности познания. Требует трехуровневого изучения предмета: ◼ изучение самого предмета - «собственный уровень»; ◼ изучение этого же предмета как элемента более широкой системы вышестоящий уровень; ◼ изучение этого предмета в соответствии с составляющими данный предмет компонентами - нижестоящий уровень. 3) принцип интеграции - изучение интегративных свойств и закономерностей систем и комплексов систем, раскрытие основных механизмов интеграции целого; 4) принцип формализации - получение количественных характеристик, создание методов сужающих неоднородность понятий, определений, оценок. Уровни изучения систем (общая стратификация) Сложную систему чаще всего невозможно охватить полностью и детально представить. На практике это не всегда и требуется. Тогда возникает проблема компромисса между простотой описания, понимания системы и необходимостью учета многочисленных и разноплановых характеристик системы. Одним из путей решения этой проблемы является послойное стратифицированное описание (от лат. stratum - настил, facere - делать). Основными уровнями изучения системы являются: ◼ микроскопический; ◼ макроскопический. Макроскопическое изучение заключается в игнорировании детальной структуры системы и наблюдении только общего поведения системы как целого, в оценке ее интегративных характеристик. К числу макроскопических характеристик относятся: ◼ тип структуры и границы системы; ◼ характер взаимосвязи «вход - выход»; ◼ особенности функционирования (дискретное или непрерывное); ◼ степень организованности и высоты организации; ◼ особенности жизненного цикла системы; ◼ эффективность системы. Микроскопическое изучение системы связано с детальным описанием каждой из компонент системы, всех внутренних процессов. Центральным для микроскопического представления является понятие элемента. В рамках микроскопического уровня изучаются: ◼ структура системы; ◼ связи и функции элементов; ◼ эффективность элементов. Виды описания системы Сведения о системе могут быть оформлены в виде следующих описаний: ◼ морфологического; ◼ функционального; ◼ информационного; ◼ процессуального; ◼ прагматического. Морфологическое описание должно дать представление о строении системы. Морфологическое изучение проводится в следующей последовательности: 1) определение границ системы ; 2) изучаются подсистема первого уровня, далее компоненты последующих уровней вплоть до уровня элементов; 3) характер межкомпонентных связей и связей с внешней средой; 4) характер пространственно-временной организации компонентного состава и связей; 5) изучается изменчивость и особенности морфологии на различных стадиях существования системы. Глубина морфологического анализа определяется тремя факторами: стоящими задачами исследования; - значимостью влияния нижестоящих слоев структуры на интегративные характеристики системы; - достижимой степенью снятия неопределенности. Основной задачей функционального описания является определение поведения системы, ее возможностей и отношения к другим системам. Функциональное описание имеет иерархическую схему и должно отражать иерархию функций, процессы, параметры системы. Наиболее рациональным методом функционального описания является описание более высокого уровня на основе обобщенных и факторизованных переменных низшего уровня. Задачи информационного описания заключаются в определении характеристик организации системы и оценке ее сложности. Целью процессуального изучения является определение особенностей жизненного цикла системы, характеристик протекающих в системе процессов. Задачей прагматического описания является получение прагматических характеристик: назначение, цель, эффективность, критерии оптимальности и т.п. Прагматическое описание выполняется только для целенаправленных систем. ЛЕКЦИЯ 3 АНАЛИЗ ПРЕДМЕТНОЙ ФОРМУЛИРОВКА И АНАЛИЗ ТРЕБОВАНИЙ ОБЛАСТИ. Анализ предметной области выполняется на первом этапе проектирования базы данных с целью формирования и спецификации требований к информационной системе и базе данных. Исследованию подвергаются: • Характер деятельности организации; • Организационная (должностная), функциональная структуры организации; • Документы и массивы, потоки данных; Характер деятельности организации Определяются сфера деятельности реализуемая организацией или область реализуемых процессов, характер, цели и результаты функционирования, а также выполняемые функции управления или стадии реализуемых процессов. Функции управления ранжируются по приоритету и с учетом их взаимосвязи. Например, если в качестве объекта рассматривать отдел кадров, то в зависимости от цели этого объекта по-разному определяются функции и информационные потребности. Так целеполагание учета кадровой информации и целеполагание управления качественно отличаются друг от друга в соотношении к информационным потребностям. В первом случает информационные потребности ограничиваются персональными данными, во втором многообразная информация, определяющая реализацию процессов по эффективному использованию трудовых ресурсов. Организационная (должностная), функциональная структура Обследование системы предполагает определение организационной, функциональной структуры системы и анализ состава информации обрабатываемой системой. Организационная структура представляет собой перечень подразделений организации с учетом их подчиненности. Если в качестве объекта автоматизации выступает какое-либо одно подразделение организации, определяется должностная структура подразделения. На рисунке 1 представлена организационная структура, построенная в среде моделирования ARIS. Рисунок 1 – Пример представления организационной структуры Изучение должностной структуры дает возможность понять содержание используемых процедур управления, смысл некоторых документов, суть отношений между сотрудниками. В результате изучения определяется функциональная структура организации, функциональные обязанности лиц, имеющих отношение к разрабатываемой задаче. На этом этапе изучения следует помнить, что конкретная задача управления реализуется определенным набором функций, хотя часто встречается взаимозаменяемость этих понятий: задача – функция. При изучении обязанностей должностных лиц, имеющих непосредственное отношение к анализируемой задаче, особенно тщательно изучается круг их функциональных обязанностей, характер выполняемых ими работ и сроки выполнения. Изучение функциональных обязанностей каждого должностного лица должно быть направлено на выявление их перегрузки, а также основных недостатков существующей организационной структуры. Источником информации для изучения деятельности объекта автоматизации могут быть внутренние нормативные акты организации, инструктивные и методические материалы. Таким образом, в результате функционального анализа по каждому подразделению и должностному лицу определяется: перечень задач (функций) управления; содержание задачи управления (перечень реализующих данную задачу функций (операций)); периодичность выполнения задач и функций управления; количество работников, участвующих в реализации задачи, их образование, должность, затрачиваемое время; наличие и содержание формальных методов решения задач; применяемые технические средства. Для фиксирования информации можно воспользоваться формой, представленной на рисунке 2. Рисунок 2 – Описание функций Так же для функционального анализа можно воспользоваться стандартом IDEF03 ) предназначен для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции [5]. Метод, предлагаемый стандартом IDEF0, предназначен для функционального моделирования, то есть моделирования выполнения функций объекта, путем создания описательной графической модели, показывающей что, как и кем делается в рамках функционирования предприятия. Функциональная модель 3 Стандарт реализует методологию анализа сложных систем SADT (Structured Analysis and Design Technique), разработанной группой американских аналитиков во главе с Дугласом Россом в 1973 году. представляет собой структурированное изображение функций производственной системы или среды, информации и объектов, связывающих эти функции. Модель строится методом декомпозиции: от крупных составных структур к более мелким, простым. Элементы каждого уровня декомпозиции представляют собой действия по переработке информационных или материальных ресурсов при определенных условиях с использованием заданных механизмов. Каждое действие раскладывается на более мелкие операции по переработке определенной части информационных или материальных ресурсов при определенных условиях с использованием части заданных механизмов. Аналогично раскладываются операции. Последний шаг декомпозиции должен приводить к получению модели, степень детализации которой удовлетворяет требованиям, заданным в самом начале процесса создания модели. Рисунок 3 – Функциональный блок и интерфейсные дуги Построение IDEF0-диаграммы начинается с представления объекта автоматизации в виде одного блока с дугами. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Например, в случае автоматизации деятельности отдела кадров в блоке будет указано «Управление персоналом» или «Учет кадров» в зависимости от целеполагания объекта. Далее выполняется декомпозиция (разбиение) исходного процесса на подпроцессы (рис. 8). Для каждого подпроцесса создается отдельный блок. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления. Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее (рис. 4). Рисунок 4 –Декомпозиция диаграмм Рисунок 5 – Схема обеспечения соответствия блоков и дуг диаграмм На рис. 6 представлен пример IDEF0-диаграммы. Для описания процессов можно воспользоваться CESE-средствами. Стандарт IDEF0 поддерживают: система бизнес-моделирования Business Studio [2], система моделирования бизнес-процессов BPwin (теперь AllFusion Process Modeler) [3], инструментальная среда ARIS [4] . Документы и массивы. Обследование информационной составляющей предполагает: • уточнение применяемой терминологии с целью обеспечение взаимопонимания персонала разработчика и заказчика; • выявление используемых в организации внешних и внутренних документов, составлении схемы документооборота; • анализ массивов информации; • определение информационных связей организации и ее подразделений. Рисунок 6 – IDEF0-диаграмма процесса управления персоналом Документы, которые предназначены для сбора и регистрации данных, называются входными (регистрационными, учетными) документами. Входными по отношению к административным процедурам обработки данных. Документы, вырабатываемые в результате обработки данных, называются Выходными (результирующими) документами. Документы, предназначенные для пользования внутри организации, называются внутренними документами. Документы, поступающие или направляемые вне организации, называются внешними документами. Прежде чем приступить к изучению каждого документа по отдельности, следует составить список всех документов, разрабатываемой задачи. Существование каждого документа должно быть обосновано, поскольку часто выясняется, что некоторые документы, хотя и существуют, но не используются. Для работы со спецификацией документов можно воспользоваться терминологической моделью (Technical terms model), выполненной в среде ARIS (рис. 7). Рисунок 7 – Терминологическая модель Массивы информации, подлежащие исследованию, могут быть или ручными, или машинными. При изучении массивов необходимо собрать информации: • наименование, • носитель, • место нахождения, • структура записи, • длина записи, • число записей, • процедуры ведения массивов, • способы использования массивов, • процедуры защиты массивов. Следует обратить внимание на ручные массивы информации, которые ведутся не по стандартным формам в тетрадях, личных записных книжках. Анализ информационных потоков Основными элементами информационного потока являются некоторые объемы информации на носителях и процедуры преобразования информации. Располагая эти элементы в виде вершин графа, дуги которого соответствуют передаче информации от одного элемента к другому, получают графическую модель в виде ориентированного графа. Наиболее удобно представлять модель в виде обобщенной структурноинформационно-временной схемы (ОСИВС), что позволяет проследить движение информации не только по логико-функциональным связям, но и по организационным. Схема ОСИВС (рис.8) служит для наглядного представления этапов решения основных задач, их последовательности, а также движения информации во времени по структурным подразделениям. На схеме по горизонтали откладывается масштаб времени в днях, неделях, месяцах - в зависимости от общей продолжительности решения рассматриваемых задач. По вертикали схема разбивается на ряд горизонтальных полос, каждая из которых соответствует организации или структурному подразделению. Удобно выделять средние полосы для структурных подразделений рассматриваемой организации, расположенные выше полосы для вышестоящих и ниже – для подчиненных организаций. На полученную сетку наносят этапы решения задач и движения информации. Рисунок 8 – Обобщенная структурно-информационно-временная схема Применяемые при этом условные обозначения позволяют непосредственно на схеме вводить пояснения и количественные характеристики – шифр и наименование документа, частоту его формирования, объем содержащейся в документе и перерабатываемой информации в алфавитно-цифровых знаках. Логический анализ схемы позволяет проследить движение информации от входа к выходу, определить моменты и места образования и использования документов, процедуры преобразования информации, время обработки, наличие дублирования при вводе исходных данных и при их обработке, количество однотипных операций, излишние перемещения данных между подразделениями. Информационные потоки могут быть описаны информационным графом (рис. 9), а исследованы посредством анализа его матрицы смежности. В качестве компонентов потока информации рассматриваются исходная, промежуточная и выходная информация в виде соответствующих наборов данных. Между компонентами информационного потока устанавливается отношение порядка: нулевой порядок имеют наборы данных исходной информации, а наивысший – выходные результаты. Упорядоченные таким образом компоненты представляют в виде графа, вершины которого отображают компоненты информационного потока, а дуги направление. Вершины соединяют дугами в том случае, если существует информационная связь между компонентами, представленными соответствующими вершинами, причем без промежуточных результатов. Их наличие требует введения дополнительной вершины между двумя рассматриваемыми. Дуги направлены от вершины более низкого порядка к вершине более высокого порядка. По дугам ставятся коды функций (работ) в результате реализации которых выполняется преобразование информации. Рисунок 9 – Информационный граф Информационные потоки могут быть также представлены комплексом графов, на каждом из которых отображается преобразование информации при расчете отдельного показателя. Ребра графа ориентированы в виде дерева от исходных показателей к результирующим, которые в свою очередь являются исходными для следующего уровня укрупнения. Такая модель удобна, например, для отображения процесса формирования сводок о различных аспектах работы цехов, предприятий, объединений; при формировании плана и т.п. Если исходные показатели используются для формирования нескольких результирующих, возможно срастание деревьев – наличие у графов общих вершин и пересекающихся дуг. Описание информационных потоков должно сопровождаться системными спецификациями. Они представляют собой комплект документов, назначение которого – представить в компактной и удобной для использования форме сведения о движении информации в системе, начиная с содержания и формы представления входных данных, описания процедур их обработки и контроля, информационных массивов и кончая формами представления выходных данных. Рисунок 10 – Форма общего описания документа Форма общей характеристики документа содержит дополнительные данные к информационному графу. На рисунке 11 представлена форма детального описания документа. В ней отражена поэлементная структура документа. Высший уровень 01 присваивается тем элементам документа, которые не являются составной частью никакого другого элемента, например шапка документа и его текстовая часть. Уровень 02 имеют элементы, непосредственно входящие составной частью в элемент уровня 01, уровень 03 - входящие в уровень 02, и т.д. Особое внимание должно уделять выявлению форматов элементов – длине, шаблону представления. Шаблон состоит из условных знаков: X – любой символ; А – буква; 9 – цифра; П – пробел. Число повторяющихся символов указывается повторением условных знаков или записью в скобках, например, 9999, или 9(4). Если число символов переменно, шаблон приводится для максимально возможного их числа. Эта информация ляжет в основу определения типов и форматов представления данных в БД. Рисунок 11 – Форма детального описания документа Уровни элементов в структуре документа на примере сведений о работнике выделяются следующим образом: 01 сведения о сотруднике 02 личные данные 03 фамилия 03 имя 03 отчество 02 сведения о рождении 03 место рождения 04 город, поселок, деревня 04 область, район 03 дата рождения При изучении элементов следует обратить внимание на использовании в документе кодификаторов информации. Поскольку правила построения системы кодирования задают ограничения на выбор типа и формата представления данных. Классификация и кодирование информации Классификатор — это документ, с помощью которого осуществляется формализованное описание информации в ИС, содержащей наименования объектов, наименования классификационных группировок и их кодовые обозначения. Виды классификаторов: • международные, • общегосударственные (общесистемные), • Отраслевые, Локальные. Кодирование — это процесс присвоения условных обозначений объектам и классификационным группам по соответствующей системе кодирования. Кодирование реализует перевод информации, выраженной одной системой знаков, в другую систему, то есть перевод записи на естественном языке в запись с помощью кодов. Система кодирования — это совокупность правил обозначения объектов и группировок с использованием кодов. Код — это условное обозначение объектов или группировок в виде знака или группы знаков в соответствии с принятой системой. Содержание классификатора: Описание и справочные данные Классификатор Код Расшифровка Число элементов дочерних Описание системы кодирования: Уточняющие коды Схема Реализация в базе данных используемых классификаторов является обязательной. Кодируемая номенклатура используется для формирования словарей и справочников. Пример описания классификатора ОКИН — Общероссийский классификатор информации о населении. Описание и справочные данные Наименование: Общероссийский классификатор информации о населении Аббревиатура: ОКИН Обозначение: ОК 018-2014 По-английски: Russian Classification of Informationon Population Ответственный: Ростехрегулирование Основание: Дата введения: Дата окончания: Последнее изменение: Основание изменения: Официальный источник: Приказ Федерального агентства по техническому регулированию и метрологии от 12.12.2014 № 2019-ст 01.07.2015 не установлена (нет приказа классификатора или его замене новым) об отмене № 10, действует с 1 июля 2019 г Приказ Росстандарта от 29.05.2019 № 242-ст protect.gost.ru/v.aspx?control=21&baseC=19&page=0& month=-1&year=-1&search=&id=193551 Коды ОКИН 01 Пол 02 Гражданство 03 Национальности … … 290 Лица, которым Российская Федерация предоставляет политическое убежище 291 Лица, которым политическое убежище Российской Федерацией не предоставляется 292 Причины утраты лицом права на предоставленное ему Российской Федерацией 293 Причины лишения лица политического убежища, предоставленного ему Российской Федерацией политическое убежище, Таким образом изучение предметной области дает материалы для построения инфологической модели предметной области; определения выполняемых запросов к базе данных для удовлетворения информационных потребностей пользователей; определить интерфейс для ввода информации в БД, формы представления выходной информации. ЛЕКЦИЯ 4-5 РАЗРАБОТКА МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ ТИПА «СУЩНОСТЬ-СВЯЗЬ» Основные понятия В проектировании структуры базы данных применяется семантическое моделирование. Основу этого подхода составляет моделирование структур данных исходя из смыслового содержания данных и логики реализуемых в предметной области процессов. Семантический подход реализуется разработкой инфологической модели сущность-связь (ER – EntityRelationship). Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные CASE-средства используют несколько отличающиеся друг от друга нотации ERD. Одна из наиболее распространенных нотаций предложена Баркером и используется в Oracle Designer. В CASE-средстве SilverRun используется один из вариантов нотации Чена. CASE-средства ERwin, ER / Studio, Design / IDEF используют методологию IDEF1Х. По сути, все варианты диаграмм сущность-связь исходят из одной идеи – рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями. Модель типа «сущность-связь» – это неформальная модель предметной области, которая используется на этапе инфологического проектирования БД. Основное назначение неформальной модели «сущность-связь» – семантическое описание ПрО и представление информации для обоснования выбора видов моделей и структуры данных. При построении модели используется три основных конструктивных элемента для представления составляющих ПрО: ❖ Сущность ❖ Атрибут ❖ Связь Информация о проекте объединяется с помощью графических диаграмм. Сущность – это собирательное понятие, некоторая абстракция реально существующего объекта, процесса или явления, о котором необходимо хранить информацию в системе. Тип сущности определяет набор однородных элементов. Экземпляр сущности – конкретный объект в наборе. Каждый тип сущности должен быть поименован. Имя сущности это, как правило, уникальное наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник", "Накладная". Атрибут – это поименованная характеристика сущности, которая принимает значения некоторого множества значений. Эта характеристика является значимой для рассматриваемой предметной области. В модели атрибут выступает в качестве средства, с помощью которого моделируются свойства сущностей. Для идентификации конкретных экземпляров сущностей в некотором типе используются идентифицирующие атрибуты. Атрибут или набор атрибутов однозначно идентифицирующие экземпляр сущности называется первичным ключом (Primary Key). Классификация сущностей: Сильные (Regular) и слабые (Weak) – сильная сущность существует сама по себе, слабые сущности существуют в зависимости от сильной. СТУДЕНТ – сильная сущность, ОЦЕНКА – слабая, т.к. оценка получается студентом и логически с ним связана. Сильные сущности еще называют базовыми, основными, родительскими, а слабые – подчиненными, дочерними. Независимые и зависимые. Экземпляры независимой сущности идентифицируются без определения его отношений с другими сущностями, Сущность является зависимой, если однозначная идентификация экземпляра сущности зависит от ее отношения с экземпляром другой сущности. Классификация атрибутов: Идентифицирующие (основные) и описательные (неосновные). Идентифицирующие атрибуты имеют уникальное значение для экземпляров сущности и используются для формирования ключей. Остальные атрибуты называются описательными и заключают в себе интересующие свойства сущности. Составные (частично структурированные) и простые (структурированные) атрибуты. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут включает несколько элементов, например, фамилия, имя, отчество хранимые в одном поле. Вопрос о декомпозиции составного атрибута к нескольким простым зависит от характера его обработки и формата пользовательского представления этого атрибута. При этом и составные и простые атрибуты рассматриваются как атомарные. Однозначные и многозначные атрибуты. Если для экземпляра сущности существует только одно значение атрибута он называется однозначным. Частным случаем может быть идентифицирующий атрибут. Если для экземпляра сущности существует много значений для каждого экземпляра сущности. Основные и производные атрибуты. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута определяется на основе значений других атрибутов (например, возраст вычисляется на основе даты рождения и текущей даты). Обязательные и необязательные. Обязательность означает, что атрибут не может принимать неопределенных значений (Null). Классификация ключей: Первичный (Primary Key) и альтернативный (Alternate Key). Атрибут или набор атрибутов которые однозначно идентифицируют экземпляр сущности, но не выбранные в качестве первичного называются альтернативным (возможным) ключом. При выборе первичного ключа основываются на логике предметной области. Так рассматривая работника, в качестве идентифицирующих атрибутов можно рассматривать ТАБЕЛЬНЫЙ НОМЕР, ИНН, СНИЛС. Но внутреннему учету организации соответствует ТАБЕЛЬНЫЙ НОМЕР и поэтому именно он выбирается первичным ключом. Спецификация атрибута состоит из его названия, назначение, указания типа данных и описания ограничений целостности – множества принимаемых значений. Пример: Сущность РАБОТНИК Атрибуты: ТАБЕЛЬНЫЙ НОМЕР, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ПОЛ, ДАТА РОЖДЕНИЯ, МЕСТО РОЖДЕНИЯ. Связи – выступают в модели в качестве средства, с помощью которого представляют отношения между сущностями, имеющими место в ПрО. Тип связи рассматривается между типами сущностей. Существуют следующие виды бинарных связей: • бинарные • терные • n-арные. Классификация бинарных связей: Отображение 1:1 (Связь один к одному) С помощью отображения 1:1 определяют такой тип связи между типами сущностей А и В, когда каждому экземпляру сущности А соответствует один и только один экземпляр сущности В и наоборот. Т.е. А однозначно идентифицирует В и, наоборот, В однозначно идентифицирует А. Рисунок 1 – Бинарная связь 1:1 Отображение 1:М (Связь один ко многим) С помощью отображения 1:М определяют такой тип связи между типами сущностей А и В, когда одному экземпляру сущности А соответствует несколько или ни одного экземпляра сущности В, а каждому экземпляру сущности В соответствует только один экземпляр А. Связь можно охарактеризовать как «имеет в составе». Рисунок 2 – Бинарная связь 1:М Отображение М:1 (Связь многие к одному) Связь обратная 1:М. Характеризуется как «входит в состав» Рисунок 3 – Бинарная связь М:1 Отображение М:М (Связь многие ко многим) С помощью отображения М:М определяют такой тип связи между типами сущностей А и В, когда каждому экземпляру сущности А соответствует несколько или ни одного экземпляра сущности В и наоборот. Рисунок 4 – Бинарная связь М:М Связь характеризуется свойством модальности: • Может • Должен. Если экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром связь имеет модальность может. Если экземпляр одной сущности всегда связан не менее чем с одним экземпляром другой сущности связь имеет модальность должен. Связь может иметь разную модальность с разных концов. Через модальность связи определяется класс принадлежности сущности. Если экземпляры данной сущности должны участвовать в связи, то класс принадлежности сущности называется обязательным (Mandatory). Если экземпляры данной сущности могут не участвовать в связи, то класс принадлежности сущности называется необязательным (Optional). Тип связи в совокупности с характеристикой модальности называется кардинальностью связи. Информация о проекте оформляется составлением спецификаций по сущностям, атрибутам и связям с использованием графических диаграмм. Разработка модели «Сущность-Связь» включает следующие основные этапы: • Определение сущностей, их атрибутов, а также первичных и альтернативных ключей. • Определение связей между сущностями и указание видов. • Определение классов принадлежности сущностей. Процесс выделения сущностей, атрибутов и связей основывается на информации, полученной на этапе анализа предметной области. Сущности выделяются исходя из информационных объектов обрабатываемых в изученных функциях элементов организационной системы. Так же можно рассматривать информационные совокупность выделяемый в документах. Следует помнить о собирательности понятия сущности. Т.е. атрибуты сущности выявляются исходя из реквизитов относящихся к рассматриваемому объекту указанным во множестве документов предметной области. Пример. Рисунок 5 – Фрагмент документа предметной области Принятие решения о выделении сущности ОКСО ОКСО – Общероссийский классификатор специальностей по образованию ОКСО содержит коды областей образования, укрупненных групп, профессий, специальностей и направлений подготовки, а также их наименования. В ОКСО использованы иерархический метод классификации и последовательный метод кодирования. Кодовое обозначение профессии, специальности или направления подготовки состоит из семи цифровых знаков: Х.XX.XX.XX, где: 1-й цифровой знак соответствует коду области образования; 2-й и 3-й цифровые знаки соответствуют коду укрупненной группы; 4-й и 5-й цифровые знаки соответствуют коду образовательного уровня; 6-й и 7-й цифровые знаки соответствуют коду профессии, специальности или направления подготовки. После кода области образования, после кода укрупненной группы и после кода образовательного уровня ставится точка. Поскольку в документе подлежат регистрации любые направления подготовки и с учетом мощности классификатора формируется отдельная сущность ОКСО Общероссийский классификатор специальностей по образованию Атрибуты: код ОКСО, Наименование направления подготовки Первичный ключ: код ОКСО Принятие решения о выделении сущности ОКИН Пол Номенклатура классификатора является устойчивой (не изменяется) и маломощной – два родительских кода. Поэтому выделять сущность ОКИН Пол нецелесообразно. На программном уровне предусматривается формирование в атрибуте Пол значения 1 – мужской 2 – женский Принятие решения о выделении сущности ОКПО ОКПО (общественный классификатор предприятий и организаций) это государственный классификатор хозяйственных субъектов страны В ОКПО использованы иерархический метод классификации и последовательный метод кодирования. Кодовое обозначение хозяйствующего субъекта состоит из десяти цифровых знаков: ХXXXXXXХХХ, где: 1-й и 2-йцифровой знак соответствует коду субъекта федерации; 3-й - 10-й цифровые знаки соответствуют коду регистрационному номеру хозяйствующего субъекта. Код ОКПО используется только для самой организации, в которой эксплуатируется информационная система. Т.е. хранится только один Код ОКПО. Формирование сущности нецелесообразно. Принятие решения о выделении сущности ОКАТО ОКАТО — Общероссийский классификатор объектов административно-территориального деления Объектами классификации в ОКАТО являются: республики; края; области; города федерального значения; автономная область; автономные округа; административные районы (районы); города; внутригородские районы, округа города; поселки городского типа; сельсоветы; сельские населенные пункты. В классификаторе принята иерархическая система классификации. Длина кода - от 2 до 8 разрядов в зависимости от уровня классификации, на котором находится объект. Структура кода: XX XXX XXX, где 1-й, 2-й знаки - объекты первого уровня классификации (республики; края; области; города федерального значения; автономную область; автономный округ, входящий в состав Российской Федерации); 3, 4, 5-й знаки – объекты второго уровня классификации (автономные округа, входящие в состав края или области; районы республики, края, области, автономной области, автономного округа, входящего в состав Российской Федерации, внутригородские районы, округа города федерального значения; города республиканского, краевого, областного значения (подчинения); поселки городского типа краевого, областного подчинения); 6, 7, 8-й знаки - объекты третьего уровня классификации (внутригородские районы, округа города республиканского, краевого, областного значения (подчинения); города районного значения (подчинения); поселки городского типа районного подчинения; сельсоветы). С учетом мощности классификатора и процедур его ведения формирование сущности нецелесообразно. Для формирования кода ОКАТО целесообразно воспользоваться электронными ресурсами формирующими значение ОКАТО по семантическому полю Формируемые сущности: Работник – сведения о личных данных работника Атрибуты: Табельный номер, Фамилия, Имя, Отчество, Пол, Год рождения, Место рождения, ИНН, СНИЛС Первичный ключ: Табельный номер Трудовой договор – сведения о заключенном работником трудовом договоре Атрибуты: Номер трудового договора, Дата заключения Первичный ключ: Номер трудового договора ОКИН Гражданство – классификатор гражданства Атрибуты: код ОКИН Гр-ва, Наименование гражданства Первичный ключ: код ОКИН Гр-ва ОКИН Образование – классификатор уровня образования Атрибуты: код ОКИН Образования, Наименование уровня образования Первичный ключ: код ОКИН Образования ОКИН Языки – классификатор Языков народов Российской Федерации и иностранных языков Атрибуты: код ОКИН языка, Наименование языка Первичный ключ: код ОКИН языка Выделенные бинарные связи: Нормализация схем сущностей Для ER -диаграмм вводится понятие нормальных форм. Нормализации подлежат схемы сущностей, т.е. нормализуется перечень атрибутов. Нормализация выполняется путем выделения в отдельную сущность аномальных атрибутов. Первая нормальная форма: устраняются повторяющиеся атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, «замаскированных» под атрибуты. ❖ Невозможно использование в виде атрибута массива данных ❖ Частично структурированные атрибуты не являются аномалией по первой нормальной форме При анализе алгоритмов манипулирования данными возможны неструктурированные атрибуты Адрес, Паспорт и т.п. Вторая нормальная форма: устраняются атрибуты, зависящие только от части уникального идентификатора. Сущность: Знание языков Атрибуты: Табельный номер, Код ОКИН Языка, Наименование языка, Код ОКИН Знания ин.яз, Наименование степени знания Первичный ключ: Табельный номер, Код ОКИН Языка Наименование языка зависит от элемента первичного ключа Код ОКИН Языка – это аномалия по 2-ой НФ. Нормализация: Сущность: ОКИН языки Атрибуты: код ОКИН языка, Наименование языка Первичный ключ: код ОКИН языка Сущность: Знание языков Атрибуты: Табельный номер, Код ОКИН Языка, Код ОКИН Знания ин.яз, Наименование степени знания Первичный ключ: Табельный номер, Код ОКИН Языка Третья нормальная форма: устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Сущность: Знание языков Атрибуты: Табельный номер, Код ОКИН Языка, Код ОКИН Знания ин.яз, Наименование степени знания Первичный ключ: Табельный номер, Код ОКИН Языка Наименование степени знания зависит от неосновного атрибута Код ОКИН Знания ин.яз – это аномалия по 3-ой НФ. Нормализация: Сущность: ОКИН Степени знания ин. яз Атрибуты: код ОКИН, Наименование степени знания Первичный ключ: код ОКИН Степени знания ин. Яз Сущность: Знание языков Атрибуты: Табельный номер, Код ОКИН Языка, Код ОКИН Знания ин.яз Первичный ключ: Табельный номер, Код ОКИН Языка ❖ ❖ ❖ ❖ ❖ Оформление модели предметной области типа «Сущность - Связь» Спецификация сущностей: Имя сущности Назначение сущности Спецификация атрибутов сущности: Имя атрибута Назначение атрибута Тип атрибута ❖ Формат атрибута ❖ Допустимые значения ❖ Примечание – отнесение атрибута к первичному или альтернативному (возможному) и другие замечания Спецификация связей (для каждой бинарной связи): ❖ Сущности участвующие в связи ❖ Кардинальность связи ❖ Классы принадлежности сущностей в бинарной связи Нотации представления «Сущность-Связь» модели предметной области типа Нотация Чена Таблица 1 – Графические элементы ER-диаграммы в нотации Чена Элемент диаграммы Обозначает Независимая сущность Зависимая сущность Родительская сущность в иерархической связи Связь Идентифицирующая связь Атрибут Первичный ключ Внешний ключ (понятие внешнего ключа вводится в реляционной модели данных) Многозначный атрибут Элемент диаграммы Обозначает Получаемый (наследуемый) иерархических связях атрибут в Рисунок 6 – модель в нотации Чена На рисунке 7 приведена диаграмма модели типа «Сущность-Связь». Рисунок 7 – Пример диаграммы «Сущность–Связь» в нотации Чена Нотация Мартина Таблица 2 – Представление сущностей в нотации Мартина Элемент диаграммы Обозначает независимая сущность Элемент диаграммы Обозначает зависимая сущность родительская сущность в связи 1:М Список атрибутов приводится внутри прямоугольника, обозначающего сущность. Ключевые атрибуты подчеркиваются. Связи изображаются линиями, соединяющими сущности, вид линии в месте соединения с сущностью определяет кардинальность связи (таблица 3). Таблица 3 – Представление связей в нотации Мартина Обозначение Кардинальность Примечание нет 1,1 Класс принадлежности сущности обязательный 0,1 Класс принадлежности сущности необязательный M,N 0,N Класс принадлежности сущности необязательный 1,N Класс принадлежности сущности обязательный Имя связи указывается на линии ее обозначающей. Примеры показаны на рисунке 8 и 9. Рисунок 8 – Пример в нотации Мартина Рисунок 9 - Пример ER-диаграммы в нотации Мартина Нотация Баркера Сущности обозначаются прямоугольниками, внутри которых приводится список атрибутов. Ключевые атрибуты отмечаются символом # (решетка). Связи обозначаются линиями с именами, место соединения связи и сущности определяет кардинальность связи. Таблица 4 – Представление связей в нотации Баркера Обозначение связи Кардинальность 0,1 1,1 0,N 1,N Примеры показаны на рисунке 10, 11 и 12. Рисунок 10 – Пример в нотации Баркера Для обозначения отношения категоризации вводится элемент "дуга". Рисунок 11 – Пример отношения категоризации Рисунок 12 - Пример ER-диаграммы в нотации Баркера Нотация IDEF1X Таблица 5 – Представление сущностей в нотации IDEF1X Элемент диаграммы Обозначает независимая сущность зависимая сущность Список атрибутов приводится внутри прямоугольника, обозначающего сущность. Атрибуты, составляющие ключ сущности, группируются в верхней части прямоугольника и отделяются горизонтальной чертой (примеры показаны на рисунках 13-16). Таблица 6 – Представление связей в нотации Мартина Элемент диаграммы Обозначает идентифицирующая связь не идентифицирующая связь Таблица 7 – Обозначение кардинальности связей Элемент диаграммы Обозначает 1,1 0,M 0,1 1,M точно N (N - произвольное число) Рисунок 13 – Пример обозначения кардинальности в нотации IDEFIX Рисунок 14 - Отношение полной категоризации Рисунок 15 - Отношение неполной категоризации Рисунок 16 - Пример модели предметной области в нотации IDEF1X На рисунке 16 приведена диаграмма даталогической модели данных. Поэтому присутствуют внешние ключи FK Признаки отображения ER-диаграммой различных моделей данных ЛЕКЦИЯ 6-7 РАЗРАБОТКА РЕЛЯЦИОННОЙ ДАННЫХ Понятие реляционного отношения МОДЕЛИ Один из самых естественных способов представления данных – это двумерная таблица. Она привычна для пользователя, понятна и обозрима. Как люба сетевая структура с некоторой избыточностью может быть разложена на совокупность древовидных структур, так и любое представление данных может быть сведено к двумерным плоским файлам (таблицам). Таблицы строятся таким образом, что информация о связях между элементами данных не теряется. Сами таблицы являются двумерными массивами и описываются математически на основе понятий реляционной алгебры. Свойства таблиц: 1. Каждый элемент таблицы представляет собой элемент данных, повторяющиеся группы отсутствуют. 2. Все столбцы в таблице однородны. 3. Столбцам присвоены имена. 4. В таблице нет двух одинаковых строк. 5. В операциях с таблицами ее строки и столбцы могут просматриваться в любом порядке и в любой последовательности безотносительно к их информационному содержанию. Таблицы такого вида называются отношениями. Математически отношение определяется следующим образом: Пусть даны N множеств D1,D2,…,DN, тогда R есть отношение над этими множествами, если R есть множество упорядоченных n-кортежей вида d1,d2,…,dN , где d1 – элемент из D1, d2 – элемент из D2, dN – элемент из DN. D1, D2,…,DN называются доменами отношения R. Пример приведен на рис. 1. Рисунок 1 – Пример отношения Здесь 4 домена: D1 – множество символьных строк (Имя домена – Фамилия); D2 – множество символьных строк, (Имя домена – Имя); D3 – множество символьных строк, (Имя домена – Отчество); D4 – множество символьных строк, (Имя домена – Группа). Отношение R состоит из 3 кортежей. Каждый кортеж из 4 элементов, которые выбираются каждый из своего домена. С точки зрения обработки данных отношение можно рассмотреть в следующих аналогиях (рис.2). Четыре домена соответствуют четырем элементам реального мира: ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ГРУППА. Отношение принимает вид таблицы или файла, где кортежи – строки таблицы или записи в файле. Имена столбцов называются атрибутами, а индивидуальное значение, появляющееся в отдельных кортежах – значением атрибута. Число столбцов в отношении называется степенью. Число кортежей – мощностью. Реляционная база данных определяется как совокупность отношений, содержащих всю информацию хранимую в БД. Рисунок 2 – Отношения в обработке данных Отношение имеет имя, которое отличает его от имён всех других отношений. Атрибутам реляционного отношения назначаются имена, уникальные в рамках отношения. Обращение к отношению происходит по его имени, а обращение к атрибуту – по имени отношения и имени атрибута. Атрибут может быть обязательным и необязательным. Значение обязательного атрибута должно быть определено в момент внесения данных в БД. Если атрибут необязательный, то для таких случаев предусмотрено специальное значение – NULL, которое можно интерпретировать как «неизвестное значение». Значение NULL не привязано к определённому типу данных, т.е. может назначаться данным любых типов. Каждое отношение в БД хранится в отдельном файле. Записи файлов имеют одинаковый формат. СУБД сохраняет отношение в виде индексного файла, где индекс представляет собой как правило первичный ключ отношения. Первичный ключ (Primary Key) – атрибут или набор атрибутов, которые могут быть использованы для однозначной идентификации конкретного кортежа. Значение первичного ключа должно быть уникальным (unique) и обязательным (not null). Для связей между отношениями используются внешние ключи. Внешний ключ (foreign key) – это атрибут подчинённого (дочернего) отношения, который является копией первичного (primary key) или уникального (unique) ключа родительского отношения. Фактически внешние ключи логически связывают экземпляры сущностей разных типов (родительской и подчинённой сущностей). Внешний ключ – это ограничение целостности, в соответствии с которым множество значений внешнего ключа является подмножеством значений первичного или уникального ключа родительской таблицы. Ограничение целостности по внешнему ключу проверяется в двух случаях: • при добавлении записи в подчинённую таблицу СУБД проверяет, что в родительской таблице есть запись с таким же значением первичного ключа; • при удалении записи из родительской таблицы СУБД проверяет, что в подчинённой таблице нет записей с таким же значением внешнего ключа. Ограничения целостности должны поддерживаться СУБД. Для соблюдения целостности сущностей достаточно гарантировать отсутствие в отношении кортежей с одним и тем же значением первичного ключа. Со ссылочной целостностью значительно сложнее. Необходимо следить за тем, чтобы не появлялись некорректные значения внешних ключей при обновлении отношений (например, заказы несуществующих клиентов). При удалении кортежа существует три подхода, позволяющие поддерживать ссылочную целостность: − запрещается производить удаление кортежа, на который существуют ссылки (либо сначала удалить ссылающиеся кортежи, либо изменить значения их внешнего ключа); − при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа становится неопределённым; − при удалении кортежа из отношения, на которое ведётся ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи (каскадное удаление). Большинство современных СУБД способны контролировать соблюдение правила ссылочной целостности. Для этой цели используются различные объекты баз данных (ссылочные ограничения и правила, триггеры и др.). Схема отношения (заголовок отношения) представляет собой список имен атрибутов. Например, СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ГРУППА, АДРЕС). Множество собственно кортежей отношения часто называют содержимым (телом) отношения. Список, в котором указываются имена реляционных таблиц с перечислением их атрибутов (первичные ключи подчёркнуты) и определений внешних ключей, называется реляционной схемой базы данных. Результат проектирования БД оформляется следующим образом: Название БД: ____________________________ Спецификация отношений: Имя отношения (перечень атрибутов) Спецификация атрибутов: Имя Назначение Тип Допустимые Примечание атрибута атрибута значения Пример: Название БД: «Учет данных о студентах» Спецификация отношений: СТУДЕНТ (ШИФР СТУДЕНТА, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ПОЛ, ДАТА РОЖДЕНИЯ, МЕСТО РОЖДЕНИЯ, АДРЕС, ГРУППА) Первичный ключ отношения: ШИФР СТУДЕНТА Внешние ключи отношения: ГРУППА Спецификация атрибутов: Имя атрибута ШИФР СТУДЕНТА Назначение атрибута Хранит шифр студента (номер зачетной книжки) ФАМИЛИЯ Хранит фамилию. студента ИМЯ Хранит имя студента ОТЧЕСТВО Хранит отчество студента ПОЛ Хранит код пол ко ОКИН ДАТА Хранит дату РОЖДЕНИЯ рождения МЕСТО Хранит место РОЖДЕНИЯ рожения ГРУППА Хранит группы, которой студент Тип Формат Строка Char (7) Строка Char (60) Строка Char (30) Строка Char (30) Числ. INT(1) Дата Data Строка Char (90) шифр Строка в учится Char (10) Допустимые значения Примечание Первичный ключ 1 – мужской 2 - женский Частично структурированное Внешний ключ Получение реляционных отношений из ER – диаграмм Процесс получения реляционных отношений основывается на учете связей между сущностями диаграммы в схеме отношения. Связанность сущность обеспечивается включением в реляционное отношение первичных ключей сущностей. Правила формируются в зависимости от вида бинарной связи и класса принадлежности сущности. Правило 1: Если степень бинарной связи равна 1:1 и класс принадлежности обеих сущностей является обязательным, то требуется только одно отношение, объединяющее атрибуты двух сущностей. Первичным ключом этого отношения может быть ключ любой из двух сущностей. Рисунок 3 – Пример бинарной связи 1:1 обе сущности обязательного класса принадлежности РАБОТНИК (ТАБ.НОМЕР, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ПОЛ, ДАТА РОЖДЕНИЯ, МЕСТО РОЖДЕНИЯ, НОМЕР, СЕРИЯ, ДАТА ВЫДАЧИ, КЕМ ВЫДАН) Первичный ключ: ТАБ.НОМЕР Следует помнить, что при реализации этого правила закладывается аномалия в схеме реляционного отношения по третьей нормальной форме. Такие реляционные отношения должны быть более внимательно проанализированы на этапе нормализации. Правило 2: Если степень бинарной связи равна 1:1 и класс принадлежности одной сущности является обязательным, а другой необязательным , то необходимо построение двух отношений. Под каждую сущность необходимо выделить по одному отношению, при этом ключ сущности должен служить первичным ключом для соответствующего отношения. Ключ сущности, для которой класс принадлежности является необязательным, добавляется в качестве атрибута в отношение, выделенное для сущности с обязательным классом принадлежности и описывается как внешний ключ. Рисунок 4 – Пример бинарной связи 1:1 одна сущность обязательного класса принадлежности, другая необязательного РАБОТНИК (ТАБ.НОМЕР, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ПОЛ, ДАТА РОЖДЕНИЯ, МЕСТО РОЖДЕНИЯ) Первичный ключ: ТАБ.НОМЕР АТТЕСТАТ (НОМЕР, СЕРИЯ, ДАТА ВЫДАЧИ, КЕМ ВЫДАН, ТАБ.НОМЕР) Первичный ключ: НОМЕР, СЕРИЯ Внешний ключ: ТАБ.НОМЕР Правило 3: Если степень бинарной связи равна 1:1 и класс принадлежности обеих сущностей является необязательным, то необходимо построение трех отношений: по одному для каждой сущности, ключи которых служат в качестве первичных ключей соответствующих отношений, и одно для связи. Среди своих атрибутов отношение, выделенное для связи, будет иметь ключи обеих сущностей, также они будут специфицироваться как внешние ключи. Первичным ключом третьего отношения может быть ключ любой из двух сущностей. Рисунок 5 – Пример бинарной связи 1:1 обе сущности необязательного класса принадлежности ГРАЖДАНИН (НОМЕР СЕРИИ, НОМЕР ПАСПОРТА, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО) Первичный ключ: НОМЕР ПАСПОРТА, СЕРИЯ ПАСПОРТА БЛАНКИ ОМС (НОМЕР, СТРАХОВАЯ КОМПАНИЯ) Первичный ключ: НОМЕР ОМС ВЫДАН (НОМЕР, НОМЕР СЕРИИ, НОМЕР ПАСПОРТА, ДАТА ВЫДАЧИ) Первичный ключ: НОМЕР Внешний ключ: НОМЕР СЕРИИ, НОМЕР ПАСПОРТА При построении отношений для связи 1:М учитывается класс принадлежности М-связанной сущности. Класс принадлежности 1-связанной сущности на конечный результат не влияет. Правило 4: Если степень бинарной связи 1:М и класс принадлежности М-связанной сущности является обязательным, то достаточным является использование двух отношений, по одному на каждую сущность. При условии, что ключ каждой сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связанной сущности должен быть добавлен как атрибут в отношение, отведенной для М-связанной сущности в качестве внешнего ключа. Рисунок 6 – Пример бинарной связи 1:М, М-связанная сущность обязательного класса принадлежности РАБОТНИК (ТАБ.НОМЕР, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ПОЛ, ДАТА РОЖДЕНИЯ, МЕСТО РОЖДЕНИЯ) Первичный ключ: ТАБ.НОМЕР ДИПЛОМ (НОМЕР, СЕРИЯ, УЧЕБНОЕ ЗАВЕДЕНИЕ, ГОД ВЫДАЧИ, КВАЛИФИКАЦИЯ, КОД ОКСО, ТАБ. НОМЕР) Первичный ключ: НОМЕР, СЕРИЯ Внешний ключ: ТАБ. НОМЕР Правило 5: Если степень бинарной связи 1:М и класс принадлежности М-связанной сущности является необязательным, то достаточным является использование трех отношений, по одному на каждую сущность, причем ключ каждой сущности служит первичным ключом соответствующего отношения, и одного отношения для связи. Отношение для связи должно иметь среди своих атрибутов первичный ключ каждой сущности (внешние ключи). Первичным ключом третьего отношения выбирается первичный ключ Мсвязанной сущности. Рисунок 7 – Пример бинарной связи 1:М, М-связанная сущность необязательного класса принадлежности РАБОТНИК (ТАБ.НОМЕР, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ПОЛ, ДАТА РОЖДЕНИЯ, МЕСТО РОЖДЕНИЯ) Первичный ключ: ТАБ.НОМЕР ПРИКАЗ (НОМЕР ПРИКАЗА, ДАТА, ТЕМА) Первичный ключ: НОМЕР ПРИКАЗА РАБОТА РАБ-КА (НОМЕР ПРИКАЗА, ТАБ.НОМЕР) Первичный ключ: НОМЕР ПРИКАЗА Внешний ключ: ТАБ. НОМЕР При построении отношений для связи М:М класс принадлежности сущностей на конечный результат не влияет. Правило 6: Если степень бинарной связи равна М:М, то необходимо три отношения: по одному на каждую сущность с первичными ключами от соответствующих сущностей, и одно отношение для связи. Отношение для связи должно иметь среди своих атрибутов ключ каждой сущности как внешние ключи. Первичный ключ третьего отношения составной из первичных ключей двух сущностей. Рисунок 8 – Пример бинарной связи М:М РАБОТНИК (ТАБ.НОМЕР, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ПОЛ, ДАТА РОЖДЕНИЯ, МЕСТО РОЖДЕНИЯ) Первичный ключ: ТАБ.НОМЕР СТРАНА (КОД СТРАНЫ, НАИМЕНОВАНИЕ СТРАНЫ) Первичный ключ: КОД СТРАНЫ ГРАЖДАНСТВО (ТАБ.НОМЕР, КОД СТРАНЫ, ПАСПОРТ ИНОЙ СТРАНЫ, ДАТА ПОЛУЧЕНИЯ) Первичный ключ: ТАБ.НОМЕР, КОД СТРАНЫ Внешний ключ: ТАБ.НОМЕР КОД СТРАНЫ Нормализация реляционных отношений Аномалии в БД Определение избыточности данных. При решении этой задачи необходимо определить, что является избыточностью, а что необходимым дублированием. ТЕМА ШИФР ТЕМЫ ИСПОЛНИТЕЛЬ 111 Исп-1 112 Исп-2 113 Исп-1 114 Исп-1 В поле исполнитель на первый взгляд наблюдается избыточность. Если привести данные к виду ШИФР ТЕМЫ ИСПОЛНИТЕЛЬ 111 Исп-2 112 Исп-1 113 --114 --То если удалить запись 112 не будет известен исполнитель тем 113 и 114. Таким образом, это пример не избыточности данных, а необходимого не избыточного дублирования. Если отношение ТЕМА расширить атрибутом ТЕЛЕФОН ШИФР ТЕМЫ ИСПОЛНИТЕЛЬ ТЕЛЕФОН Мы получим пример избыточного отношения по атрибуту ТЕЛЕФОН. Достаточно хранить один экземпляр телефона для каждого исполнителя. В этом случае для устранения избыточности необходимо получить два отношения. ТЕМА (ШИФР_ТЕМЫ, ИСПОЛНИТЕЛЬ) ТЕЛ._ИСПОЛНИТЕЛЯ (ИСПОЛНИТЕЛЬ, ТЕЛЕФОН) Аномалии вставки, удаления и обновления. Вставка. При добавлении новых экземпляров отношения может возникнуть ситуация , когда некоторые из атрибутов не имеют значения ( они могут принимать значение 0 для арифметических данных или пробелы для символьных данных, если событие еще не наступило). При обработке запросов по таким данным будут выдаваться искаженные результаты. Обновление. Если имеет место большая избыточность данных, то к одному и тому же объекту может относиться несколько кортежей. В этом случае изменения должны вноситься во все записи, относящиеся к этому объекту. Удаление. Аномалия сводится к тому, что при необходимости удаления некоторых значение атрибутов в случае определенной избыточности данных, удаляется вся запись. Нормальные формы Функциональная зависимость Процесс разбиения отношения с целью уменьшения вероятности возникновения аномалий манипулирования данными называется нормализацией. Нормализация осуществляется методом декомпозиции. Логической и методической основой декомпозиции является концепция функциональной зависимости между атрибутами в рассматриваемом отношении. Определение функциональной зависимости: Если даны два атрибута А и В, то говорят, что В функционально зависит от А, если для каждого значения А существует ровно одно связанное с ним значение В в любой момент времени: А→В При этом А и В могут быть не только атомарными, но и составными. На практике это сводится к тому, что функциональная зависимость В от А означает, что если в любой момент времени известно значение А, то можно одновременно найти значение атрибута В. Примером функциональной зависимости может служить первичный ключ, который определяет значения неосновных атрибутов. Отсутствие функциональной зависимости А В РАБОТНИК (ТАБ.НОМЕР, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ПОЛ, ДАТА РОЖДЕНИЯ, МЕСТО РОЖДЕНИЯ) ТАБ.НОМЕР → ФАМИЛИЯ ИМЯ ОТЧЕСТВО ПОЛ ДАТА РОЖДЕНИЯ МЕСТО РОЖДЕНИЯ Определение функциональной зависимости через термины реляционной алгебры: Пусть R (A1, A2, …, AN) – схема отношения, X и Y – подмножества (A1,A2,…,AN). Говорят, что Х функционально определяет Y (X→Y) , если в любом отношении R, являющемся текущим значением R, не может содержаться два кортежа, компоненты которых совпадают по всем атрибутам, принадлежащим множеству Х, но не совпадают по одному или более атрибутам принадлежащим множеству Y. Определение полной функциональной зависимости: Если А → В есть функциональная зависимость и В не зависит функционально от любого подмножества А, то говорят что В функционально полно зависит от А . А представляет собой детерминант А →→ В. ГРАЖДАНСТВО (ТАБ.НОМЕР, КОД СТРАНЫ, ПАСПОРТ ИНОЙ СТРАНЫ, ДАТА ПОЛУЧЕНИЯ) ТАБ.НОМЕР, КОД СТРАНЫ→→ ПАСПОРТ ИНОЙ СТРАНЫ ДАТА ПОЛУЧЕНИЯ Т.е. первичный ключ реляционного отношения функционально полно определяет неосновные атрибуты отношения. Единственный способ определения функциональной зависимости для схемы отношения заключается в тщательном анализе семантики атрибутов этого отношения. В этом смысле зависимости являются фактически отображением связей, существующих в реальном мире. Исходя из функциональной зависимости можно определить как первичные, так и возможные ключи. Наличие тех или иных зависимостей в схеме отношения определяет степень ее нормализации. Для реляционных моделей данных выделяют наиболее значимые четыре нормальные формы (1НФ, 2НФ, 3НФ, 4НФ) и еще одну дополнительную нормальную форму Бойса-Кодда (НФБК). Другие более высокие нормальные формы являются значимыми для объектно-ориентированных моделей. Определение 1 НФ: Отношение находится в 1 НФ, если каждый его элемент имеет и всегда будет иметь атомарное строение. В этом случае реляционное отношение представлено в виде множества неповторяющихся кортежей. Эта форма является необходимой для работы языков запросов СУБД. Формально само определение реляционного отношения подразумевает удовлетворение 1 нормальной форме. Представление атрибута как частично структурированного, например АДРЕС, не является аномалией по 1НФ. Определение 2 НФ: Отношение задано во 2НФ, если оно является отношением в 1НФ, и каждый атрибут не являющийся первичным атрибутом в этом отношении, функционально полно зависит от любого возможного (альтернативного) ключа этого отношения. Первичным называется атрибут, которые входят хотя бы в один из возможных ключей. Если все возможные ключи отношения содержат по одному атрибуту, т.е. являются несоставными, то это отношение задано во 2НФ, т.к. в этом случае все атрибуты не являющиеся первичными полностью зависят от возможных ключей. Если ключи составные, отношение заданное в 1НФ может не быть отношением во 2НФ. РАБОТНИК (ТАБ.НОМЕР, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ПОЛ, ДАТА РОЖДЕНИЯ, МЕСТО РОЖДЕНИЯ) Первичный ключ является несоставным, возможных ключе нет, следовательно отношение находится во 2НФ. ЗНАНИЕ ИН.ЯЗЫКОВ (ТАБ.НОМЕР, КОД ИН.ЯЗЫКА, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, НАЗВАНИЕ ЯЗЫКА, СТЕПЕНЬ ЗНАНИЯ) Первичный ключ: ТАБ.НОМЕР, КОД ИН.ЯЗЫКА ТАБ.НОМЕР → ФАМИЛИЯ ИМЯ ОТЧЕСТВО КОД ИН.ЯЗЫКА→ НАЗВАНИЕ ЯЗЫКА ТАБ.НОМЕР, КОД ИН.ЯЗЫКА→→ СТЕПЕНЬ ЗНАНИЯ В отношении ЗНАНИЕ ИН.ЯЗЫКОВ выявлены зависимости неосновных атрибутов от элементов первичного ключа. Следовательно, реляционное отношения не находится во 2НФ. Для приведения реляционного отношения к нормальной форме требуется выполнить его декомпозицию в соответствии в выявленными функциональными зависимостями. РАБОТНИК (ТАБ.НОМЕР, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО) Первичный ключ: ТАБ.НОМЕР КОДИФИКАТОР ИН.ЯЗЫКОВ (КОД ИН.ЯЗЫКА, НАЗВАНИЕ ЯЗЫКА) Первичный ключ: КОД ИН.ЯЗЫКА ЗНАНИЕ ИН.ЯЗЫКОВ (ТАБ.НОМЕР, КОД ИН.ЯЗЫКА, СТЕПЕНЬ ЗНАНИЯ) Первичный ключ: ТАБ.НОМЕР, КОД ИН.ЯЗЫКА Внешний ключ: ТАБ.НОМЕР КОД ИН.ЯЗЫКА Практически выявленные аномалии свидетельствуют о недостаточно внимательной нормализации сущностей на этапе разработки модели предметной области типа «Сущность-Связь». Выделенное реляционное отношение РАБОТНИК уже будет присутствовать в даталогической модели БД. Определение 3 НФ: Отношение задано в 3 НФ, если оно задано во 2 НФ и каждый атрибут из отношения, не являющийся первичным, нетранзитивно зависит от каждого возможного ключа. Пусть А, В, С – атрибута реляционного отношения. Если С зависит от В, а В – от А, то С зависит от А. Если при этом обратное соответствие неоднозначно (т.е. А не зависит от В или В не зависит от С), то говорят, что С транзитивно зависит от А. Преобразование к 3НФ состоит в разбиении исходного отношения на два: А→ В В →С Функциональная зависимость А→ С исключается. Третья нормальная форма является достаточной для нормализации реляционной модели данных. РАБОТНИК (ТАБ.НОМЕР, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ПОЛ, ДАТА РОЖДЕНИЯ, МЕСТО РОЖДЕНИЯ, КОД ОКАТО МЕСТА РОЖДЕНИЯ) ТАБ.НОМЕР → ФАМИЛИЯ ИМЯ ОТЧЕСТВО ПОЛ ДАТА РОЖДЕНИЯ КОД ОКАТО МЕСТА РОЖДЕНИЯ КОД ОКАТО МЕСТА РОЖДЕНИЯ→ МЕСТО РОЖДЕНИЯ Таким образов выявлены транзитивные зависимости ТАБ.НОМЕР → КОД ОКАТО МЕСТА РОЖДЕНИЯ→ МЕСТО РОЖДЕНИЯ Приведение реляционного отношения к 3НФ РАБОТНИК (ТАБ.НОМЕР, ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ПОЛ, ДАТА РОЖДЕНИЯ, КОД ОКАТО) Первичный ключ: ТАБ.НОМЕР Внешний ключ: КОД ОКАТО КОДИФИКАТОР ОКАТО (КОД ОКАТО, МЕСТО РОЖДЕНИЯ) Первичный ключ: КОД ОКАТО Определение НФБК: Отношение находится в НФБК, если каждый детерминант отношения является возможным ключом. НФБК является дополнительной проверкой правильной нормализации по предыдущим нормальным формам. Также используется для нормализации универсального реляционного отношения. Определение 4 НФ: Схема реляционного отношения задана в 4 НФ, если при существовании многозначной зависимости Х определяет Y, где Y не является пустым множеством, Y не принадлежит Х, причем ХY состоит не из всех атрибутов отношения, также существует зависимость Х → А для любого атрибута А отношении. СЛУЖАЩИЙ СЛУЖАЩИЙ ИН.ЯЗЫК ДОЛЖНОСТЬ ГОД Иванов Английский инженер 1996 Иванов Немецкий инженер 1996 Иванов Немецкий Ст.инженер 1998 Иванов Английский Ст.инженер 1998 Сидоров Французский Вед.инженер 1998 Сидоров Французский Руководитель 1999 Сидоров Испанский Вед.инженер 1999 Сидоров Испанский Руководитель 1999 СЛУЖАЩИЙ→ ИН.ЯЗЫК СЛУЖАЩИЙ →ДОЛЖНОСТЬ Для устранения избыточности выполняет разбиение ИН.ЯЗЫК СЛУЖАЩИЙ ИН.ЯЗЫК Сидоров Французский Сидоров Испанский Иванов Английский Иванов Немецкий ДОЛЖНОСТЬ СЛУЖАЩИЙ Сидоров Сидоров Иванов Иванов ДОЛЖНОСТЬ Вед.инженер Руководитель Инженер Ст.инженер ГОД 1998 1999 1996 1998 При разработки реляционной модели данных исходя из инфологической модели предметной области типа «Сущность-Связь» аномалии по 4НФ быть не может. Т.К. рассматриваемая множественность вытекает из логики бинарной связи М:М. Как рассматривалось выше, по правилу 6, эта бинарная связь преобразуется к трем реляционным отношениям, которые исключат ненормальность по 4НФ. Алгоритм декомпозиции Предлагаемый алгоритм целесообразно использовать, если в БД учитывается порядка 20-30 атрибутов. Для баз данных используемых в реальных информационных такое практически невозможно. Так как в основу алгоритма полагается удовлетворение НФБК. 1. Разработка универсального отношения для БД. Универсальное реляционное отношение представляет собой совокупность атомарных атрибутов составляющих БД. В случае повторяющихся групп, они оформляются путем введения избыточности данных. СЛУЖАЩИЙ ШИФР ФАМИЛИЯ ОБРАЗОВАНИЕ ОТДЕЛ ДОЛЖНОСТЬ 0341 Иванов высшее 31 Инженер 0341 Иванов высшее 31 Ст. инж-р 0341 Иванов высшее 31 Вед. Инж-р Атрибуты ОТДЕЛ и ДОЛЖНОСТЬ представляют повторяющуюся группу. Такая корректно заполненная таблица представляет собой универсальное реляционное отношение. 2. Определение всех функциональных зависимостей между атрибутами отношения. 3. Определение того, что находится ли отношение в НФБК. Если «ДА» проектирование завершается, если «НЕТ», отношение должно быть разложено на два отношения. Декомпозиция выполняется следующим образом: Пусть отношение R (A, B, C, D, E…) не приведено к нормальной форма Бойса- Кодда. Определяется функциональная зависимость C → D, про которую известно, что она является причиной того, что отношение не находится в НФБК. С является детерминантом, но не является возможным ключом. Создаются два новых отношения. R1 ( A, B, C, E…) R2 ( C,D ) Отношение R2 называется проекцией отношения R. Этот метод декомпозиции называется декомпозицией без потерь. ЛЕКЦИЯ 8 СОВРЕМЕННЫЕ ПРОБЛЕМЫ ЭКСПЛУАТАЦИИ И РАЗВИТИЯ ТЕХНОЛОГИИ БАЗ ДАННЫХ Хранилища данных В настоящее время однозначного определения ХД не существует, из-за того что разработано большое количество различных архитектур и технологий ХД, а сами хранилища используются для решения самых разнообразных задач. Хранилище данных — разновидность систем хранения, ориентированная на поддержку процесса анализа данных, обеспечивающая целостность, непротиворечивость и хронологию данных, а также высокую скорость выполнения аналитических запросов. Важнейшим элементом ХД является семантический слой — механизм, позволяющий аналитику оперировать данными посредством терминов предметной области. Семантический слой дает пользователю возможность сосредоточиться на анализе и не задумываться о механизмах получения данных. Типичное ХД существенно отличается от обычных систем хранения данных. Главным отличием являются цель использования – накопление данных для анализа. Другое отличие заключается в динамике изменения данных. Базы данных в OLTP-системах характеризуются очень высокой динамикой изменения записей из-за повседневной работы большого числа пользователей (откуда, кстати, велика вероятность появления противоречий, ошибок, нарушения целостности данных и т.д.). Что касается ХД, то данные из него не удаляются, а пополнение происходит в соответствии с определенным регламентом (раз в час, день, неделю, в определенное время). Основные требования к ХД: • высокая скорость получения данных из хранилища; • автоматическая поддержка внутренней непротиворечивости данных; • возможность получения и сравнения срезов данных; • наличие удобных средств для просмотра данных в хранилище; • обеспечение целостности и достоверности хранящихся данных. Основные положения концепции ХД Билл Инмон4 дал определение и сформулировал основные положения ХД. 4 Билл Инмон, технический директор компании Prism Solutions. в начале 1990-х гг. опубликовал ряд работ, ставших основополагающими для последующих исследований в области аналитических систем. ХД – предметно-ориентированный, интегрированный, неизменяемый и поддерживающий хронологию набор данных, предназначенный для обеспечения принятия управленческих решений. Рисунок 1 – Интеграция хранилищ данных в информационноаналитические системы В основе концепции ХД лежат следующие положения: интеграция и согласование данных из различных источников, таких как обычные системы оперативной обработки, базы данных, учетные системы, офисные документы, электронные архивы, расположенные как внутри предприятия, так и во внешнем окружении; разделение наборов данных, используемых системами выполнения транзакций и СППР. Под предметной ориентированностью в данном случае подразумевается, что ХД должно разрабатываться с учетом специфики конкретной предметной области, а не аналитических приложений, с которыми его предполагается использовать. Структура ХД должна отражать представления аналитика об информации, с которой ему приходится работать. Интегрированность означает, что должна быть обеспечена возможность загрузки в ХД информации из источников, поддерживающих различные форматы данных и созданных в различных приложениях — учетных системах, базах данных, электронных таблицах и других офисных приложениях, поддерживающих структурированность данных (например, текстовые файлы с разделителями). При этом данные, допускающие различный формат (например, числа, дата и время), в процессе загрузки должны быть преобразованы к единому представлению. Необходимо проверять загружаемые данные на целостность и непротиворечивость и обеспечить необходимый уровень их обобщения (агрегирования). Объем данных в хранилище должен быть достаточным для эффективного решения аналитических задач, поэтому в ХД может накапливаться информация за несколько лет и даже десятилетий. Принцип неизменчивости предполагает, что, в отличие от обычных систем оперативной обработки данных, в ХД данные после загрузки не должны подвергаться каким-либо изменениям, за исключением добавления новых данных. И наконец, поддержка хронологии означает соблюдение порядка следования записей, для чего в структуру ХД вводятся ключевые атрибуты Дата и Время. Кроме того, если физически упорядочить записи в хронологическом порядке, например в порядке возрастания атрибута Дата, можно уменьшить время выполнения аналитических запросов. Использование концепции ХД в СППР и анализе данных способствует достижению таких целей, как: • своевременное обеспечение аналитиков и руководителей всей информацией, необходимой для выработки обоснованных и качественных управленческих решений; • создание единой модели представления данных в организации; • создание интегрированного источника данных, предоставляющего удобный доступ к разнородной информации и гарантирующего получение одинаковых ответов на одинаковые запросы из различных аналитических приложений. Задачи, решаемые ХД: • выбор структуры хранения данных, обеспечивающей высокую скорость выполнения запросов и минимизацию объема оперативной памяти; • первоначальное заполнение и последующее пополнение хранилища; • обеспечение единой методики работы с разнородными данными и создание удобного интерфейса пользователя. Круг задач интеллектуального анализа данных весьма широк, а сами задачи существенно различаются по уровню сложности. Поэтому в зависимости от специфики решаемых задач и уровня их сложности архитектура ХД и модели данных, используемых для их построения, могут различаться. Обобщенная концептуальная схема ХД представлена на рис. 17. Рисунок 2 – Концептуальная схема ХД Согласно схеме данные извлекаются из различных источников и загружаются в ХД, которое содержит как собственно данные, представленные в соответствии с некоторой моделью, так и метаданные. Данные в ХД хранятся как в детализированном, так и в агрегированном виде. Данные в детализированном виде поступают непосредственно из источников данных и соответствуют элементарным событиям, регистрируемым OLTP-системами. Такими данными могут быть ежедневные продажи, количество произведенных изделий и т.д. Это неделимые значения, попытка дополнительно детализировать которые лишает их логического смысла. Многие задачи анализа (например, прогнозирование) требуют использования данных определенной степени обобщения. Например, суммы продаж, взятые по дням, могут дать очень неравномерный ряд данных, что затруднит выявление характерных периодов, закономерностей или тенденций. Однако, если обобщить эти данные в пределах недели или месяца и взять сумму, среднее, максимальное и минимальное значения за соответствующий период, то полученный ряд может оказаться более информативным. Процесс обобщения детализированных данных называется агрегированием, а сами обобщенные данные — агрегированными (иногда — агрегатами). Обычно агрегированию подвергаются числовые данные (факты), они вычисляются и содержатся в ХД вместе с детализированными данными. Поскольку один и тот же набор детализированных данных может породить несколько наборов агрегированных данных с различной степенью обобщения, объем ХД возрастает, иногда существенно. Метаданные5 в широком смысле необходимы для описания значения и свойств информации с целью лучшего ее понимания, использования и управления ею. Пример: В любой книге, помимо собственно текста, содержится значительное количество дополнительной информации. Цель ее заключается в том, чтобы, во-первых, помочь читателю быстрее ознакомиться с содержимым книги и осмыслить его, во-вторых, описать структуру книги для более эффективного поиска нужной информации. Для решения первой задачи служат такие элементы, как аннотация, комментарии, глоссарий, примечания и т.д. Для поиска нужной информации используются оглавление, названия глав, параграфов и разделов, номера страниц, колонтитулы, предметный указатель и т.д. Кроме этого, читателю могут понадобиться сведения об авторах или об издательстве. Вся эта информация, которая не является частью книги, а служит для повышения эффективности работы с ней, и представляет собой метаданные. В библиотеке метаданные применяются для поиска нужных изданий и отслеживания их перемещений, например, систематический или алфавитный каталоги, в которых используются названия книг, фамилии авторов, год издания и т.д. Таким образом, метаданные имеют очень большое значение при работе с различного рода информацией. С точки зрения IT-технологий метаданные — любая информация, необходимая для анализа, проектирования, построения, внедрения и применения компьютерной информационной системы. Одно из основных назначений метаданных — повышение эффективности поиска. Поисковые запросы, использующие метаданные, делают возможным выполнение сложных операций по фильтрации и отбору данных. Если рассматривать понятие «метаданные» в контексте технологии ХД, то его можно определить следующим образом. Метаданные — высокоуровневые средства отражения информационной модели и описания структуры данных, используемой в ХД. Метаданные должны содержать описание структуры данных хранилища и структуры данных импортируемых источников. Метаданные хранятся отдельно от данных в так называемом репозитарии метаданных. Метаданные являются ключевым фактором эффективности ХД. Они содержат всю информацию, необходимую для извлечения, преобразования и загрузки данных из различных источников, а также для последующего использования и интерпретации данных, содержащихся в ХД. Можно выделить два уровня метаданных — технический (административный) и бизнес-уровень. Технический уровень содержит метаданные, необходимые для обеспечения функционирования хранилища (статистика загрузки данных и их использования, описание модели данных и 5 «Метаданные» (от греч. meta и лат. data) буквально переводится как «данные о данных» т.д.). Бизнес-метаданные обеспечивают пользователю возможность концентрироваться на процессе анализа, а не на технических аспектах работы с хранилищем; они включают бизнес-термины и определения, которыми привык оперировать пользователь. Фактически бизнес-метаданные представляют собой описание предметной области, для работы в которой создается аналитическая система или ХД. К формированию бизнес-метаданных должны активно привлекаться эксперты и аналитики, которые впоследствии и будут использовать систему для получения аналитических отчетов. Бизнес-метаданные описывают объекты предметной области, информация о которых содержится в ХД, — атрибуты объектов и их возможные значения, соответствующие поля в таблицах и т.д. Бизнесметаданные образуют так называемый семантический слой. Пользователь оперирует близкими ему терминами предметной области: товар, клиент, продажи, покупки и т.д., а семантический слой транслирует бизнес-термины в низкоуровневые запросы к данным в хранилище. Спектр аналитических задач очень широк. Соответственно, и методики применения ХД для решения тех или иных задач весьма разнообразны. Тем не менее можно выделить три основных подхода к использованию ХД: • регулярные отчеты — подготовка отчетов стандартных форм, получаемых многократно с определенной периодичностью; • нерегламентированные запросы — возможность получать ответы на нестандартные, сформированные «по требованию» вопросы; • интеллектуальный анализ данных — поддержка процесса интеллектуального анализа больших массивов данных с целью выявления скрытых закономерностей, структур и объектов, построения моделей, прогнозов и т.д. Архитектуры ХД В настоящее время разработано несколько архитектур хранилищ: Реляционные ХД – используют классическую реляционную модель, характерную для оперативных регистрирующих OLTP-систем. Данные хранятся в реляционных таблицах, но образуют специальные структуры, эмулирующие многомерное представление данных. Такая технология обозначается аббревиатурой ROLAP — Relational OLAP; Многомерные ХД – реализуют многомерное представление данных на физическом уровне в виде многомерных кубов. Данная технология получила название MOLAP — Multidimensional OLAP; Гибридные ХД – сочетают в себе свойства как реляционной, так и многомерной модели данных. В гибридных ХД детализированные данные хранятся в реляционных таблицах, а агрегаты — в многомерных кубах. Такая технология построения ХД называется HOLAP — Hybrid OLAP; Виртуальные ХД – не являются хранилищами данных в привычном понимании. В таких системах работа ведется с отдельными источниками данных, но при этом эмулируется работа обычного ХД. Иначе говоря, данные не консолидируются физически, а собираются непосредственно в процессе выполнения запроса. Кроме того, все ХД можно разделить на одноплатформенные и кроссплатформенные. Одноплатформенные ХД строятся на базе только одной СУБД, а кросс-платформенные могут строиться на базе нескольких СУБД. Многомерные хранилища данных Основное назначение многомерных хранилищ данных (МХД) — поддержка систем, ориентированных на аналитическую обработку данных, поскольку такие хранилища лучше справляются с выполнением сложных нерегламентированных запросов. Многомерная модель данных, лежащая в основе построения многомерных хранилищ данных, опирается на концепцию многомерных кубов, или гиперкубов. Они представляют собой упорядоченные многомерные массивы, которые также часто называют OLAP6-кубами. Технология OLAP представляет собой методику оперативного извлечения нужной информации из больших массивов данных и формирования соответствующих отчетов. Основы многомерного представления данных Сущность многомерного представления данных состоит в следующем. Большинство реальных бизнес-процессов описывается множеством показателей, свойств, атрибутов и т.д. Например, для описания процесса продаж могут понадобиться сведения о наименованиях товаров или их групп, о поставщике и покупателе, о городе, где производились продажи, а также о ценах, количествах проданных товаров и общих суммах. Кроме того, для отслеживания процесса во времени должен быть введен в рассмотрение такой атрибут, как дата. Если собрать всю эту информацию в таблицу, то она окажется сложной для визуального анализа и осмысления. Более того, она может оказаться избыточной: если, например, один и тот же товар продавался в один и тот же день в различных городах, то придется несколько раз повторить одно и то же соответствие «город — товар» с указанием различных суммы и количества. Все это способно окончательно запутать и сбить с толку любого, кто попытается извлечь из такой таблицы полезную информацию с целью анализа текущего состояния продаж и поиска путей оптимизации процесса торговли. Указанные проблемы возникают по одной простой причине: в плоской таблице хранятся многомерные данные. Проясним суть вопроса с помощью геометрической аналогии. Представьте себе трехмерную фигуру (например, тетраэдр или параллелепипед) и спроецируйте его на плоскость, а затем по полученной плоской проекции попытайтесь оценить форму и размеры исходной объемной фигуры. Сделать это будет трудно: во-первых, потеряна информация об одном измерении, а во-вторых, фигура теперь представлена в совершенно несвойственном ей плоском виде. 6 OLAP (On-Line Analytical Processing) — оперативная аналитическая обработка Примерно то же самое можно сказать об информации, представленной несколькими рядами данных. Каждый такой ряд (поле таблицы) можно рассматривать как своего рода информационное измерение, и тогда «плоская» таблица может быть интерпретирована как результат преобразования многомерной информационной структуры в совершенно несвойственную ей плоскую форму. Чтобы компенсировать потерю информации от исключения одного или нескольких измерений, приходится усложнять структуру таблицы, а это в большинстве случаев приводит к тому, что разобраться в ней становится очень сложно. Можно пойти другим путем — выполнить декомпозицию информации в несколько более простых таблиц, связать их некоторым набором отношений и перейти к реляционной модели, которую используют классические базы данных. Однако доказано, что реляционная модель не является оптимальной с точки зрения задач анализа, поскольку предполагает высокую степень нормализации, в результате чего снижается скорость выполнения запросов. Поэтому разработка многомерной модели представления данных, которая реализуется с помощью многомерных кубов, стала естественным шагом. В основе многомерного представления данных лежит их разделение на две группы — измерения и факты. Измерения — это категориальные атрибуты, наименования и свойства объектов, участвующих в некотором бизнес-процессе. Значениями измерений являются наименования товаров, названия фирм-поставщиков и покупателей, ФИО людей, названия городов и т.д. Измерения могут быть и числовыми, если какой-либо категории (например, наименованию товара) соответствует числовой код, но в любом случае это данные дискретные, то есть принимающие значения из ограниченного набора. Измерения качественно описывают исследуемый бизнес-процесс. Факты — это данные, количественно описывающие бизнес-процесс, непрерывные по своему характеру, то есть они могут принимать бесконечное множество значений. Примеры фактов — цена товара или изделия, их количество, сумма продаж или закупок, зарплата сотрудников, сумма кредита, страховое вознаграждение и т.д. Структура многомерного куба Многомерный куб можно рассматривать как систему координат, осями которой являются измерения, например Дата, Товар, Покупатель. По осям будут откладываться значения измерений — даты, наименования товаров, названия фирм-покупателей, ФИО физических лиц и т.д. В такой системе каждому набору значений измерений (например, «дата — товар — покупатель») будет соответствовать ячейка, в которой можно разместить числовые показатели (то есть факты), связанные с данным набором. Таким образом, между объектами бизнес-процесса и их числовыми характеристиками будет установлена однозначная связь. Принцип организации многомерного куба поясняется на рис. 18. В ячейке 1 будут располагаться факты, относящиеся к продаже цемента ООО «Спецстрой» 3 ноября, в ячейке 2 — к продаже плит ЗАО «Пирамида» 6 ноября, а в ячейке 3 — к продаже плит ООО «Спецстрой» 4 ноября. Рисунок 3 – Принцип организации многомерного куба Распределенные базы данных Распределенная база данных (Distributed Database – DDB) – это совокупность логически взаимосвязанных баз данных, распределенных в компьютерной сети. В распределенных системах база данных состоит из нескольких частей, которые называются фрагментами базы данных. Пример конфигурации распределенной базы данных представлен на рис. 4. Рисунок 4 – Топология распределенной системы Распределенная база данных предполагает физическое разделение на фрагменты и распределение их по локальным узлам сети данных. Главный критерий распределения данных в сети состоит в следующем: данные должны находиться там, где существует наибольшая частота обращения к ним. Такой подход обеспечивает быстрый и эффективный доступ к данным. Каждый фрагмент базы данных сохраняется на одном или нескольких узлах, соединенных между собой линиями связи, и каждый из них работает под управлением отдельной СУБД. Будучи фрагментом общего пространства данных, часть базы данных функционирует как полноценная локальная база данных. Управление выполняется локально и независимо от других узлов системы. Пользователи взаимодействуют с распределенной базой данных через приложения. Принципы построения РБД. – Минимизация интенсивности обмена данными (сетевого трафика) – Оптимальное размещение серверных и клиентских приложений в сети – Декомпозиция данных на часто и редко используемые сегменты (для правильной настройки репликации - размещение наиболее часто используемых данных на АРМ конечных пользователей) – Периодическое сохранение копий данных и выполнение действий по поддержке целостности распределенной информационной системы. К. Дейт сформулировал 12 требований к распределенной базе данных: 1. Локальная автономия. Означает, что управление данными на каждом из узлов распределенной системы выполняется локально. 2. Независимость узлов. Предполагает, что все узлы равноправны и независимы, а расположенные на них базы являются равноправными поставщиками данных в общее пространство данных. База данных на каждом из узлов включает полный собственный словарь данных и полностью защищена от несанкционированного доступа. 3. Непрерывность операций. Это возможность непрерывного доступа к данным в рамках распределенной базы данных вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах. 4. Прозрачность расположения. Пользователь, обращающийся к базе данных, ничего не должен знать о реальном, физическом размещении данных в узлах информационной системы. 5. Прозрачная фрагментация. Это требование определяется как возможность распределенного (то есть на различных узлах) размещения данных, логически представляющих собой единое целое. 6. Независимое тиражирование. Предполагает перенос изменений объектов исходной базы данных в базы, расположенные на других узлах распределенной системы. 7. Обработка распределенных запросов. Заключается в возможности выполнения операций выборки данных из распределенной базы данных, посредством запросов на языке SQL. 8. Обработка распределенных транзакций. Предполагает выполнение операций обновления распределенной базы данных, не нарушающих целостность и согласованность данных. 9. Независимость от оборудования. Означает, что в качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей. Система должна выполняться на любой аппаратной платформе. 10. Независимость от операционных систем. Допускает многообразие операционных систем, управляющих узлами распределенной системы. 11. Прозрачность сети. Трактуется как возможность использования в распределенной системе любых сетевых протоколов. Типы СУРаБД Гомогенная распределенная система баз данных – это такая система, в которой каждый узел имеет СУБД одного и того же типа. Гетерогенная распределенная система баз данных – это система, объединяющая несколько различных типов баз данных. Распределенные базы данных характеризуются следующими преимуществами: – разделяемость и локальная автономия. – быстрый доступ к данным. – управление распределенными данными на разных уровнях прозрачности; – увеличение производительности системы. – увеличение гибкости реорганизации за счет модульности системы. Однако распределенные базы данных не лишены и некоторых недостатков: – повышение сложности. – усложнение контроля за целостностью данных. Компоненты клиента компоненты оборудования (компьютер, процессор, жесткий диск, видео, сетевая плата и т.д.). Процессы клиента требуют значительных аппаратных ресурсов. Поэтому, они должны размещаться на компьютере, обладающем достаточной мощностью. Такие мощности облегчают создание систем с мультимедийными возможностями; компоненты программного обеспечения – Операционная система с возможностью многозадачной обработки информации – развитый графический интерфейс пользователя (GUI). Для создания интерфейсных прикладных программ используются языки программирования 3-го и 4-го поколений. – коммуникационные возможности. Связка оборудование плюс операционная система должна обеспечить возможность связи с несколькими сетевыми операционными системами. Компоненты сервера – Сервер, как и клиент, также имеет компоненты оборудования и ПО. Компьютер, на котором располагается процесс сервера, должен быть более мощным, т.к. серверный процесс должен уметь одновременно обрабатывать запросы от нескольких клиентов. Но сервисному процессу не нужен графический интерфейс. Характеристика серверного оборудования зависит от уровня предоставляемого сервиса: файловые сервисы. Файловый сервер предназначен для хранения файлов общего использования; сервер приложений позволяет с рабочих станций запускать сетевые приложения, записанные на сервере; сервисы печати. Сервер печати печатает на подключенных к нему принтерах файлы, отправляемые на печать с рабочих станций. Клиент получает доступ к любому из принтеров так, словно он напрямую подключен к его собственному компьютеру; сервисы факсимильной связи. Факс-сервер хранит, получает и рассылает факсимильные сообщения; сервисы передачи данных. Позволяют клиентским ПК подключаться к серверу передачи данных, чтобы получить доступ к другим компьютерам или сервисам, к которым клиент не может подключиться непосредственно. Например, к электронным доскам объявлений, к удаленной локальной сети и т.д. сервисы баз данных. Клиенту необходимо иметь только интерфейсную программу для получения доступа к серверу базы данных. Клиент посылает SQL-запросы на сервер. Сервер получает SQL-код, проверяет его, выполняет, а клиенту отсылает только результат; сервисы транзакций; Сервер транзакций содержит код транзакции базы данных или процедуры, которые манипулируют информацией в БД. Интерфейсная программа на клиентском ПК посылает запрос на сервер транзакций для выполнения специфической процедуры, хранящейся на сервере БД. При этом по сети не передается никакой SQL-код. Сервер транзакций снижает нагрузку сети и обеспечивает лучшую производительность. другие сервисы, включая обслуживание устройств CD-ROM, видео, резервное копирование и т.д. RDA-модель В модели доступа к удаленным данным на компьютере-клиенте располагаются презентационная логика и бизнес-логика приложений. На сервере находится ядро СУБД. Функции сервера определяются управлением данными и обработкой запросов со стороны клиентов. Клиент обращается к серверу с запросами на языке SQL. В ответ на запрос клиент получает только данные, соответствующие запросу. Основное достоинство данной модели состоит в том что, во-первых, взаимодействие пользователя с сервером осуществляется с помощью стандартного языка запросов SQL. Во-вторых, это наличие большого числа готовых СУБД и других инструментальных средств, обеспечивающих быстрое создание программ клиентской части. Недостатки RDA-модели: высокая загрузка системы передачи данных; неудобны с точки зрения разработки, модификации и сопровождения. Так как в этой модели на клиенте располагается и презент. логика, и бизнеслогика приложений, то при повторении аналогичных функций в различных приложениях код соответствующей бизнес-логики должен быть повторен для каждого клиентского приложения. Это вызывает излишнее дублирование кода приложений. DBS-модель В модели сервера баз данных на компьютере-клиенте располагаются части приложения, реализующие только функции представления, а прикладные функции, определяющие основные алгоритмы решения задач приложения и включающие обеспечение целостности, безопасности и секретности, реализуются на стороне сервера. Работа приложения основана на механизме хранимых процедур и триггеров. Хранимые процедуры – это специальные программные модули, которые используются для извлечения или изменения данных. Существует два вида хранимых процедур: системные и пользовательские. Системные хранимые процедуры предназначены для получения информации из системных таблиц и выполнения различных служебных операций. Чаще всего такие процедуры используются при администрировании базы данных. Пользовательские хранимые процедуры создаются непосредственно разработчиками или администраторами базы данных. Обычно процедуры хранятся в словаре базы данных и могут разделяться между несколькими клиентами. Выполняются хранимые процедуры на том же компьютере, где функционирует SQL-сервер. Хранимые процедуры пишутся на процедурном языке, который зависит от конкретной СУБД. Клиентское приложение обращается к серверу с командой запуска хранимой процедуры, а сервер выполняет ее и возвращает клиенту требуемые данные. Механизм триггеров позволяет выполнять централизованный контроль целостности базы данных. Триггер – это особый тип хранимой процедуры, автоматически выполняющейся при каждой попытке изменить данные. Триггер, как и хранимая процедура, хранится в словаре базы данных. Если триггер вызывает ошибку в запросе, обновление информации не производится, а в приложение возвращается сообщение об ошибке. Достоинства модели сервера баз данных: возможность централизованного администрирования приложений и обеспечения целостности, а также эффективное использование вычислительных и коммуникационных ресурсов. Недостатки DBS-модели: ограниченность действий, выполняемых с помощью хранимых процедур и триггеров и очень большая загрузка сервера. AS-модель Модель сервера приложений является трехзвенной моделью. На компьютере пользователя расположены приложения клиентов, обеспечивающие пользовательский интерфейс. Это нижний уровень модели. Между клиентом и сервером вводится дополнительный промежуточный уровен – сервер приложений, обеспечивающий управление данными и реализующий несколько прикладных функций. Серверов приложений может быть несколько, в зависимости от вида предоставляемого сервиса. Любая программа, запрашивающая услугу у сервера приложений, является для него клиентом. На верхнем, третьем уровне располагается удаленный сервер баз данных, выполняющий функции управления информационными ресурсами базы данных. Трехзвенная модель эффективна в тех случаях, когда требуется выполнить сложные аналитические расчеты над базой данных. К достоинствам AS-модели относят разгрузку сервера базы данных, к недостаткам – увеличение нагрузки на сеть Распределенные реестры Технология распределенных реестров (Distributed ledger technology , DLT ) – это подход к обмену и хранению информации, при котором: ❖ каждый участник может обладать полноценной копией реестра; ❖ синхронизация копий реестра происходит на основе протокола достижения распределенного консенсуса, то есть соглашения среди участников на добавление новой информации; ❖ каждый участник взаимодействия может иметь доступ к истории транзакций. Рисунок 5 – Архитектура распределенного реестра Таблица 1. Достоинства технологии распределенных систем № Достоинство Сущность Крупные организации, как правило, имеют множество отделений, которые могут находиться в разных концах страны и даже за ее пределами. Вполне логично будет предположить, что используемые этими организациями базы данных должны быть распределены между отдельными офисами. В каждом отделении может Отражение 1. поддерживаться своя база данных. В структуры организации подобной базе данных персонал отделения сможет выполнять необходимые ему локальные запросы. Руководству компании может потребоваться выполнять глобальные запросы, предусматривающие получение доступа к данным, сохраняемым во всех существующих отделениях компании. Географическая распределенность организации может быть отражена в Разделяемость и распределении ее данных, причем 2. локальная пользователи одного сайта смогут получать автономность доступ к данным, сохраняемым на других сайтах. Данные могут быть помещены на тот сайт, на котором зарегистрированы № Достоинство 3. Повышение доступности данных 4. Повышение надежности 5. Повышение производительности Сущность пользователи, которые их чаще всего используют. В результате заинтересованные пользователи получают локальный контроль над требуемыми им данными и могут устанавливать или регулировать локальные ограничения на их использование. Администратор глобальной базы данных (АБД) отвечает за систему в целом. Как правило, часть этой ответственности делегируется на локальный уровень, благодаря чему АБД локального уровня получает возможность управлять локальной СУБД. В централизованных СУБД отказ центрального компьютера вызывает прекращение функционирования всей СУБД. Отказ одного из сайтов СУРБД или линии связи между сайтами сделает недоступным лишь некоторые сайты, тогда как вся система в целом сохранит свою работоспособность. Распределенные СУБД проектируются таким образом, чтобы обеспечивать продолжение функционирования системы, несмотря на подобные отказы. Если выходит из строя один из узлов, система сможет перенаправить запросы к отказавшему узлу в адрес другого сайта. Если организована репликация данных, в результате чего данные и их копии будут размещены на более чем одном сайте, отказ отдельного узла или соединительной связи между узлами не приведет к недоступности данных в системе. Если данные размещены на самом нагруженном сайте, который унаследовал от систем-предшественников высокий уровень параллельности обработки, то развертывание распределенной СУБД может способствовать повышению скорости доступа к базе данных (по № Достоинство 6. Экономические выгоды 7. Модульность системы Сущность сравнению с доступом к удаленной централизованной СУБД). Более того, поскольку каждый сайт работает только с частью базы данных, уровень использования центрального процессора и служб ввода/ вывода может оказаться ниже, чем в случае централизованной СУБД. В настоящее время считается общепринятым положение, согласно которому намного дешевле собрать из небольших компьютеров систему, мощность которой будет эквивалентна мощности одного большого компьютера. Гораздо выгоднее устанавливать в подразделениях организации собственные маломощные компьютеры, кроме того, гораздо дешевле добавить в сеть новые рабочие станции, чем модернизировать систему с мейнфреймом. Второй потенциальный источник экономии имеет место в том случае, когда базы данных географически удалены друг от друга и приложения требуют осуществления доступа к распределенным данным. В этом случае из-за относительно высокой стоимости передаваемых по сети данных (по сравнению со стоимостью их локальной обработки) может оказаться экономически выгодным разделить приложение на соответствующие части и выполнять необходимую обработку на каждом из сайтов локально. В распределенной среде расширение существующей системы осуществляется намного проще. Добавление в сеть нового сайта не оказывает влияния на функционирование уже существующих. Подобная гибкость позволяет организации легко расширяться. Перегрузки из-за увеличения размера базы данных обычно устраняются путем добавления в сеть № Достоинство Сущность новых вычислительных мощностей и устройств дисковой памяти. В централизованных СУБД рост размера базы данных может потребовать замены и оборудования (более мощной системой), и используемого программного обеспечения (более мощной или более гибкой СУБД). Таблица 2. Недостатки технологии распределенных систем № Недостаток 1. Повышение сложности 2. Увеличение стоимости Сущность Распределенные СУБД, способные скрыть от конечных пользователей распределенную природу используемых ими данных и обеспечить необходимый уровень производительности, надежности и доступности, безусловно, являются более сложными программными комплексами, чем централизованные СУБД. Тот факт, что данные могут подвергаться репликации, также добавляет дополнительный уровень сложности в программное обеспечение СУРБД. Если репликация данных не будет поддерживаться на требуемом уровне, система будет иметь более низкий уровень доступности данных, надежности и производительности, чем централизованные системы, а все изложенные выше преимущества превратятся в недостатки. Увеличение сложности означает и увеличение затрат на приобретение и сопровождение СУРБД (по сравнению с обычными централизованными СУБД). Разворачивание распределенной СУБД потребует дополнительного оборудования, необходимого для установки сетевых соединений между сайтами. Следует ожидать и роста расходов на оплату каналов связи, вызванных возрастанием сетевого графика. Кроме того, возрастают затраты на оплату труда персонала, который потребуется для обслуживания локальных СУБД и сетевых соединений. № Недостаток Сущность В централизованных системах доступ к данным легко контролируется. В распределенных системах потребуется организовать контроль доступа не только к данным, реплицируемым на несколько различных сайтов, но и защиту сетевых Проблемы 3. соединений самих по себе. Раньше сети защиты рассматривались как совершенно незащищенные каналы связи. Хотя это отчасти справедливо и для настоящего времени, тем не менее, в отношении защиты сетевых соединений достигнут весьма существенный прогресс. Целостность базы данных означает корректность и согласованность сохраняемых в ней данных. Требования обеспечения целостности обычно формулируются в виде некоторых ограничений, выполнение которых будет гарантировать защиту информации в базе Усложнение данных от разрушения. Реализация 4. контроля за ограничений поддержки целостности обычно целостностью данных требует доступа к большому количеству данных, используемых при выполнении проверок, но не требует выполнения операций обновления. В распределенных СУБД повышенная стоимость передачи и обработки данных может препятствовать организации эффективной защиты от нарушений целостности данных. Хотя функционирование распределенных СУБД зависит от эффективности используемых каналов связи, только в последнее время стали вырисовываться контуры стандарта на Отсутствие 5. каналы связи и протоколы доступа к данным. стандартов Отсутствие стандартов существенно ограничивает потенциальные возможности распределенных СУБД. Кроме того, не существует инструментальных средств и методологий, способных помочь № Недостаток Сущность пользователям в преобразовании централизованных систем в распределенные. В настоящее время в эксплуатации находится уже несколько систем-прототипов и распределенных СУБД специального назначения, что позволило уточнить требования к используемым протоколам и установить круг основных проблем. Однако на текущий момент распределенные системы общего назначения еще не получили Недостаток 6. широкого распространения. Соответственно, опыта еще не накоплен необходимый опыт промышленной эксплуатации распределенных систем, сравнимый с опытом эксплуатации централизованных систем. Такое положение дел является серьезным сдерживающим фактором для многих потенциальных сторонников данной технологии. Разработка распределенных баз данных, помимо обычных трудностей, Усложнение связанных с процессом проектирования процедуры централизованных баз данных, требует 7. разработки базы принятия решения о фрагментации данных, данных распределении фрагментов по отдельным сайтам и организации процедур репликации данных. Комплексный учет всех предоставляемых выигрышей и проигрышей является сложной задачей, методология решения которой в настоящее время не определена. Ответственность за принятие решения по разработке и внедрению распределенной системы может взять на себя группа смелых специалистов. Баланс положительных и отрицательных аспектов существенно зависит от рода задачи, для решения которой предполагается создание распределенной системы. Потоковые базы данных Обработка в режиме реального времени выполняется для потоков данных, получаемых в реальном времени и обрабатываемых с минимальной задержкой для создания отчетов или автоматизированного реагирования в режиме реального времени (или приближенном к реальному времени). Принцип работы PipelineDB можно сформулировать так: «постоянные запросы, кратковременные данные». В реляционных СУБД всё обстоит ровно наоборот: «кратковременные запросы, постоянные данные. В PipelineDB данные не хранятся, а поступают в потоке; их обработка происходит «на лету», в движении. Архитектура обработки в режиме реального времени • Прием сообщений в реальном времени. Архитектура должна включать средства сбора и сохранения сообщений в режиме реального времени, доступные для объекта-получателя, обрабатывающего поток. В простых случаях роль такой службы может выполнять обычное хранилище данных, в одной из папок которого размещаются новые сообщения. Но чаще для этого компонента нужны специализированные брокеры обмена сообщениями, например Центры событий Azure, которые выполняют роль буфера для входящих сообщений. Брокер обмена сообщениями должен поддерживать масштабируемую обработку и надежную доставку. • Потоковая обработка. Сохранив сообщения, поступающие в режиме реального времени, система выполняет для них фильтрацию, статистическую обработку и другие процессы подготовки данных к анализу. • Хранилище аналитических данных. Многие решения по обработке больших данных спроектированы так, чтобы подготавливать данные к анализу и предоставлять их в структурированном формате для запросов через средства аналитики. • Анализ и создание отчетов. Большинство решений по обработке больших данных предназначены для анализа и составления отчетов, что позволяет получить важную информацию. Обработка потоковых данных требует использования двух уровней: уровня хранилища и уровня обработки. Уровень хранилища должен поддерживать очередность записей и строгую непротиворечивость для обеспечения быстрых, экономичных и воспроизводимых операций записи и чтения больших потоков данных. Уровень обработки отвечает за потребление данных, расположенных на уровне хранилища, выполнение вычислений с использованием этих данных и уведомление уровня хранилища о том, какие данные можно удалить за ненадобностью. Кроме того, необходимо предусмотреть масштабируемость, надежность данных и отказоустойчивость как на уровне хранилища, так и на уровне обработки. В результате появилось множество платформ, предоставляющих необходимую инфраструктуру для создания приложений обработки потоковых данных, включая Amazon Kinesis Streams, Amazon Kinesis Firehose, Apache Kafka, Apache Flume, Apache Spark Streaming и Apache Storm. Таблица 3 – Сравнительные характеристикипакетной и потоковой обработки Пакетная обработка Потоковая обработка Перечень данных Запросы ко всем или большей части данных в наборе или же их обработка. Запросы или обработка данных в пределах скользящего временного окна или самой последней записи данных. Размер данных Большие данных. Отдельные микропакеты записей. Производительность Задержки от Требуется задержка в пределах нескольких минут до нескольких секунд или нескольких часов. миллисекунд. Анализ Комплексная аналитика. пакеты записи или из нескольких Простые функции ответа, агрегации данных или динамических метрик. Нереляционные данные и базы данных NoSQL Нереляционная база данных — это база данных, в которой в отличие от большинства традиционных систем баз данных не используется табличная схема строк и столбцов. В этих базах данных применяется модель хранения, оптимизированная под конкретные требования типа хранимых данных. Например, данные могут храниться как простые пары "ключ — значение", документы JSON или граф, состоящий из ребер и вершин. Все эти хранилища данных не используют реляционную модель. Кроме того, они, как правило, поддерживают определенные типы данных. Процесс запроса данных также специфический. Например, хранилища данных временных рядов рассчитаны на запросы к последовательностям данных, упорядоченных по времени, а хранилища данных графов — на анализ взвешенных связей между сущностями. Ни один из форматов не подходит в полней мере при выполнении задач управления данными о транзакциях. Термин NoSQL применяется к хранилищам данных, которые не используют язык запросов SQL, а запрашивают данные с помощью других языков и конструкций.На практике NoSQL означает "нереляционная база данных", даже несмотря на то, что многие из этих баз данных под держивают запросы, совместимые с SQL. Однако базовая стратегия выполнения запросов SQL обычно значительно отличается от применяемой в системе управления реляционной базой данных (реляционная СУБД). Хранилища данных документов Хранилище данных документов управляет набором значений именованных строковых полей и данных объекта в сущности, которая называется документом. Обычно данные в этих хранилищах содержатся в виде документов JSON. Каждое значение поля может представлять собой скалярный элемент, например число, или сложный объект, например список или коллекция типа "родитель — потомок". Данные в полях документа можно закодировать разными способами, например в формате XML, YAML, JSON, BSON, или хранить в виде обычного текста.Поля документов доступны системе управления хранилищем, что позволяет приложению выполнять запросы и применять фильтры, основанные на значениях этих полей. Как правило, документ содержит все данные одной сущности. Элементы, составляющие сущность, зависят от конкретного приложения.Например, сущность может содержать сведения о клиенте, заказе или и те, и другие. Один документ может содержать сведения, которые в реляционной СУБД обычно распределяются по нескольким реляционным таблицам.Хранилище документов не обязывает использовать одинаковую структуру для всех документов. Например, приложения могут хранить в документах разные данные в соответствии с текущими требованиями компании. Приложение может получать документы по ключу документа. Это уникальный идентификатор документа. Часто к нему применяется хэширование для равномерного распределения данных. Некоторые базы данных документов создают ключ документа автоматически. Другие позволяют указать, какой атрибут документа следует использовать в качестве ключа. Также приложение может запрашивать документы по значениям одного или нескольких полей. Некоторые базы данных документов поддерживают индексирование, что ускоряет поиск документов по одному или нескольким индексированным полям Многие базы данных документов поддерживают обновления "на месте", то есть позволяют приложению изменять значения отдельных полей без перезаписи всего документа.Операции чтения и записи для нескольких полей в одном документе обычно являются атомарными. Столбчатые хранилища данных Столбчатое хранилище данных или хранилище семейств столбцов упорядочивает данные по столбцам и строкам. Столбчатое хранилище данных в простейшей форме почти неотличимо от реляционной базы данных, по крайней мере организационно. Настоящее преимущество столбчатого хранилища данных заключается в способности денормализованно структурировать разреженные данные, что связано со столбцовоориентированным методом хранения данных Столбчатое хранилище данных можно представить как набор табличных данных со строками и столбцами, в которых столбцы разделяются на определенные группы или семейства столбцов. Каждое семейство столбцов включает набор логически связанных столбцов, которые обычно извлекаются или управляются как единое целое. Другие данные, которые используются в других процессах, хранятся отдельно в других семействах столбцов. В семейство столбцов можно динамически добавить новые столбцы, а строки могут быть разреженными (то есть строки не обязаны иметь значение для каждого столбца). В отличие от хранилища пар "ключ — значение" и баз данных документов, большинство столбчатых баз данных упорядочивают хранимые данные с помощью самих значений ключей, а не хэш-кодов от них. Ключ строки рассматривается как первичный индекс и обеспечивает доступ на основе определенного ключа или их диапазона. Некоторые реализации позволяют создавать вторичные индексы по определенным столбцам в семействе столбцов. Вторичные индексы позволяют получать данные по значениям столбцов, а не ключам строки. Все столбцы одного семейства хранятся на диске в одном файле. Каждый файл содержит определенное число строк. При использовании больших наборов данных этот подход позволяет повысить производительность за счет снижения объема данных, которые необходимо считывать с диска, когда отправляется запрос на получение нескольких столбцов за раз. Операции чтения и записи для строки обычно являются атомарными в пределах одного семейства столбцов, хотя некоторые реализации обеспечивают атомарность по всей строке, охватывающую несколько семейств столбцов. Хранилище пар "ключ — значение" Хранилище пар "ключ — значение" по сути представляет собой большую хэш-таблицу. Каждое значение сопоставляется с уникальным ключом, и хранилище ключей использует этот ключ для хранения данных, применяя к нему некоторую функцию хэширования. Выбор функции хэширования должен обеспечить равномерное распределение хэшированных ключей по хранилищу данных. Большинство хранилищ пар "ключ — значение" поддерживают только самые простые операции запроса, вставки и удаления. Чтобы частично или полностью изменить значение, приложение всегда перезаписывает существующее значение целиком. В большинстве реализаций атомарной операцией считается чтение или запись одного значения. Запись больших значений занимает относительно долгое время. Приложение может хранить в наборе значений произвольные данные, но некоторые хранилища пар "ключ — значение" накладывают ограничения на максимальный размер значений. Программное обеспечение хранилища ничего не знает о значениях, которые в нем хранятся. Все сведения о схеме поддерживаются и применяются на уровне приложения. Эти значения по существу являются большими двоичными объектами, которые хранилище извлекает и сохраняет по соответствующему ключу. Хранилища пар "ключ — значение" рассчитаны на приложения, выполняющие простые операции поиска на основе значения ключа или диапазона ключей, но не очень подходят для систем, которым нужно запрашивать данные из нескольких таблиц хранилищ пар "ключ — значение", например присоединенные данные в нескольких таблицах. Хранилища данных графов Хранилища данных графов управляют сведениями двух типов: узлами и ребрами. Узлы в этом случае представляют сущности, а ребра определяют связи между ними. Узлы и грани имеют свойства, которые предоставляют сведения о конкретном узле или грани, примерно как столбцы в реляционной таблице. Грани могут иметь направление, указывающее на характер связи. Хранилища данных графов позволяют приложениям эффективно выполнять запросы, которые проходят через сеть узлов и ребер, а также анализировать связи между сущностями. На схеме ниже представлены данные персонала организации, структурированные в виде графа. Сущностями здесь являются сотрудники и отделы, а грани определяют отношения подчинения и отдел, в котором работает каждый сотрудник. На этом графе грани имеют строгое направление, которое на схеме обозначено стрелками. Хранилища данных временных рядов Данными временных рядов называются наборы значений, которые упорядочены по времени. Соответственно хранилища данных временных рядов оптимизированы для хранения данных именно такого типа. Хранилища данных временных рядов должны поддерживать очень большое число операций записи, так как обычно в них в режиме реального времени собирается большой объем данных из большого количества источников. Эти хранилища также хорошо подходят для хранения данных телеметрии. Например, для сбора данных от датчиков Интернета вещей или счетчиков в приложениях или системах. Обновления в таких базах данных выполняются редко, а удаление чаще всего является массовой операцией. Размер отдельных записей в базе данных временных рядов обычно невелик, но их очень много, а значит общий размер данных быстро увеличивается. Хранилища данных временных рядов также обрабатывают данные, полученные вне очереди или несвоевременно, автоматически индексируют точки данных и оптимизируют запросы, полученные в течение определенного промежутка времени. Эта последняя возможность позволяет быстро выполнять запросы к миллионам точек данных и нескольким потокам данных, что, в свою очередь, обеспечивает поддержку визуализации временных рядов (стандартный способ потребления данных временных рядов). Хранилище данных объектов Хранилища данных объектов оптимизированы для хранения и извлечения больших двоичных объектов, например изображений, текстовых файлов, видео- и аудиопотоков, объектов данных и документов приложений большого размера, образы дисков виртуальных машин. Объект состоит из сохраненных данных, метаданных и уникального идентификатора доступа к объекту. Хранилища объектов поддерживают отдельные большие файлы, а также позволяют управлять всеми файлами за счет внушительного общего объема хранилища. Некоторые хранилища данных объектов реплицируют определенный большой двоичный объект между несколькими узлами кластера, что обеспечивает быстрое параллельное чтение. Это, в свою очередь, позволяет реализовать масштабируемую архитектуру запроса данных, хранящихся в больших файлах, так как несколько процессов, обычно выполняющихся на разных серверах, могут одновременно запрашивать большие файлы данных. Часто хранилища данных объектов используют как сетевые общие папки. Доступ к файлам, хранящимся в этих папках, можно получить через компьютерную сеть с использованием стандартных сетевых протоколов, например SMB. Учитывая соответствующие механизмы обеспечения безопасности и параллельного управления доступом, совместное использование данных позволяет распределенным службам обеспечить высокую масштабируемость доступа к данным для базовых операций низкого уровня, таких как простые запросы на чтение и запись. Хранилища данных внешних индексов Хранилища данных внешних индексов позволяют искать информацию, содержащуюся в других хранилищах данных и службах. Внешний индекс выступает в роли вторичного индекса любого хранилища данных. Кроме того, с его помощью можно индексировать большие объемы данных и предоставлять доступ к этим индексам почти в реальном времени. Например, в файловой системе могут храниться текстовые файлы. По пути файл можно найти быстро, но поиск на основе содержимого выполняется медленно, так как сканируются все файлы. Внешний индекс позволяет создавать вторичные индексы, а затем быстро искать путь к файлам, соответствующим заданным условиям. Рассмотрим еще один пример использования внешнего индекса. Предположим, что хранилища пар "ключ — значение" поддерживают индексирование только по ключу. Вы можете создать вторичный индекс на основе значений данных и быстро найти ключ, однозначно определяющий каждый соответствующий элемент. Индексы создаются в процессе индексирования, который может выполняться по модели извлечения, то есть по требованию хранилища данных, или по модели передачи, то есть по команде из кода приложения. В некоторых системах поддерживаются многомерные индексы и полнотекстовый поиск по большим объемам текстовых данных. Хранилища данных внешнего индекса часто используются для поддержки полнотекстового поиска. В этих случаях поддерживается точный или нечеткий поиск. Нечеткий поиск находит документы, которые соответствуют набору условий, и вычисляет для них коэффициент совпадения с этим набором. Некоторые внешние индексы также поддерживают лингвистический анализ, который возвращает соответствия с учетом синонимов, категорий (например, при поиске по запросу "собаки" соответствием считается "питомцы") и морфологии (например, при поиске по запросу "бег" соответствием считается "бегущий"). Стандартные требования В таблице ниже приведено сравнение требований каждого нереляционного хранилища данных. Требование Нормализация Хранилище данных документов Столбчатое хранилище данных Хранилище Хранилище данных парданных графов "ключ — значение" ДенормалиНормализированные зированные данные данные Схема при чтении Схема при чтении ДенормалиДенормализированные зированные данные данные Схема Схема приСемейства чтении столбцов, определен-ные при записи, схема столбца при чтении Согласованность Настраиваемый Гарантии наГарантии наГарантии на (между уровень уровне уровне ключей уровне графа параллельными согласованност семейства транзакциями) и, гарантии настолбцов уровне документа Атомарность (область Коллекция Таблица Таблица График транзакции) Стратегия Оптимистичная Пессимистична Оптимистичная блокировки (без я (блокировка(ETag) блокировки) строк) Шаблон доступа Прямой доступ Статистические Прямой доступ Прямой доступ выражения на основе данных большого формата Индексация Первичный иПервичный иТолько первичныйПервичный и вторичные вторичные индекс вторичные индексы индексы индексы Форма представленияДокумент Таблица сКлюч и значение Граф с ребрами данных семействами и вершинами столбцов разреженные Да Да Да Нет Масштабность Да Да Нет Нет (большое количество столбцов и атрибутов) Требование Размер данных Общий максимальный масштаб Хранилище данных документов Столбчатое хранилище данных Хранилище Хранилище данных парданных графов "ключ — значение" От малого (КБ)От среднего Небольшой (КБ) Небольшой до среднего(МБ) до (КБ) (несколько МБ) большого (несколько ГБ) Очень большойОчень большойОчень (ПБ) (ПБ) (ПБ) Требование Данные временных рядов Недоступно Хранилище Хранилище данных объектов данных внешних индексов Денормализиро- Денормализиванные данные рованные данные Схема при чтении Схема при записи Недоступно Недоступно Недоступно Объект Нормализация Нормализированные данные Схема Схема при чтении Согласованность (между параллельными транзакциями) Атомарность (область транзакции) Стратегия блокировки большойБольшой (ТБ Недоступно Недоступно Пессимистичная Недоступно (блокировка больших двоичных объектов) Шаблон Прямой доступ и агрегирование Последовательный Прямой доступ доступ Индексация Первичный и вторичныеТолько первичныйНедоступно индексы индекс Форма представления Таблица Большой Документ данных двоичный объект и метаданные разреженные нет Недоступно Нет Масштабность Нет Да Да (большое количество столбцов и атрибутов) Размер данных Небольшой (КБ) От большого (ГБ) Небольшой до очень большого(КБ) (ТБ) Проблемы защиты баз данных Внешними дестабилизирующими факторами, создающими угрозы безопасности функционированию СУБД, являются: ❖ умышленные, деструктивные действия лиц с целью искажения, уничтожения или хищения программ, данных и документов системы, причиной которых являются нарушения информационной безопасности защищаемого объекта; ❖ искажения в каналах передачи информации, поступающей от внешних источников; ❖ сбои и отказы в аппаратуре вычислительных средств; ❖ вирусы и иные деструктивные программные элементы, распространяемые с использованием систем телекоммуникаций, обеспечивающих связь с внешней средой или внутренние коммуникации распределенной СУБД; ❖ изменения состава и конфигурации комплекса взаимодействующей аппаратуры системы за пределами, проверенными при тестировании или сертификации системы. Среди внутренних угроз можно выделить следующие атаки: ❖ атаки со стороны авторизованных пользователей, направленные на повышение привилегий в системе управления базами данных; ❖ непреднамеренные ошибки сотрудников, которые по какой-либо причине нарушают установленную политику безопасности или применяют неверные методы безопасности; ❖ целенаправленное изменение или искажение хранимых данных; ❖ угрозы, возникающие из-за ошибок в программном обеспечении и неверной конфигурации системы; ❖ угрозы, возникающие из-за ошибок в аппаратном обеспечении и неверной их настройки. Атаки на ОС, в которых функционирует СУБД, возникают гораздо чаще, т. к. защитить ОС гораздо сложнее, чем СУБД. Это обусловлено тем, что число различных типов защищаемых объектов в современных ОС может достигать нескольких десятков, а число различных типов защищаемых информационных потоков - нескольких сотен. Возможность практической реализации той или иной атаки на ОС в значительной мере определяется архитектурой и конфигурацией ОС. Тем не менее существуют атаки (перечислены ниже), которые могут быть направлены практически на любые ОС. 1. Кража ключевой информации. Данная атака может реализовываться с использованием следующих методов: — подсматривание пароля при его вводе пользователем; — получение пароля из командного файла. Некоторые ОС при сетевой аутентификации (подключении к серверу) допускают ввод пароля из командной строки. Если аутентификация происходит с использованием командного файла, пароль пользователя присутствует в этом файле в явном виде; — некоторые пользователи, чтобы не забыть свой пароль, записывают его в записные книжки, на бумажки, которые затем приклеивают к нижней части клавиатуры, и т. д. Для злоумышленника узнать такой пароль не составляет никакого труда. Особенно часто такая ситуация имеет место, если администраторы заставляют сотрудников использовать длинные, труднозапоминаемые пароли; — кража внешнего носителя ключевой информации. Некоторые ОС допускают использование вместо паролей внешних носителей информации (ключевые дискеты, Touch Memory, Smart Card и т. д.). Использование внешних носителей повышает надежность защиты ОС, но в этом случае появляется угроза кражи носителя с ключевой информацией; — перехват пароля программной закладкой. 2. Подбор пароля. При данной атаке могут использоваться следующие методы: — неоптимизированный перебор. В этом случае злоумышленник последовательно опробует все возможные варианты пароля. Для паролей длиннее шести символов во многих случаях данный метод может быть признан неэффективным; — перебор, оптимизированный по статистике встречаемости символов и биграмм. Разные символы встречаются в паролях пользователей с разной вероятностью. Согласно различным исследованиям, статистика встречаемости символов в алфавите паролей близка к статистике встречаемости символов в естественном языке. При практическом применении данного метода злоумышленник вначале опробует пароли, состоящие из наиболее часто встречающих символов, за счет чего время перебора существенно сокращается. Иногда при подборе паролей используется не только статистика встречаемости символов, но и статистика встречаемости биграмм и триграмм - комбинаций двух и трех последовательных символов. Для подбора паролей по данному методу злоумышленник может использовать множество программ, в основном ориентированных на взлом ОС. При этом можно выделить две базовые технологии: явное опробование последовательно генерируемых паролей их подачей на вход подсистемы аутентификации и расчет значения хэш-функции и ее последующего сравнения с известным образом пароля; — перебор, оптимизированный с использованием словарей вероятных паролей. При использовании данного метода подбора паролей злоумышленник вначале опробует в качестве пароля все слова из словаря, содержащего наиболее вероятные пароли. Если подбираемый пароль отсутствует в словаре, злоумышленник может опробовать всевозможные комбинации слов из словаря, слова из словаря с добавленными к началу или к концу одной или несколькими буквами, цифрами и знаками препинания и т. д.; — перебор, оптимизированный с использованием знаний о пользователе. В этом случае в первую очередь злоумышленник пробует пароли, использование которых сотрудником представляется наиболее вероятным (имя, фамилия, дата рождения, номер телефона и т. д.); — перебор, оптимизированный с использованием знаний о подсистеме аутентификации ОС. Если ключевая система ОС допускает существование эквивалентных паролей, при переборе из каждого класса эквивалентности опробуется всего один пароль. Все перечисленные выше методы злоумышленник может применять в совокупности. 4. Сканирование жестких дисков компьютера. Данная атака заключается в последовательном считывании файлов, хранящихся на жестких дисках компьютера. Если при обращении к некоторому файлу или каталогу злоумышленник получает отказ, он просто продолжает сканирование дальше. Если объем жесткого диска компьютера достаточно велик, можно быть уверенным, что при описании прав доступа к файлам и каталогам этого диска администратор допустил хотя бы одну ошибку. При применении этой атаки все файлы, для которых были допущены такие ошибки, будут прочитаны злоумышленником. Несмотря на примитивность данной атаки, она во многих случаях оказывается весьма эффективной. Для ее реализации злоумышленник должен быть легальным пользователем ОС.Данный метод можно применять не только для сканирования дисков локального компьютера, но и для сканирования разделяемых ресурсов локальной сети. 5. Превышение полномочий. Используя ошибки в программном обеспе чении или администрировании ОС, злоумышленник получает в системе полномочия, превышающие предоставленные ему согласно текущей политике безопасности. Превышение полномочий может быть достигнуто следующими способами: — запуск программы от имени пользователя, обладающего необходимыми полномочиями; — запуск программы в качестве системной программы (драйвер, сервис, демон и т. д.), выполняющейся от имени ОС; — подмена динамически подгружаемой библиотеки, используемой системными программами, или несанкционированное изменение переменных среды, описывающих путь к такой библиотеке; — модификация кода или данных подсистемы защиты ОС. 6. Атаки класса «Отказ в обслуживании». Эти атаки нацелены на полный или частичный вывод ОС из строя. Существуют следующие атаки данного класса: — захват ресурсов - программа захватывает все ресурсы компьютера, которые может получить. Например, программа присваивает себе наивысший приоритет и уходит в вечный цикл; — бомбардировка трудновыполнимыми запросами - программа в вечном цикле направляет ОС запросы, выполнение которых требует больших затрат ресурсов компьютера; — бомбардировка заведомо бессмысленными запросами - программа в вечном цикле направляет ОС заведомо бессмысленные (обычно случайно генерируемые) запросы. Рано или поздно в ОС происходит фатальная ошибка; — использование известных ошибок в программном обеспечении или администрировании ОС. Наиболее опасные атаки на СУБД исходят из сетей. Это в первую очередь обусловлено обилием протоколов, которые используются в сетях Интернет, и автономными программами небольшого размера, загруженными в пользовательские компьютерные системы. Эти протоколы и активные элементы могут создать серьезную угрозу для безопасности системы. На уровне сетевого программного обеспечения возможны следующие атаки на СУБД. 1. Прослушивание канала. Данная атака возможна только в сегменте локальной сети. Практически все сетевые карты поддерживают возможность перехвата пакетов, передаваемых по общему каналу локальной сети. При этом рабочая станция может принимать пакеты, адресованные другим компьютерам того же сегмента сети. Таким образом, весь информационный обмен в сегменте сети становится доступным злоумышленнику. Для успешной реализации этой атаки компьютер злоумышленника должен располагаться в том же сегменте локальной сети, что и атакуемый компьютер. 2. Перехват пакетов на маршрутизаторе. Сетевое программное обеспечение маршрутизатора имеет доступ ко всем сетевым пакетам, передаваемым через данный маршрутизатор, что позволяет осуществлять перехват пакетов. Для реализации этой атаки хакер должен иметь привилегированный доступ хотя бы к одному маршрутизатору сети. Поскольку через маршрутизатор обычно передается очень много пакетов, их тотальный перехват практически невозможен. Однако отдельные пакеты вполне могут быть перехвачены и сохранены для последующего анализа хакером. Наиболее эффективен перехват пакетов FTP, содержащих пароли пользователей. 3. Создание ложного маршрутизатора. Злоумышленник отправляет в сеть пакеты определенного вида, в результате чего его компьютер становится маршрутизатором и получает возможность осуществлять предыдущую угрозу. Ложный маршрутизатор необязательно заметен всем компьютерам сети - можно создавать ложные маршрутизаторы для отдельных компьютеров сети и даже для отдельных соединений. 4. Навязывание пакетов. Злоумышленник отправляет в сеть пакеты с ложным обратным адресом. С помощью этой атаки злоумышленник может переключать на свой компьютер соединения, установленные между другими компьютерами и получать необходимые данные от СУБД. При этом права доступа хакера становятся равными правам того пользователя, чье соединение с сервером было переключено на компьютер хакера. 5. Атаки класса «Отказ в обслуживании». Злоумышленник отправляет в сеть пакеты определенного вида, в результате чего один или несколько компьютеров сети полностью или частично выходят из строя. 6. Нелегальное внедрение разрушающих программных средств. Злоумышленник может использовать троянские программы, которые могут быть предназначены для исследования параметров информационной системы, сбора данных, зомбирования компьютера с последующим нецелевым расходованием ресурсов и т. д. Может быть осуществлено также заражение компьютера вирусами с деструктивными функциями. Классификацию угроз на уровне базы данных по результатам воздействия: угрозы конфиденциальности информации, угрозы целостности информации и угрозы доступности. К угрозам конфиденциальности информации можно отнести следующие. 1. Инъекция SQL. Во многих приложениях используется динамический SQL формирование SQL - формирование SQL-предложений кодом программы путем конкатенации строк и значений параметров. Зная структуру базы данных, злоумышленник может либо выполнить хранимую программу в запросе, либо закомментировать «легальные» фрагменты SQL-кода, внедрив, например, конструкцию UNION, запрос которой возвращает конфиденциальные данные. В последнее время злоумышленник может использовать специальные программы, автоматизирующие процесс реализации подобных угроз. 2. Логический вывод на основе функциональных зависимостей. Пусть дана схема отношения: R(A1, ..., An). Пусть U = {A1, ..., An},X,Y - подмножества из U. X функционально определяет Y,если в любом отношении r со схемой R(A1, ..., An) не могут содержаться два кортежа с одинаковыми значениями атрибутов из X и с различными из Y . В этом случае имеет место функциональная зависимость, обозначаемая X ® Y . В реальных БД при наличии сведений о функциональных зависимостях злоумышленник может вывести конфиденциальную информацию при наличии доступа только к части отношений, составляющих декомпозированное отношение. 3. Логический вывод на основе ограничений целостности. Для кортежей отношений в реляционной модели данных можно задать ограничения целостности - логические условия, которым должны удовлетворять атрибуты кортежей. При этом ограничение целостности может быть задано в виде предиката на всем множестве атрибутов кортежа. В случае попытки изменить данные в таблице, СУБД автоматически вычисляет значение этого предиката, и в зависимости от его истинности операция разрешается или отвергается. Многократно изменяя данные и анализируя реакцию системы, злоумышленник может получить те сведения, к которым у него нет непосредственного доступа. К этому виду угроз можно отнести также анализ значений первичных/вторичных ключей. 4. Использование оператора UPDATE для получения конфиденциальной информации. В некоторых стандартах SQL пользователь, не обладая привилегией на выполнение оператора SELECT, мог выполнить оператор UPDATE со сложным логическим условием. Так как после выполнения оператора UPDATE сообщается, сколько строк он обработал, фактически пользователь мог узнать, существуют ли данные, удовлетворяющие этому условию. Угрозы целостности информации, специфические для СУБД. С помощью SQL-операторов UPDATE, INSERT и DELETE можно изменить данные в СУБД. Опасность заключается в том, что пользователь, обладающий соответствующими привилегиями, может модифицировать все записи в таблице. К угрозам доступности для СУБД можно отнести следующие. 1. Использование свойств первичных и внешних ключей. В первую очередь отнесем сюда свойство уникальности первичных ключей и наличие ссылочной целостности. В том случае, если используются натуральные, а не генерируемые системой значения первичных ключей, может создаться такая ситуация, когда в таблицу невозможно будет вставить новые записи, т. к. там уже будут записи с такими же значениями первичных ключей. Если в БД поддерживается ссылочная целостность, можно организовать невозможность удаления родительских записей, умышленно создав подчиненные записи. 2. Блокировка записей при изменении. Заблокировав записи или всю таблицу, злоумышленник может на значительное время сделать ее недоступной для обновления. 3. Загрузка системы бессмысленной работой. Злоумышленник может выполнить запрос, содержащий декартовое произведение двух больших отношений. Мощность декартового произведения двух отношений мощности N1 и N2 равна N1 • N2. Это означает, что при выдаче злоумышленником запроса вида SELECT * FROM Tabl, Tabl ORDER BY 1, где мощность отношения (количество строк в таблице Tab1) N1 = 10 000, мощность результирующего отношения будет N = N12 = 10 0002. Вычисление соединения и сортировка результирующего отношения потребуют значительных ресурсов системы и отрицательно скажутся на производительности операций других пользователей. 4. Использование разрушающих программных средств. Например, атака типа «троянский конь» - запуск пользователями программ, содержащих код, выполняющий определенные действия, внедренный туда злоумышленником. Разработка любой системы информационной безопасности должна основываться на определенном перечне потенциальных угроз безопасности и установлении возможных источников их возникновения. Так как если в системе существуют угрозы, для которых непредусмотрены какие-либо меры противодействия, то это может привести к тому, что все усилия, затраченные на возведение системы защиты, к ожидаемому результату не приведут. Поэтому при проектировании конкретной системы безопасности для любого объекта, в том числе и для СУБД, необходимо произвести всесторонний учет угроз и для каждой из них реализовать соответствующий угрозе метод защиты. 1. Громов Ю.Ю., Иванова О.Г., Яковлев А.В., Однолько В.Г. Управление данными. Учебник. Тамбов – Издательство ТГТУ, 2015, 193 с., ISBN 13:978-5-8265-1385-9 2. Проектирование организации. Business studio. Электронный ресурс https://www.businessstudio.ru/demo/business_studio/ (дата обращения: 29.11.2019). 3. WIN01SOFT.RU. Электронный ресурс: https://win10soft.ru/287bpwin.html (дата обращения: 29.01.2020). 4. Моделирования в среде ARIS EXPRESS. Электронный ресурс: https://www.bazt.ru/publications/моделирование-aris-express (дата обращения: 29.01.2020). 5. Методология IDEF0. Стандарт. Русская версия. МетаТехнология. Электронный ресурс: http://elearning.bmstu.ru/moodle/pluginfile.php/5190/mod_resource/content/1/Стан дарт%20IDEF0.pdf (дата обращения: 29.01.2020).