Файл: Способы представления данных в информационных системах(ИНФОРМАЦИОННАЯ СИСТЕМА. ПОНЯТИЕ И КЛАССИФИКАЦИЯ).pdf

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

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

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

2.2 Сетевая модель данных

Модель сетевых данных заменяет более простую и понятную иерархическую модель. По своей сути сетевая модель очень похожа на иерархическую модель, она также имеет узлы, то есть корневые элементы, в которые вводится наиболее важная информация [15]. Между собой узлы объединены посредством связей. И узлы лежат на том же расстоянии от формы корневого узла, что и в иерархической модели, образуя уровни. Особенность иерархической модели заключается в том, что от одного элемента до другого возможен только один маршрут, в сетевой напротив -есть несколько маршрутов. Модель сетевых данных предоставляет возможность строить более сложные структуры данных. В этом основное отличие двух моделей

Рисунок 3- Сетевая структура

Целью создания такой модели данных было внедрение отношений «многие ко многим» с одновременным исправлением всех недостатков в иерархической модели, выявленных с течением времени. Модель сетевых данных основана на применении теории графов. С этой точки зрения ей соответствует произвольный граф.

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

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

В сетевой модели групповые отношения обычно описывают связь вида "один к множеству", то есть владелец один, а у него много подчиненных. Можно привести в пример такое отношение, как «работать». Тут подразумевается, что каждый сотрудник работает в каком-то определенном отделе, но в каждом отделе вполне может работать несколько сотрудников. В сетевой модели вида "один к множеству" отношения между различными объектами реализуются с помощью групповых отношений.

2.3 Реляционная модель данных

История реляционных СУБД ведет свое начало с конца 60-х, когда одновременно несколькими авторами были выдвинуты предложения об использовании теоретико-множественных операторов для организации доступа к данным. Затем была экспериментальная система управления базами данных System R и использованный в ней язык SEQUEL, который можно считать непосредственным предшественником языка SQL. В настоящее время именно язык SQL является стандартом для работы с реляционными СУБД. Например, семейство серверов реляционных баз данных Informix Dynamic Server поддерживают все эти стандарты и, кроме того, обеспечивают дополнительные возможности [16].

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

Рисунок 4- Реляционная структура

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

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

Информационные системы, представленные в виде реляционной базы данных, можно разделить на однотабличные и многотабличные. Спрос на базы данных с одной таблицей относительно невелик. Такие разработки применимы в случае информационной системы с относительно небольшим количеством полей или в случае, когда разделение на отдельные таблицы приводит к чрезмерной детализации данных. В подавляющем большинстве случаев реляционная база данных действует как система с несколькими таблицами [17]. При проектировании таких информационных систем они руководствуются принципами нормализации данных. Принципы стандартизации определяют такое разделение базы данных на таблицы, чтобы исключить дублирование информации об одном и том же объекте. Это позволяет избежать потери памяти при хранении и потери времени при обработке информации в системе.

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

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

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

Еще одним преимуществом реляционных СУБД является высокая стандартизация. Существует несколько стандартов, определяющих синтаксис и семантику операторов SQL. Почти все производители систем управления реляционными базами данных поддерживают стандарты. В результате программисты и разработчики получили возможность разрабатывать легко переносимые, надежные приложения, которые могут работать на самых разных аппаратных средствах. К преимуществам реляционных СУБД относится тот факт, что существует очень четкая математическая основа для работы с данными.

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

3 РАЗРАБОТКА И ПРОЕКТИРОВАНИЕ БД ИС НА ПРЕДПРИЯТИИ ГП «АЛУШТАЛИФТ»

3.1 Проектирование БД ИС «Вызов»

Проектирование баз данных - процесс решения задач, связанных с созданием баз данных.

При выполнении этого процесса решаются следующие основные задачи:

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

В процессе написания использовался язык SQL, поскольку основным требованием к реляционной СУБД является наличие сильного и в то же время простого языка, который позволяет выполнять все операции, которые нужны пользователю. В последние время таким повсеместно принятым языком стал язык реляционных БД SQL - Structured Query Language [18].

На основе описания предметной области во втором разделе, описанном в первом разделе, мы разработаем модель базы данных разработанного IP.

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

Для каждой заявки заводится отдельная строка в таблице базы данных, в которой указываются: