использование альтернативных ключей

43
УДК 004.652.4:550.3
ИСПОЛЬЗОВАНИЕ АЛЬТЕРНАТИВНЫХ КЛЮЧЕЙ
ДЛЯ ПОВЫШЕНИЯ БЫСТРОДЕЙСТВИЯ
ГЕОЛОГО - ГЕОФИЗИЧЕСКИХ БАЗ ДАННЫХ
И РЕАЛИЗАЦИИ БИЗНЕС - ЛОГИКИ
Бакусов Л.М., Насыров Р.В., Старцев Ю.В. 1
Уфимский государственный авиационный технический университет, г. Уфа
e-mail: 1 startcevy@mail.ru
Аннотация. Рассмотрены полезные свойства реляционных баз данных, построенных на основе альтернативных ключей. Исследовано сравнительное быстродействие баз данных с суррогатными и альтернативными ключами на примере связанных
таблиц с данными геофизических исследований скважин. Показано, что использование
альтернативных ключей для связей между таблицами может дать существенный выигрыш по времени выборки данных по сравнению с суррогатными ключами. Рассмотрены способы использования альтернативных ключей для реализации бизнес-правил соответствия данных и реализации иерархий категорий. Приведены примеры моделей данных, реализующих бизнес-правила по классификациям территорий нефте- и газодобычи.
Ключевые слова: реляционная база данных, таблица, первичный ключ, суррогатный ключ, альтернативный ключ, SQL-запрос, объединение таблиц, время выборки данных, каскадные обновления, геофизические исследования скважин, бизнес-правила,
иерархия категорий
Базам данных в области нефте- и газодобычи свойственны большие объемы хранимых данных. Особенно большое количество записей характерно для таблиц с данными по геофизическим и гидродинамическим исследованиям скважин,
а также для таблиц с информацией по геологическим объектам в разрезах скважин. Количество записей в таких таблицах по одной скважине может достигать
десятков и сотен тысяч, а по совокупности скважин нефтегазодобывающей компании исчисляться миллиардами. Выборка данных при этом требует больших затрат
времени, что снижает эффективность работы с базой данных.
Общепринятым правилом проектирования таблиц реляционной базы данных в настоящее время является использование суррогатных ключей [1, 4]. Современные системы управления базами данных (СУБД) должны поддерживать ключи, определяемые системой (суррогатные ключи) [1]. Например, СУБД Oracle
поддерживает генерацию значения суррогатного ключа с помощью механизма последовательностей и триггеров.
Если в реляционной таблице первичный ключ – суррогатный, то уникальность записей обеспечивается альтернативным ключом. В этом смысле наличие в
реляционной таблице хотя бы одного альтернативного ключа является необходимым. В противоположность суррогатному ключу, альтернативный ключ строится
на атрибутах, непосредственно связанных с реальными объектами.
_____________________________________________________________________________
 Электронный научный журнал «Нефтегазовое дело», 2012, № 2
http://www.ogbus.ru
44
Целью настоящей статьи является исследование полезных свойств баз данных, построенных на основе альтернативных ключей.
1. Альтернативный и суррогатный ключи
с точки зрения пользователя базы данных
Использование суррогатного ключа имеет смысл, когда все потенциальные
ключи являются композитными – состоят из нескольких атрибутов. В качестве
обоснования эффективности применения суррогатного ключа приводятся доводы,
что [2]:
– SQL-запрос на выборку из таблицы по значению суррогатного ключа синтаксически проще и выполняется быстрее, чем аналогичный запрос на выборку по
значениям атрибутов композитного ключа;
– не требуется в подчиненных таблицах хранить значения атрибутов композитного ключа;
– отпадает необходимость каскадных изменений.
Эти доводы в основном сводятся к упрощению разработки базы данных и
ее приложений. Как справедливо отмечено в [4], суррогатный ключ в основном
направлен на упрощение SQL-запроса. Но с точки зрения пользователя базы данных (а именно для него она и создается) подобная аргументация не является убедительной.
Суррогатный ключ имеет существенный недостаток – он никоим образом
не связан с реальными объектами. Посмотрим на него с точки зрения пользователя базы данных. Для него суррогатный ключ не несет в себе никакой информации. Пользователь оперирует понятиями реальных объектов и может сформулировать запрос на выборку на основе атрибутов композитного альтернативного
ключа, но никак не суррогатного. Кроме того, чтобы сформулировать запрос на
основе значения суррогатного ключа, само это значение предварительно откуда-то должно быть получено. Например, при выборке из подчиненной таблицы
значение ее внешнего ключа соответствует значению суррогатного ключа конкретной записи главной таблицы. Этим случаем, собственно, и ограничивается
удобство использования суррогатного ключа как средства связи между реляционными таблицами. При этом, как правило, результирующая выборка представляется пользователю в виде отчета «главный - детальный».
2. Альтернативные и суррогатные ключи
с точки зрения объединения таблиц
В отличие от вышеуказанного отчета вида «главный - детальный» довольно часто пользователю требуется представить результирующую выборку в виде
простого отчета, в котором объединяются данные из главной и подчиненной
таблиц. Естественно, в нем должны присутствовать атрибуты альтернативных
ключей главной и подчиненной таблиц, и SQL-запрос на выборку – это запрос с
_____________________________________________________________________________
 Электронный научный журнал «Нефтегазовое дело», 2012, № 2
