Наиболее распространенные современные субд

Промышленные коммерческие СУБД:

• Oracle (Oracle Corporation),

• IBM DB2 (IBM),

• Microsoft SQL Server (Microsoft),

• Sybase (Sybase),

• ADABAS (Software AG)

• Interbase (Borland)

• Caché (InterSystems Corporation).

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

• MySQL,

• PostgreSQL,

• Firebird.

На практике основными критериями классификации СУБД выступают: мощность, масштаб, стоимость, используемые платформы.

По мощности и масштабу обычно выделяют следующие категории:

1. «Легкие» (настольные/упрощенные): xBase, FoxPro, Paradox, MS Access …

2. «Средние»: Pervasive SQL (Btrieve), Sybase (ASA, ASE), SQL Base Gupta, InterBase, MS SQL Server …

3. «Тяжелые»: Oracle (фирма Oracle), DB2 (фирма IBM), Informix (фирма Informix –Informix Software в 2001 г. приобретена IBM, и входит в ее подразделение Data Management Division IBM), ADABAS + TAMINO для XML (фирма Software AG), Progress (фирма Progress), CA Ingress (фирма CA), Teradata (фирма Teradata).

Ведущее положение среди крупнейших промышленных СУБД занимает Oracle – у нее до 40% доли рынка СУБД. Oracle появилась в 1979 г., в 1997 г. вышла 8 версия; выпущена уже 11 версия.

Кроме того, существуют разработки на границе между «средними» и «тяжелыми»: Cache (постреляционная, фирма InterSystems), Линтер (фирма «Рэлекс» г. Воронеж).

Объектно-ориентированные СУБД: Jasmine (фирма CA), Versant, Object /DB, GemStone, Ontos DB.

• MySQL: главное достоинство – быстродействие, однако, ограниченные функциональные возможности. Применяется для простых приложений, в частности Web. Часто используется с PHP и сервером Apache. (создавалась для Unix).

• PostgreSQL: недостаток – сложное администрирование, достоинство – мощность. Она реляционно-объектная. (создавалась для Unix).

• FireBird (≈InterBase 6): простая, с открытым кодом. Одна из утилит, облегчающая взаимодействие с FireBird – IBConsole.

• Cache – объектно-реляционная СУБД, самая быстрая по выполнению запросов.

• Семейство Microsoft SQL: SQL Server обособилась от Sybase в 1989 г. Сервер был ориентирован на OS/2 и Windows NT; сегодня работает только под Windows.

Известно, что в основном все современные промышленные СУБД поддерживают клиент-серверную архитектуру.

Архитектура клиент-сервер

Эффективность функционирования информационной системы с базой данных во многом зависит от ее архитектуры. На сегодня наиболее распространенной и перспективной является распределенная архитектура клиент-сервер. Она предполагает наличие компьютерной сети и распределенной базы данных. Развитие этой архитектуры началось с 80-х годов XX века с развитием локальных компьютерных сетей (Local Area Network – LAN) на базе персональных компьютеров.

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

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

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

Исторически первыми были распределенные ИС архитектуры «файл-сервер». В таких ИС по запросам с пользовательских автоматизированных рабочих мест (АРМ) файлы базы данных передавались на персональные компьютеры АРМ, где и производилась их обработка. Недостатки такого варианта архитектуры очевидны – высокая интенсивность передачи данных в сети (большая загрузка сети – высокий трафик). Кроме того, – передача в большинстве случаев избыточных данных, поскольку независимо от потребностей пользователя АРМ, файлы базы данных передаются целиком.

В архитектуре файл-сервер работали СУБД семейства xBase (dBaseIII, Clipper, FoxPro, Paradox). Кроме отмеченных эти системы имели следующие недостатки.

1. Не обеспечивали приемлемой производительности с большими объемами данных.

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

3. Не обеспечивали нужный уровень секретности и разграничения доступа

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

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

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

Технология клиент-сервер подразумевает 4 основных принципа (элемента):

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

2. Функциональное разделение и «обособление» процессов;

3. Организация связи (мониторинг, управление) между процессами;

4. Использование различных вычислительных платформ (многоплатформенность);

Преимущества архитектуры "клиент-сервер":

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

• снижается сетевой трафик за счет посылки сервером клиенту только тех данных, которые он запрашивал; например, если необходимо сделать из таблицы объемом 10 000 записей выборку, результатом которой будут всего 2 записи, сервер выполнит запрос и перешлет клиенту набор данных из 2 записей;

• упрощается наращивание вычислительных мощностей в условиях развития программного обеспечения и возрастания объемов обрабатываемых данных: проще и чаще дешевле усилить мощности на сетевом сервере или полностью заменить сервер на более мощный, нежели наращивать мощности или полностью заменять 100-500 клиентских компьютеров;

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

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

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

