Преподаватель который помогает студентам и школьникам в учёбе.

Способы представления данных в информационных системах (Общие понятия и определения)

Содержание:

ВВЕДЕНИЕ

С начала развития вычислительной техники образовались два основных направления ее использования. Первый предусматривал применение вычислительной техники для выполнения численных расчетов, которые сложно или вообще невозможно осуществить вручную. Становление этого направления способствовало интенсификации методов численных решений сложных математических задач и развития класса языков программирования, ориентированных на удобную запись алгоритмов.

Второе направление ориентировано на использования средств вычислительной техники для автоматической обработки данных. Обобщенно второе направление стали называть – «ИНФОРМАЦИОННЫЕ СИСТЕМЫ» или системы ориентированные на обработку информации. Именно это направление и является объектом исследования данной работы.

В ходе развития второго направления одним из острых вопросов стал вопрос особенностей и способов представления данных в информационных системах. Естественно первые информационные системы оперировали информацией представленной в виде обычных файлов. Но такой подход очень быстро исчерпал свои возможности. Основными проблемами стали большие объемы информации и необходимость более эффективного представления данных с целью уменьшения объема и ускорения процессов обработки, основным из которых является поиск.

В процессе своего развития человечество веками накапливало знания. И только во второй половине ХХ и в начале XXI века чрезвычайную актуальность приобрел вопрос сортировки (как подготовительного этапа для организации поиска) и обработки (поиск и фильтрация по ранее определенным критериям) массива информации. Хранение и обработка информации ‑ важнейшие функции компьютера. Именно в процессе решения конкретных прикладных задач происходит обработка нужных данных по заданному алгоритму. Данные могут быть самыми разнообразными: числа, фамилии, адреса, названия и тому подобное. В течении продолжительного времени для решения отдельной задачи использовалась собственная совокупность данных, в большинстве представляемая набором разрозненных файлов. При этом набор данных был очень индивидуальным с жесткой привязкой к конкретной реализации информационной системы, ее способам обработки и хранения информации. Такие данные не могли быть использованы другой системой или для решения другой задачи. Такой подход представления данных в ИС имеет ряд недостатков, в частности, его недостатками являются отсутствие инфицированности, избыточность и несогласованность данных, для такого способа организации данных невозможно предложить универсальных формализованных методов обработки и технологий взаимодействия.

Точкой отсчета новой информационной эпохи стала именно появление первых баз данных (в дальнейшем - БД). В самом общем случае БД ‑ это файл специального формата, содержащий определенным образом структурированную информацию.

Объектом исследования в работе являются информационные системы – как компьютерные программы взаимодействия и обработки данных.

Предметом исследования являются эффективные современные способы представления данных в виде баз данных и особенности взаимодействия ИС с данными.

Цель работы – рассмотреть понятие БД, как основного способа представления данных в современных ИС.

Для достижения цели исследования в работе поставлены следующие задачи:

‑ определить основные термины и понятия связанные с предметом исследования;

‑ охарактеризовать базы данных как структурированный способ представления данных;

‑ рассмотреть технологии взаимодействия с данными представленными в виде БД;

‑ предложить пример проектирования базы данных для информационной системы в конкретной прикладной области.

1 ОБЩИЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ

Одним из направлений применения средств вычислительной техники является их использования автоматизированных информационных системах (ИС). ИС представляет собой программный комплекс, функции которого состоят в поддержке надежного хранения информации, выполнении преобразований информации и/или вычислений, предоставлении пользователям удобного и легко осваиваемого интерфейса. Обычно объемы информации, с которыми приходится иметь дело таким системам, достаточно велики, а сама информация имеет достаточно сложную структуру. Классическими примерами информационных систем являются банковские системы, системы резервирования билетов, мест в гостиницах и т.д.

Первые информационные системы основывались на файловых системах. Файловая система – набор программ, которые выполняют некоторые операции над хранящимися во внешней памяти данными, причем каждая программа определяет свои данные, и управляем ими.

С точки зрения прикладной программы, файл – это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные. Пользователи видят файл как линейную последовательность записей и могут выполнить над ним ряд стандартных операций:

создать файл (требуемого типа и размера);
открыть ранее созданный файл;
прочитать из файла некоторую запись (текущую, следующую, предыдущую, первую, последнюю);
записать в файл на место текущей записи новую, добавить новую запись в конец файла.

Следующим шагом в развитии информационных систем явился новый подход к управлению информацией, который был реализован в рамках новых программных систем, названных Системами Управления Базами Данных (СУБД), а сами хранилища информации, которые работали под управлением этих систем, стали называть базами данных.

Уже из этого вступления можно сделать вывод о широте темы. Естественно в разрезе темы могут рассматриваться различные классификации, сравнение форматов, структурные особенности данных и многое другое. Объем работы не позволяет смотреть на вопрос исследования так широко. Исходя из этого, в работе был конкретизирован предмет исследования – базы данных, как современный и эффективный способ представления данных в ИС.

Дальнейшие исследования будут касаться исключительно этого аспекта тематики.

В самом общем случае БД ‑ это файл специального формата, содержащий определенным образом структурированную информацию.

В течение продолжительного времени для решения отдельной задачи использовалась собственная совокупность данных (она не могла быть использована в другой задачи). Такой способ использования данных является неудобным. В частности, его недостатками являются избыточность и несогласованность данных (другие недостатки будут рассмотрены далее). Например, для высшего учебного заведения разработана программа подсчета ежегодного нагрузки преподавателей и программу учета использования преподавателями фондов библиотеки. Для обеих программ используются такие общие данные: фамилия, имя, отчество сотрудника, его должность, принадлежность к определенной кафедры. Однако каждая из созданных программ использовала эти одинаковые данные о преподавателях из собственного файла, то есть данные дублируются (избыточность). Понятно, что хранение одних и тех же данных в одном файле, независимо от программы, которые использует эти данные, значительно экономит ресурсы ПК. Несогласованность данных заключается в том, что технологически трудно проследить внесении изменений одновременно во все файлы (например, изменение фамилии преподавателя, его должность и т.п.). Так, изменение фамилии преподавателя временно могла быть отражена только в одном из файлов данных - в том, что используется для расчета нагрузки, а в другом файле, - который обслуживает библиотечную программу, - остаться без изменений (изменения вовремя не внесены по технологическим причинам). Таким образом, возникает несогласованность данных, ведь в обоих случаях речь об одном и том же лице, хоть компьютер будет оперировать двумя разными фамилиями.