http://www.ogbus.ru
45
объединением таблиц. Для такой ситуации типичен случай, когда значения в
отдельных столбцах таблиц берутся из справочников, и замена естественного значения для объекта каким-либо кодом недопустима.
Объединение таблиц всегда требует большего времени на получение результирующего набора данных, чем выборка из одной таблицы. Разница во времени весьма существенна при больших количествах записей в объединяемых таблицах. Оценим эту разницу на примере реальных данных, соответствующих предметной области геофизических исследований скважин (ГИС).
На рис. 1 приведена модель данных (физический уровень), содержащая три
таблицы: Well (Скважина), Wellbore (Ствол скважины) и Log_curve_actual (Значения актуальных кривых ГИС). Все таблицы имеют суррогатные первичные
ключи.
Рис. 1. Модель данных с тремя связанными таблицами
Связи между таблицами реализованы в двух вариантах – по первичным
ключам и по альтернативным ключам. При связи по первичному ключу в дочернюю таблицу мигрирует атрибут первичного ключа родительской таблицы. При
связи по альтернативному ключу в дочернюю таблицу мигрируют атрибуты альтернативного ключа родительской таблицы. Альтернативный ключ таблицы Well
– интеллектуальный ключ Unique_well_id (Уникальный идентификатор скважины). Альтернативный ключ таблицы Wellbore – комбинация столбцов Unique_well_id и Wellbore_number_user (Пользовательский номер ствола). Альтернативный ключ таблицы Log_curve_actual – комбинация столбцов Unique_well_id,
Wellbore_number_user и Depth (Глубина). В реальной базе данных таблицы Well и
Wellbore содержат по 1 357 записей каждая, таблица Log_curve_actual содержит
4 742 621 запись.
Пусть требуется получить итоговую выборку из таблицы Log_curve_actual, которая содержала бы данные обо всех глубинах замеров по выбранной скважине и выбранному стволу этой скважины. Исследуем два варианта получения
этих данных (практическая реализация была выполнена на СУБД Oracle 10g XE).
Вариант 1. В результате миграции атрибутов альтернативных ключей
таблица Log_curve_actual содержит все необходимые столбцы для того, чтобы по
_____________________________________________________________________________
 Электронный научный журнал «Нефтегазовое дело», 2012, № 2
http://www.ogbus.ru
46
ним можно было сформировать результирующую выборку. SQL-запрос на выборку выглядит следующим образом:
select lca .*
from Log_curve_actual lca
where lca.UNIQUE_WELL_ID = 'ЗС_ЕМ-ЁГА_0000001R'
and lca.WELLBORE_NUMBER_USER = '1R'
Объединения таблиц в SQL-запросе в этом случае не требуется. Среднее
время выборки данных составило 363 мс, разброс значений по серии выборок от
328 мс до 391 мс.
Вариант 2. Если рассматривать таблицы как связанные только по суррогатным ключам, то SQL-запрос на итоговую выборку должен быть построен как внутреннее объединение таблицы Well (столбец Unique_well_id), таблицы Wellbore
(столбец Wellbore_number_user) и таблицы Log_curve_actual (столбец Depth).
SQL-запрос на выборку выглядит следующим образом:
select w.UNIQUE_WELL_ID, wb.WELLBORE_NUMBER_USER, lca.DEPTH
from Log_curve_actual lca,
Wellbore wb,
Well w
where wb.WELLBORE_ID = lca.WELLBORE_ID
and w.WELL_ID = wb.WELL_ID
and w.UNIQUE_WELL_ID = 'ЗС_ЕМ-ЁГА_0000001R'
and wb.WELLBORE_NUMBER_USER = '1R'
Среднее время выборки данных составило 633 мс, разброс значений по
серии выборок от 594 мс до 656 мс.
Вывод очевиден: с точки зрения минимизации времени выполнения запросов на объединение таблиц использование альтернативных ключей явно предпочтительнее, чем суррогатных.
Другие доводы в пользу суррогатных ключей в настоящее время также не
представляются сколько-нибудь существенными. Необходимость хранить в подчиненной таблице значения атрибутов альтернативного ключа, конечно, требует
дополнительной памяти. Но современные запоминающие устройства уже достигли таких объемов памяти, что не накладывают практически никаких ограничений
на объемы баз данных. Более того, в связи с удешевлением микросхем оперативных запоминающих устройств, увеличением их емкости и уменьшением времени
доступа в настоящее время появились тенденции хранения всех таблиц базы данных в оперативной памяти ради ускорения выборок. Проблема же каскадных обновлений в целом решается очень просто, если для проектирования базы данных
использовать CASE-средства.
Наконец, максимальную эффективность может дать совместное использование суррогатного и альтернативных ключей. Так, если построить один из аль-
_____________________________________________________________________________
 Электронный научный журнал «Нефтегазовое дело», 2012, № 2
