CC BY
45
78
Общетехнические задачи и пути их решения
Заключение
В статье широко представлены различные варианты моделирования шероховатостей поверхностей.
Дальнейшие планы авторов сводятся к увязке типа шероховатости поверхности с той наработкой пар трения, которую они будут иметь в процессе конкретной эксплуатации. Иными словами, представляется весьма целесообразным проследить, как влияет та или иная начальная обработка заготовок деталей, создающая определённый микро- и макрорельеф поверхностей трения, на последующий гарантийный срок службы подвижных сопряжений.
Библиографический список
1. MATHCAD 2000 : математический практикум / А. И. Плис, Н. А. Сливина. -М. : Финансы и статистика, 2000. - 656 с. - ISBN 5-279-02281-0.
2. Краткий курс математики для экономистов / А. Н. Колесников. - М. : ИНФРА-М, 1999. - 208 с. - ISBN 5-86225-569-9.
3. Математика для экономистов на базе Mathcad / А. А.Черняк, В. А. Новиков, О. И. Мельников, А. В. Кузнецов. - СПб. : БХВ-Петербург, 2003. - 496 с. - ISBN 594157-282-4.
4. Специальные функции / Е. Янке, Ф. Эмде, Ф. Лёш. - М. : Наука, 1977. - 344 с.
5. 3D-topography measurements and characterizations of deformable surfaces in context of system’s reliability / T. G. Mathia, K. Voynov, S. Carras // Сборник научных трудов VIII Международной конференции «Трибология и надёжность». - СПб. : ПГУПС, 2008. -C. 351-363. - ISBN 978-5-7641-0207-8.
Статья поступила в редакцию 15.09.2010.
УДК 681.324
М. Л. Глухарёв
ПРИМЕНЕНИЕ ФОРМАЛЬНЫХ ОПИСАТЕЛЕЙ ДЛЯ ЛОГИКО-АЛГЕБРАИЧЕСКОГО МОДЕЛИРОВАНИЯ ТРЕБОВАНИЙ ЦЕЛОСТНОСТИ ИНФОРМАЦИИ В РЕЛЯЦИОННЫХ БАЗАХ ДАННЫХ
В статье рассматривается способ логико-алгебраического моделирования требований целостности, предъявляемых к реляционным базам данных. Вводится понятие формального описателя требования целостности. Рассматривается метамодель формальных описателей, которая задает общий вид формальных описателей, определяет
2010/4
Proceedings of Petersburg Transport University
Общетехнические задачи и пути их решения
79
специфические действия над описателями. Даются практические рекомендации по программной реализации требований целостности в реляционных базах данных.
целостность, требование целостности, требование к состоянию, требование к переходу, ограничение целостности, триггер, триггерная связка, связанная таблица, активизирующий оператор, псевдотаблица, формальный описатель, метамодель формальных описателей, соединение описателей, разбиение описателей, верификация, спецификация, модель реализации.
Введение
В теории реляционных баз данных свойство целостности определяется как согласованность и корректность данных с точки зрения здравого смысла [1]. БД является отражением предметной области, для которой она создается. Каждая предметная область определяет ряд ограничений на множество допустимых состояний данных в БД и переходов данных из одного состояния в другое. На практике пользователь может попытаться случайно или умышленно внести в БД некорректные данные. Если это удается сделать, то возникает нарушение целостности информации, которое в некоторых случаях может повлечь за собой серьезные проблемы на производстве.
Автоматическая поддержка целостности на уровне БД реализуется с помощью специальных программных объектов - ограничений целостности (ОЦ) и триггеров. Выбор конкретного способа реализации каждого требования целостности - задача разработчика БД. Чтобы выбор был оптимальным, а реализация ОЦ и триггеров - максимально полной и корректной, желательно соблюдение следующих условий.
1. Требования целостности должны быть четко и полно сформулированы заказчиком.
2. Реализация соответствующих механизмов поддержки целостности должна проводиться поэтапно. Непосредственной разработке должно предшествовать формальное моделирование требований целостности.
В настоящей статье рассматривается метамодель, определяющая способ формального описания требований целостности; вводится понятие формального описателя требования целостности; приводятся примеры формального описания типовых требований целостности; даются некоторые практические рекомендации по применению формальных описателей в процессе реализации и верификации ОЦ и триггеров.
1 Метамодель формальных описателей
Согласно концепции Дейта [1], целостность может рассматриваться как корректность состояний данных и корректность переходов из одного состояния в другое.
ISSN 1815-588 Х. Известия ПГУПС
2010/4
80
Общетехнические задачи и пути их решения
Состоянием данных называется совокупность текущих значений, хранящихся в таблицах БД. В зависимости от целей проектирования, разработки и верификации БД состояние данных можно рассматривать на различных уровнях детализации: допустимо говорить о состоянии БД в целом, а также о состоянии некоторых (выбранных) таблиц или отдельных столбцов. Состояния данных могут быть корректными и некорректными, т. е. допустимыми и недопустимыми с точки зрения здравого смысла. Задача разработчика БД - добиться того, чтобы БД и любой ее фрагмент всегда находились в корректном состоянии. Требование целостности, задающее множество корректных состояний для выбранных таблиц и (или) столбцов, будем называть требованием к состоянию. Для одной БД можно задать много требований к состоянию, связывающих различные таблицы и столбцы.
Выполнение операций записи в таблицах - вставки, обновления и удаления строк - приводит к переходу данных из одного состояния в другое. Возможны случаи, когда для выбранных таблиц и (или) столбцов только часть возможных переходов является допустимой в данной предметной области или с точки зрения здравого смысла. Требование целостности, задающее множество допустимых переходов для выбранных таблиц и (или) столбцов, будем называть требованием к переходу. В рамках одного проекта БД может быть определено множество требований к переходу, связанных с различными таблицами и столбцами.
Оригинальный способ моделирования требований целостности предложили Г. Гарсиа-Молина, Дж. Ульман и Дж. Уидом [2]. Основная идея способа состоит в том, чтобы описывать множество допустимых состояний данных, задаваемое требованием целостности, на языке реляционной алгебры. Действительно, реляционная алгебра содержит средства для описания различных состояний данных, в том числе допустимых на любой момент времени. Авторы рекомендуют описывать требования целостности выражениями вида:
R = 0,
где R - набор данных, полученный как результат вычисления некоторого выражения реляционной алгебры;
0 - пустое множество строк.
Рассмотрим два примера, приводимых авторами в указанной работе. Пусть в БД имеются таблицы Movie (фильмы) и MovieExec («руководители», т. е. продюсеры фильмов и президенты кинокомпаний). Таблица Movie содержит внешний ключ producerC# - идентификационный номер «руководителя», являющегося продюсером фильма. Соответствующий первичный ключ в таблице MovieExec имеет название cert#. Формально требование ссылочной целостности между этими таблицами описывается при помощи следующего выражения:
2010/4
Proceedings of Petersburg Transport University
Общетехнические задачи и пути их решения
81
п produce* #(Movie) - ncert ,(MovieExec) = 0. С1)
Действительно, связи между таблицами Movie и MovieExec корректны, когда столбец Movie .producerC# не содержит ни одного значения, отсутствующего в MovieExec.cert#.
Аналогичным способом можно описать ограничение домена, устанавливаемое на столбец таблицы. Пусть таблица MovieStar содержит информацию о киноактерах. В составе таблицы имеется столбец gender (пол актера) символьного типа, в котором допускается хранить одно из двух значений: ‘F’ (женский) и ‘M’ (мужской). Другие значения в этом столбце не допускаются (за исключением неопределенных). Значит, множество строк таблицы MovieStar, в которых поля gender обладают значениями, отличными от ‘F’ и ‘M’, должно быть всегда пустым. Формальная запись этого требования имеет следующий вид:
® genderdF' AND genderФ'M(MovieStar) = 0 . (2)
По мнению авторов, подобным образом могут быть описаны и другие требования целостности. Однако очевидно, что во всех рассмотренных и аналогичных случаях речь идет о требованиях к состоянию. Требования (1) и (2) предписывают, чтобы данные в таблицах всегда удовлетворяли заданным условиям, независимо от выполнения конкретных операций записи в таблицах MovieStar и MovieExec соответственно, т. е. независимо от какого бы то ни было перехода.
Приведем пример требования, которое невозможно смоделировать рассмотренным способом. Пусть имеется таблица Equipment (оборудование), которая содержит столбец howlongused (срок эксплуатации). Предположим, что для рассматриваемой БД должно быть справедливо следующее требование: при регистрации нового оборудования должен указываться нулевой срок эксплуатации. Необходимо сделать акцент на словах «при регистрации»: здесь есть указание на то, что поле how long used должно быть нулевым только в строках, добавляемых с помощью оператора INSERT. Данное требование является требованием к переходу, которое содержит указание на конкретную операцию записи, активизирующую переход, и утверждение о промежуточных (в данном случае - добавляемых) данных.
Метамодель Г арсиа-Молина, Ульмана и Уидом в чистом виде пригодна для формального описания требований к состоянию и недостаточна для описания требований к переходу. Предлагаемая нами метамодель позволяет устранить указанный недостаток.
Введем понятие формального описателя (или просто описателя) требования целостности. Под описателем будем понимать формулу вида:
б(T,C) | A, (3)
ISSN 1815-588 Х. Известия ПГУПС
2010/4
82
Общетехнические задачи и пути их решения
где T - множество таблиц, связанных данным требованием;
C - множество столбцов таблиц, входящих в множество T и связанных данным требованием;
Q(T, C) - условие требования, связывающее все элементы множеств
T, C;
A - множество операций записи данных, после выполнения которых (любой из них) условие Q(T, C) должно быть истинно; если
T = {tl,..., tn} то
A с {ins(tl), upd(t1), del(t1)} u... u {ins(tn), upd(tn), del(tn)};
ins(t) - предикат выполнения вставки строк в таблицу t; upd(t) - предикат выполнения обновления строк таблицы t; del(t) - предикат выполнения удаления строк из таблицы t.
Множество T требования к состоянию включает только основные («физические») таблицы БД. Множество A требования к состоянию содержит всю совокупность возможных операций записи над таблицами из множества T. Если T = {tx,..., tn}, то для требования к состоянию
A = {ins(t1), upd(t1), del(tj)} u... u {ins(tn), upd(tn), del(tn)}.
Требование к переходу может описывать конечное состояние данных, в которое они должны быть приведены после выполнения любой операции из множества A, но при этом A с {ins(tx), upd(t1), del(t1)}u...
... u {ins(tn), upd(tn), del(tn)}, т. е. условие требования справедливо только для некоторых, но не для всех возможных операций записи над таблицами из множества T.
Однако требование к переходу может учитывать не только конечное состояние данных, но и детали изменений, вносимых в некоторую выбранную таблицу t. В этом случае A с {ins(t), upd(t), del(t)}, а множество T требования к переходу включает хотя бы одну из двух псевдотаблиц:
• псевдотаблица tms содержит строки, добавляемые в таблицу t при выполнении операции ins(t), либо обновляемые строки после выполнения операции upd(t);
t— del t—
• псевдотаблица t содержит строки, удаляемые из таблицы при выполнении операции del(t) или обновляемые строки непосредственно перед выполнением операции upd(t).
Таким образом, формула (3) означает следующее: выражение
Q (T, C) должно быть истинно при выполнении любой операции из множества A .
2010/4
Proceedings of Petersburg Transport University
Общетехнические задачи и пути их решения
83
Покажем, что предлагаемая нами метамодель формальных описателей является расширением метамодели Г арсиа-Молина, Ульмана и Уидом.
Выделим две группы описателей: описатели требований к состоянию и описатели требований к переходу. Для описателей требований к состоянию примем сокращенную форму записи, считая, что в них не требуется явное перечисление операций. Описатель требования «пол киноактера всегда имеет значение ‘M’ или ‘F’» может выглядеть так:
Vge^F'ANDge^M'iMovieStar) = 0|{ins(MovieStar),
upd(MovieStar), del(MovieStar)}.
Но поскольку речь идет о требовании к состоянию, можно принять сокращенную форму описателя:
®genderФF' AND genderФ'M (MoVieStar) = 0 . (4)
Описатель (4) совпадает с формулой (2), или, иначе говоря, формула (2) является описателем требования целостности, согласно которому столбец gender таблицы MovieStar может хранить только значения ‘F’ или ‘M’. Аналогичным образом можно показать, что формула (1) является описателем требования ссылочной целостности по отношению к взаимосвязанным таблицам Movie и MovieExec. Таким образом, если в описателе явно не указаны предикаты выполнения операций записи и не используются псевдотаблицы, следует считать, что данное требование распространяется на все операции над связанными таблицами, т. е. является требованием к состоянию.
В описателях требований к переходу множество операций должно присутствовать обязательно - данная черта отличает метамодель формальных описателей от метамодели Гарсиа-Молина, Ульмана и Уидом в чистом виде. Например, в описателе требования «при регистрации нового оборудования необходимо указывать нулевой срок эксплуатации» присутствует операция ins(Equipment):
Vhow _ long _ u^0(EquipmentinS ) = 0|0 (Equipment)}. (5)
Этим подчеркивается, что условие a how _ long _ used Ф0( Equipmentms) = 0 истинно не всегда, а только тогда, когда истинен предикат ins(Equipment). Условие требования сформулировано относительно псевдотаблицы Equip-mentins, т. к. именно она содержит сведения о новом оборудовании, в то время как базовая таблица Equipment - не только о новом, но и о зарегистрированном оборудовании, поступившем в эксплуатацию.
Описатели можно использовать в формулах логики высказываний как операнды. Кроме того, в метамодель формальных описателей целесооб-
ISSN 1815-588 Х. Известия ПГУПС
2010/4
84
Общетехнические задачи и пути их решения
разно включить два специфических действия над описателями: соединение и разбиение.
Соединением описателей Q(T, C) | Лх,..., Q(T, C) | An с одинаковым условием Q(T, C) назовем действие, результатом которого является описатель Q(T, C) | Л1 и... и Лп.
Разбиением описателя Q (т, c ) | л назовем действие, обратное соединению. Описатели Q(T, C )| Л1,..., Q(T, C )| Лп, полученные путем разбиения, будем называть частями исходного описателя Q(T, C) | Л.
Если Л > 1, то для описателя существует множество вариантов раз-
биения, при этом максимальное количество частей исходного описателя равно |Л| - в случае, когда каждому из результирующих описателей соответствует одна и только одна операция из исходного множества Л.
2 Типовые требования целостности и их формальные описатели
Пусть имеется таблица t и в ней - столбец или составной атрибут х. Ниже определены типовые требования целостности, которые можно предъявить к атрибуту t.x. Каждому виду требования поставлен в соответствие формальный описатель.
1. Первичный ключ. К первичному ключу предъявляются два требования: уникальность и определенность каждого значения. Следовательно, ни одно значение столбца х не может повторяться дважды или быть неопределенным:
а
COUNT(х)>1v(xisnull)\> х
(Y х (t))=0
(6)
Если х - составной атрибут, который состоит из столбцов х1? х2, .. хп, то следует представить требование для первичного ключа в следующем виде:
а
COUNT(х1, х2,..., хи)>1v(х1 isnull)v(х2 is null)v...v(х3 is null) V i х1, х-
(Y,
(t))=0. (7)
Форма записи (6) допустима для этого случая в качестве сокращенной.
2. Уникальность значений. Уникальность значений х означает, что при группировании по х не может появиться ни одной группы с количеством элементов больше 1:
аCOUNT(х)>1(Yх (t)) 0
(8)
2010/4
Proceedings of Petersburg Transport University
Общетехнические задачи и пути их решения
85
3. Определенность значений. Определенность значений x означает, что не должно существовать ни одной строки с неопределенным значением x:
^xisnull ) = 0. (9)
Если х - составной атрибут, то можно принять данную форму описателя как сокращенную, более точной является следующая форма:
^(xlisnull)v(х2 is null)v...v(x3 is null) (0=0, (10)
где x2, xn - столбцы, входящие в составной атрибут х.
4. Ограничение домена. Это ограничение задает логическое условие, которому должны удовлетворять все значения x. Пусть для атрибута x таблицы t задано логическое условие C(x). В любой момент времени все значения атрибута должны удовлетворять этому условию, то есть не должно быть ни одной строки, в которой поле x не удовлетворяет условию C(x):
аад(О=0. (И)
5. Внешний ключ. Данное ограничение, как правило, предполагает наличие двух таблиц. Внешний ключ определяется в таблице t и является ссылкой на ключевой атрибут x’ таблицы t’. В таблице t не должно быть ни одного значения x, которое не совпадает ни с одним из значений t’.x\ Следует оговориться, что x’ может быть первичным или альтернативным ключом таблицы t ’, поэтому обязательным для него является только требование уникальности. Учитывая все сказанное выше, получаем описатель:
nx (t) \ nx'(t ) = 0 Л °COUNT(x)>1(Tx'(t ) = 0 . (12)
Нетрудно понять, что типовые требования целостности являются требованиями к состоянию и создаются для контроля простого или составного атрибута только одной таблицы БД. Исключением является внешний ключ: это ограничение, как правило, согласует общие атрибуты двух взаимосвязанных таблиц.
3 Использование формальных описателей в качестве спецификаций ограничений целостности и триггеров
Реализация требований целостности связана с решением вопроса о том, какие объекты - ОЦ или триггеры - следует использовать.
ОЦ являются декларативными объектами: они не содержат описаний алгоритмов обеспечения целостности и используются только для объявления СУБД о том, что указанный столбец или группа столбцов таблицы связаны некоторым требованием. В большинстве реляционных БД встречаются ОЦ
ISSN 1815-588 Х. Известия ПГУПС
2010/4
86
Общетехнические задачи и пути их решения
пяти видов: определение первичного ключа (PRIMARY KEY), определение внешнего ключа (FOREIGN KEY), требование уникальности значений простого или составного атрибута отношения (UNIQUE), запрет неопределенных значений атрибута (NOT NULL), ограничение домена (CHECK).
Очевидно, что ОЦ хорошо подходят для реализации типовых требований целостности, которым соответствуют описатели (6)-(12), где в качестве t выступает одна таблица БД, но не соединение таблиц и никакой другой результат вычислений.
Требования целостности, не относящиеся к типовым или предполагающие автоматическую коррекцию неправильных данных, целесообразно реализовывать с помощью триггеров.
Триггер - это привязанная к некоторой пользовательской таблице хранимая SQL-процедура специального типа, которая запускается автоматически при осуществлении тех или иных модификаций в таблице. Пользовательская таблица, для которой создается триггер, называется связанной таблицей. SQL-оператор, который инициирует выполнение триггера, называется активизирующим оператором.
На практике часто встречаются случаи, когда одно требование целостности необходимо реализовать с помощью нескольких триггеров. Совокупность триггеров, совместно реализующих одно и то же требование целостности, будем называть триггерной связкой, а количество триггеров в связке - размером триггерной связки. При необходимости одиночный триггер может рассматриваться как вырожденная триггерная связка, имеющая размер 1.
Разработка триггеров связана с решением двух важных вопросов:
• каким должен быть размер триггерной связки, чтобы требование было полностью реализовано;
• какие именно действия должны выполнять триггеры.
Для ответа на первый вопрос воспользуемся следующими утверждениями, определенными в рамках метамодели формальных описателей.
Утверждение 1. Описатель требования целостности может быть спецификацией триггера для связанной таблицы t, если и только если A с {ins(t), upd(t), del(t)}.
Утверждение 2. Требование целостности, описатель которого имеет вид Q(Т, C) | A, причем Т не содержит псевдотаблиц, является спецификацией триггерной связки, минимальный размер которой равен | Т\.
Операции из множества A определяют виды триггерных событий. Однако при написании программного кода триггера рекомендуется прописывать в триггерах только те активизирующие операторы, выполнение которых может нарушить заданное требование.
Алгоритм работы каждого триггера должен быть составлен таким образом, чтобы после его выполнения постусловие Q(T, C) было истинным.
2010/4
Proceedings of Petersburg Transport University
Общетехнические задачи и пути их решения
87
4 Использование описателей для проведения формальной верификации ограничений целостности и триггеров
Верификацией называется процесс оценивания пригодности и корректности ОЦ и триггеров относительно исходных требований заказчика. Цель верификации состоит в том, чтобы проверить полноту реализации требований целостности в БД и выявить недекларированные возможности в ОЦ и триггерах.
В настоящее время нами разрабатывается метод формальной верификации ОЦ и триггеров, в основе которого лежит сопоставление моделей двух видов: спецификации и реализации. Спецификация на ОЦ и триггеры включает описатели всех исходных требований целостности. Модель реализации ОЦ и триггеров БД включает описатели фактически реализованных в БД ограничений; следует отметить, что реализованные функции целостности могут соответствовать или не соответствовать требованиям заказчика.
Описатели в спецификации создаются разработчиками БД по согласованию с заказчиками. Модель реализации строится экспертом на основе результатов анализа SQL-кодов ОЦ, триггеров и триггерных связок.
Таким образом, верификация БД с использованием разрабатываемого нами метода проводится в два этапа.
1. Восстановление описателей, т. е. получение описателей реализованных функций целостности на основе анализа кодов ОЦ и триггеров. Восстановление описателей выполняется в соответствии с определенным набором правил, которые в данной публикации не рассматриваются.
2. Сравнение описателей. БД можно считать корректной в части ОЦ и триггеров, если каждому описателю в модели реализации соответствует описатель в спецификации. Сравнение описателей либо подтверждает это соответствие, либо выявляет несоответствия. Наличие несоответствий может говорить о том, что:
• часть специфицированных требований не была реализована;
• в БД имеются лишние ОЦ или триггеры;
• некоторые ОЦ и триггеры содержат недекларированные возможности.
Результатом сравнения описателей является обобщенная количественная оценка соответствия между спецификацией и реализацией, а также детальная информация о некорректных описателях в спецификации и модели реализации.
Заключение
Рассмотренная в статье метамодель задает общий вид формальных описателей требований целостности. Каждый формальный описатель, будучи логико-математической моделью конкретного требования целостности, в то же время является и спецификацией на ОЦ или триггеры, создаваемые разработчиками БД для поддержки данного требования.
ISSN 1815-588 Х. Известия ПГУПС
2010/4
88
Общетехнические задачи и пути их решения
Формальные описатели несут в себе определенную информацию, которой можно руководствоваться при выборе механизма поддержки требования целостности и при написании программного кода триггеров. Описатели требований целостности применимы при проведении формальной верификации ОЦ и триггеров БД.
Библиографический список
1. Введение в системы баз данных : учеб. пособие / Дейт К. Дж. ; пер. с англ. -Киев; М. ; СПб. : Издательский дом «Вильямс», 2000. - 848 с. - ISBN 5-8459-0019-0.
2. Системы баз данных. Полный курс / Г. Гарсиа-Молина, Дж. Ульман, Дж. Уидом; пер. с англ. - М. : Издательский дом «Вильямс», 2004. - 1088 с. - ISBN 5-8459-0384-X.
Статья поступила в редакцию 30.09.2010;
представлена к публикации членом редколлегии А. А. Корниенко.
УДК 621.391.15 М. В. Гофман
МЕТОД ПОСТРОЕНИЯ АЛГЕБРАИЧЕСКИХ ПРОСТРАНСТВЕННО-ЧАСТОТНО-ВРЕМЕННЫХ КОДОВ
В статье представлен метод построения порождающей матрицы пространственно-частотно-временного (ПЧВ) кода. Этот метод основан на целочисленных функциях, очень просто реализуемых на ЭВМ. Приведен простой пример построения порождающей матрицы ПЧВ-кода.
MIMO-система, пространственно-частотно-временной код, порождающая матрица, матрица перестановок.
Введение
В работе [1] была представлена методика построения кодового слова для кодов, ориентированных на использование в MIMO-системах (MIMO -Multiple Input Multiple Output) связи. Эта методика строит кодовые слова путем объединения независимо кодируемых частей, называемых слоями. Слой представляет собой вектор из комплексных чисел. Кодовое слово представимо матрицей, в которой каждый элемент принадлежит некоторому слою. Далее методику построения кодовых слов, представленную в [1], будем называть методикой слоения.
2010/4
Proceedings of Petersburg Transport University
