1 Базы данных. Основные понятия

1.1 Общие сведения

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

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

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

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

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

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

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

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

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

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

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

В настоящее время существуют СУБД, реализующие эти возможности как на уровне локальных баз данных, расположенных на одном диске (Paradox, DBase), так  и промышленных удаленных баз данных (Acсess, Oracle, FoxPro). Выполнение основных функций по методам доступа и поддержания физической модели базы данных во всех современных системах обеспечивается ядром СУБД.

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

 SHAPE  \* MERGEFORMAT

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

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

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

Таблица 1 – Требования к реляционным базам данных

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

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

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

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

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

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

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

-      объединения таблиц;

-      пересечения таблиц;

-      взятия разности таблиц;

-      прямого произведения таблиц.

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

-      ограничение таблицы;

-      проекцию таблицы;

-      соединение таблиц;

-      деление таблиц.

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

1.3 Нормализация базы данных

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

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

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

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

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

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

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

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

1.4 Основные требования к организации базы данных

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

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

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

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

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

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

Целостность: если база данных содержит данные, используемые многими пользователями, очень важно, чтобы элементы данных и связи между ними не разрушались.

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

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

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

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

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

1.5 Трехуровневая архитектура

Архитектура ANSI/SPARC включает в себя три уровня:

-      внутренний, наиболее близкий к физическому хранению информации;

-      внешний, наиболее близкий к представлению данных конечным пользователям;

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

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

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

Внешний уровень представлен для различных пользователей различными языками общения: для программиста – это какой-либо язык программирования, для конечного пользователя – язык запросов или специализированный язык, основанный на формах и меню. Вне зависимости от типа, каждый из них включает подъязык данных, связанный только с объектами баз данных. В большинстве случаев это SQL. Любой подъязык данных является комбинацией как минимум двух подчиненных языков – языка определения данных (DDL), поддерживающего объявление объектов базы данных, и языка обработки данных (DML), поддерживающего обработку таких объектов.

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

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

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

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