Такие недостатки и вызвали в начале 60-х годов появление БД. БД является проявлением современности, поскольку создать аналог БД вне компьютера почти невозможно. Прототипами БД можно считать библиотечные каталоги или телефонные справочники. Однако, сведения в них остаются неизменными до очередного обновления каталога или переиздание справочника. БД ‑ большой благоустроенный комплекс информации, который хранится на компьютерных носителях обычно вместе с программой, позволяющей осуществлять быстрый поиск данных, их обновления и печать. Без собственной БД теперь не обходится ни одно учебное заведение, государственное учреждение, частная фирма или корпорация. Современные технологии БД является результатом развития в течение нескольких последних десятилетий способов обработки данных и управления имеющейся информацией.

Обработка данных развивалась от простых методов 50-х годов до сложных интегрированных систем современности. Первые системы обработки данных выполняли только канцелярскую работу, сокращая тем самым бумажный оборот. Новые системы накапливали информацию и осуществляли управление ею.

В конце 60-х - начале 70-х годов произошел переход от обработки данных к обработке информации. Это было признанием того, что информация не является простой записью данных. В этом контексте следует различать данные и информацию. Под данными обычно понимают разрозненные факты. Информация ‑ это организованные и обработанные данные или выводы из них. Информация ‑ это ресурс, имеющий большую ценность, а потому важно научиться организовывать его и управлять им. Постепенное признание этого факта привело к пониманию ценности информации и потенциала компьютерных систем в процессе поддержания такого значительного ресурса, как информация. Так, в конце 60-х появились информационно-управляющие системы. Такие системы использовали уже имеющиеся в компьютере данные и давали ответы на ряд вопросов. Информационная система (ИС) ‑ это программный комплекс, функциями которого являются:

1) поддержка надежного хранения информации в памяти компьютера;

2) выполнение специфических для конкретного приложения преобразований информации и (или) вычислений;

3) предоставление пользователям удобного интерфейса.

Сегодня для работы с файлами баз данных используют специальное программное обеспечение - системы управления базами данных (СУБД). Средствами СУБД осуществляется наполнение базы данных, поиск необходимой информации, отчетов, создание новых или удаления существующих БД, экспорт и импорт данных и др. Фактически под базой данных чаще понимают не саму базу данных как хранилище информации, но и сопроводительное программное обеспечение, то есть СУБД + БД.

Наиболее популярные базы данных - Microsoft SQL Server, Oracle, PostgreSQL или MySQL - используют реляционную модель представления данных. В этих базах данных сущности представляются в виде строк таблиц, их параметры - в виде столбцов, а связь между сущностями различных типов осуществляется с помощью отношений один-к-одному или один-ко многих. Типы данных, которые могут иметь столбцы, ограничиваются базовыми типами (Integer, double, varchar, text). Системы управления базами данных, как правило, не позволяют расширить систему типов путем добавления собственного типа данных.

Реляционные БД имеют собственный математический аппарат. Для реляционных БД в свое время Кодд заложил фундамент математического аппарата реляционной алгебры. Этот математический аппарат объясняет, как должны выполняться основные операции над отношениями в базе данных. В 1986 году был принят первый стандарт SQL-86, который определил всю судьбу реляционных БД. После принятия стандарта все разработчики реляционных СУБД обязаны были следовать ему. Так, реляционные базы данных, как правило, используют язык SQL как языка запросов.

Реляционные базы данных очень успешны на рынке, и написано очень много программ, которые в качестве хранилища данных используют именно эти базы данных. В подобные продукты вложены большие деньги, и заказчики будут дальше вкладывать деньги в их развитие.

Но традиционные базы данных не всегда идеально подходят для хранения данных. Да, порой бывает сложно использовать реляционные БД в информационных системах со сложной объектно-ориентированной архитектурой.

Программа может иметь, например, типы данных для больших и неструктурированных объектов мультимедиа, географических информационных систем или Computer Aided Design/Computer Aided Manufacturing. Сложность заключается в том, что, во-первых, нужно разрабатывать не только архитектуру классов приложения, но и схему базы данных. Во-вторых, затрачивается время на разработку функционала, который сможет представить табличные данные в виде объектов классов и наоборот.

Эти аргументы (приведенные выше) определяют необходимость исследования и развития других подходов структурирования и представления данных, альтернативных ставшим уже классическими реляционным базам. Такой альтернативой могут стать объектно-ориентированные БД.

Стоит отметить, что разнообразие способов и форматов представления информации предложенных на сегодняшний день далеко не ограничивается только реляционными и ОО БД, но далее основное внимание уделим именно этим типам.

2 БАЗЫ ДАННЫХ КАК ОСНОВНОЙ ВИД ПРЕДСТАВЛЕНИЯ ИНФОРМАЦИИ В ИС

Информация стала фактором, определяющим эффективность любой какой сфере деятельности человека. Поэтому и возникла необходимость в применении наиболее перспективных компьютерных технологий для работы с информации разного типа. Современной формой информационных систем является банки данных, в состав которых входят вычислительная система, одна или несколько баз данных (БД), система управления базами данных и набор прикладных программ (ПП).

В БД используются классические модели данных: иерархическая, сетевая, реляционная и объектно-ориентированная. Иерархическая модель является удобной для работы с иерархически упорядоченной информацией и громоздкая для информации из сложными логическими связями. Сетевая модель - это представление данных в виде произвольного графа. Преимуществом сетевой и иерархической моделей является их эффективность реализации по затратам памяти. Недостатком сетевой модели данных является сложность схемы БД. Реляционную модель предложил американский математик Кодд, который доказал, что любая совокупность данных предметной области может быть подана взаимосвязанными между собой математическими отношениями. Объектно-ориентировочные БД объединяют в себе две модели данных, реляционную и сетевую, используются при создании больших БД со сложными структурами данных.

