Классификация баз данных научной информации. Классификация баз данных. Классификация БД по способу хранения данных

2.1. Определения и понятия теории баз данных

База данных (БД, database) — поименованная совокупность структурированных данных, относящихся к определенной предметной области.

Предметная область — некоторая часть реально существующей системы, функционирующая как самостоятельная единица.

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

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

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

Таблица базы данных (table) — регулярная структура, которая состоит из однотипных строк (записей, records), разбитых на столбцы (поля, fields).

В теории реляционных баз данных синоним таблицы — отношение (relation), в котором строка называется кортежем, а столбец — атрибутом.

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

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

Первичный ключ (primary key) — главный ключевой элемент, однозначно идентифицирующий строку в таблице. Могут также существовать альтернативный (candidate key) и уникальный (unique key) ключи, служащие также для идентификации строк в таблице.

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

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

Связь (relation) — функциональная зависимость между объектами. В реляционных базах данных между таблицами устанавливаются связи по ключам, один из которых в главной (parent, родительской) таблице — первичный, второй — внешний ключ — во внешней (child, дочерней) таблице, как правило, первичным не является и образует связь «один ко многим» (1:N). В случае первичного внешнего ключа связь между таблицами имеет тип «один к одному» (1:1). Информация о связях сохраняется в базе данных.

Внешний ключ (foreign key) — ключевой элемент подчиненной (внешней, дочерней) таблицы, значение которого совпадает со значением первичного ключа главной (родительской) таблицы.

Ссылочная целостность данных (referential integrity) — набор правил, обеспечивающих соответствие ключевых значений в связанных таблицах.

Хранимые процедуры (stored procedures) — программные модули, сохраняемые в базе данных для выполнения определенных операций с информацией базы.

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

Объект (object) — элемент информационной системы, обладающий определенными свойствами (properties) и определенным образом реагирующий на внешние события (events).

Система — совокупность взаимодействующих между собой и с внешним окружением объектов.

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

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

Язык SQL (Structured Query Language) — универсальный язык работы с базами данных, включающий возможности ее создания, модификации структуры, отбора данных по запросам, модификации информации в базе и прочие операции манипулирования базой данных.

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

2.2. Классификация баз данных

По технологии обработки данных базы данных подразделяются на централизованные и распределенные.

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

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

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

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

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

  • файл-сервер;
  • клиент-сервер базы данных;
  • «тонкий клиент» — сервер приложений — сервер базы данных (трехуровневая архитектура).

Рис. 1. Схема работы с БД в локальной сети с выделенным файловым сервером

Файл-сервер. Архитектура систем БД с сетевым доступом предполагает выделение одной из машин сети в качестве центральной (файловый сервер). На этот компьютер устанавливается операционная система (ОС) для выделенного сервера (например, Microsoft Windows Server 2003). На нем же хранится совместно используемая централизованная БД в виде одного или группы файлов. Все другие компьютеры сети выполняют функции рабочих станций (могут работать в ОС Microsoft Windows 2000 Professional или Microsoft Windows 98). Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где и производится обработка информации (рис. 1). При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает. Пользователи могут создавать также локальные БД на рабочих станциях.

Рис. 2. Схема работы с БД в архитектуре «Клиент-сервер»

Клиент-сервер. В этой архитектуре на выделенном сервере, работающем под управлением серверной операционной системы, устанавливается специальное программное обеспечение (ПО) — сервер БД, например Microsoft ® SQL Server™или Oracle. СУБД подразделяется на две части: клиентскую и серверную. Основа работы сервера БД — использование языка запросов (SQL). Запрос на языке SQL, передаваемый клиентом (рабочей станцией) серверу БД, порождает поиск и извлечение данных на сервере. Извлеченные данные транспортируются по сети от сервера к клиенту (рис. 2). Тем самым количество передаваемой по сети информации уменьшается во много раз.

Трехуровневая архитектура функционирует в интранет- и интернет-сетях. Клиентская часть («тонкий клиент»), взаимодействующая с пользователем, представляет собой HTML-страницу в Web-браузере либо Windows-приложение, взаимодействующее с Web-сервисами. Вся программная логика вынесена на сервер приложений, который обеспечивает формирование запросов к базе данных, передаваемых на выполнение серверу баз данных. Сервер приложений может быть Web-сервером или специализированной программой (например, Oracle Forms Server) (рис. 3).

Рис. 3. Схема работы с БД в трехуровневой архитектуре

2.3. Иерархические и сетевые модели данных

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

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

Рис. 4. Схема иерархической модели данных

Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г. До сих пор поддерживается много баз данных этой системы.

Сетевые базы данных

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

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

Рис. 5. Схема сетевой модели данных

Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL) — организации, ответственной за определение языка программирования Кобол. Отчет DBTG был опубликован в 1971 г., а позже появилось несколько систем, среди которых IDMS.

2.4. Реляционные базы данных

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

Реляционная модель данных основывается на математических принципах, вытекающих непосредственно из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 1960-х гг. доктором Е. Ф. Коддом, в то время работавшим в IBM, а впервые опубликованы в 1970 г.

Техническая статья «Реляционная модель данных для больших разделяемых банков данных» доктора Е. Ф. Кодда, опубликованная в 1970 г., является родоначальницей современной теории реляционных БД. Доктор Кодд определил 13 правил реляционной модели (которые называют тринадцатью правилами Кодда).

13 правил Кодда

  1. Реляционная СУБД должна быть способна полностью управлять базой данных через ее реляционные возможности.
  2. Информационное правило — вся информация в реляционной БД (включая имена таблиц и столбцов) должна определяться строго как значения в таблицах.
  3. Гарантированный доступ — любое значение в реляционной БД должно быть гарантированно доступно для использования через комбинацию имени таблицы, значения первичного ключа и имени столбца.
  4. Поддержка пустых значений (null value) — СУБД должна уметь работать с пустыми значениями (неизвестными или неиспользованными значениями), в отличие от значений по умолчанию и независимо для любых доменов.
  5. Онлайновый реляционный каталог — описание БД и ее содержание должны быть представлены на логическом уровне как таблицы, к которым можно применять запросы, используя язык базы данных.
  6. Исчерпывающий язык управления данными — по крайней мере, один из поддерживаемых языков должен иметь четко определенный синтаксис и быть всеобъемлющим. Он должен поддерживать описание структуры данных и манипулирование ими, правила целостности, авторизацию и транзакции.
  7. Правило обновления представлений (views) — все представления, теоретически обновляемые, могут быть обновлены через систему.
  8. Вставка, обновление и удаление — СУБД поддерживает не только запрос на отбор данных, но и вставку, обновление и удаление.
  9. Физическая независимость данных — на программы-приложения и специальные программы логически не влияют изменения физических методов доступа к данным и структур хранилищ данных.
  10. Логическая независимость данных — на программы-приложения и специальные программы логически не влияют, в пределах разумного, изменения структур таблиц.
  11. Независимость целостности — язык БД должен быть способен определять правила целостности. Они должны сохраняться в онлайновом справочнике, и не должно существовать способа их обойти.
  12. Независимость распределения — на программы-приложения и специальные программы логически не влияет, первый раз используются данные или повторно.
  13. Неподрывность — невозможность обойти правила целостности, определенные через язык базы данных, использованием языков низкого уровня.

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

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

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

  • объединения отношений;
  • пересечения отношений;
  • взятия разности отношений;
  • взятия декартова произведения отношений.

