30.03.17 3.4K

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

Процесс проектирования базы данных

Надлежащим образом структурированная база данных:

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

Разработка БД включает в себя следующие этапы:

1. Анализ требований или определение цели базы данных;
2. Организация данных в таблицах;
3. Указание первичных ключей и анализ связей;
4. Нормализация таблиц.

Рассмотрим каждый этап проектирования баз данных подробнее. Обратите внимание, что в этом руководстве рассматривается реляционная модель базы данных Эдгара Кодда , написанная на языке SQL (а не иерархическая, сетевая или объектная модели ).

Анализ требований: определение цели базы данных

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

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

• Опрос людей, которые будут ее использовать;
• Анализ бизнес-форм, таких как счета-фактуры, расписания, опросы;
• Рассмотрение всех существующих систем данных (включая физические и цифровые файлы ).

Начните со сбора существующих данных, которые будут включены в базу. Затем определите типы данных, которые нужно сохранить. А также объекты, которые описывают эти данные. Например:

Клиенты

• Адрес;
• Город, штат, почтовый индекс;
• Адрес электронной почты.

Товары

• Название;
• Цена;
• Количество в наличии;
• Количество под заказ.

Заказы

• Номер заказа;
• Торговый представитель;
• Дата;
• Товар;
• Количество;
• Цена;
• Стоимость.

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

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

Структура базы данных: построение блоков

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

Чтобы преобразовать списки данных в таблицы, начните с создания таблицы для каждого типа объектов, таких как товары, продажи, клиенты и заказы. Вот пример:

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

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

• CHAR — конкретная длина текста;
• VARCHAR — текст различной длины;
• TEXT — большой объем текста;
• INT — положительное или отрицательное целое число;
• FLOAT , DOUBLE — числа с плавающей запятой;
• BLOB — двоичные данные.

Некоторые СУБД также предлагают тип данных Autonumber , который автоматически генерирует уникальный номер в каждой строке.

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

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

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

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

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

Создание связей между сущностями

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

Каждый объект может быть взаимосвязан с другим с помощью одного из трех типов связи:

Связь «один-к одному»

Когда существует только один экземпляр объекта A для каждого экземпляра объекта B, говорят, что между ними существует связь «один-к одному » (часто обозначается 1:1 ). Можно указать этот тип связи в ER-диаграмме линией с тире на каждом конце:

Если при проектировании и разработке баз данных у вас нет оснований разделять эти данные, связь 1:1 обычно указывает на то, что в лучше объединить эти таблицы в одну.

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

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

Связь «один-ко-многим»

Эта связи возникают, когда запись в одной таблице связана с несколькими записями в другой. Например, один клиент мог разместить много заказов, или у читателя может быть сразу несколько книг, взятых в библиотеке. Связи «один- ко-многим » (1:M ) обозначаются так называемой «меткой ноги вороны», как в этом примере:

Чтобы реализовать связь 1:M , добавьте первичный ключ из «одной » таблицы в качестве атрибута в другую таблицу. Если первичный ключ таким образом указан в другой таблице, он называется внешним ключом. Таблица со стороны связи «1 » представляет собой родительскую таблицу для дочерней таблицы на другой стороне.

Связь «многие-ко-многим»

Когда несколько объектов таблицы могут быть связаны с несколькими объектами другой. Говорят, что они имеют связь «многие-ко-многим » (M:N ). Например, в случае студентов и курсов, поскольку студент может посещать много курсов, и каждый курс могут посещать много студентов.

На ER-диаграмме эти связи отображаются с помощью следующих строк:

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

Для этого нужно создать между этими двумя таблицами новую сущность. Если между продажами и продуктами существует связь M:N , можно назвать этот новый объект «sold_products », так как он будет содержать данные для каждой продажи. И таблица продаж, и таблица товаров будут иметь связь 1:M с sold_products . Этот вид промежуточного объекта в различных моделях называется таблицей ссылок, ассоциативным объектом или таблицей связей.

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

