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

Таблица I обладает следующими свойствами:

●каждая строка представляет собой кортеж из К значений, принадлежащим столбцам;

●порядок столбцов фиксирован (1,2...К);

●порядок строк безразличен;

●любые две строки различаются хотя бы одним элементом;

●строки и столбцы таблицы могут обрабатываться в любой последовательности, определяемой применяемыми операциями обработки.

Рис.19. Графическая интерпретация получения декартова произведения

Таблица I

Математическое отношение используется двояко:

–для представления набора объектов;

–для представления связей между наборами объектов.

Столбцы отношений называют атрибутами и присваивают им имена. Список имен атрибутов отношения называют схемой отношения. Если отношение называется R и его схема имеет атрибуты с именами А1, А2,…Ак, то схема отношения R (А1, А2..., Aк).

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

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

R1 (A1.1, A1.2,……., A1.k1)

R2 (A2.1, A2.2,……, A2.K2)

……………………………

Rm (Am.1, Am.2,…….., Am.Km)

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

Сравнивая рассматриваемые выше три типа моделей данных, можно сделать следующие выводы.

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

– владельца набора.

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

Функциональный характер реализуемых связей не позволяет непосредственно представлять в сетевой модели связи типа "многие – ко многим", т.е. M:N.

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

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

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

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

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

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

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

развитые средства для описания явных ограничений целостности. Реляционная модель поддерживает явные ограничения.

Большинство явных ограничений, встречающихся на практике – это ограничения на зависимости между атрибутами. Например, значение атрибута ТАБЕЛЬНЫЙ – НОМЕР определяет значение атрибута ВОЗРАСТ в отношении СОТРУДНИК.

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

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

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

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

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

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

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

Достаточно широкое применение иерархическая модель данных находит при разработке информационно-справочных автоматизированных рабочих мест.

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

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

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

●сложность и трудоемкость написаний определений данных и программ для манипулирования структурами данных;

●сложность модели для изучения пользователями;

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

●наглядность представления структуры данных.

6. Характеристика программных средств обслуживания банков данных

6.1. Программно-аппаратный уровень процесса накопления

данных

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

(рис. 20).

ПКС

ЭВМ

Рис. 20. Состав моделей и программ процесса накопления

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

(ПИ).

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

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

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

СУБД

Рис. 21. Состав СУБД

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

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

СУБД принципиально различаются по моделям БД, с которыми они работают. Если модель БД реляционная, то нужно использовать реляционную СУБД, если сетевая – сетевую СУБД и т.д.

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

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

6.2. Типы и классификация СУБД

При централизованном принципе обработки информации в АС, все существующие СУБД подразделялись на три группы, в зависимости от используемого типа ЭВМ:

• для больших – единой системы (ЕС) ЭВМ;

•для мини – системы малых (СМ) ЭВМ;

•для микро-ЭВМ.

Наибольшее распространение в это время для ЕС ЭВМ получили следующие СУБД:

•СУБД «ОКА» – система общего назначения, ориентированная на применения в БнД АСУ предприятиями, организациями, производственными объединениями, отраслями. Система ОКА относилась к классу систем с включающим языком, и поддерживала древовидную иерархическую модель данных. Допускала при определенных ограничениях реализацию сетевых структур данных. При составлении прикладных программ, ориентированных на применение СУБД «ОКА», использовали языки высокого уровня PL/1, КОБОЛ, АССЕМБЛЕР.

•СУБД «Сеть», которая относилась к классу систем общего назначения, реализованных для ЕС ЭВМ, и применялась в крупных АСУ производственными объединениями и отраслями. Поддерживала сетевую модель данных.

•СУБД ДИСОД – диалоговая информационная система обработки данных, которая представляла собой многофункциональную систему, рассчитанную на широкий класс приложений и обеспечивающую коллективный доступ к базе данных. Прикладные программы могли быть написаны, кроме языковых средств ДИСОД, на языках высокого уровня PL/1, КОБОЛ, ФОРТРАН, АССЕМБЛЕР. СУБД ДИСОД обеспечивала одновременный приоритетный доступ пользователей к БД, работу с несколькими реляционными базами данных, работу в режиме диалога или пакетном режиме.

•СУБД «СЕТОР» (сетевая организация данных) позволяла поддерживать сетевую модель данных и предоставляла пользователям возможность работы с базами данных в прикладных программах, написанных на алгоритмических языках PL/1, ФОРТРАН, КОБОЛ, АССЕМБЛЕР.

Для мини-ЭВМ, которым характерен интерактивный режим работы пользователя, был создан целый ряд СУБД: СЕТОР – СМ (поддерживающая сетевую модель данных), ДИАМС, ФОБРИН, КВАНТ, МИРИС (поддерживающая иерархическую модель данных), РИБД (поддерживающая реляционную модель данных). Из них, например, СУБД МИРИС – малая иерархическая распределенная информационная система баз данных относилась к системам смешанного типа, т.е. сочетала в себе возможности как открытой системы, допуская программирование прикладных программ на языках