YourLib.net
Твоя библиотека
Главная arrow Информатика (Под общ. ред. А.Н. Данчула) arrow 3.3.2. Системы управления базой данных
3.3.2. Системы управления базой данных

3.3.2. Системы управления базой данных

   Типичными задачами, решаемыми АИС, являются поиск и обработка данных, т. е. их преобразование по определенным алгоритмам, реализованным в соответствующих программах согласно потребностям пользователя. В ранних АИС каждая программа содержала все необходимые для ее решения данные, которые находились именно в этой программе и не могли, как правило, быть использованы другой программой. Одной из причин этого были разные форматы данных и разные способы их структурирования (упорядочивания) в разных программах, которые были ориентированы на наилучшее использование в конкретной программе, но не на возможность использования этих же данных в другой программе. Таким образом, можно утверждать, что в этом случае программы и данные не были разделены до такой степени, когда возможно использование одних и тех же данных разными программами. Это приводило к неоправданному дублированию фактически одних и тех же данных, но имеющих разную структуру. Другой серьезной проблемой, порождаемой такой тесной интеграцией программ и данных, является необходимость серьезных изменений в программах при любом изменении в структуре данных, порождаемом необходимостью учесть изменение информационных потребностей пользователей.
   Одним из способов решения указанных проблем явилась идея максимального разделения собственно программ и данных, необходимых для этих программ. Такой подход к обработке информации одновременно позволил выявить и универсальные процедуры обработки, характерные для любой ИС, — процедуры ввода, обновления и модификации, а также поиска данных, требующихся пользователю.
   Данные, требующиеся для решения задач пользователя, структурируются и накапливаются в базах данных. Структурирование — это упорядочивание данных по определенным правилам.
   База данных (БД) — это поименованная совокупность структурированных данных, относящихся к некоторой конкретной предметной области.
   Создание базы данных, первичное наполнение ее данными, последующее пополнение и модификация данных, а также организация поиска в базе данных выполняются специальной совокупностью программных средств (разновидностью системного ПО) — системой управления базой данных (СУБД).
   Система управления базой данных (СУБД) — комплекс программных средств, реализующих задачи создания, пополнения, модификации и поиска данных в БД, а также предоставляющих пользователю интерфейс для работы с данными, хранящимися в БД.
   Банк данных — это совокупность БД и СУБД, управляющей этой БД. В настоящее время пользователь работает в среде именно банка данных, так как любая БД предполагает наличие соответствующей СУБД, которая и предоставляет пользователю интерфейс для работы с БД.
   СУБД, в том числе и входящие в состав офисной системы, могут использоваться как самостоятельные программные средства. В то же время СУБД является в настоящее время одним из главных, базовых компонентов практически любой АИС. При этом, чем более сложна АИС по своим функциям и размерам, чем больше ее размеры и объем обрабатываемых данных, тем важнее роль СУБД в эффективной работе АИС.
   Проектирование БД опирается на формализацию описания предметной области (ПрО), информация о которой и должна быть содержимым БД. В самом общем виде информационное содержание ПрО может быть представлено в виде:
   —  множества сущностей (реальных объектов, явлений, процессов, состояний, ситуаций);
   —  множества свойств (атрибутов, реквизитов) сущностей;
   —  множества связей (отношений) между сущностями.
   Информационный объект — это описание некоторой сущности в виде совокупности логически связанных атрибутов, т. е. совокупности ее свойств. Например, в ПрО, связанной с учебным процессом в вузе, сущность (информационный объект) СТУДЕНТ может быть описана как совокупность атрибутов Номер студента (предполагаем, что каждому студенту присвоен уникальный, т. е. неповторяющийся, номер) и ФИО (студента). Понятно, что такое описание относится не к конкретному студенту, а к классу (типу) студентов, т. е. информационный объект (сущность) — это класс реальных объектов, обладающих одинаковыми характеристиками, которому присвоено уникальное имя (в нашем примере — СТУДЕНТ). Информационный объект имеет множество «реализаций» (экземпляров) — описаний конкретных объектов ПрО, относящихся к данному классу, в виде совокупности конкретных значений атрибутов.
   После выделения информационных объектов, их свойств устанавливаются связи между этими объектами, характерные для данной ПрО.
   В общем случае возможны три типа связей между информационными объектами:
   —  один к одному (1:1);
   —  один ко многим (1:m);
   —  многие ко многим (m:m).
   Связь «один к одному» означает, что в моделируемой предметной области одному экземпляру данного информационного объекта А соответствует не более одного экземпляра объекта В, и наоборот.
   Связь «один ко многим» означает, что в моделируемой ПрО одному экземпляру данного информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с одним экземпляром объекта А.
   Связь «многие ко многим» означает, что в моделируемой ПО одному экземпляру данного информационного объекта А соответствует 0, 1 или более экземпляров объекта В, и наоборот.
   Например, между информационными объектами ГРУППА, описывающей учебные группы некоторого вуза, и СТУДЕНТ

 Рис. 3.6. Иерархическая структура БД