Специальные реляционные операции включают:

  • ограничение отношения;
  • проекцию отношения;
  • соединение отношений;
  • деление отношений.

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

  • При выполнении операции объединения (UNION) двух отношений с одинаковыми заголовками производится отношение, включающее все кортежи, которые входят хотя бы в одно из отношений — операндов.
  • Операция пересечения (INTERSECT) двух отношений с одинаковыми заголовками производит отношение, включающее все кортежи, которые входят в оба отношения-операнда.
  • Отношение, являющееся разностью (MINUS) двух отношений с одинаковыми заголовками, включает все кортежи, входящие в отношение — первый операнд, такие, что ни один из них не входит в отношение, которое является вторым операндом.
  • При выполнении декартова произведения (TIMES) двух отношений, пересечение заголовков которых пусто, производится отношение, кортежи которого производятся путем объединения кортежей первого и второго операндов.
  • Результатом ограничения (WHERE) отношения по некоторому условию является отношение, включающее кортежи отношения-операнда, удовлетворяющее этому условию.
  • При выполнении проекции (PROJECT) отношения на заданное подмножество множества его атрибутов производится отношение, кортежи которого являются соответствующими подмножествами кортежей отношения-операнда.
  • При соединении (JOIN) двух отношений по некоторому условию образуется результирующее отношение, кортежи которого производятся путем объединения кортежей первого и второго отношений и удовлетворяют этому условию.
  • У операции реляционного деления (DIVIDE BY) два операнда — бинарное и унарное отношения. Результирующее отношение состоит из унарных кортежей, включающих значения первого атрибута кортежей первого операнда таких, что множество значений второго атрибута (при фиксированном значении первого атрибута) включает множество значений второго операнда.
  • Операция переименования (RENAME) производит отношение, тело которого совпадает с телом операнда, но имена атрибутов изменены.
  • Операция присваивания (:=) позволяет сохранить результат вычисления реляционного выражения в существующем отношении БД.

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

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

Модель данных, или концептуальное описание предметной области, — самый абстрактный уровень проектирования баз данных.

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

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

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

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

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

Сущность — некоторый обособленный объект или событие, информацию о котором необходимо сохранять в базе данных, имеющий определенный набор свойств — атрибутов. Сущности могут быть как физические (реально существующие объекты: например, СТУДЕНТ, атрибуты — номер зачетной книжки, фамилия, его факультет, специальность, номер группы и т. д.), так и абстрактные (например, ЭКЗАМЕН, атрибуты — дисциплина, дата, преподаватель, аудитория и пр.). Для сущностей различают ее тип и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр — конкретными значениями свойств.

Атрибуты сущности бывают:

  1. Идентифицирующие и описательные. Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ (ПК). В качестве ПК обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам записи. ПК должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными.
  2. Простые и составные. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных (например, адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от особенностей процессов его использования и может быть связано с обеспечением высокой скорости работы с большими базами данных.
  3. Однозначные и многозначные — могут иметь соответственно одно или много значений для каждого экземпляра сущности.
  4. Основные и производные. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст человека вычисляется на основе даты его рождения и текущей даты).

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

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

Связи — на концептуальном уровне представляют собой простые ассоциации между сущностями. Например, утверждение «Покупатели приобретают продукты» указывает, что между сущностями «Покупатели» и «Продукты» существует связь, и такие сущности называются участниками этой связи.

Существует несколько типов связей между двумя сущностями: это связи «один к одному», «один ко многим» и «многие ко многим».

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

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

Диаграмма «сущности-связи» (Entity-Relationship diagrams, или E/R diagram) служит для описания схемы базы на концептуальном уровне проектирования. Метод был предложен в 1976 г. Питером Пин Шань Ченом (Peter Pin Shan Chen) . На диаграммах «сущности-связи» сущности изображаются в виде прямоугольников, атрибуты — в виде эллипсов, а связи — в виде ромбов (рис. 6).

Рис. 6. Диаграмма «сущности-связи»

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

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

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

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

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

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

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

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

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

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

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

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

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

Третья нормальная форма (3НФ) связана с понятием транзитивной зависимости. Пусть A, B, C — атрибуты некоторого отношения. При этом A B и B C, но обратное соответствие отсутствует, т. е. C не зависит от B или B не зависит от A. Тогда говорят, что C транзитивно зависит от A (A C).

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

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

Существуют также нормальная форма Бойса-Кодда (НФБК), 4НФ и 5НФ. Однако наибольшее значение имеет 1НФ, так как последующие НФ связаны с понятиями о составных ключах и сложных зависимостях от ключей, а на практике встречаются обычно более простые случаи.

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

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

В реальном проектировании структуры базы данных применяется другой метод — так называемое семантическое моделирование. Семантическое моделирование представляет собой моделирование структуры данных, опирающееся на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм «сущность-связь» (ERD) c построением концептуальной модели базы данных.

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

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