http://www.ogbus.ru
47
тернативных ключей таким образом, чтобы в его состав вошел и суррогатный
ключ, и использовать его в качестве внешнего ключа подчиненной таблицы, то
такая модель данных использовала бы все достоинства и суррогатных, и альтернативных ключей.
3. Альтернативные ключи как средство
реализации правил соответствия данных
Альтернативные ключи, помимо своей основной функции, могут служить
средством реализации некоторых бизнес-правил – например, для задания требуемых правил соответствия данных. В качестве примера рассмотрим модель данных
(логический уровень), описывающую достаточно крупные нефте- и газоносные
территории и их соответствия друг другу (рис. 2).
Рис. 2. Модель данных взаимного соответствия нефте- и газоносных территорий
Сущность Вид территории производственной представляет собой справочник, в котором перечислены возможные виды производственных территорий
(под производственной территорией понимается достаточно крупная нефте- или
газоносная территория, на которой ведется разведка или добыча). Значениями
атрибута Вид_территории_производственной справочника могут быть, например, следующие: месторождение, площадь ГРР (площадь геолого-разведочных работ), проект (территория проектных работ). Значения этого атрибута нестабильны: в разных нефтегазодобывающих предприятиях используются отличающиеся
названия видов территорий, также отличается и номенклатура видов территорий,
и номенклатура может меняться со временем. Территории одного вида могут принадлежать территориям другого вида (входить в состав). Например, проект может
охватывать (т.е. иметь в своем составе) месторождения. Следовательно, месторождение может принадлежать проекту. Аналогично: площадь ГРР может принадлежать месторождению (на месторождении может находиться обособленная площадь ГРР), и месторождение может принадлежать площади ГРР (на площади ГРР
может быть образовано обособленное месторождение).
_____________________________________________________________________________
 Электронный научный журнал «Нефтегазовое дело», 2012, № 2
http://www.ogbus.ru
48
Для описания правил принадлежности видов производственных территорий служит сущность Классификация видов территорий производственных.
Два ее атрибута Вид_территории_производственной и Принадлежит_Вид_территории – это мигрирующий по двум связям атрибут альтернативного ключа АК1
сущности Вид территории производственной. Такая организация данных позволяет пользователю устанавливать правила принадлежности даже в процессе эксплуатации базы данных, причем с использованием естественных словесных обозначений, а не числовых значений суррогатных ключей.
Для описания собственно самих производственных территорий предназначена сущность Территория производственная. Она связана со справочником
Вид территории производственной, и атрибут альтернативного ключа АК1
справочника мигрирует в сущность Территория производственная. Альтернативный ключ АК1 сущности Территория производственная построен по атрибутам Регион_нефтегазоносный, Территория_производственная и Вид_территории_производственной. Таким образом, каждая территория производственная всегда имеет определенный тип и привязана к конкретному нефтегазоносному региону – это нужно для того, чтобы различать, например, Комсомольское месторождение в Волго-Уральском регионе и Комсомольское месторождение в Западной Сибири.
Наконец, принадлежность производственных территорий друг другу описывается в сущности Классификация территорий производственных. Она связана, с одной стороны, с сущностью Территория производственная. Двойная
связь этих сущностей обеспечивает миграцию атрибутов альтернативного ключа
АК1 из сущности Территория производственная в сущность Классификация
территорий производственных соответственно в атрибуты Регион_нефтегазоносный, Территория_производственная, Вид_территории_производственной, Принадлежит_Территория и Принадлежит_Вид_территории. Миграция атрибута
Регион_нефтегазоносный автоматически обеспечивает условие, что взаимная
принадлежность может быть задана только для территорий одного и того же нефтегазоносного региона. С другой стороны, сущность Классификация территорий производственных одновременно связана и с сущностью Классификация
видов территорий производственных. Атрибуты альтернативного ключа АК1
Вид_территории_производственной и Принадлежит_Вид_территории сущности Классификация видов территорий производственных мигрируют под
своими собственным именами в сущность Классификация территорий производственных и оказываются полностью идентичными тем, которые мигрировали
сюда из сущности Территория производственная. Таким образом, пара значений атрибутов Вид_территории_производственной и Принадлежит_Вид_территории в таблице Классификация территорий производственных может быть
только такой, которая присутствует в одной из записей таблицы Классификация
_____________________________________________________________________________
 Электронный научный журнал «Нефтегазовое дело», 2012, № 2
