Разделение функций БД - СУБД - Приложение.

Концептуальные модели баз данных.

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

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

Рис. 2. Граф-дерево

Достоинства ИМД:

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

Недостатки ИМД:

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

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

Рис. 4. Граф с произвольными связями

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

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

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

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

Счет (№счета, Дата, Покупатель, Товар, Кол-во).

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

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

В многомерной модели данных та же самая информация может быть представлена гораздо более наглядно:

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

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

Разделение функций БД - СУБД - Приложение.

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

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

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

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

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

Рис. 1. Структура современной БД

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

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

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

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

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

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

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

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

Относительным достоинством привязки структур хранения информации к приложению является полная свобода разработчика в плане оптимизации этих структур для хранения конкретной, характерной только для решаемой задачи информации. Первый шаг на этом направлении развития баз данных был продиктован очевидным желанием: один раз тщательно отработать вопросы хранения самой разнообразной информации и прийти к некоторым универсальным, унифицированным решениям, которые и использовать всегда, когда встает проблема хранения накопленной информации. При этом, с одной стороны, отпадает необходимость в повторном решении одной и той же задачи, а с другой – не возникает проблем при необходимости прямого доступа к информации, поскольку правила доступа едины и всем хорошо известны. Ярким примером здесь могут служить, так называемые, dbf-файлы. Они были разработаны в качестве структуры хранения информации в рамках ныне забытой СУБД dBase, но прекрасно используются и по настоящее время (загляните, например, в список форматов, поддерживаемых MS Excel).

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2018-05-31; просмотров: 565; Мы поможем в написании вашей работы!

Поделиться с друзьями:

12 3 4 5 6 7 8 9 10 Следующая ⇒

Мы поможем в написании ваших работ!