Соблюдение условий ссылочной целостности в реляционной базе данных

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

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

Для родительской таблицы:

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

Для дочерней таблицы:

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

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

  1. Обновление записей в родительской таблице.
  2. Удаление записей в родительской таблице.
  3. Вставка записей в дочерней таблице.
  4. Обновление записей в дочерней таблице.

Основные стратегии поддержания ссылочной целостности

Существуют две основные стратегии поддержания ссылочной целостности.

RESTRICT (ОГРАНИЧИТЬ) — не разрешать выполнение операции, приводящей к нарушению ссылочной целостности.

CASCADE (КАСКАДНОЕ ИЗМЕНЕНИЕ) — разрешить выполнение требуемой операции, но внести при этом необходимые изменения в связанных таблицах так, чтобы не допустить нарушения ссылочной целостности и сохранить все имеющиеся связи. Изменение начинается в родительской таблице и каскадно выполняется в дочерних таблицах. В реализации этой стратегии имеется одна тонкость, заключающаяся в том, что дочерние таблицы сами могут быть родительскими для некоторых третьих таблиц. При этом может дополнительно потребоваться выполнение какой-либо стратегии и для этой связи и т. д. Если при этом какая-либо из каскадных операций (любого уровня) не может быть выполнена, то необходимо отказаться от первоначальной операции и вернуть базу данных в исходное состояние. Это сложная стратегия, но она не нарушает связей между родительскими и дочерними таблицами.

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

Дополнительные стратегии поддержания ссылочной целостности

IGNORE (ИГНОРИРОВАТЬ) — разрешить выполнять операцию без проверки ссылочной целостности. В этом случае в дочерней таблице могут появляться некорректные значения внешних ключей, вся ответственность за целостность базы данных ложится на программиста или пользователя.

SET NULL (ЗАДАТЬ ЗНАЧЕНИЕ NULL) — разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на null-значения. Эта стратегия имеет два недостатка. Во-первых, для нее требуется разрешение на использование null-значений. Во-вторых, записи дочерней таблицы теряют связь с записями родительской таблицы. Установить, с какой записью родительской таблицы были связаны измененные записи дочерней таблицы, после выполнения операции уже нельзя.

SET DEFAULT (ЗАДАТЬ ЗНАЧЕНИЕ ПО УМОЛЧАНИЮ) — разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на некоторое значение, принятое по умолчанию. Достоинство этой стратегии по сравнению с предыдущей в том, что она позволяет не пользоваться null-значениями. Установить, с какими записями родительской таблицы были связаны измененные записи дочерней таблицы, после выполнения такой операции тоже нельзя.

На рис. 7 представлен пример реляционной базы, содержащей сведения отдела кадров по работникам предприятия, в которой для каждой таблицы показан список ее полей и показаны связи между таблицами по простому ключу — значению поля tabn.

Рис. 7. Схема реляционной базы данных

Начиная с 1980-х г., одновременно с широким распространением персональных компьютеров, большое распространение получили так называемые «настольные» реляционные СУБД (Desktop Databases), такие как dBase, FoхBase (его более поздние версии — FoхPro и Visual FoхPro), Paradoх, Access. Наиболее распространенным форматом таблиц подобных реляционных баз стал *.dbf, с которым работали dBase, FoхBase, а также Clipper — система написания программ (в режиме строкового компилятора) для работы с базами данных. В последующем некоторые из них стали полноценными сетевыми СУБД, работающими не только в различных операционных системах в архитектуре «файл-сервер», но и имеющими возможности для работы с серверами баз данных в архитектуре «клиент-сервер», а также разработки и использования html-страниц для работы с базами данных.

Все СУБД для ПК можно подразделить на три вида:

  1. Системы управления базами данных в буквальном смысле этого термина, для которых работа с базами возможна только после запуска в работу этой системы без возможности создания автономных программ, работающих с базами. К этим системам относятся: Access, Paradoх, dBase.
  2. Системы, имеющие как средства для работы с базами данных, так и возможности разработки исполняемых в операционной системе пользовательских программ (приложений), т. е. средства разработчика программ — FoхPro.
  3. Системы для разработки пользовательских программ для работы с базами данных — Clipper, Clarion.