Рис. 3.6. Иерархическая структура БД

имеется связь «один ко многим», так как в одной группе обучается 1 и более студентов.
   Выделив при анализе ПрО информационные объекты, описав их через свойства, установив связи между информационными объектами, характерные для данной ПрО, разработчик получает информационно-логическую модель ПрО — представление ПрО в виде совокупности информационных объектов и связей между ними.
   Описание информационных объектов и связей между ними реализуется посредством структурирования данных на основе определенных соглашений и правил, совокупность которых определяет ту или иную модель данных.
   Правила упорядочивания данных в БД, т. е. структуру данных в БД, определяет модель данных, на основе которой и осуществляется представление данных той или иной предметной области.
   Модель данных — совокупность принципов и методов описания данных и манипулирования этими данными.
   Выделяют четыре основных типа моделей данных: иерархическую, сетевую, реляционную и объектную.
   Иерархическая модель данных основывается на представлении связей между информационными объектами в виде иерархической структуры, представляющей собой связанные иерархическими отношениями информационные объекты и образующей ориентированный граф в виде дерева (рис. 3.6). Пример иерархического отношения — «состоит из» (объект ГРУППА состоит из объектов СТУДЕНТ).
   Узел — совокупность атрибутов (свойств), описывающих некоторый информационный объект (представлен вершиной графа). Каждый узел нижнего уровня связан с одним, и только одним, узлом верхнего уровня. Иерархическое дерево имеет только одну вершину (корень дерева), находящуюся на самом верхнем, первом уровне. Зависимые узлы находятся на нижних уровнях: первом, втором и т. д. Существует только один путь к какой-либо записи (объекту) БД от корневой записи.
   В сетевой модели данных, в отличие от иерархической, каждый элемент(объект)-узел может быть связан с любым другим узлом, находящимся на любом уровне. С точки зрения моделирования объектов и связей ПрО сетевая модель более адекватна реальному миру. Однако, сточки зрения конкретного пользователя, который работает лишь с небольшой частью ПрО области, часто более естественным является именно ее иерархическое представление.
   Существуют методы, позволяющие достаточно просто преобразовать иерархическое представление в сетевое. Обратное преобразование также возможно, однако сопряжено с определенными трудностями.
   Реляционная модель данных в настоящее время является наиболее распространенной моделью, положенной в основу большинства БД. Она ориентирована на представление (структурирование) данных в виде двумерных таблиц. При этом каждая таблица имеет определенные свойства:
   —  каждый элемент таблицы (ячейка) является атомарным (неделимым), т. е. содержит только один элемент данных;
   —  все элементы столбца являются однородными по типу данных (или только текстовые, или только числовые);
   —  в таблице нет одинаковых строк;
   —  каждый столбец имеет уникальное наименование.
   Каждая строка таблицы — это запись, т. е. совокупность связанных по смыслу полей.
   С точки зрения реляционной модели таблицы представляют собой отношения, строки таблиц — это кортежи отношений, а столбцы — атрибуты отношений.
   Очень важным для реляционной модели данных (и для других моделей) является понятие ключа данных.
   Первичный ключ данных (таблицы) — это поле или совокупность нескольких полей, однозначно идентифицирующие запись в таблице.
   Если для однозначной идентификации записи таблицы БД достаточно одного поля, то такой ключ называется простым', если же требуется более одного поля — составным. Вторичный ключ (внешний ключ) — это поле записи, которое содержит первичный ключ другой таблицы БД.
   Поле (атрибут), входящее в состав первичного ключа, называется ключевым, невходящее — неключевым.
   Другим важным понятием реляционной модели является тип связи между таблицами. Предположим, что имеются три таблицы, содержащие данные о студентах, группах, преподавателях и факультетах некоторого вуза. Опишем каждую из этих таблиц поименованной совокупностью названий столбцов таблицы (отношения).
   Таблица 1 (имеет имя СТУДЕНТ) содержит данные о студенте (уникальный идентификатор — номер студента, его ФИО и группу):

 Таблица 1

   Таблица 2 (имеет имя ГРУППА) содержит данные о группе (уникальный идентификатор — номер группы, количество студентов, принадлежность к конкретному факультету):