2.1 Трехуровневое представление данных в ИС

Как было сказано выше, ядром современных информационных систем являются базы данных – специально организованные информационные массивы, накопление и обработка которых, по сути, являются центральной задачей функционирования информационных систем.

Этап проектирования данных является сегодня отдельным этапом в жизненном цикле проектирования ИС. Этап предполагает

‑ концептуальное проектирование информационной модели предметной области ИС и структур данных;

‑ разработка даталогической модели данных;

‑ физическая реализация БД, с учетом особенностей конкретно выбранного формата БД и технологий СУБД.

Концептуальное описание выполняется с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных. Концептуальную модель также называют инфологической моделью данных.

Инфологическая модель понятна людям (разработчикам, программистам, архитекторам, заказчикам, пользователям), но она не достаточно формализована для понимания машиной. По этому следующими этапами являются разработка компьютеро-ориентированных моделей.

Инфологическая модель, описанная на языке описания данных конкретной СУБД, называется даталогической моделью данных.

Последний уровень детализации модели данных – физическая модель, предполагает конкретизированное описание структуры файла (например в реляционной модели – это имя, тип поля, его длина и точность (для числовых полей).

Рисунок 2.1 ‑ Трехуровневое представление данных в ИС

Таким образом, рассматривают три уровня описания базы данных, на каждом из которых ее структура изображается по-разному.

Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ.

2.2 Реляционные БД

Реляционная модель данных основана на математическом понятии отношения и представлении отношений в виде таблиц. Модель предложена в начале 70-х лет американским ученым Э.Коддом. В любой реляционной СУБД допускается, что пользователь воспринимает БД как набор таблиц. Это касается только логической структуры БД, т.е. относится к концептуальному и внешнему представлениям. На физическом уровне БД реализуется с помощью разных структур хранения. В табл. 2.1 приведенные элементы реляционной модели. Для однозначной идентификации строк, для связывания таблиц между собой, для ускорения операций над данными применяют ключи. В табл. 2.2 приведенные возможные виды реляционных ключей. Внешний и соответствующий ему потенциальный ключ должны быть определены в одном домене.

Таблица 2.1 – Элементы реляционной модели

Элемент реляционной модели	Форма представления
Отношение	Таблица
Кортеж	Строка таблицы
Атрибут	Заголовок столбца таблицы
Ключ	Совокупность атрибутов, которые уникально определяют каждую строку таблицы, или выполняют функции связывания таблиц, или позволяют ускорить операции над таблицами
Домен	Множество значений атрибута
Схема отношения	Строка заголовков столбиков таблиц идентифицирующих связи между сущностями

Таблица 2.2 – Реляционные ключи

Название	Пояснение
Потенциальный ключ (CandidateKey)	Минимальная подмножество атрибутов отношение, которые единственным образом идентифицируют кортеж данного отношение
Первичный ключ (Primary Key)	Потенциальный ключ, который выбран для уникальной идентификации кортежей отношение
Вторичный ключ (Secondary Key)	Ключ, каждому значению которого может отвечать более чем один экземпляр индексированных данных
Внешний ключ (Foreign Key)	Совокупность атрибутов отношения, значение которых является одновременно и значениями первичного или потенциального ключа другого отношение

Задача группирования атрибутов в отношение при условии, что набор возможных отношений заранее не фиксирован, допускает большое количество вариантов схем отношений: аналитический подход - все данные собрать в одну таблицу; семантический подход - данные собирать в несколько таблиц по смыслу. Рациональные варианты должны отвечать следующим требованиям:

все таблицы должны иметь один первичный ключ;
первичные ключи, которые выбраны для отношений, должны быть минимальными;
выбранный состав отношений базы должен быть минимальным (отличается минимальной чрезмерностью атрибутов);
не должно быть проблем при выполнении операций включения, модификации и удаление данных в базе; перестройка набора отношений при введении новых типов данных должна быть минимальной;
время ответа на разные запросы к БД должно быть минимальным.

Нормализация – это процедура определения того, какие атрибуты связаны в отношении. Одна из главных задач при разработке реляционной БД – объединение в одном отношении тех атрибутов, которые связаны между собой (между которыми есть функциональные зависимости). Нормализация представляет собой поэтапный процесс замены совокупности отношений другой совокупностью (схемой), в которой отношение имеют простую и регулярную структуру. Результатом нормализации есть логическая модель БД.

Процесс проектирования БД с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая следующая итерация отвечает нормальной форме более высокого уровня и имеет лучшие свойства в сравнении с предыдущей (рис. 2.2).

Рисунок 2.2 – Соотношение нормальных форм

2.3 Объектно-ориентрованные БД

Основные определения

В начале 1980-х годов начались первые исследования и разработка концепций объектно-ориентированных баз данных.

Объектно-ориентированные базы данных ‑ базы данных, в которых информация представлена в виде объектов, как в объектно-ориентированных языках программирования.

Причиной появления систем объектно-ориентированных баз данных была потребность в более адекватном представлении и моделировании сущностей реального мира, поскольку ООБД обеспечивают гораздо более развитую модель данных, чем традиционные реляционные базы данных. Парадигма ООБД основывается на ряде базовых понятий, как объект, идентификатор объекта, класс, наследование, перегрузка и отложено связки. Любой объект при своем создании получает генерируемый системой уникальный идентификатор, который связан с объектом в все время его существования и не изменяется при изменении состояния объекта. каждый объект имеет состояние и поведение.

1. Состояние объекта ‑ набор значений его атрибутов.

2. Значение атрибута объекта ‑ это тоже определенный объект или множество объектов.

3. Поведение объекта ‑ набор методов (программный код), оперирующих над состоянием объекта.

Основные трудности объектно-ориентированного моделирования данных является следствием того, что такого развитого математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует.

Декларируемые возможности ООБД

Обязательные возможности ООБД:

1. Поддержка сложных объектов

Механизм сложных объектов позволяет объекта иметь атрибут, могут тоже быть объектами. Атрибутами могут быть массивы, списки, хеш таблицы и тому подобное.

2. Идентификация объектов

Каждая сущность в базе данных имеет уникальный идентификатор OID. Он есть свойством объекта отличает его от других объектов и существует в течение всего жизненного цикла объекта. Идентификатор объекта должен быть независимым от значений его атрибутов

3. Инкапсуляция

Объектно-ориентированная модель представления данных навязывает инкапсуляции и сокрытие информации. Это означает, что состояние объекта может скрываться для запрета доступа к внутренней логики работы объекта.

4. Поддержка структур и классов

В ООП структура объединяет общие характеристики набора сущностей.

5. Наследование и полиморфизм

Наследование ‑ одно из базовых понятий в объектно-ориентированном программировании. Связано с тем, что класс может иметь класса-наследника, который имеет те же свойства, что и базовый класс, но также и иметь новые свойства.

6. Вычислительная полнота

SQL (как основной язык реляционных БД) не имеет всех возможностей обычных языков программирования. Языки типа Pascal, C, C# или Java можно назвать вычислительно полными, так как они используют все вычислительные возможности компьютера. SQL можно назвать реляционно полным, так как в нем реализована вся логика реляционной алгебры. Так, любой код, написанный на SQL, можно переписать на C ++, но далеко не любой код на C ++ можно переписать на SQL.

Поэтому большинство программ, использующих реляционные базы данных, включают использование встроенных SQL-запросов в рамках обычной языка программирования.

Это означает, что язык манипулирования данными должен быть языком программирования общего назначения.

7. Параллелизм

8. Восстановление

9. Специальная система запросов

10. Возможность добавления новых типов данных

Набор типов данных должен быть расширяемым. Пользователь должен иметь средства создания новых типов данных на основе набора определенных системных типов. Более того, между способами использования системных и пользовательских типов данных не должно быть никаких различий.

Сравнение концепций ООБД и реляционных БД

Соотношение между базовыми понятиями ООБД и РБД показаны в табл. 2.3

Таблица 2.3 – Соотношения между базовыми понятиями

ООБД	Реляционная БД
Объект	Строка таблицы
Поле	Столбик таблицы
Иерархия классов	Схема данных БД
Наследование	Один из видов соотношения «1 к 1», когда основной ключ таблицы-наследника одновременно является внешним ключом на основной ключ таблицы -предка
Метод	Частично реализуется встроенными процедурами и триггерами
Полиморфизм	-
Инкапсуляция	-

В таблице 2.3 указаны соотношения между базовыми понятиями, используются в объектно-ориентированных и реляционных базах данных.

Преимущества и недостатки ООСУБД

Преимущества ООСУБД:

1. Отсутствует проблема несоответствия модели данных в приложения и БД (Impedance mismatch). Все данные хранятся в БД в том же виде, что и в модели программы.

2. Не нужно отдельно поддерживать модель данных на стороне СУБД.

3. Все объекты на уровне источника данных строго типизированные. Преимущества использования объектно-ориентированных баз данных перед реляционными БД:

1. Объектно-ориентированные базы данных позволяют представлять сложные объекты более непосредственным образом, чем реляционные системы.

2. Определение собственных абстракций. Объектно-ориентированные базы данных предоставляют возможность определять новые абстракции и управлять реализацией таких абстракций. Современные пакеты ООБД дают пользователю возможность создание нового класса с атрибутами и методами, иметь классы, с унаследованными атрибутами и методами от суперклассов. Представляется возможность создавать экземпляры класса, каждый из которых обладает уникальным объектным идентификатором, извлекать эти экземпляры по одному или группами, а также загружать и выполнять методы, определять объекты как совокупности других объектов, определять свойства которые тоже могут иметь сложную структуру и определяться с помощью конструктора коллекций.

3. Облегченное проектирование некоторых связей. В объектно-ориентированных базах данных поддерживается средство инверсных связей для выражения взаимных ссылок между двумя объектами (бинарная связь).

4. Отсутствие необходимости в оговоренных пользователями ключах. В модели ООБД появляется понятие идентификаторов объектов, они автоматически генерируются системой и гарантированно являются уникальными для каждого объекта. Это обстоятельство, наряду с тем, что в модели ООБД устраняется потребность в обусловленных пользователями ключах, дает объектно-ориентированным базам данных другие преимущества. Во-первых, идентификатор объекта не может быть модифицирован приложением. Во-вторых, понятие «идентифицированный объект» влечет отдельное и согласованное понятие идентичности, независимое от того, каким образом проводится доступ к объекту или как объект моделируется с помощью описательных данных.

5. Наличие предикатов сравнения. В РБД сравнение всегда базируется только на значениях. В этой модели две записи являются одной и той же сущностью, если все их ключевые атрибуты имеют одинаковые значения. Однако в модели ООБД были разработаны и определены другие типы сравнения, которые позволяют сравнивать сущности с определенной степенью идентичности. Этот механизм существенно расширяет возможности использования данных, особенно для адаптивных интеллектуальных систем.

6. Меньшая потребность в соединениях. Реляционных соединение - это механизм, сопоставляет отношения между таблицами на основе значений соответствующих пар атрибутов в этих отношениях. В ООБД потребность в таких сочетаниях значительно меньше. Но поскольку в ООБД два класса могут иметь соответствующие пары атрибутов, в этой модели все еще может сохраняться возможность проведения реляционного соединения.

7. Выигрыш в производительности. В большинстве ООБД при загрузке объекта в память сохранены в этом объекте идентификаторы превращаются в указатели в памяти.

8. Объектная алгебра. Объектная алгебра существенно уступает реляционной алгебре в развитии, но как бы там ни было, такая алгебра существует.

Недостатки использования объектно-ориентированных баз данных перед реляционными БД:

1. Недостаточность возможностей для оптимизации запросов. Одной из наиболее значительных проблем в ООБД является оптимизация декларативных запросов. Оптимизацию запросов к ООБД затрудняет дополнительная сложность самой объектно-ориентированной моделью данных.

2. Отсутствие стандартной алгебры запросов. Это обстоятельство тоже затрудняет оптимизацию запросов.

3. Проблемы с безопасностью. В РБД поддерживается авторизация, тогда как в большинстве ООБД она отсутствует. РБД предоставляют пользователям передавать и изымать права на чтение или изменения. ООБД смогут получить более широкое распространение в области бизнеса только в том случае, если эта функция в них будет усовершенствована.

4. Ограниченные возможности настройки производительности. В большинстве ООБД является лишь ограниченные возможности настройки производительности. В РБД инсталляторам предоставляется возможность настраивать производительность системы путем задания большого количества параметров, устанавливаются системным администратором.

5. Ограниченная интеграция с объектно-ориентированными системами программирования. Конфликты по именам, необходимость переделывать иерархии классов, склонность ООБД к перегрузке системных операций.

В принципе, ООСУБД ‑ это объектно-ориентированная база данных, предоставляющая возможности СУБД объектам, которые были созданы с использованием объектно-ориентированного языка программирования.

3 ТЕХНОЛОГИИ ВЗАИМОДЕЙСТВИЯ С ДАННЫМИ В БД

Сегодня базы данных являются неотъемлемым элементом практически любого приложения. В одних приложениях БД может использоваться полнофункционально – формирование запросов, фильтрация и т.д., а в других просто как удобный формат хранения данных. Форматы данных и протоколы обмена сложны и существенно отличаются друг от друга, поэтому создание приложения СУБД является трудоемким процессом. Однако на логическом уровне данные, получаемые от сервера (или из места их хранения), не зависят от типа базы данных – они представляются в виде таблиц, между которыми организованы связи. Поэтому были созданы механизмы, связывающие приложение и базу данных, то есть, с одной стороны, выполняющие функции получения данных из базы (с учетом особенностей хранения или правил обмена), а с другой – реализующие интерфейс для доступа к данным на логическом уровне, не зависящий от выбранного типа базы данных.

Механизмы доступа к базам данных снижают сложность обмена информацией с базами, однако интерпретация результатов их работы также достаточно трудоемка. В языках и средах программирования (фраймворки, библиотеки) реализованы наборы компонентов, предназначенные для взаимодействия с механизмами обмена.

Таким образом, можно выделить несколько субъектов, участвующих в движении информации между базой данных и приложением (например, пользовательским интерфейсом):

1) интерфейсная часть приложения или его программная часть, манипулирующая информацией, хранимой в базе данных;