Все подобные СУБД имеют в своем составе средства для:

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

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

Важными факторами, определяющими выбор СУБД, являются:

  • Формат базы данных, обеспечивающий возможность обмена информацией с другими приложениями операционной системы. Одним из самых распространенных форматов является dbf-формат, с которым работают dBase, FoхBase, FoхPro, Visual FoхPro, Clipper. Его «понимают» все приложения MS Office. Данные из этих баз можно переносить в Word, Eхcel, Access. Свои собственные форматы данных имеют Clarion, Paradoх, Access.
  • Обеспечение секретности и конфиденциальности данных имеют системы, не ориентированные на разработчика программ: Access, Paradoх. Однако этот фактор может быть реализован при хранении данных на выделенном сервере, где права различных пользователей легко разграничить.

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

Последние версии СУБД, разработанные для работы в OC Windows 95, относятся к классу RAD-систем (Rapid Application Development) — средства быстрой разработки приложений — и имеют объектно-ориентированный язык программирования. Это такие системы, как Visual FoхPro, MS Access, Visual dBase и др.

Постреляционные базы данных

В настоящее время известны также так называемые постреляционные СУБД, в основе которых лежат модель данных в виде многомерных таблиц (например, в системе Cache фирмы InterSystems Сorporation) и широкое использование принципов объектно-ориентированного подхода при организации баз данных и программировании.

Серверы баз данных

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

Примерами серверов могут быть:

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

Термин «сервер баз данных» обычно используют для обозначения всей СУБД, основанной на архитектуре «клиент-сервер», включая и серверную, и клиентскую части. Наиболее распространенными серверами являются в настоящее время Microsoft SQL Server, Oracle, IBM DB2 Universal DataBase, Informix и др. Размер одной базы данных на этих серверах может достигать миллиона терабайт.

2.5. Распределенные базы данных

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

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

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

Хрестоматия

Название работы Аннотация

Практикумы

Название практикума Аннотация

Презентации

Название презентации Аннотация
Презентации к теме 2

ТЕМА 2 КЛАССИФИКАЦИЯ БнД

Изучаемые вопросы:

1. Классификация БД

2. Классификация СУБД

Литература: , глава 1, глава 2, глава 3.

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

1. Классификация БД

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

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

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

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

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

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

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

5) По характеру организации хранения данных и обращения к ним различают локальные и распределенные БД.

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

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

2. Классификация СУБД

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

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

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

4) По «мощности» СУБД делятся на настольные и корпоративные. Характерными чертами настольных СУБД являются сравнительно невысокие требования к техническим средствам, ориентация на конечного пользователя, низкая стоимость.

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

Таблица 2.1 - Наиболее популярные настольные СУБД

СУБД

Производитель

Visual dBase

dBase, Inc

Paradox

Corel

Microsoft Access

Microsoft

Microsoft FoxPro

Microsoft

Microsoft Data Engine

Microsoft

Таблица 2.2 - Серверные СУБД

СУБД

Производитель

Oracle

Oracle Corp.

Microsoft SQL Server

Microsoft

Informix

Informix

Sybase

Sybase

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

Системы, ориентированные на разработчиков , должны:

¾ иметь качественные компиляторы;

¾ позволять создавать «отчуждаемые» программные продукты;

¾ обладать развитыми средствами отладки;

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

¾ обладать возможностями, позволяющими создавать эффективные сложные системы.

Основными требованиями , предъявляемыми к системам, ориентированным на конечного пользователя , являются:

¾ удобство интерфейса;

¾ высокий уровень языковых средств;

¾ наличие интеллектуальных модулей подсказок;

¾ повышенная защита от непреднамеренных ошибок («защита от дурака») и т. д.

3. Классификация банков данных

1) По условиям предоставления услуг различают бесплатные и платные. Платные делятся на коммерческие и бесприбыльные.

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

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

