Проектирование базы данных

 

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

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

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

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

1) копируемые данные. Одинаковые копии данных хранятся в различных местах использования, так как это дешевле пере­дачи данных. Модификация данных контролируется централи­зованно;

2) подмножество данных. Группы данных, совместимые с исходной базой данных, хранятся отдельно для местной обра­ботки;

3) реорганизованные данные. Данные в системе интегриру­ются при передаче на более высокий уровень;

4) секционированные данные. На различных объектах ис­пользуются одинаковые структуры, но хранятся разные дан­ные;

5) данные с отдельной подсхемой. На различных объектах используются различные структуры данных, объединяемые в интегрированную систему;

6) несовместимые данные. Независимые базы данных, спро­ектированные без координации, требующие объединения.

Большое значение для процесса создания БД имеет внутрен­нее содержание информации, которое формирует прикладные БД (ориентированные на конкретные приложения, например, БД для учета и контроля поступления материалов) и предмет­ные БД (ориентированные на конкретный класс данных, например, БД «Материалы» — может быть использована для различных приложений).

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

Для работы с БД используется специальный обобщенный инструментарий в виде СУБД (МВД), предназначенный для управления БД и обеспечения интерфейса пользователя.

Основные требования к СУБД:

- независимость данных на концептуальном, логическом, физическом уровнях;

- универсальность (по отношению к концептуальному и ло­гическому уровням, типу ЭВМ);

— совместимость, неизбыточность;

- безопасность и целостность данных;

— актуальность и управляемость.

Существует два основных вида реализации СУБД: програм­мная и аппаратная.

Программная реализация (в дальнейшем СУБД) представ­ляет собой набор программных модулей, работает под управле­нием конкретной ОС и выполняет ряд функций:

- описание данных на концептуальном и логическом уров­нях;

- загрузка данных;

- хранение данных;

- поиск и ответ на запрос (транзакция); внесение изменений;

- обеспечение безопасности и целостности. Пользователя СУБД обеспечивает такими языковыми сред­ствами, как:

- язык описания данных (ЯОД);

- язык манипулирования данными (ЯМД); прикладной (встроенный) язык данных (ПЯД, ВЯД).

Аппаратная реализация предусматривает использование так называемых машин баз данных (МВД). Их появление вызвано возросшими объемами информации и требованиями к скорости доступа. Слово «машина» в термине МВД означает вспомога­тельный периферийный процессор, термин «компьютер БД» — автономный процессор баз данных или процессор, поддерживающий СУБД. Основные функции МВД — параллельная об­работка; распределенная логика; ассоциативные ЗУ; конвейер­ные ЗУ; фильтры данных и др.

На рис. 2.15 представлена последовательность процедур про­ектирования БД, которые можно объединить в 6 этапов.

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

Этап 2 заключается в описании и синтезе информационных требований пользователей к первоначальному проекту БД. Ре­зультатом этого этапа является высокоуровневое представление информационных требований пользователей на основе различ­ных подходов.

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

На этапе 4 решаются вопросы, связанные с производитель­ностью системы, определяются структуры хранения данных и методы доступа.

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

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

Этап 5 связан с разбиением базы данных на разделы и син­тезом различных приложений на основе модели. Основными факторами, определяющими методику расчленения, являются: размер каждого раздела (допустимые размеры); модели и ча­стоты использования приложений; структурная совместимость: факторы производительности БД. Связь между разделом БД

 

Рис. 7.15. Совокупность процедур проектирования БД

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

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

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

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

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

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

Предназначение склада данных — информационная под­держка принятия решений, а не оперативная обработка дан­ных. Потому база данных и хранилище данных не 5шляются одинаковыми понятиями. Архитектура ХД представлена на рис. 7.16.

Основные принципы организации хранилищ данных [39] при­ведены ниже:

1. Предметная ориентация. В оперативной базе данных обыч­но поддерживается несколько предметных областей, каждая из которых может послужить источником данных для ХД. Напри­мер, для магазина, торгующего видео- и музыкальной продук­цией, интерес представляют такие предметные области, как: клиенты, аудио-, видео-, CD-диски, сотрудники, поставщики. Явно прослеживается аналогия между предметными областями ХД и классами объектов в объектно-ориентированных базах данных. Это говорит о возможности применения методов проек­тирования, применяемых в объектно-ориентированных СУБД.

2. Средства интеграции. Разные представления одних и тех же сущностей приводятся к некоторому общему типу.

 

 

Рис. 7.16. Архитектура ХД

 

3. Постоянство данных. В ХД не поддерживаются операции модификации как в случае традиционных баз данных. В ХД под­держивается модель «массовых загрузок» данных, производимых в заданные моменты времени по установленным правилам в от­личие от традиционной модели индивидуальных модификаций.

4. Хронология данных. Благодаря средствам интеграции реализуется определенный хронологический временной аспект, присущий содержимому ХД.

Основные функции репозитариев:

- парадигма включения/выключения и некоторые формаль­ные процедуры для объектов;

- поддержка множественных версий объектов и процедуры управления конфигурациями для объектов;

- способность оповещения инструментальных и рабочих си­стем об интересующих их событиях;

- управление контекстом и разные способы обзора объектов репозитария;

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

— развитие теории реляционных баз данных;

— моделирование данных и разработка конкретных моделей разнообразного назначения;

— отображение моделей данных, направленных на создание методов преобразования моделей данных и конструирования коммутативных отображений, разработку архитектурных аспек­тов отображения моделей данных и спецификаций определения отображений для конкретных моделей данных;

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

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

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

- управление конкурентным доступом;

- системы программирования баз данных и знаний, которые обеспечивали бы единую эффективную среду как для разработ­ки приложений, так и для управления данными;

- машины баз данных;

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

- пространственно-временные базы данных;

- интеграция неоднородных информационных ресурсов.

Серьезные недостатки реляционной модели данных привели к необходимости поиска других моделей. Такой прогрессивной и перспективной моделью данных является объектно-ориенти­рованная модель данных.

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

Автор реляционной модели данных Э. Ф. Кодд первоначально сформулировал 12 требований к БД, чтобы она могла назы­ваться реляционной. В дальнейшем этот перечень увеличился до 333 требований. Им, несмотря на широкое распространение реляционных баз данных, не удовлетворяет ни одна из извест­ных СУБД.

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

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

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

Программную реализацию класса называют компонентой. Реализация компоненты в некоторой программе получила на­звание объекта.

В объектно-ориентированном программировании использу­ются три основных принципа: инкапсуляция, наследование, полиморфизм.

Инкапсуляция — выделение класса с доступом к нему че­рез свойства или методы.

Наследование — трансформация класса путем изменения свойств и методов с помощью методов, называемых конструк­тором и деструктором.

Все классы (компоненты) строятся по иерархическому прин­ципу с происхождением от некоторого исходного класса.

Полиморфизм позволяет использовать метод с одним име­нем как в базовом, так и в производных классах.

Дело в том, что количество классов значительно: уже сейчас оно приближается к ста и продолжает расти. Если в произво­дных классах применять для однотипных, «похожих» методов (например, начертание квадрата и окружности) разные имена, пользователю, особенно начинающему, будет сложно освоиться с таким разнообразием имен.

Приведем основные положения ООБД, базирующиеся на объектно-ориентированном подходе.

1. В качестве значения столбца может быть использован произвольный кортеж:. Иными словами, столбец может являть­ся как бы некоторой самостоятельной таблицей. Таким образом, создается возможность реализации таблиц с нелинейной струк­турой.

2. Процедура манипуляции данными позволяют присоединять процедуры, определяемые значениями столбцов.

3. Данные столбцов могут наследоваться.

4. Элементами отношений могут служить не только отдель­ные элементы, как в реляционных БД, но и множества.

