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

      Основные  типы данных SQL – используемые языком SQL основные типы данных, форматы которых  могут несколько различаться  для разных СУБД: целое число; десятичное число; вещественное число; символьная строка фиксированной или переменной длины; дата в формате (по умолчанию  mm/dd/yy); время в формате (по умолчанию hh.mm.ss); деньги в формате, определяющем символ денежной единицы и его расположение (суффикс или префикс) и др.

      Таблицы создаются командой CREATE TABLE. Эта команда  создает структуру таблицы. Значения вводятся с помощью DML команды INSERT (см. далее). Команда CREATE TABLE в основном определяет имя таблицы в виде описания набора имен столбцов, указанных в определенном порядке. Она также определяет типы данных и размеры столбцов. Cинтаксис команды CREATE TABLE будет следующим:

CREATE TABLE базовая_таблица (столбец тип_данных [,столбец тип_данных] ...);

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

      Предложение для создания следующее:

CREATE INDEX ON (имя_столбца[,] ...);

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

      Представления (View) – это таблицы, чье содержание выбирается или получается из других таблиц. Они работают в запросах и операторах DML точно так же, как и базовые таблицы, но не содержат никаких собственных данных. Представление создается командой CREATE VIEW. Она состоит из слов CREATE VIEW (создать представление), имени представления, которое нужно создать, слова AS (как) и, далее, запроса.

Синтаксис предложения CREATE VIEW имеет вид:

CREATE VIEW имя_представления

[(столбец[,столбец] ...)]

AS подзапрос;

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

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

SELECT [ DISTINCT]

<Список полей  > или *

FROM < Список таблиц>

[WERE<Условие отбора>]

[ORDER BY <Список полей для сортировки  >]

[GROUP BY < Список полей для группирования>]

[HAVING <Условия группирования >]

[UNION<Вложенный оператор SELECT>]

      Критерий  отбора строк формируется из одного или нескольких условий, соединенных  логическими операторами:

• AND – когда должны удовлетворяться оба разделяемых с помощью AND условия;
• OR – когда должно удовлетворяться одно из разделяемых с помощью OR условий;
• AND NOT – когда должно удовлетворяться первое условие и не должно – второе;
• OR NOT – когда или должно удовлетворяться первое условие, или не должно удовлетворяться второе.

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

      В языке SQL также имеется возможность  изменения таблицы после того, как она была создана. Команда ALTER TABLE используется, чтобы изменить определение  существующей таблицы. Обычно она добавляет  столбцы к таблице. Иногда она  может удалять столбцы или  добавлять в (удалять из) определение таблицы новые (существующие) ограничения. Типичный синтаксис, чтобы добавить столбец к таблице:

ALTER TABLE  имя_таблицы

ADD имя_столбца;

 

Глава 2.Преимущества и недостатки реляционных баз данных

2.1. Преимущества реляционных баз данных

Реляционная модель данных – логическая модель данных. Впервые была предложена британским учёным, сотрудником компании IBM Эдгаром Франком Коддом в 1970 году в статье "A Relational Model of Data for Large Shared Data Banks". В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.

В реляционной  модели достигается гораздо более  высокий уровень абстракции данных, чем в иерархической или сетевой. В упомянутой статье Е.Ф. Кодда утверждается, что "реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления". Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название "реляционная" происходит от английского relation – "отношение").

Основные идеи современной информационной технологии базируются на

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

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

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

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

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

Итак, преимущества реляционных баз данных:

  • простота и доступность для понимания пользователем. Единственной используемой информационной конструкцией является "таблица";

• строгие правила проектирования, базирующиеся на математическом аппарате;

• полная независимость данных. Изменения в прикладной программе при изменении реляционной БД минимальны;

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

 

2.2. Недостатки реляционных баз данных

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

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

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

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

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

Пример:

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

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

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

o возможность определения новых типов данных

o определение наборов операций, связанных с данными определенного типа

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

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

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

Первые работы, в которых отмечались эти и  ряд других недостатков, появились  уже в начале 80-х годов. Одна из наиболее ярких статей была опубликована в 1990 г. - Системы баз данных третьего поколения: Манифест. Вслед за первым манифестом последовали Манифест систем объектно-ориентированных баз данных. (М. Аткинсон, Ф. Бансилон, Д. ДеВитт, К. Диттрих, Д. Майер, С.Здоник, СУБД № 4 1995) и Третий манифест (Х.Дарвин, К.Дэйт, СУБД № 1 1996).