2) По форме собственности БнД делятся на государственные и негосударственные (частные, групповые, личные).

3) По степени доступности различают общедоступные и с ограниченным кругом пользователей.

4) По охвату предметной области БнД могут классифицироваться в разных «разрезах»:

¾ территориальный (всемирный, страна, город и т.д.);

¾ временной (год, месяц, с начала века и т.п.);

¾ ведомственный;

¾ проблемный (тематический) .

5) По характеру взаимодействия с пользователем БнД делятся на активные и пассивные. В пассивных БнД ведущая роль принадлежит пользователю. В активных – система может самостоятельно менять поведение.

6) По характеру преобладающей обработки информации различают OLTP - системы (On - Line Transaction Processing ) – системы оперативной обработки транзакций (реализуют большое число достаточно простых запросов) и OLAP – системы (On - Line Analytical Processing ) – системы аналитической обработки данных (реализуют сложную аналитическую обработку данных) или системы поддержки принятия стратегических решений (СППР) .

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

Таблица 2.3 - Сравнение OLTP и OLAP

Характеристика

OLTP

OLAP

Преобладающие операции

Ввод данных, поиск

Анализ данных

Характер запросов

Много простых транзакций

Сложные транзакции

Хранимые данные

Оперативные, детализированные

Охватывающие большой период времени, агрегированные

Вид деятельности

Оперативная, тактическая, несложная обработка

Аналитическая, стратегическая: прогнозирование, моделирование, анализ и выявление связей, выявление статистических закономерностей

Тип данных

Структурированные

Разнотипные

Период хранения данных

До года

До нескольких десятков лет

Изменчивость данных

Изменяются

Добавляются

Упорядочение данных

По любому полю

По хронологии

Объем обрабатываемой информации

Небольшой

Очень большой

Скорость обработки

Средняя

Очень высокая

Часто и небольшими порциями

Редко и очень большими порциями

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

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

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

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

СУБД организует хранение информации таким образом, чтобы ее было удобно:

просматривать,

пополнять,

изменять,

искать нужные сведения,

делать любые выборки,

осуществлять сортировку в любом порядке.

Классификация баз данных:

По характеру хранимой информации:

Фактографические (картотеки),

Документальные (архивы)

По способу хранения данных:

Централизованные (хранятся на одном компьютере),

Распределенные (используются в локальных и глобальных компьютерных сетях).

По структуре организации данных:

Табличные (реляционные),

Иерархические,

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

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

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

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

В реляционной БД используются четыре основных типов полей:

Числовой,

Символьный (слова, тексты, коды и т.д.),

Дата (календарные даты в форме «день/месяц/год»),

Логический (принимает два значения: «да» - «нет» или «истина» - «ложь»).



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

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

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

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

Популярные СУБД - FoxPro, Access for Windows, Paradox. Для менее сложных применений вместо СУБД используются информационно-поисковые системы (ИПС), которые выполняют следующие функции:

хранение большого объема информации;

быстрый поиск требуемой информации;

добавление, удаление и изменение хранимой информации;

вывод ее в удобном для человека виде.


Базовые топологии локальных компьютерных сетей.

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

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

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

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

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

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


Топология глобальной вычислительной сети

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

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

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

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

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

    иерархические,

    сетевые,

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

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

Типология баз данных с точки зрения информационных процессов

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

    уровень информационных технологий (ИТ),

    уровень системы (ИС),

    уровень информационных ресурсов (ИР).

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

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

При рассмотрении на уровне информационных ресурсов БД трактуется как элемент мировых ИР. Основной характеристикой здесь является содержание БД , хотя и структуры данных также немаловажны.

Классификация по модели данных

    Иерархическая

    Сетевая

    Реляционная

    Объектная и объектно-ориентированная

    Объектно-реляционная

    Функциональная .

Классификация по среде постоянного хранения

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

    В оперативной памяти (англ. in-memory database, memory-resident database, main memory database ): все данные на стадии исполнения находятся в оперативной памяти .

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

Классификация по содержимому

    Географическая

    Историческая

  • Мультимедийная.