Обязательно или нет?

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

Два объекта могут быть взаимозависимыми (один не может существовать без другого ).

Рекурсивные связи

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

Лишние связи

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

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

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

В то же время не все базы данных необходимо нормализовать. В целом, базы с обработкой транзакций в реальном времени (OLTP ), должны быть нормализованы.

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

Первая форма нормализации

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

Возможно, у вас возникнет желание обойти это ограничение, разделив данные на дополнительные столбцы. Но это также противоречит правилам: таблица с группами повторяющихся или тесно связанных атрибутов не соответствует первой форме нормализации. Например, приведенная ниже таблица не соответствует 1NF :
Вместо этого во время физического проектирования базы данных разделите данные на несколько таблиц или записей, пока каждая ячейка не будет содержать только одно значение, и дополнительных столбцов не будет. Такие данные считаются разбитыми до наименьшего полезного размера. В приведенной выше таблице можно создать дополнительную таблицу «Реквизиты продаж », которая будет соответствовать конкретным продуктам с продажами. «Продажи » будут иметь связь 1:M с «Реквизитами продаж ».

Вторая форма нормализации

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

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

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

Таким образом, таблица с этими полями не будет соответствовать второй форме нормализации, поскольку атрибут «название товара » зависит от идентификатора продукта, но не от номера заказа:

• Номер заказа (первичный ключ );
• ID товара (первичный ключ );
• Название товара.

Третья форма нормализации

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

В соответствии с 3NF , нельзя хранить в таблице любые производные данные, такие как столбец «Налог », который в приведенном ниже примере, напрямую зависит от общей стоимости заказа:

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

Многомерные данные

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

Правила целостности данных

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

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

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

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

Добавление индексов и представлений

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

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

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

Расширенные свойства

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

SQL и UML

Унифицированный язык моделирования (UML ) — это еще один визуальный способ выражения сложных систем, созданных на объектно-ориентированном языке. Некоторые из концепций, упомянутых в этом руководстве, известны в UML под разными названиями. Например, объект в UML известен, как класс.

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

Хорошо Плохо

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

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

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

Структура базы данных

Система базы данных состоит из следующих элементов:

Таблицы: Данные хранятся в строках (записи) и столбцах (поля).

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

Запросы: Запросы написаны для извлечения строк и / или столбцов на основе заранее определенного состояния.

Наиболее известные базы данных это: MySQL, SAP, Oracle, IBM DB2 и т.д. СУБД или "система управления базы данных» используется в качестве интерфейса для связи между пользователем и базой данных.

Что такое базы данных и для где они используются?

Хранение данных / Вставка: Начальная фаза (перед вводом данных) включает в себя создание структуры данных, таких как таблицы (с необходимым количеством строк и столбцов). Затем данные вносят в эту структуру.

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

Данные модификации / Updation: Статические данные не нуждаются в обновлении. Тем не менее, динамические данные нуждаются в постоянной модификации. Рассмотрим возраст сотрудников в организации. Она должна обновляться каждый год (периодическое обновление).

Пример

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

Преимущества баз данных

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

Ассоциация данных: записи данных из отдельных таблиц могут быть связаны. Это необходимо, когда определенный фрагмент данных существует в более чем одной таблице. Например, идентификаторы работников могут существовать в таких данных как «Заработная плата», а также «сотрудники». Связь имеет важное значение для того, чтобы иметь единые изменения в нескольких местах и ​​тех же данных.

Несколько пользователей: Разрешения могут быть предоставлены для множественного доступа к базе данных. Это позволяет одновременно нескольким (более одного) пользователям, получить доступ и манипулировать данными.

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

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

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

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

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