Таблица 2

   Таблица 3 (имеет имя ФАКУЛЬТЕТ) содержит данные о факультете, его преподавателях и декане:

Таблица 3

   Каждая таблица отображает некий информационный объект. В первой таблице таким объектом является студент, во второй — группа, в третьей — факультет.
   В БД, состоящей из трех вышеприведенных таблиц, между таблицами ГРУППА и СТУДЕНТ, ФАКУЛЬТЕТ и ГРУП ПА существует связь «один ко многим». Если предположить, что на каждом факультете всегда учится только одна-единственная группа, то тогда между таблицами ФАКУЛЬТЕТ и ГРУППА была бы связь «один к одному». Если же предположить, что любой студент может обучаться в нескольких группах (т. е. допускается получение им нескольких специальностей одновременно), то в этом случае между таблицами ГРУППА и СТУДЕНТ имела бы место связь «многие ко многим».
   В реляционной модели связь двух таблиц осуществляется с помощью ключей. Возможны два варианта связи:
   —  ключ одной таблицы входит в состав ключа (или совпадает с ним) второй таблицы;
   —  ключ одной таблицы является одним из полей второй таблицы, т. е. внешним ключом (так как не входит в состав ключа второй таблицы).
   Таким образом, связь между сущностями ПрО при реляционном подходе может быть задана:
   —  как вхождение в состав элементов (полей) одной и той же записи конкретной таблицы;
   —  как указание типа связи (1:1 или 1: т) с указанием поля — ключа, по которому осуществляется данная связь. Именно благодаря наличию указанных видов связи и осуществляется выборка данных из таблиц в соответствии с информационными потребностями пользователей.
   Так как описание одних и тех же информационных объектов и связей между ними конкретной ПрО можно выполнить разными способами, т. е. получить в результате разный набор таблиц, то возникает проблема наиболее рациональной группировки (отображения) этих объектов и связей в некоторый набор таблиц. При рациональном конструировании набора таблиц и структуры каждой из этих таблиц следует обеспечить:
   —  минимальное дублирование данных в таблицах, что упрощает процедуры их ведения (ввод новых данных, модификация и удаление), обработки и поиска ошибок;
   —  минимизацию времени обработки данных при их ведении и поиске.
   В общем случае два этих требования могут оказаться противоречащими друг другу, так как для сокращения времени обработки данных в БД (например, при поиске в БД по запросу пользователя) оказывается необходимым ввести определенное дублирование (избыточность) данных. Поэтому понимание причин дублирования данных в БД позволяет не только минимизировать это дублирование, но и в случае необходимости контролировать введение избыточных данных (так называемая контролируемая избыточность данных).
   Для выявления ситуации дублирования данных в БД Е. Кодц предложил правила формирования структур таблиц, которые получили название правил нормализации отношений (описываемых таблицами).
   Отношение (таблица) считается находящимся в первой нормальной форме, если все его атрибуты (поля таблицы) далее неделимы. Это означает, что в любой записи (строке таблицы) в любом поле записи (ячейке таблицы) содержится не более одного значения.
   Рассмотрим таблицу СТУДЕНТ. В каждой строке (записи) этой таблицы каждому значению ключевого атрибута (поля) НОМЕР СТУДЕНТА соответствует только одно значение атрибутов ФИО, НОМЕР_ГРУППЫ (если студент не учится в нескольких группах одновременно). В этом случае говорят, что данный ключевой атрибут и каждый из указанных неключевых атрибутов функционально зависимы.
   Предположим, что ключ некоторого отношения (таблицы) является составным. Например, если студенту разрешается учиться одновременно в нескольких группах и эта информация хранится в виде нескольких строк таблицы СТУДЕНТ, то в этой таблице ключ оказывается составным — из атрибутов НО- МЕР СТУДЕНТА и НОМЕР ГРУППЫ. Если каждый неключевой атрибут отношения функционально зависит от такого составного ключа, но не находится в такой зависимости от любой части (т. е. любого подмножества атрибутов, входящих в ключ) этого ключа, то говорят о полной функциональной зависимости неключевых атрибутов от ключа. В отношении СТУДЕНТ неключевой атрибут ФИО находится в функциональной зависимости от части составного ключа — НОМЕР СТУДЕНТА, следовательно, полная функциональная зависимость отсутствует.
   Отношение, имеющее первую нормальную форму, находится во второй нормальной форме, если оно имеет простой ключ или при составном ключе каждый неключевой атрибут этого отношения функционально полно зависит от ключа. Итак, если разрешить обучение студента одновременно в нескольких группах, то отношение (таблица) СТУДЕНТ не находится во второй нормальной форме. Если возможность обучения в нескольких группах исключена, то это отношение будет находиться во второй нормальной форме.
   Если один из неключевых атрибутов однозначно определяет значение другого неключевого атрибута в отношении, то в этом случае наблюдается транзитивная зависимость последнего неключевого атрибута от ключа. Если такой зависимости нет, то неключевой и ключевой атрибуты имеют нетранзитивную зависимость.
   Отношение находится в третьей нормальной форме, если оно имеет вторую нормальную форму и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.
   Пусть преподавателю разрешается работать только на одном факультете. Тогда ключевой атрибут в таблице ФАКУЛЬТЕТ — ПРЕПОДАВАТЕЛЬ и имеет место транзитивная зависимость неключевого атрибута ДЕКАН от неключевого атрибута ФАКУЛЬТЕТ. Таким образом, данное отношение не находится в третьей нормальной форме и имеет место избыточность данных (повтор в записях значений атрибута ДЕКАН). Следовательно, данное отношение (таблицу) необходимо разделить на два новых отношения (таблицы), в которых избыточность данных уже отсутствует и они находятся в третьей нормальной форме (например, в одной из этих таблиц будут храниться данные о преподавателях факультета, а в другой — о декане факультета).
   Следует отметить, что в настоящее время выделены и другие нормальные формы отношения (четвертая и пятая), однако для практического применения при построении отношений (таблиц), как правило, используют именно указанные выше три нормальные формы, т. е. стремятся привести все отношения (таблицы) некоторой БД к третьей нормальной форме. Именно в этом случае и обеспечивается достаточная минимизация избыточных данных в БД.
   Новым и интенсивно развивающимся направлением в проектировании БД является построение БД на основе объектно- ориентированного подхода к представлению (моделированию) проблемной области (см. главу 4). В настоящее время отсутствует общепринятое определение объектно-ориентированной модели данных. Сейчас можно говорить лишь о неком «объектном» подходе к представлению данных и о различных объектно- ориентированных способах его реализации.
   В объектно-ориентированных базах данных, в отличие от реляционных, хранятся не записи, а объекты. Объектно-ориентиро- ванный подход представляет собой более совершенное средство отображения реального мира, чем реляционная модель, за счет:
   —  более естественного, в сравнении с реляционным, представления данных. В реляционной модели все отношения принадлежат одному уровню, что осложняет преобразование иерархических связей реального мира в реляционную модель. Объ- ектно-ориентированная модель лишена этого недостатка;
   —  возможности определения новых типов данных и операций с ними, адекватно отражающих сложность и разнообразие связей между объектами реального мира.
   В то же время объектно-ориентированной модели присущ и ряд недостатков:
   —  отсутствуют мощные непроцедурные средства извлечения объектов из БД. Все запросы приходится писать на процедурных языках, проблема их оптимизации возлагается на программиста;
   —  вместо чисто декларативных ограничений целостности для обеспечения целостности БД приходится писать процедурный код.
   В настоящее время уже существуют СУБД, реализующие объектно-ориентированные модели БД, однако для промыш-ленных целей, как правило, используются СУБД, ориентированные на сочетание реляционного и объектно-ориентированного подходов к моделированию проблемной области.
   Как указывалось выше, особенности обработки данных той или иной СУБД определяются во многом моделью данных, используемой при проектировании БД. В связи с этим различают иерархические, сетевые и реляционные СУБД. Однако можно представить некоторую обобщенную, имеющую многоуровневую структуру архитектуру банка данных, ориентированную на использование той или иной СУБД (рис. 3.7).
   При работе с БД в среде некоторой СУБД различают три уровня представления данных:
   —  концептуальный;
   —  внешний;
   —  внутренний.
   Концептуальный уровень — уровень представления данных