http://www.ogbus.ru
49
видов территорий производственных. При этом реализуется контроль за соблюдением правил соответствия видов территорий на уровне самой СУБД, без необходимости ручного написания контролирующих процедур и триггеров. Наконец,
использование во всех приведенных сущностях атрибутов альтернативных ключей, значениями которых являются легко понятные пользователю термины предметной области, облегчает восприятие данных без каких-либо объединений
таблиц.
4. Альтернативные ключи как средство реализации иерархии категорий
Альтернативные ключи могут служить эффективным средством построения иерархии категорий. Иерархии категорий (иерархии наследования) – это особый вид объединения сущностей, детализирующих общие характеристики некоторых объектов. Примером этого может служить упомянутая выше сущность
Территория производственная, в которую сведены отличающиеся по виду и
имеющие собственные специфические атрибуты объекты – месторождения и площади ГРР. Однако широко распространенные CASE-средства проектирования баз
данных, например ERwin [3], часто не в полной мере обеспечивают выполнение
бизнес-правил для построения иерархии категорий. В нашем примере дискриминатором категорий служит атрибут Вид_территории_производственной, и он определяет неполную категорию (возможны значения этого атрибута, которые не
относятся ни к месторождениям, ни к площадям ГРР). Главное, что требуется
обеспечить – независимость модели данных от конкретных значений дискриминатора и возможность настройки базы данных на принятые в той или иной организации значения дискриминатора. Например, в категорию месторождений должны
быть отнесены все территории, имеющие для атрибута Вид_территории_производственной значения «месторождение», «месторожд.», «мест. геологическое»,
«месторождение лицензионное» и т.п.
Модель данных, реализующая иерархию категорий, приведена на рис. 3.
Обобщенная сущность (супертип) Территория производственная имеет две дочерние категориальные сущности (подтипы) Месторождение и Площадь разведочная. Мощность связей между ними 1:1. По этим связям из родительской сущности в дочерние мигрируют атрибуты альтернативного ключа Регион_нефтегазоносный, Территория_производственная и Вид_территории_производственной.
В каждой из дочерних сущностей эти же атрибуты образуют альтернативный
ключ. Для описания правил разделения на категории служат сущности Соответствие Вид ТП - Месторождение и Соответствие Вид ТП - Площадь ГРР. Их атрибуты Вид_территории_производственной мигрируют из справочника Вид территории производственной. В таблице Соответствие Вид ТП - Месторождение
должны находиться только такие записи, у которых значение в столбце Вид_территории_производственной соответствует понятию месторождения. Аналогично
_____________________________________________________________________________
 Электронный научный журнал «Нефтегазовое дело», 2012, № 2
http://www.ogbus.ru
50
в таблицу Соответствие Вид ТП - Площадь ГРР нужно занести записи, у которых значение в столбце Вид_территории_производственной соответствует понятию площади ГРР.
Рисунок 3. Модель данных для иерархии категорий
Связь между сущностями Месторождение и Соответствие Вид ТП Месторождение допускает занесение в таблицу Месторождение только записей,
соответствующих категории месторождения. Аналогично связь между сущностями Площадь разведочная и Соответствие Вид ТП - Площадь ГРР допускает
занесение в таблицу Площадь разведочная только записей, соответствующих категории площади ГРР. Процесс занесения записей в родительскую и дочерние
таблицы можно автоматизировать с помощью триггера.
В результате пользователь получает базу данных, в которой:
– при необходимости правила разделения категорий можно настраивать,
– выборку данных как по супертипу, так и по подтипам можно производить
непосредственно из соответствующих таблиц, без применения «медленных»
объединений.
_____________________________________________________________________________
 Электронный научный журнал «Нефтегазовое дело», 2012, № 2