Сортировки данных / Фильтрация: Фильтры могут быть применены к данным, которые имеют одинаковые значения данных. Примером одинаковых данных могут быть имена сотрудников организации с аналогичными фамилиями или именами. Аналогичным образом данные могут быть отсортированы как по возрастанию, так и по убыванию. Это помогает в просмотре или распечатки результатов в требуемом порядке.

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

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

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

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

Цели использования баз данных

Использование БД в основном обеспечивает:

1. независимость данных и программ;

2. реализацию отношений между данными;

3. совместимость компонентов БД;

4. простоту изменения логической и физической структур БД;

5. целостность, восстановление и защиту БД и др.

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

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

Независимость данных и программ объясняется двумя основными причинами.

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

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

Отношения между данными . Данные об объектах в БД связаны между собой отношениями (связями). Отношение между объектами А и В обозначим следующим образом:

где F(х) - вид связи объекта А с объектом В; G(х) - вид связи объекта В с объектом А. Функции F(х) и G(х) могут принимать значения U и N - единичная и множественная связи соответственно. Обычно рассматривают четыре типа отношений.

1. Отношение

(один к одному) означает, что каждому экземпляру объ­екта А В и, наоборот, любому экземпляру объекта В может соответствовать только один экземпляр объекта А. Например:

ПРЕДПРИЯТИЕ -- ДИРЕКТОР

2. Отношение

A -- B (1: N )

(один ко многим) означает, что могут существовать экземпляры объекта А, которым соответствует более одного экземпляра объекта В, но каждому экземпляру объекта В может соответствовать только один экземпляр объекта А. Например:

ОРГАНИЗАЦИЯ -- ПОДРАЗДЕЛЕНИЕ (1:N)

3. Отношение

A -- B (1:N )

(многие к одному) означает, что каждому экземпляру объекта А может соответствовать только один экземпляр объекта В и среди экземпляров объекта В могут быть такие, которым соответствует несколько экземпляров объекта А. Очевидно, что если 1: N - тип отношения между А и В, то N : 1 - тип отношения между В и A . Например:

РАБОЧИЙ -- ПРЕДПРИЯТИЕ

4. Отношение

A -- B (M: N )

(многие ко многим, или групповое) означает, что может существовать экземпляр объекта А, которому соответст­вует несколько экземпляров объекта В, и, наоборот, од­ному экземпляру объекта В может соответствовать не­сколько экземпляров объекта А. Очевидно, что если М: N А и В, то N:М - тип отношения между объектами В и А. Например:

ПОСТАВЩИК -- ПРОДУКТ

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

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

Программное обеспечение СУБД обычно является надстройкой, расширением возможностей ОС в части управления данными.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выделяют следующие виды СУБД:

* полнофункциональные СУБД;

* серверы БД;

* средства разработки программ работы с БД.

Полнофункциональные СУБД представляют собой традиционные СУБД. К ним относятся dBaseIV, Microsoft Access, Microsoft FoxPro и др.

Серверы БД предназначены для организации центров обработки данных в сетях ЭВМ. Серверы БД обеспечивают обработку запросов клиентских программ обычно с помощью операторов SQL. Примерами серверов БД являются: Microsoft SQL Server, InterBase и др.

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

Средства разработки программ работы с БД могут использоваться для создания следующих программ:

* клиентских программ;

* серверов БД и их отдельных компонентов;

* пользовательских приложений.

По характеру использования СУБД делят на многопользовательские (промышленные) и локальные (персональные).

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

* возможность организации совместной параллельной работы многих пользователей;

* масштабируемость;

* переносимость на различные аппаратные и программные платформы;

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

* обеспечение безопасности хранимых данных и развитой структурированной системы доступа к ним.

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

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

* относительно ограниченные требования к аппаратным ресурсам.

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

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

· язык описания данных -- высокоуровневый непроцедурный языкструктуры данных;

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

Названные языки в различных СУБД могут иметь отличия. Наибольшее распространение получили два стандартизованных языка: QBE -- язык запросов по образцу и SQL -- структурированный язык запросов. QBE в основном обладает свойствами языка манипулирования данными, SQL сочетает в себе свойства языков обоих типов.

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

* управление данными во внешней памяти;

* управление буферами оперативной памяти;

* управление транзакциями;

* ведение журнала изменений в БД;

* обеспечение целостности и безопасности БД.

Реализация функции управления данными во внешней памяти обеспечивает организацию управления ресурсами в файловой системе ОС.

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

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

Транзакции присущи три основных свойства:

* атомарность (выполняются все входящие в транзакцию операции или ни одна);

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

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

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

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

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

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

Введение

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

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

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

1. Организация баз данных

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

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

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

Схемы и подсхемы базы данных часто изображают в виде диаграмм. На рис. 1 приведена общая схема логической структуры базы данных и подсхемы двух прикладных программистов, которые имеют различные представления о данных. Сплошные линии обозначают связи на схеме. Простые связи обозначаются одной стрелкой, связи "один ко многим" - двойной стрелкой. Штриховые линии отображают перекрестные ссылки. Наличие перекрестных ссылок позволяет избежать повторения записей ПОСТАВЩИК и СПЕЦИФИКАЦИИ - ПАРТИИ -ТОВАРА в каждой записи СТАТЬЯ ЗАКУПКИ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Выбор СУБД

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

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

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

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

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

Ниже приведены краткие характеристики некоторых универсальных СУБД.

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

В системе допускается обращение к данным из прикладных программ пользователя, написанных на языке АССЕМБЛЕР, ПЛ/1, КОБОЛ, АЛГОЛ-60, ФОРТРАН-4.

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

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

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

Пользовательские программы могут быть написаны на языках КОБОЛ, ФОРТРАН, БЕЙСИК-2 и обращаются к базе данных с помощью САМ-интерфейса.

СУБД КВАНТ-М поддерживает базу данных, состоящую из набора массивов (файлов). Записи массива имеют одинаковую структуру и уникальный последовательный номер (ISN). Записи состоят из полей, которые являются минимальной единицей данных в базе. Поле может быть объявлено ключом. Для описания данных в файлах создается схема, содержащая имена полей записей, их тип и признак, указывающий, является ли поле ключом. Для пользователей создается одна или несколько подсхем, к которым они имеют доступ.

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

Языком манипулирования данными является язык КВАНТ СКРИПТ-М. Это англоподобный диалоговый язык, предназначенный для эффективного поиска и выделения записей в базе данных и вывода их на дисплей.

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

4. Специализированные базы данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Распределенные базы данных

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

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

Проектирование РБД может проходить в условиях:

а) создание АСУ только начинается и стоит задача выбора оптимальной структуры РБД и размещения отдельных ЛБД;

б) существует определенное количество ЛБД и ВЦ и стоит задача размещения дополнительного числа ЛБД и оптимального изменения структуры связей в системе;

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

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

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

Выбор топологии сети ЛБД определяется характером их информационных взаимосвязей, направлением и интенсивностью информационных потоков, необходимой надежностью и достоверностью передачи информации. Обычно пользователи прикрепляются к одной ЛБД и через эту ЛБД связываются с остальными базами данных в РБД. Различают следующие типы структур связей ЛБД в РБД: радиальную, радиально-узловую, кольцевую, каждый с каждым, комбинированную (рис. 4, а - г). Наиболее надежной, с быстрым поиском информации является система со структурой "каждый с каждым". Информационные связи такого типа характерны для объектов, подчиненных друг другу только функционально.

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

1) по структурной информации о размещении данных в РБД происходит поиск необходимой ЛБД и обращение к этой ЛБД;

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

3) осуществляется обращение в управляющую ЛБД, где хранится структурная информация о всех ЛБД;

4) осуществляется опрос всех ЛБД либо параллельно, либо последовательно.

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

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

Стратегия 3 минимизирует структурную информацию.

Стратегия 4 отличается большими потоками запросной информации.

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