2) компоненты, обеспечивающие связь приложения с механизмом доступа к базе данных;

3) механизм доступа к базе данных;

4) база данных.

На рис. 3.1 представлена схема движения информации между приложением и базой данных[17].

Движение информации от базы данных к приложению

Рисунок 3.1 – Движение информации от базы данных к приложению

Из схемы видно, что при разработчике приложения-СУБД (система управления базами данных) программист работает с наборами компонентов, предназначенных для обмена информацией с базами данных и ее отображения. В зависимости от выбранного механизма доступа к базе данных некоторые наборы компонентов могут не использоваться, однако все они, вне зависимости от особенностей используемой базы данных и механизма доступа к ней, имеют схожие свойства и методы, так как основная их часть унаследована от класса TDataSet (Data Set – набор данных).

Операционная система Windows имеет в своем составе несколько механизмов доступа к базам данных: ODBC, OLE DB и ADO[7].

Кратко остановимся только на технологии доступа ADO.

Технология Microsoft ACTIVEX Data Objects обеспечивает универсальный доступ к источникам данных из приложений к БД. Такую возможность предоставляют функции набора интерфейсов, созданные на основе общей модели объектов СОМ и описанные в спецификации OLE DB.

Технология ADO и интерфейсы OLE DB обеспечивают для приложений единый способ доступа к источникам данных разных типов (рис. 3.2). Например, приложение, использующее ADO, может применять одинаково сложные операции и к данным, что хранятся на корпоративном сервере SQL, и к электронным таблицам, и локальным СУБД. Запрос SQL, направленный любому источнику данных через ADO, будет выполнен.