http://www.ogbus.ru
51
Выводы
Базам данных в области нефте- и газодобычи свойственны большие
объемы хранимых данных, особенно велики объемы данных по геофизическим
исследованиям скважин. При проектировании таких баз данных следует стремиться к уменьшению времени выборки данных из реляционных таблиц. Использование альтернативных ключей для связи между таблицами позволяет непосредственно извлекать необходимые данные из дочерних таблиц, не прибегая в SQLзапросах к медленно работающим объединениям таблиц, что повышает скорость
выборки при больших объемах данных. Что же касается необходимого для реализации такого подхода увеличения объема памяти, то в настоящее время этот показатель уже не является столь значимым, как повышение быстродействия.
Альтернативные ключи реляционных таблиц баз данных являются мощным средством реализации бизнес-логики. Они могут использоваться не только
для контроля уникальности записей, но и для создания настраиваемых пользователем таблиц, соответствующих принятым в конкретном предприятии бизнес-правилам.
Литература
1. Дейт, К., Дж. Введение в системы баз данных. 7-е изд. Пер. с англ. М.:
Издательский дом «Вильямс», 2001. 1072 с.
2. Суррогатный ключ // WIKIPEDIA.ORG: Википедия – свободная энциклопедия. URL: http://ru.wikipedia.org/wiki/Суррогатный_ключ (дата обращения:
25.01.2012).
3. Маклаков С.В. Создание информационных систем с AllFusion Modelling
Suite. М.: ДИАЛОГ-МИФИ, 2003. 432 с.
4. Дэйв Энсор, Йен Стивенсон. Oracle. Проектирование баз данных. Пер. с
англ. К.: Издательская группа BHV, 1999. 560 с.
_____________________________________________________________________________
 Электронный научный журнал «Нефтегазовое дело», 2012, № 2
http://www.ogbus.ru
UDC 004.652.4:550.3
USING ALTERNATIVE KEYS TO IMPROVE PERFORMANCE
OF GEOLOGICAL AND GEOPHYSICAL DATABASES
AND FOR BUSINESS LOGIC IMPLEMENTATION
Bakusov L.M., Nasyrov R.V., Startsev Yu.V.
Ufa state aviation technical university, Ufa, Russia
e-mail: startcevy@mail.ru
Abstract. The useful properties of relational databases, built on the basis of alternative
keys are considered. The comparative performance of the database with the surrogate and the
alternative keys are investigated on the example of the related tables with data of geophysical
research of wells. It is shown the using of alternative keys for the relationships between tables
can provides significant benefits over time sample data compared to the surrogate keys. The
methods of using of alternative keys for the implementation of the business rules of conformity
of data and implementation of the hierarchies of categories are considered. The examples of
data models which implemented the business rules of the classification of the areas of oil and
gas production are giving.
Keywords: relational data base, table, primary key, surrogate key, alternative key,
SQL-query, joining tables, data access time, cascading updates, geophysical research of wells,
business-rules, hierarchy of categories.
References
5. Deit K.Dzh. Vvedenie v sistemy baz dannykh. 7 izd. Moscow, Wilyams,
2001. 1072 p. (Transl. from: Date C.J. Introduction to database systems, 7th Edition.
Addison-Wesley Pub, 2000. 938 p.)
6. Surrogate key // Wikipedia – the free encyclopedia.
http://en.wikipedia.org/wiki/Surrogate_key (Last accessed: 25.01.2012).
7. Maklakov S.V. Sozdanie informatsionnykh sistem s AllFusion Modelling Suite (Creation of information systems with an AllFusion Modelling Suite). Moscow:
DIALOG-MIFI, 2003. 432 p.
8. Deiv Ensor, Ien Stivenson. Oracle. Proektirovanie baz dannykh. Kiev, BHV,
1999. 560 p. (Transl. from: Dave Ensor, Jan Stevenson. Oracle design: the definitive
guide. O'Reilly Media, 1997. 552 p.)
_____________________________________________________________________________
 Электронный научный журнал «Нефтегазовое дело», 2012, № 2
http://www.ogbus.ru