• Основные модели построения баз данных. Системы управления базами данных

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

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

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

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

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

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

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

    • иерархическая (англ. hierarchical), конец 1960-х и 1970-е гг.;
    • сетевая (англ. network), 1970-е гг.;
    • реляционная (англ. relational), 1970-е и начало 1980-х гг.;
    • "сущность – связь" (англ. entity – relationship), 1970-е гг.;
    • расширенная реляционная (англ. extended relational), 1980-е гг.;
    • семантическая (англ. semantic), конец 1970-х и 1980-е гг.;
    • объектно-ориентированная (англ. object-oriented), конец 1980-х – начало 1990-х гг.;
    • объектно-реляционная (англ. object-relational), конец 1980-х – начало 1990-х гг.;
    • полуструктурированная (англ. semi-structured), с конца 1990-х гг. до настоящего времени.

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

    Модель "сущность – связь" была предложена П. Ченом (Peter Chen) в 1976 г. в качестве унифицированного способа описания предметной области. Как самостоятельная модель данных (в соответствии с приведенным выше определением) она развития не получила, но стала основой для создания инфологических моделей БД. Этап инфологического проектирования рассмотрен в главе 6.

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

    Объектно-ориентированная и объектно-реляционная модели данных появились в результате распространения объектно-ориентированного подхода в программировании. Объектная модель данных предлагает рассматривать БД как множество объектов, обладающих свойствами инкапсуляции, наследования и т.д. В 1989 г. был опубликован "Манифест систем объектно-ориентированных баз данных", а в 1991 г. образован консорциум ODMG (от англ. Object Data Management Group), который занялся разработкой стандартов. В 2000 г. была опубликована версия стандарта The Object Data Standard: ODMG 3.0, а в 2001 г. группа прекратила свою деятельность. Примерно в то же время велась активная работа по адаптации реляционной модели к требованиям объектно-ориентированного подхода к разработке ПО, что привело к появлению объектно-реляционной модели данных. Позднее объектные расширения были введены в стандарт языка SQL.

    К полуструктурированным относят данные, в которых можно выделить некоторую структуру, но она недостаточно строгая по сравнению с реляционными структурами данных (или структурами других традиционных моделей данных) . Наиболее ярким примером полуструктурированных данных являются XML-документы (от англ. extensible Markup Language – расширяемый язык разметки). Действительный (англ. valid) XML-до- кумент должен соответствовать определенному формату описания (схеме), где заданы структура документа, допустимые названия элементов, атрибутов и т.д. Формат XML широко используется для обмена данными между приложениями, и его поддержка обеспечивается многими СУБД.

    Типы моделей баз данных

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

    Иерархическая модель

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

    «Система управления информацией » (Information Management System ) компании IMB - пример иерархической СУБД.

    Иерархическая модель организует данные в форме дерева с иерархией родительских и дочерних сегментов. Такая модель подразумевает возможность существования одинаковых (преимущественно дочерних ) элементов. Данные здесь хранятся в серии записей с прикреплёнными к ним полями значений. Модель собирает вместе все экземпляры определённой записи в виде «типов записей » - они эквивалентны таблицам в реляционной модели, а отдельные записи — столбцам таблицы. Для создания связей между типами записей иерархическая модель использует отношения типа «родитель-потомок » вида 1:N . Это достигается путём использования древовидной структуры - она «позаимствована » из математики, как и теория множеств, используемая в реляционной модели.

    Иерархические системы баз данных

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

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

    Иерархические БД были популярны, начиная с конца 1960-х годов, когда компания IBM представила свою СУБД «Система управления информацией. Иерархическая схема состоит из типов записей и типов «родитель-потомок »:

    • Запись - это набор значений полей.
    • Записи одного типа группируются в типы записей.
    • Отношения «родитель-потомок» - это отношения вида 1:N между двумя типами записей.
    • Схема иерархической базы данных состоит из нескольких иерархических схем.

    Сетевая модель

    В сетевой модели данных у родительского элемента может быть несколько потомков, а у дочернего элемента - несколько предков. Записи в такой модели связаны списками с указателями. IDMS («Интегрированная система управления данными ») от компании Computer Associates international Inc. - пример сетевой СУБД.

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

    Сетевая модель позволяет более естественно моделировать отношения между элементами. И хотя эта модель широко применялась на практике, она так и не стала доминантной по двум основным причинам. Во-первых, компания IBM решила не отказываться от иерархической модели в расширениях для своих продуктов, таких как IMS и DL/I . Во-вторых, через некоторое время её сменила реляционная модель, предлагавшая более высокоуровневый, декларативный интерфейс.

    Популярность сетевой модели совпала с популярностью иерархической модели. Некоторые данные намного естественнее моделировать с несколькими предками для одного дочернего элемента. Сетевая модель как раз и позволяла моделировать отношения «многие ко многим». Её стандарты были формально определены в 1971 году на конференции по языкам систем обработки данных (CODASYL ).

    Основной элемент сетевой модели данных - набор, который состоит из типа «запись-владелец », имени набора и типа «запись-член ». Запись подчинённого уровня («запись-член ») может выполнять свою роль в нескольких наборах. Соответственно, поддерживается концепция нескольких родительских элементов.

    Запись старшего уровня («запись-владелец ») также может быть «членом » или «владельцем » в других наборах. Модель данных - это простая сеть, связи, типы пересечения записей (в IDMS они называются junction records , то есть «перекрёстные записи ). А также наборы, которые могут их объединять. Таким образом, полная сеть представлена несколькими парными наборами.

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

    Известные сетевые базы данных:

    • TurboIMAGE;
    • IDMS;
    • Встроенная RDM;
    • Серверная RDM.

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

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

    В отличие от двух других типов СУБД, в реляционных моделях данных нет необходимости просматривать все указатели, что облегчает выполнение запросов на выборку информации по сравнению с сетевыми и иерархическими СУБД. Это одна из основных причин, почему реляционная модель оказалась более удобна. Распространённые реляционные СУБД: Oracle , Sybase , DB2 , Ingres , Informix и MS-SQL Server .

    «В реляционной модели, как объекты, так и их отношения представлены только таблицами, и ничем более ».

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

    Реляционные таблицы обладают следующими свойствами:

    • Все значения атомарны.
    • Каждый ряд уникален.
    • Порядок столбцов не важен.
    • Порядок рядов не важен.
    • У каждого столбца есть своё уникальное имя.

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

    Часто у полей будет одно и то же имя в обеих таблицах. Например, таблица «Заказы » может содержать пары «ID-покупателя » и «код-товара ». А в таблице «Товар » могут быть пары «код-товара » и «цена ». Поэтому чтобы рассчитать чек для определённого покупателя, необходимо суммировать цену всех купленных им товаров, использовав JOIN в полях «код-товара » этих двух таблиц. Такие действия можно расширить до объединения нескольких полей в нескольких таблицах.

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

    Сравнение трёх моделей

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

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

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

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

    Объекты связываются отношениями, основные типы которых можно определить следующим образом:

    «Один к одному»

    В этом виде отношений один объект связан с другим. Например, Менеджер -> Отдел .

    У каждого менеджера может быть только один отдел, и наоборот.

    «Один ко многим»

    В моделях данных отношение одного объекта с несколькими. Например, Сотрудник -> Отдел .

    Каждый сотрудник может быть только в одном отделе, но в самом отделе может быть больше одного сотрудника.

    «Многие ко многим»

    В заданный момент времени объект может быть связан с любым другим. Например, Сотрудник -> Проект .

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

    В реляционной модели объекты и их отношения представлены двухмерным массивом или таблицей.

    Каждая таблица представляет объект.

    Каждая таблица состоит из рядов и столбцов.

    Отношения между объектами представлены столбцами.

    Каждый столбец представляет атрибут объекта.

    Значения столбцов выбираются из области или набора всех возможных значений.

    Столбцы, которые используются для связи объектов, называются ключевыми. Есть два типа ключей - первичные и внешние.

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

    Преимущества реляционной модели данных:

    1. Простота использования.
    2. Гибкость.
    3. Независимость данных.
    4. Безопасность.
    5. Простота практического применения.
    6. Слияние данных.
    7. Целостность данных.

    Недостатки:

    1. Избыточность данных.
    2. Низкая производительность.

    Другие модели баз данных (ООСУБД)

    В последнее время на рынке СУБД появились продукты, представленные объектными и объектно-ориентированной моделью данных, такие как Gem Stone и Versant ОСУБД. Также производятся исследования в области многомерных и логических моделей данных.

    Особенности объектно-ориентированных систем управления базами данных (ООСУБД):

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

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

    Известны три типа моделей описания баз данных (рис.3.7):

    ü иерархическая;

    ü сетевая;

    ü реляционная.

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

    Рис 3.7. Основные типы моделей данных

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

    Достоинством модели является:

    · простота ее построения;

    · легкость понимания сути принципа иерархии;

    · наличие промышленных СУБД, поддерживающих данную модель.

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

    Рис. 3.8. Иерархическая модель данных

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

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

    База данных, описываемая сетевой моделью, состоит из областей (области - из записей, а записи - из полей).

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

    Рис.3.9. Сетевая модель данных

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

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



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

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

    Рис.3.10 Реляционная модель данных

    В зависимости от содержания отношения реляционные базы данных бывают:

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

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



    Достоинства реляционной модели:

    · простота построения;

    · доступность понимания;

    · возможность эксплуатации базы данных без знания методов и способов ее построения;

    · независимость данных;

    · гибкость структуры и др.

    Недостатки реляционной модели:

    · низкая производительность по сравнению с иерархической и сетевой моделями;

    · сложность программного обеспечения;

    · избыточность элементов.

    В последние годы все большее признание и развитие получают объектно-ориентированные базы данных (ООБД).

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

    Традиционными областями применения объектных СУБД являются системы автоматизированного проектирования (САПР), моделирование, мультимедиа.

    К объектным СУБД можно отнести СУБД ONTOS - одного из лидеров направляя ООБД, Jasmine. ODB-Jupiter - первый российский продукт такого рода, ORACLE 8.0.

    Базы знаний - это специальные компьютерные системы, основанные на обобщении, анализе и оценке знаний высококвалифицированных специалистов-экспертов.

    Например, «КонсультантПлюс», «Гарант Сервис».

    Основными элементами информационной технологии, используемой в БЗ являются:

    Интерфейс пользователя,

    База знаний,

    Интерпретатор,

    Модуль создания системы,

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

    Выходная информация включает не только само решение, но необходимые объяснения, которые могут быть двух видов:

    1) по запросам, т.е. те, которые пользователь может получить в любой момент;

    2) которые пользователь получает уже при выдаче решения, т.е. то, каким образом получается решение (например, каким образом влияет на прибыль и издержки выбранная цена и т.д.).

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

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

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

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

    Контрольные вопросы

    1. В чем различие между информацией и данными?

    2. Как выражается адекватность информации?

    3. Назовите признаки классификации экономической информации.

    4. Что такое структура информации?

    5. Чем показатель отличается от реквизита?

    6. Укажите основные свойства информации.

    7. Что входит в состав информационного обеспечения?

    8. Чем внемашинное информационное обеспечение отличается от внуримашинного?

    9. Какие бывают классификаторы и с какой целью разрабатываются классификаторы?

    10. Каково назначение штрихового кодирования? В чем его особенности?

    11. Определите понятия «классификаторы» и «коды».

    12. Чем автоматизированные банки данных отличаются от баз знаний?

    13. Что входит в состав автоматизированных банков данных?

    14. Чем клиент-серверная архитектура отличается от файл-серверной?

    15. Укажите основные характеристики СУБД.

    16. Что подразумевает обеспечение целостности данных?

    17. Охарактеризуйте типы моделей описания баз данных.

    4. информационные технологии в управлении и экономике

    Лекция 5

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

    База данных. Классификация и характеристика СУБД.

    Основные модели баз данных.

    Базы данных в экономических системах

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

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

    Задачами СУБД являются:

    Хранение информации в структурированном виде;

    Обновление информации по мере необходимости;

    Поиск нужной информации по определенным критериям;

    Выдача информации пользователю в удобном для него виде;

    Устранение избыточности данных;

    Поддержка языков БД.

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



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

    Централизованные СУБД;

    Распределенные СУБД.

    Централизованная СУБД - система управления базой данных, которая хранится в памяти одной вычислительной системы.

    Системы централизованных баз данных с сетевым доступа предполагают две основные архитектуры:

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

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

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

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

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

    Безопасность данных в базе данных достигается:

    ¾ шифрованием прикладных программ;

    ¾ шифрованием данных;

    ¾ защитой данных паролем;

    ¾ ограничением доступа к базе данных.

    Основные модели баз данных

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

    ¾ "один к одному";

    ¾ "один ко многим";

    ¾ "многие ко многим".

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

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

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

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

    Рис. 1 – Иерархическая модель баз данных

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

    Рис. 2 – Сетевая модель баз данных

    Реляционная модель баз данных (РМД) реализует табличный способ.

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

    Отношения обладают следующими свойствами :

    ¾ каждый элемент таблицы представляет собой один элемент данных (повторяющиеся группы отсутствуют);

    ¾ элементы столбца имеют одинаковую природу, и столбцам однозначно присвоены имена;

    ¾ в таблице нет двух одинаковых строк;

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

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

    Достоинства реляционной модели :

    ¾ простота построения;

    ¾ доступность понимания;

    ¾ возможность эксплуатации базы данных без знания методов и способов ее построения;

    ¾ независимость данных;

    ¾ гибкость структуры и др.

    Недостатки реляционной модели :

    ¾ низкая производительность по сравнению с иерархической и сетевой модели;

    ¾ сложность программного обеспечения;

    ¾ избыточность элементов.

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

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

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

    Свойство - это характеристика, с помощью которой описывается внешний вид и работа объекта.

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

    Метод - это функция или процедура, управляющая работой объекта при его реакции на событие.

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

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

    8.1. Иерархическая модель базы данных

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

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

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

    Рис. 6. Иерархическая база данных

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

    Атрибут (элемент данных)

    Наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.

    Запись

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

    Групповое отношение

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

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

    Поэтому, для информационной системы управления персоналом необходимо создать групповое отношение, состоящее из родительской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на рис. 7 (а) (Для простоты полагается, что имеются только две дочерние записи).

    Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры: заказчик - контракты с ним - сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК (НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА) (рис. 7b).

    Рис. 7. Пример иерархической БД

    Из этого примера видны недостатки иерархических БД :

    Частично дублируется информация между записями СОТРУДНИК и ИСПОЛНИТЕЛЬ (такие записи называют парными), причем виерархической модели данных не предусмотрена поддержка соответствия между парными записями.

    Иерархическая модель реализует отношение между исходной и дочерней записью по схеме 1:N, то есть одной родительской записи может соответствовать любое число дочерних.

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

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