Рисунок 3.2 ‑ Схема доступа к данным через ADO

Для обработки файловых последовательностей, электронных таблиц, файлов электронной почты на помощь приходят механизмы ADO и интерфейсы OLE DB.

OLE DB является набором специализированных объектов СОМ, которые инкапсулируют стандартные функции обработки данных, и специализированные функции конкретных источников данных и интерфейсов, которые обеспечивают передачу данных между объектами.

Согласно терминологии ADO, любой источник данных ( база данных, электронная таблица, файл) называется хранилищем данных, с которым с помощью провайдера данных взаимодействует приложение. Минимальный набор компонентов приложения может включать объект соединения, объект набора данных, объект процессора запросов

Перед открытием соединения необходимо задать его параметры. Для этого предназначенное свойство property Connectionstring: Widestring;

Набор параметров меняется в зависимости от типа провайдера и может настраивать как в ручном режиме, так и с помощью специального редактора параметров соединения, который вызывается для компонента TАdoСonnection.

Как раз наличие унифицированных технологий делает использование реляционных баз данных доступным. Разработка ИС с использованием БД на основе готовых технологий и решений доступа к данным становится существенно проще, готовые решения серверов БД и компонент взаимодействия позволяет разработчику сосредоточиться на анализе бизнес-логики, и отстраниться от технических моментов.

Для других типов представления баз данных (отличных от реляционных) технологии разработаны недостаточно, или вообще отсутствуют в унифицированном представлении. Именно этот фактор является одним из сдерживающих факторов массового использования и популярности тех же ООБД.

4 ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ НА ПРИМЕРЕ ИС В КОНКРЕТНОЙ ПРИКЛАДНОЙ ОБЛАСТИ

Для того что бы предать работе уникальности и не ограничиваться только теоретическим обзором, проиллюстрируем проектирование структуры данных и представление информации в виде БД для конкретной прикладной задачи и информационной системы, призванной обрабатывать информацию в данной предметной области.

4.1 Словесная постановка задачи

Каталог картин содержит сведения о музеях мира и частных коллекциях картин, их авторах, а также о выставках.

Картина характеризуется названием, автором, годом написания, фактурой, техникой, стилем, владельцем, номером по каталогу и т.п. Как правило, картина имеет несколько копий, которые создавались самим художником или его мастерской. Копии находятся в различных музеях либо в частных коллекциях.

Периодически картины, принадлежащие одному или разным владельцам, участвуют в выставках. Выставка характеризуется временем и местом проведения (страна, название музея или выставочного зала, адрес), сведениями об организаторах, количеством экспонатов и их полным перечнем, числом посетителей.

Картины могут находиться в реставрации. Представляют интерес сведения о реставраторах, срока реставрации, месте реставрации.

4.2 Анализ предметной области, информационные единицы и особенности представления информации

Музей ‑ учреждение, занимающееся сбором, изучением, хранением и экспонированием предметов ‑ памятников естественной истории, материальной и духовной культуры, а также просветительской и популяризаторской деятельностью.

Музеи могут быть как государственные, так и частные. Частные музеи ‑ это музеи, которые принадлежат частным лицам, созданы их усилиями и поддерживаются их средствами. Как правило, коллекции частных музеев отражают эстетические, культурные или научные интересы своих создателей и являются доступными для посещения. Превращение частных коллекций в частные музеи связано со стремлением к демонстрации коллекций, с желанием их популяризировать и сделать доступными для изучения. Частные музеи могут передаваться по наследству, а также в дар какому-либо учреждению, ведомству, то есть сохранять или менять свою принадлежность.

В музеях и галереях проходят художественные выставки. Художественная выставка ‑ временный публичный показ художественных произведений, она является основной формой ознакомления зрителей со станковым искусством.

Владельцами частных музеев чаще всего являются коллекционеры предметов искусства.

Коллекция ‑ систематизированное собирание чего-либо, объединённое по какому-то конкретному признаку, имеющее внутреннюю целостность и принадлежащее конкретному владельцу частному лицу, организации, государству. Человека, занимающегося коллекционированием, называют коллекционером.

Коллекционеры обычно имеют коллекции одного вида, несколько разных или межвидовые тематические. Некоторые виды коллекционирования предполагают большие финансовые затраты, некоторые нет. Часто коллекционирование ставит перед коллекционером задачу нахождения очень редких экземпляров, которых ни у кого нет, или тираж которых существенно ограничен.

Картина в переносном или более общем значении любое законченное, цельное произведение искусства, в том числе живое и яркое описание, устное или письменное, видов природы.

Репродукция или копия оригинала может также называться картиной, если в соответствующем контексте не важно, копия это или оригинальное произведение.

Картина характеризуется такими характеристиками: название, автор, год, фактура, техника, стиль, владелец, каталожный номер.

Название, наименование – словесное обозначение произведения искусства, созданное на основе изображенного мотива, идеи.

Автор – человек, который создал то или иное произведение искусства.

Год – дата окончания работы над каким-либо произведением искусства.

Фактура (от лат. factura обработка, строение) характер поверхности художественного произведения, её обработки в изобразительных искусствах, своеобразие художественной техники в поэзии, музыке, живописи или скульптуре. В живописи существует много различных типов фактур.

Техника – вид исполнения работы в зависимости от применяемых материалов или инструментов.

Стиль ‑ общность образной системы, средств художественной выразительности, творческих приемов, обусловленная единством идейно-художественного содержания. Можно говорить о стиле отдельных произведений или жанрах (напр., о стиле русского романа сер. 19 в.), об индивидуальном стиле (творческой манере) отдельного автора, а также о стиле целых эпох или крупных художественных направлений, поскольку единство общественно-исторического содержания определяет в них общность художественно-образных принципов, средств, приемов (таковы, напр., в пластическом и др. искусствах романский стиль, готика, Возрождение, барокко, рококо, классицизм). Примерами стилей в живописи являются: импрессионизм, экспрессионизм, сюрреализм, примитивизм, модерн, постмодернизм и т.д.

Владелец – человек или организация, которая владеет произведением искусства.

Каталожный номер это цифровой и/или буквенный код, который присваивается объекту, что позволяет с точностью до 100% установить его принадлежность, а так же ее характеристики и другие данные.

Естественно базовым информационным объектом в этой предметной ИС должна быть «КАРТИНА». Согласно заданиям последующих КР все запросы и информационные поиски связаны именно с этим объектом. Характеристики (атрибуты сущности) описаны в задании и являются достаточно тривиальными: автор, название, год и т.д. Хранение непосредственно самого изображение картины – для информационной системы не является обязательным (а иногда и нежелательным) по нескольким причинам:

‑ эта информационная составляющая не используется для поиска и запросов;

‑ хранение изображений в БД существенно увеличивает ее конечный размер, а в случае сетевых БД – размер передаваемой клиенту информации по запросу.

С другой точки зрения (точка зрения пользователя) не включить в ИС, которая имеет основным информационным объектом картину, непосредственно само изображение – тоже было бы не совсем правильно.

Компромиссом в этой ситуации может быть следующее решение.

Изображения картин хранятся в отдельном каталоге или на отдельном удаленном сервере. В БД среди атрибутов характеризующих сущность сохраняется название файла или ссылка на ресурс. С целью экономии трафика и скорости передачи данных (по умолчанию) изображения не передаются из БД. Этот вариант актуален, когда речь идет о больших группах картин, например – картины находящиеся в данный момент на реставрации, или картины, представленные на конкретной выставке и т.д.. Но, в то же время, такой подход позволит увидеть изображение выбранной картины по требованию пользователя, что является достаточно удобным и грамотным решением в данной ситуации.

4.3 Выделение сущностей и определение атрибутов

Проанализировав задание и предметную область, стоит выделить следующие основные сущности:

Музей

название

страна

город

адрес

профиль

Частная коллекция

владелец

Выставка

название

страна

город

адрес

выставочный зал

время проведения

ДОПОЛНИТЕЛЬНО

Картина

название

автор

год написания

фактура

техника

стиль

владелец

номером по каталогу

местонахождение

ССЫЛКА НА ИЗОБРАЖЕНИЕ

Реставратор

название

место реставрации

Ограничения:

В словесной постановке задачи сказано, что картина может иметь несколько копий. Предлагается рассматривать это как отдельные картины. Во-первых, потому, что они могут иметь различных авторов и различный год написания. Во-вторых, хранение всех копий в одном информационном контейнере очень усложняет структуру БД и нарушает основные принципы нормализации данных.
Информация о выставке указанная в задании (сведениями об организаторах, количество экспонатов и их полный перечень, число посетителей) не будет учитываться в БД в «чистом виде» в качестве атрибутов. Например: организаторами могут выступать как частные лица так и организации различного масштаба, полный перечень и количество выставленных экспонатов не являются поисковыми ключами и могут быть добавлены как описание, количество посетителей – достаточно сложно оценимая характеристика и также не будет использоваться для фильтрации или поиска. Предлагается добавить текстовое поле «Дополнительно», где по мере необходимости указывать подобную информацию. С «перечнем экспонатов» предлагается поступить аналогично как с «изображение картины», если организаторы предоставляют такую информацию – хранить ее как отдельные файлы в специально отведенном месте. А в БД хранить только ссылку на ресурс.
Так как реставрация является временным процессом, то для информационного обеспечения предлагается добавить в структуру БД отдельную «буферную» таблицу, где будет храниться информация о нахождении картины на реставрации и срок реставрации
Предлагается разделить атрибут «местонахождение» на «владелец» ‑ характеристика того, кому фактически принадлежит картина как материальный объект (частное неопределенное лицо, частная коллекция с указанием владельца, музей, организация) и «текущее местонахождение» ‑ атрибут, определяющий где объект находится в текущее время (музей, выставка и т.д.)

4.4 Построение ER-модели и ее анализ

Для проектирования структуры БД и построения модели «сущность -связь» будем использовать средство проектирования MS Visio.

Уже на этапе проектирования структуры таблиц становится понятно, что представлять сущности в том виде, в котором они описаны в П.4.3 работы неэффективно с точки зрения теории БД и нормализации.

Рисунок 4.1 – первичное представление сущности «Картина»

Как видно на рисунке 4.1, изначально в качестве атрибутов в эту сущность были интегрированы все поля, представленные в П.4.3. Но проанализировав ситуацию, становится понятным, что тут необходима декомпозиция данных и вынесение в отдельные таблицы-справочники информации типа «Фактура», «Стиль» и т.д. Справочной информацией в БД называются относительно статичные данные или характеристики целевых объектов, которые будут повторяться для определенных подмножеств (например – в каталоге будет 1550 картин в стиле «пейзаж»). С целью экономного представления данных все эти характеристики стоит вынести в отдельные таблицы-справочники, а в целевой (консолидирующей) таблице хранить только коды этих характеристик.

Вопросы также вызывает поле «Номер в каталоге». Если речь идет о нашей системе, то эту функцию будет выполнять ID – поле ключ. Но, возможно, речь идет о каких-то мировых или музейных каталогах (стандартизированных). Ввиду этого – оставим это поле в структуре, но пометим его как «не обязательное».

Другим примером декомпозиции будет вынесение атрибута «страна» в справочную информацию. Эта характеристика участвует в нескольких сущностях и имея перечень значений в справочной таблице можно будет организовать автоматизированный ввод – как выбор из списка значений (предварительно справочник должен быть заполнен). В справочники предлагается вынести и «автор», так как у всемирно известных художников количество работ достаточно велико и это также скажется на эффективности представления данных.

При установлении связей имеем ситуацию. Например: музей характеризуется «страной» и «городом» и с этой позиции связи могут выглядеть так (рис. 4.2). Во всех случаях связь типа «1 ко многим».

Рисунок 4.2 – «Город» и «Срана» в разных таблицах

При такой структуре осложняются связи, но упрощается поиск по ключам «Город», «Страна». Второй вариант: любой «город» однозначно характеризуется «страной» (одноименные города не учитываем), тогда структура может выглядеть так (рис. 4.3). В таком случае структура связей упрощается, хранение более эффективно, но усложняется поиск (добавляются промежуточные таблицы)

Рисунок 4.3 – таблица «Город» хранит код «Страна»

Структура БД в виде ER – модели в нотации IDEF1x, после всех изменений, представлена на рис. 4.4

Структура БД включает:

11 таблиц – справочников;

Три основных таблицы: «Местонахождение», «Владелец» и консолидирующая таблица «Картина»

Рисунок 4.4 – ER-модель БД

4.5 Макеты таблиц БД

Не имеет смысла приводить примеры макетов всех справочников, так как их структура достаточно проста и однотипна, для примера рассмотрим следующие:

Таблица – Страна

Атрибут	Тип	Описание
ID_Cn	BYTE	Числовое поле, уникальный первичный ключ
Страна	CHAR(20)	Название страны

Таблица – Город

Атрибут	Тип	Описание
ID_Sty	INTEGER	Числовое поле (городов гораздо больше чем стран по этому тип INTEGER, при необходимости можно заменить на LONG), уникальный первичный ключ
Страна	CHAR(20)	Название города
ID_Cn	BYTE	Вторичный ключ, определяет принадлежность города стране

Таблица – Стиль

Атрибут	Тип	Описание
ID_St	BYTE	Числовое поле, уникальный первичный ключ
Стиль	CHAR(20)	Название стиля

Таблица – Местонахождение

Атрибут	Тип	Описание
ID_ptn	INTEGER	Числовое поле, уникальный первичный ключ
Срок	DATE	Определяет конечную дату нахождения картины в этом месте
ID_M	INTEGER	Вторичный ключ, определяет местонахождение картины в музее
ID_Ex	INTEGER	Вторичный ключ, определяет местонахождение картины на выставке
ID_Rec	INTEGER	Вторичный ключ, определяет местонахождение картины в реставрации

* последние три поля являются взаимоисключающими, это можно реализовать либо через промежуточные таблицы, либо программным способом.

В таблице «Картина» уникальными (собственными) полями являются только: «название», «год», «ключевое поле», «каталожный номер». Все остальные поля подставляются из других таблиц по вторичному ключу.

Таблица – Картина

