Курс лекций информатика

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

Подход с использованием СУБД

СУБД Программа

Программа

База Данных

Программа

Рис. 45 Две основные функции СУБД это:

помочь пользователю в манипулировании данными;

защитить данные от пользователя.

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

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

292

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

Хотя управление данными является сложным вопросом, основные функции до удивления просты. Существуют только 4 основных операции. Пользователю необходимо вводить информацию в базу, производить поиск информации, удалять ненужную информацию или корректировать (модифицировать, изменять) содержимое базы.

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

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

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

Кфункциям СУБД также относятся:

определение структуры БД, инициализация БД и начальная загрузка данных;

управление ресурсами среды хранения;

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

293

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

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

поддержка логической целостности (непротиворечивости) БД;

обеспечение физической целостности БД, т.е. защита и восстановление БД после различного рода сбоев;

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

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

специализированные системы.

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

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

294

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

Для работы с СУБД используют языки различного назначения:

для описания данных в терминах БД и манипулирования данными;

для написания прикладных программ.

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

Язык манипулирования данными (ЯМД или язык запросов к БД) предназначен для выражения операций доступа к БД из прикладных программ. Он обычно представлен системой команд манипулирования данными.

По способу реализации языков СУБД разделяют на 2 группы:

с включающим языком;

с базовым языком.

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

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

295

11.3. Модели данных

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

внешний уровень;

концептуальный уровень;

физический уровень.

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

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

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

296

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

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

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

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

В качестве средств реализации инфологической модели могут выступать семантические сети, текстовые описания предметной области, но опыт показывает, что такие способы представления предметной области крайне неэффективны. Гораздо более информативными и полезными при разработке баз данных являются описания предметной области, выполненные при помощи графических средств. Из наиболее известных можно назвать методику структурного анализа SADT, диаграммы потоков данных Гейна-Сарсона, методику объектно-ориентированного анализа UML и др. Наиболее популярными оказались различные варианты ER- диаграмм (Entity-Relationship, диаграммы «сущность-связь»). ER-

297

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

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

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

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

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

Модель данных определяют три компонента:

допустимая организация данных;

ограничения целостности;

298

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

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

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

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

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

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

299

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

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

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

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

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

300

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

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

11.4. Общая характеристика реляционной модели данных

Наиболее распространенная трактовка реляционной модели данных (РМД) принадлежит К. Дейту. Реляционная модель данных отличается от сетевой и иерархической следующими положениями:

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

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

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

301