Классификация по степени распределённости

    Централизованная, или сосредоточенная (англ. centralized database ): БД, полностью поддерживаемая на одном компьютере.

    Распределённая (англ. distributed database ): БД, составные части которой размещаются в различных узлах компьютерной сети в соответствии с каким-либо критерием.

    • Неоднородная (англ. heterogeneous distributed database ): фрагменты распределённой БД в разных узлах сети поддерживаются средствами более одной СУБД

      Однородная (англ. homogeneous distributed database ): фрагменты распределённой БД в разных узлах сети поддерживаются средствами одной и той же СУБД.

      Фрагментированная, или секционированная (англ. partitioned database ): методом распределения данных является фрагментирование (партиционирование, секционирование ), вертикальное или горизонтальное.

      Тиражированная (англ. replicated database ): методом распределения данных является тиражирование (репликация ).

Другие виды БД

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

    Временная , или темпоральная (англ. temporal database ): БД, в которой поддерживается какой-либо аспект времени , не считая времени, определяемого пользователем.

    Пространственно-временная (англ. spatial-temporal database ) БД: БД, в которой одновременно поддерживается одно или более измерений в аспектах как пространства, так и времени.

    Циклическая (англ. round-robin database ): БД, объём хранимых данных которой не меняется со временем, поскольку в процессе сохранения данных одни и те же записи используются циклически.

СУБД имеет программные, технические и организационные составляющие.

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

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

Классификации субд По модели данных

    Иерархические

  • Реляционные

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

    Объектно-реляционные

По степени распределённости

    Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

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

По способу доступа к бд

    Файл-серверные

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

На данный момент файл-серверная технология считается устаревшей.

    Клиент-серверные

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

    Встраиваемые

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

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

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

    Моделирование данных

    Особенности архитектуры и функциональные возможности

    Контроль работы системы

    Особенности разработки приложений

    Производительность

    Надежность

    Требования к рабочей среде

    Смешанные критерии

3. Архитектура базы данных

Информация об определенной предметной области представлена в базе данных моделями нескольких уровней. По числу уровней в архитектуре различают одноуровневые, двухуровневые, трехуровневые системы. На различных уровнях архитектуры СУБД поддерживается разный уровень абстракции данных. В настоящее время наиболее распространенной является предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД. При проектировании баз данных выделяют три уровня: концептуальный, внутренний и внешний.

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

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

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

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

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

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

Клиент-серверная информационная система состоит в простейшем случае из 2 основных компонентов:

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

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

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

Клиент - это приложение пользователя. Его также называют приложением - клиентом.

Клиент и сервер взаимодействуют следующим образом:

1. Клиент формирует и посылает запросы (SQL-запросы) на чтение или изменения данных на сервер, на котором размещена БД. Эти запросы написаны на языке SQL.

2. Удалённый сервер сети направляет запрос программе SQL Server (серверу баз данных).

Достоинства архитектуры «клиент-сервер».

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

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

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

 Уменьшение сложности клиентских приложений за счёт отсутствия в нём кода, связанного с контролем БД и разграничения доступа к ней.

Жизненный цикл базы данных.

Процесс проектирования, реализации и поддержания системы базы данных называется жизненным циклом базы данных (ЖЦБД). Процедура создания системы называется жизненным циклом системы (ЖЦС).

ЖЦБД состоит из следующих этапов:

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

 какие прикладные программы используются, и какие функции они выполняют;

 какие файлы связаны с каждым из этих приложений;

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

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

Информация этого этапа документируется в виде обобщенной модели данных.

2. Проверка осуществимости. Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.:

 технологическая осуществимость – есть ли технология для реализации запланированной БД?

 операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД?

 экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду?

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

 Определяются цели системы путём анализа информационных потребностей. Здесь также обязательно указывается, какую именно БД следует создавать (распределённую, целостную) и какие коммуникационные средства необходимы. Выходной документ – комментарий, описывающий цели системы.

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

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

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

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

Основным выходным документом является единая инфологическая модель (или схема БД на концептуальном уровне). При разработке данной модели используются информация и функции, которые должна выполнить система, определённые на этапе сбора и определения требований к системе. На данном этапе желательно также определить: 1) правила для данных; 2) правила для процессов; 3) правила для интерфейса.