5. Формируются классы данных, которые организуют столб­цы в иерархию.

Базовым языком ООБД чаще всего является С++. Для ра­боты с такими ООБД разработан новый вариант языка про­граммирования SQL, получивший название SQL3 и содержащий внутри себя в качестве частного случая реляционную модель (SQL2). Если SQL2 определяет семь способов связывания со стандартными языками программирования, в SQL3 это коли­чество предполагается увеличить.

В технологии разработки ООБД конкурируют два направ­ления.

Distributed Object Linking and embedding (OLE) фирмы Microsoft;

- Common Object request Broker Architecture (COR) груп­пы OBDMG, поддерживаемая фирмами IBM, Novell, DEC, с ориентацией на все платформы. В рамках этого направления выделены и сформированы указанные ранее язык определения объектов Object Definition Language (ODL); объектный язык запроса — Object Query Language (OQL); язык определения интерфейсов — Interface Definition Language (IDL).

Во втором направлении обычно выделяют [44] два стандарта управления БД:

- ODL/OQL, в котором объекты и методы формируются обычно с помощью языка программирования С;

- язык программирования SQL3.

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

Таким образом, чтобы воспользоваться объектно-ориентиро­ванным подходом в построении собственно БД, необходимо:

- провести инкапсуляцию данных, т.е. выделить классы и объекты;

определить возможные виды структуры реализуемых та­блиц;

- создать наследование классов данных;

- обеспечить полиморфизм.

Реализация даже первой позиции неоднозначна и различна, например в ООСУБД и ОРСУБД. Имеется некоторое отличие и в рамках различных ООСУБД.

По сравнению с реляционными базами данных ООБД об­ладают рядом преимуществ:

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

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

- возможность использования рекурсивных методов при на­вигационном методе доступа к большим объемам данных;

- повышение производительности в 10 — 30 раз;

- более широкая сфера применения (например, использование в мультимедиасистемах).

Преимущества ООБД [3, 4, 36] приведут, видимо, к очень широкому их распространению. Однако прежде следует решить ряд задач по устранению недостатков ООБД: создать гибкую структуру БД; построить четкий язык программирования; от­работать синтаксис разбора запросов, в том числе — вложенных; определить несколько методов доступа к данным; отработать вопросы одновременного доступа (разрешение конфликтов при множественном наследии); определить сложный перебор данных; отработать защиту и восстановление данных; уточнить семан­тику (действия) операторов при динамических изменениях; встроить изменение атрибутов дочерних объектов.

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

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

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

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

Чтобы понять перспективы развития ОРБД, следует оценить их достоинства и недостатки.

К достоинствам следует отнести [36]:

- устранение ряда недостатков реляционных БД;

- повторное использование компонентов;

- использование накопленных знаний по реляционным БД. К недостаткам ОРБД возможно отнести:

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

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

- менее широкий набор типов связей, определяемых языком программирования SQL, чем в объектно-ориентированных БД;

- менее продуманный, отлаженный и стандартизованный набор типов данных, чем в ООБД.

ОРБД, по-видимому, будут существовать еще достаточно долго, чему есть, по меньшей мере, два объяснения:

- быстрое накопление с помощью ОРБД опыта, который можно использовать при создании ООСУБД;

- необходимость иметь средства для постепенного эволюци­онного «перевода» многочисленных реляционных БД в разряд ООБД, за которыми, видимо, будущее.

В последнее время распределенные базы данных (РБД) на­ходят все более широкое применение в связи с массовым рас­пространением «сетевых» технологий.

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

Быстрое распространение сетей передачи данных, резкое увеличение объема внешней памяти ПК при ее удешевлении в 1980-е гг., развитие возможностей персональных компьютеров, которые по своим характеристикам в 1990-е гг. уже превосходи­ли суперЭВМ 1980-х гг., создали необходимую базу для реали­зации и широкого внедрения РБД.