Способы (модели) реализации архитектуры клиент-сервер

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

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

В соответствии с этим в любом приложении выделяются следующие логические блоки (компоненты):

- компонент представления (presentation), реализующий функции первой группы;

- прикладной компонент (business application), поддерживающий функции второй группы;

- компонент доступа к информационным ресурсам (resource access) или менеджер ресурсов (resource manager), поддерживающий функции третьей группы.

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

1. Модель доступа к удаленным данным – RDA (Remote Data Access)

2. Модель сервера БД – DBS (Data Base Server)

3. Модель сервера приложений – AS (Application Server)

Рис. 1. Модель доступа к удаленным данным – RDA

Данная модель характеризуется понятиями «тонкий сервер» – «толстый клиент».

Рис. 2. Модель сервера БД – DBS

В этой модели – наоборот: «толстый сервер» – «тонкий клиент».

Рис. 3. Модель сервера приложений – AS

Обратите внимание – в AS-модели и сервер и клиент – «тонкие». Серверов приложений может быть несколько, ориентированных на разные функции.

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

Главное преимущество RDA-модели лежит в практической плоскости. Сегодня существует множество инструментальных средств, обеспечивающих быстрое создание desktop-приложений, работающих с SQL-ориентированными СУБД. Большинство из них поддерживают графический интерфейс пользователя в MS Windows, технологию ADO, стандарт интерфейса ODBC, содержат средства автоматической генерации кода. Иными словами, основное достоинство RDA-модели заключается в унификации и широком выборе средств разработки приложений. Подавляющее большинство этих средств разработки на языках четвертого поколения (включая и средства автоматизации программирования) как раз и создают коды, в которых смешаны прикладные функции и функции представления.

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

AS-модель (рис.3) в наибольшей степени отражает сильные стороны технологии "клиент-сервер".

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

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

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

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

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

Реляционная модель данных была предложена в 1969 – 1970 годах Е.Ф.Коддом (E.F.Codd), известным исследователем в об­ласти баз данных, работавшим тогда в корпорации IBM. Согласно Кодду, реляционная база данных представляет собой хранилище данных, содержащее набор двумерных таблиц. Набор средств для управления подоб­ным хранилищем называется реляционной системой управле­ния базами данных (РСУБД).

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

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

Базовой структурой реляционной модели данных является отношение, основанное на декартовом произведении доменов.

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

Пусть D1, D2 ,…, Dk – произвольные конечные и не обязательно различные множества (домены). Декартово произведение этих множеств определяется следующим образом:

D₁×D₂×...×D_k = {(d₁, d₂,...,d_k | d_i  D_i, i=1,...,k)}

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

Отношением называется подмножество декартова произведения доменов; его элементами являются упорядоченные n-кортежи вида <d1, d2,…, d_k >.

Отношение (таблица) содержит данные о сущностях (объектах) определённого типа.

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

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

Количество атрибутов в отношении называется степенью отношения.

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

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

Термины реляционной модели	Термины «табличные» и языка SQL	Термины обработки данных
Отношение	Таблица	Файл
Кортеж	Строка	Запись
Атрибут	Столбец	Поле
Домен	Множество допустимых значений	Базовый или пользовательский тип данных (с условиями)
Мощность (кардинальность) отношения	Количество строк	Количество записей
Степень отношения	Количество столбцов	Количество полей

Е.Ф.Кодд предложил следующие принципы, определяющие структуру базы данных реляционной модели:

1) каждое значение на пересечении строки и столбца должно быть атомарным (скалярным);

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

3) каждый кортеж (запись) в таблице уникален; отношения не содержат идентичных кортежей;

4) каждый атрибут (поле) имеет уникальное имя (обычно в пределах одного отношения);

5) последовательность атрибутов в отношении не определена (на практике в СУБД их порядок фиксируется);

6) последовательность кортежей в отношении не определена.

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

Логические связи в реляционной модели.

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

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

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

• "один–ко–многим";

• "один–к–одному";

• "многие–ко–многим".

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

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

Отношение "многие–ко–многим" применяется в следующих случаях:

• одной записи в родительской таблице соответствует более одной записи в дочерней;

• одной записи в дочерней таблице соответствует более одной записи в родительской.

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

Виды ключей в реляционной модели данных. Первичные и внешние ключи.

Для идентификации кортежей (записей) используются ключи.

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

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

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

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

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

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

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

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

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

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

Логические части реляционной модели; ограничения целостности.

Реляционную модель можно рассматривать как состоящую из трех частей:

• структурной;

• манипуляционной;

• целостной.

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

Манипуляционная часть описывает два эквивалентных теоретических способа манипулирования реляционными данными – реляционную алгебру и реляционное исчисление.

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

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

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