5. Реализация – процесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы.

1) Выбор и приобретение необходимой СУБД.

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

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

 определяются, какие прикладные процессы необходимо реализовать в схеме данных как хранимые процедуры;

 реализовать ограничения, предназначенные для обеспечения целостности данных и реализации правил для данных;

 спроектировать и сгенерировать триггеры для реализации всех централизованно определённых правил для данных и правил целостности данных, которые не могут быть заданы как ограничения;

 разработать стратегию индексирования и кластеризации; выполнить оценку размеров всех таблиц, кластеров и индексов;

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

 разработать сетевую топологию БД и механизм бесшовного доступа к удалённым данным (реплицированная или распределённая БД).

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

4) Заполнение базы данных.

5) Создание прикладных программ, контроль управления.

6) Обучение пользователей.

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

Таким образом, ЖЦБД включает в себя:

 Изучение предметной области и представление соответствующей документации (1-3).

 Построение инфологической модели (4).

 Реализация (5).

 Оценка работы и поддержка БД (6).

Этапы проектирования баз данных

При разработке БД можно выделить следующие этапы работы.

I этап. Постановка задачи.

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

II этап. Анализ объекта.

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

III этап. Синтез модели.

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

IV этап. Выбор способов представления информации и программного инструментария.

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

В большинстве СУБД данные можно хранить в двух видах:

    с использованием форм;

    без использования форм.

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

V этап. Синтез компьютерной модели объекта.

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

Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

Стадия 2. Создание исходной таблицы или таблиц.

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

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

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

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

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

Стадия 3. Создание экранных форм.

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

Стадия 4. Заполнение БД.

Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE – в виде формы.

VI этап. Работа с созданной базой данных.

Работа с БД включает в себя следующие действия:

    поиск необходимых сведений;

    сортировка данных;

    отбор данных;

    вывод на печать;

    изменение и дополнение данных.

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

Концептуальное (инфологическое) проектирование

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

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

Логическое (даталогическое) проектирование

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

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

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

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

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

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

К неструктурированным могут быть отнесены БД, организованные в виде семантических сетей.

Частично структурированными можно считать БД в виде обычного текста или гипертекстовые системы.

Структурированные БД требуют предварительного проектирования и описания структуры.

Структурированные БД по типу используемой модели делятся на

· иерархические,

· сетевые,

· реляционные,

· смешанные и

· мульти модельные.

Эта классификация распространяется и на СУБД.

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

Большинство систем поддерживает:

· поле – наименьшая семантическая единица информации;

· совокупность полей (или более сложных ИЕ) образует запис ь ;

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

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

По типу хранимой информации БД делятся на

· фактографические,

· документальные и

· лексикографические.

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

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

К лексикографическим БД относятся различные словари (классификаторы, многоязычные словари, словари основ слов и т. п.).

По характеру организации хранения данных и обращения к ним различают

· локальные (персональные),

· общие (интегрированные,

· централизованные) и

· распределенные БД (рис. 10).

Рис. 10. Классификация БД по характеру хранения и обращения к данным

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

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

Распределяться по узлам сети могут и другие компоненты СБД. Сама БД при этом может быть нераспределенной. Поэтому различают:

· распределенные БД;

· распределенные СБД (в которых распределен хотя бы один компонент).

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

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

Классификация СУБД

По языкам общения СУБД делятся на

· открытые,

· замкнутые и

· смешанные.

В открытых системах для обращения к БД используются универсальные языки. Замкнутые системы имеют собственные языки общения с пользователями СБД.

По выполняемым функциям СУБД делятся на

· информационные и

· операционные.

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

По сфере возможного применения различают

· универсальные и

· специализированные (проблемно ориентированные СУБД).

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

По мощности СУБД делятся на

· настольные (Dbase, FoxBase/FoxPro, Clipper, Paradox, Access, Approach) и

· корпоративные (Oracle, DB2, Sybase, Informix, Ingres, Progress).

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

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

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

По ориентации на преобладающую категорию пользователей можно выделить СУБД