К достоинствам РБД можно отнести:

- соответствие структуры РБД структуре организаций;

- гибкое взаимодействие локальных БД;

- широкие возможности централизации узлов;

— непосредственный доступ к информации, снижение стои­мости передач (за счет уплотнения и концентрации данных);

- высокие системные характеристики (малое время отклика за счет распараллеливания процессов, высокая надежность);

- модульная реализация взаимодействия, расширения аппа­ратных средств, возможность использования объектно-ориентированного подхода в программировании;

- возможность распределения файлов в соответствии с их активностью;

- независимые разработки локальных БД через стандартный интерфейс.

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

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

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

Возникла необходимость в теоретической проработке про­цессов в РБД.

Распределенная база данных (РБД) — система логически интегрированных и территориально распределенных БД, язы­ковых, программных, технических и организационных средств, предназначенных для создания, ведения и обработки информа­ции.

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

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

Дополнительными специфическими требованиями к РБД являются следующие.

ЯОД в рамках схемы должен быть один для всех локальных БД.

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

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

Степень централизации должна быть разумной.

Необходим сбор и обработка информации об эффективности функционирования РБД.

В дальнейшем К. Дейт сформулировал 12 правил для РБД

[13]:

локальная автономность;

отсутствие опоры на центральный узел;

непрерывное функционирование (развитие) РБД;

- независимость РБД от расположения локальных БД; независимость от фрагментации данных; независимость от репликации (дублирования) данных;

- обработка распределенных запросов;

- обработка распределенных транзакций;

- независимость от типа оборудования; независимость от операционной системы;

- независимость от сетевой архитектуры;

- независимость от типа СУБД.

 

Рис. 7.17. Схема, распределенной базы данных

 

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

Схема РБД может быть представлена в виде, показанном на рис. 7.17.

Сравнительные характеристики стратегий хранения приве­дены в табл. 7.3. На ее основе может быть построен простейший алгоритм выбора стратегии, показанный на рис. 7.18.

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

 

Таблица 2.3. Стратегии хранения данных

Название Суть стратегии Достоинства Недостатки
Централизация (в том числе технология клиент-сервер) Единственная копия в одном узле Простота структуры Скорость обработки ограничена одним узлом. Ограниченный доступ. Малая надежность. Долговременная память определяет объем БД
Локализация (расчленение) Единственная копия, расчленение по узлам (полная копия БД не допускается) Объем БД определяется памятью сети. Снижение стоимости РБД. Время отклика при параллельной обработке уменьшается. Малая чувствительность к узким местам. Повышенная надежность при высокой локализации данных Запрос может быть по всем узлам. Доступ хуже, чем при централизации. Рекомендации применения. Долговременная память ограничена по сравнению с объемом БД. Должна быть повышена эффективность функционирования при высокой степени локализации

 

 

Рис. 7.18. Алгоритм выбора стратегии хранения данных: А —- запрос доступа к данным в процедурах обновления и запро­сов.

 

 

В связи с этим часто используют архитектуру «клиент-сервер» (рис.7.19) — структуру локальной сети, в которой применено распределенное управление сервером и рабочими станциями (клиентами) для максимально эффективного ис­пользования вычислительной мощности.

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

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

На сервере чаще всего хранятся только данные, запраши­ваемые клиентами.

Клиент компьютер, обращающийся к совместно исполь­зуемым ресурсам, которые предоставляются сервером.

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

Работа в архитектуре «клиент-сервер» может поддерживаться и с помощью схемы ODBC (Open DataBase Connectivity), как по­казано на рис. 2.20.

Сеть образуется в этом случае путем сое­динения серверов. Такое соединение обеспе­чивается или средствами СУБД (SQL Server), или мониторами транзакций (TUXEDO).

Рис. 7.19. Архитектура «клиент-сервер»

 

Рис. 2.20. ODBC вархитектуре «клиент-сервер»