Рис. 3.7. Архитектура банка данных 

Рис. 3.7. Архитектура банка данных

БД на основе той или иной модели данных (иерархической, сетевой или реляционной).
   Внешний уровень — это некоторая часть концептуального уровня, ориентированная по своему содержанию на информационные потребности конкретного пользователя (группы пользователей) или приложения. Выделение внешнего уровня и соответствующей ему внешней модели ориентировано на представление данных пользователю в том объеме, который определяется информационными потребностями и возможностями доступа к определенной информации (санкционированный доступ к данным в соответствии со статусом пользователя) именно данного пользователя.
   Внутренний уровень — это уровень физического представления (хранения) данных.
   Таким образом, пользователь работает с данными в среде СУБД на внешнем уровне представления данных. Концептуальный и внутренний уровень пользователю, как правило, недоступны.
   СУБД выполняет следующие основные функции:
   —  предоставление разработчику БД инструментальных средств создания концептуальной и внешней модели БД, основным из которых является язык описания данных,
   —  обеспечение целостности данных: их непротиворечивости, полноты и сохранности;
   —  обеспечение безопасности данных при помощи шифрования данных, использования паролей, ограничения прав доступа пользователей к различным файлам, полям, таблицам БД;
   —  обеспечение приложениям и пользователям доступа к данным БД для ведения (ввода и удаления данных, их модификации) и поиска данных, требующихся пользователю или прикладной программе; основным средством доступа к данным, их ведения и поиска выступает язык манипулирования данными, или язык запросов,
   —  обеспечение взаимодействия с операционной системой при организации доступа к данным на физическом уровне, а также многопользовательского и многозадачного режимов работы СУБД.
   Наиболее важной для пользователя из перечисленных выше функций СУБД является предоставление в его распоряжение языка запросов, посредством которого пользователь выражает свои информационные потребности в поиске требующейся ему информации в БД.
   Различают специализированные СУБД, ориентированные на определенную ПрО и определенные информационные потребности пользователей, и СУБД общего назначения, ориентированные на использование практически в любой ПрО и любым пользователем.
   СУБД различаются также и по возможностям обработки определенных объемов информации. Если объем данных в БД измеряется в сотнях гигабайт, то далеко не всякая СУБД способна обработать запросы приложений и пользователей к такой БД. Поэтому при выборе СУБД большое значение имеет размер предполагаемой БД.
   Типичным представителем СУБД общего назначения, ориентированной на обработку данных в объеме, измеряемом сотнями мегабайт, является СУБД Microsoft Access, входящая в состав офисной системы MS Office.

 
< Пред.   След. >