Атрибут	Тип	Описание
ID_P	LONG	Числовое поле, уникальный первичный ключ
Название	ТЕКСТ (30)	Хранит название произведения
Год	INTEGER	Год написания картины автором
Каталожный номер	CHAR(10)	Каталожный код картины во внешних каталогах
ID_Av	INTEGER	Вторичный ключ, определяет автора картины
ID_St	INTEGER	Вторичный ключ, определяет стиль картины
ID_F	INTEGER	Вторичный ключ, определяет фактуру картины
ID_Tch	INTEGER	Вторичный ключ, определяет технику выполнения картины
ID_Ptn	INTEGER	Вторичный ключ, определяет местоположение картины
ID_Pr	INTEGER	Вторичный ключ, определяет владельца картины
Ссылка	CHAR(20)	Ссылка на расположение изображения

Вид описания сущности «Картина» в пользовательском табличном представлении приведен в приложении 1.

ВЫВОДЫ

Способы представления данных в информационных системах претерпели определенную эволюцию. В первичных реализациях данные ИС представлялись разрозненным набором файлов. Но такой подход имеет множество недостатков.

В ходе развития подходов и технологий для эффективного представления данных были предложены базы данных.

Работа состоит из четырёх разделов.

В первом разделе приводятся основные термины и трактуются базовые понятия предметной области исследования. Тут приведена короткая история развития и перехода от файловой системы к базам данных при представлении данных для ИС.

Второй раздел рассматривает два из известных типов БД. Реляционная база (РБД) и объектно-ориентированная база (ООБД) выбраны не случайно. Первая является наиболее распространённой и широко применимой при проектировании ИС сегодня, вторая – имеет все шансы получить широкое распространение ввиду актуальных тенденций в секторе программирования. Кроме того что ООБД имеет более четко выраженную интеграцию с ПП на основе объектно-ориентированного подхода, некоторые особенности этого типа БД дают ей существенные преимущества над другими типами БД. В модели ООБД были разработаны и определены типы сравнения, которые позволяют сравнивать сущности с определенной степенью идентичности. Этот механизм существенно расширяет возможности использования данных, особенно для адаптивных интеллектуальных систем.

Третий раздел коротко рассматривает некоторые стандартные технологии доступа к реляционным БД. Именно наличие этих технологий не в последнюю очередь определяет популярность РБД.

Четвертый раздел имеет практическую прикладную направленность. В данной части работы проводится анализ и проектирования структуры данных на основе реляционного подхода для конкретной прикладной области и ИС, ориентированной на обработку информации в данной области.

Содержание работы полностью отвечает тематике, структура работы отображает последовательность задач, определенных во введении.

СПИСОК ЛИТЕРАТУРЫ

Architecture In Object Oriented databases. – Режим доступа: http://citeseerx.ist.psu.edu/viewdoc/download?rep=rep1&type=pdf&doi=10.1.1.116.434/. – Дата доступа: 29.11.2019
Microsoft Access 2007. Шаг за шагом: Практическое пособие / Пер. с англ. – М.: ЭКОМ, 2011. – С.63
PostgreSQL. Tutorial inheritance. – Режим доступа: https://www.postgresql.org/docs/8.4/static/tutorial-inheritance.html/. – Дата доступа: 02.12.2019
S. K. Singh. Database Systems: Concepts, Design and Applications / S. K. Singh – London : Dorling Kinderslay. – 2011
Thomas A. Mueck. Index Data Structures in Object-Oriented Databases / Thomas A. Mueck – Luxembourg : Springer Science & Business Media. – 1997
Багриновский К.А. Хрусталев Е.Ю. Новые информационные технологии. – М.: ЭКО, 2011. – С.122
Базы данных. «Проектирование, реализация и сопровождение», Томас Конном, Королинг Берг – 2010. – С.102
Гаврилова Т.А. Базы знаний интеллектуальных систем: Учебное пособие/ Т.А.Гаврилова, В.Ф. Хорошевский-СПб.: Питер, 2012. - 384 с.
Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. - Вильямс, 2010. – С.125
Дейт К. Введение в системы баз данных, 8-е издание. – Вильямс, 2006. – С.725
Дейт К., Дарвен Х. Основы будущих систем баз данных. Третий манифест. – Янус-К, 2011. – С.102
Дунаев В.В. Базы данных. Язык SQL. – СПб. : БХВ-Петербург, 2010. – С.88
Иванова Г.С. – «Основы программирования» Учебник для вузов. – М.: Изд-во МГТУ им. Н.Э. Баумана, 2010. – С.156
Информатика и информационно-коммуникационные технологии. Базовый курс: И.Г. Семакин, С.В. Русаков, Л.В. Шестакова. - М: БИНОМ, Лаборатория знаний, 2016. – С. 169
Мирошниченко Г. Реляционные базы данных. Практические приемы оптимальных решений. – СПб. : БХВ-Петербург, 2011. – С.199
Объектно-ориентированные базы данных - основные концепции, организация и управление: краткий обзор. – Режим доступа: http://citforum.ru/database/articles/art_24.shtml/. – Дата доступа: 13.12.2019
Реализация баз данных Microsoft SQL Server 7.0. Учебный курс: официальное пособие для самостоятельной подготовки. - М.: Русская редакция, 2015. - 528 с.
Скотт В. Эмблер, Прамодкумар Дж. Садаладж Рефакторинг баз данных. Эволюционное проектирование. – Вильямс, 2010. – C.36
Советов Б.Я., Цехановский В.В., Чертовской В.Д. Базы данных. Теория и практика.– Высшая школа, 2010. – С.49

ПРИЛОЖЕНИЯ

Приложение 1 Пример представления данных в таблице ИС «Картинная галерея»

Название	Год	Стиль	Фактура	Техника	Автор	Владелец	Местонахождение	Изображение
Утро в сосновом лесу	1889	реализм	холст	Живопись масляными красками	Иван Шишкин и Константин Савицкий	Третьяковская галерея	Третьяковская галерея
Постоянство памяти	1931	сюрреализм	холст	Живопись масляными красками	Сальвадор дали	Нью-Йоркский музей современного искусства	Нью-Йоркский музей современного искусства
Вавилонская башня	1563	Позднее Возрождение	дерево	масло	Питер Брейгель Старший	Музей истории искусств	Музей истории искусств, Вена