ҚЫЗЫЛОРДА БЕКЕТІНЕ КЕЛІП ТҮСЕТІН ЖҮКТЕРДІ

51
Қабылдаушы – жөнелтуші кезекшілікті алған кезде станцияда төмендегідей міндеттерді орындау:  
• Қабылдаушы – тапсырушыдан жұмыс туралы ақпаратты білуге міндетті.  
• Жүкті тексеру және жүкті қоймадағы жүкпен құжаттарды салыстыруға, оның салу және уақыт 
мезгілдерін шыққан және жіберген кездерін баратын жерін тексеруге міндетті. 
• Егер жүктің құжаттары болмаса не жүктің өзі болмаса, тапсырушы – қабылдаушы жедел түрде 
өзінен жоғары тұрған тиісті орындарға бекітілген ереже бойынша коммерциялық акті жасауға міндетті 
және оны іздеуге атсалысуы керек. 
• Тасылуға тиісті жүктің және басқа да заттардың құжаттарын, атын, ярлыгын рәсімдеуге арналған 
барлық құжаттармен бланкілерді тексеруге міндетті.  
• Таразылардың дұрыстығын тексеру және оған керек құрал­саймандардың дұрыстығын қадағалау 
жүкті түсіретін, тиеу­түсіру құралдарының жай­жапсарын білу өртке қарсы саймандардың дайын тұ­
руы жарық және қойманың жағдайын қадағалау. 
Тасымалдауға алынған жүктерді қабылдаушы – жөнелтуші қабылдау кітабына тіркеп ЛУ­60 фор­
масымен рәсімдеп жіберуге дайын етеді. 
Қабылдаушы  –  жөнелтуші  жүкті  жібермес  бұрын  станцияда  барлық  құжаттарға  талдау  жасап 
кете тін жүктің бағытын білуге тиісті. Барлық жіберілетін жүкке жіберу тізімі екі данамен жасалады. 
Жіберілу  тізімі  анық,  ашық  жасалуға  тиісті.  Әрбір  қатарға  бір  ғана  заттың  аты  жазылуға  тиіс. 
Тиелу, тиеу құжаттарымен әрі міндетті түрде жол ведомостын салыстыра отырып тиеуге міндетті. 
Қабылдау шы – жөнелтуші станцияда келесі қабылдаушы – жөнелтушіге міндетті түрде жол ведомос­
тын құжаттармен бірге өткізеді. 
ГУ­26 формасында жазылған өткізу тізімі басты құжат болып табылады. Сонымен қабылдап әрі 
жүкті тиеу, түсіру вагоннан қабылдаушы – жөнелтуші үшін негізгі жұмыс. 
Жүкті вагоннан түсірер кезде поезда қабылдаушы – жөнелтуші өткізу тізімін жасайды. Бланкінің 
жоғарғы жағына жүкті түсіріп алған станцияның атын жазады, поездің, вагонның нөмірін, онда аты 
және жолдың аты әрі бекеттегі жүк қабылдаушының тегі көрсетіледі.  
Қабылдаушы, жөнелтуші адамдардың қолтаңбасы бекеттерде анық, айқын жазылып, сол мекеменің 
қызметтік мөрімен анықтайды.  
Қызылорда  станциясына  келіп  түсетін  жүктерді  қабылдау  –  жөнелту  жұмыс  орындарын  авто­
маттандыру  жұмысы  алға  қойылады.  Бұл  жүйе  ену,  өзгеру  және  ақпарат  іздеу  ережелерінен  тұруға 
тиісті.  Бұл  қабылдау  –  жөнелту  қызметі  «Қазақстан  темір  жолы»  ұлттық  компаниясының  мәліметі 
негізінде жүзеге асырылады.  
Қабылдаушы  –  жөнелтушінің  міндеттері  мен  функцияларын  қарастырамыз.  Бұл  жағдайда  авто­
маттандырылған жұмыс орны мына төмендегі тапсырыстарды шешуге міндетті: 
1) Қабылдаушы – жөнелтуші туралы мәндерді ендіру; 
2) Тарқатушы жайында мәндерді ендіру; 
3) Жүк жіберушілер жайындағы мәліметтерді ендіру; 
4) Қабылдау және жөнелту станцияларын есепке алу; 
5) Алынған және жіберілген жүктерді есепке алу; 
6) Тапсыру тізімін жасау және т.б. 
Қазіргі таңда МҚБЖ­ны құру үшін көптеген жаңа заманғы жоғары деңгейлі бағдарламалау жүйесі 
бар. Алға қойылған есепті шешу үшін жаңа заманғы кең тараған мәліметтер қорын басқару жүйелерінің 
артықшылықтарын, кемшіліктерін және ортасын анықтап салыстырмалы таңдалады 
Visual  Basic  бағдарламалаудың  әмбебап  құрал  болып  табылады,  бірақ  біз  оның  мүмкіндіктерін 
мәліметтерді өңдеу бойынша қосымша құру жағынан ғана қарастырамыз. 
Көптеген бағдарламалар пакеттерінен айырмашылығы «Visual Basic»­те жасаушының барлық қалған 
интерфейс элементтерін қосатын басты терезе болмайды. Оның әрбір элементінде өзінің тәуелсіз тере­
зесі  болады,  оларды  басқаларына  тәуелсіз  экранның  кез  келген  жеріне  орналастыруға  немесе  алып 
тастауға болады. 
«Visual  Basic»­ті  іске  қосқанда  құру  режиміне  түсесіз  және  қалыпты  жағдай  бойынша  жаңа  жо­
ба  құруға  дайын  форма  ашылады.  «Visual  Basic»­тің  негізгі  мүмкіндіктері,  ақпаратты  өңдеу  үшін 
қосымшаны құру кезінде қолдану, мәліметтерге қол жеткізу үшін олардағы объектілерді тарату Data 
Access  Object  (DAO),  берілгендерді  басқару  элементтерінің  жұмысы  үшін  арналған  32  разрядты 
мәліметтер процессоры – JET 3.0 көмегімен болады. 

52
Visual Basic жаңа заманғы барлық визуалды жобалаудың жүйелері сияқты объектілі­бағыттал ған 
бағдарламалау болып табылады. «Visual Basic»­те жазылған кез келген қосымша объектілердің жиын­
тығын көрсетеді. 
Кез­келген қосымшаны құру келесі кезеңдерден тұрады: 
1. Тапсырма орнатып қою. Болашақ қосымшаның жұмыс принциптерінің сипатталуы, осы қосым­
шаның экрандық форма түрлері. 
2. Интерфейстің құрылуы. Формадағы барлық объектілерін және қасиеттерін пайдаланып қосым­
шаның экрандық формасын құру. 
3.  Бағдарламалау.  Процедуралардың  бағдарламасын  жазу  және  осы  оқиғалар  үшін  процедура 
алгоритмін құру, қосымшаның жұмысы процесінде қандай оқиғалар орындалатынын анықтау. 
4.  Бағдарламаны  жөндеу.  Жобалау  ортасында қосымша  қанағаттанарлық  жұмыс істеу  үшін  және 
процедуралардағы логикалық қателерді жою. 
5. Жобаны сақтау және компиляция жасау (Жобалау ортасынан тыс өздігінен жұмысқа қабілетті, 
жобаның орындалатын қосымшаға айналуы). 
Қосымша интерпретация немесе компиляция режимінде жұмыс істеуі мүмкін. Қызылорда бекетіне 
келіп  түсетін  жүктерді  қабылдау­жөнелту  қызметінің  ақпараттық  жүйесін  Visual  Basic  әмбебап 
бағдарламау тіліндегі көрінісі төменде көрсетілгендей 
Әдебиеттер:
1. Брайан Сайлер, Джефф Споттс. Использование Visual Basic 6. Классическое издание // Special 
Edition Using Visual Basic 6. – М.: Вильямс, 2007.
2. Билл Семпф. Microsoft Visual Basic 2005 для «чайников» // Visual Basic 2005 For Dummies. — М.: 
Диалектика, 2006.
3. Игорь Сафронов. Visual Basic в задачах и примерах.  – СПб.: БХВ­Петербург, 2008.
4.  Дан  Эпплман.  Win32 API  и  Visual  Basic.  Для  профессионалов  //  Dan Appleman’s  Visual  Basic 
Programmer’s Guide to the Win32 API.  – СПб.: Питер, 2001.
Резюме
Практически все пользователи имеют дело с офисными пакетами Microsoft, причем многие из них 
адаптируют эти продукты в соответствии со спецификой своих конкретных задач, используя внутренний 
макроязык. Например, VBA. В статье изложены основы работы соз дания собственных приложений, а 
именно организации транспортирования железнодорожного груза в Visual Basic.
Summary
Practically all users deal with the office packages of Microsoft, thus many of them adapt these products 
in accordance with the specific of the certain tasks, using an internal macro language. For example, VBA. 
This article is sanctified to fundamental bases of work of creation of own applications, namely organizations 
portage railway  load in Visual Basic.

53
УДК 004.65:004.657
ОПТИМИЗАЦИЯ ЗАПРОСОВ 
В РАСПРЕДЕЛЕННЫХ И ПАРАЛЛЕЛЬНЫХ СИСТЕМАХ 
УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ 
   У.Ж. АЙТИМОВА,  
кандидат физико-математических наук
Г.Д. ТАЖИКОВА, 
магистрант,
 Кызылординский государственный университет имени Коркыт Ата, 
Республика Казахстан
Распределенные  и  параллельные  системы  управления  базами  данных  (СУБД)  предоставляют  ту 
же функциональность, что и центра лизованные, если не считать того, что они работают в среде, где 
данные распределены по узлам компьютерной сети или многопроцессорной системы. 
Рассмотрим вопросы, связанные с оптимизацией выполнения запросов в распределенных и парал ­
лельных СУБД, а также некоторые открытые вопросы по оптимизации времени обращения к уст ройст­
вам хранения данных в СУБД и времени передачи данных по сети.
Обработка и оптимизация запросов 
Обработка  запроса  (query  processing)  –  это  процесс  трансляции  декларативного  определения 
запроса  в  операции  манипулирования  данными  низкого  уровня.  Стандартным  языком  запросов, 
поддерживаемым современными СУБД, является SQL. Оптимизация запроса (query optimization) – это 
процедура выбора «наилучшей» стратегии выполнения запроса из множества альтернатив.
Для централизованной СУБД весь процесс состоит обычно из двух шагов: декомпозиции запроса 
(query  decomposition)  и  оптимизации  запроса.  Декомпозиция  запроса  –  это  трансляция  его  с  языка 
SQL в выражение реляционной алгебры. В ходе декомпозиции запрос подвергается семантическому 
анализу;  при  этом  некорректные  запросы  отвергаются,  а  корректные  упрощаются.  Упрощение 
заключается,  в  частности,  в  исключении  избыточных  предикатов,  которые  могли  быть  привнесены 
за счет использования представлений, а также исходя из ограничений безопасности и семантической 
целостности. Упрощенный запрос преобразуется в алгебраическую форму.
Для  заданного  SQL­запроса  существует  более  чем  одно  алгебраическое  представление,  причем 
некоторые из них могут быть «лучше» других. «Качество» алгебраического выражения определяется 
исходя  из  объема  затрат,  необходимых  для  его  вычисления.  Традиционная  процедура  состоит  в 
том,  чтобы  сначала  оттранслировать  SQL­запрос  в  какое­нибудь  выражение,  а  затем,  применяя 
правила  эквивалентных  алгебраических  преобразований,  получать  из  него  другие  алгебраические 
преобразования, пока не будет найдено «наилучшее». При поиске «наилучшего» выражения исполь­
зуется  функция  стоимости,  в  соответствии  с  которой  вычисляется  сумма  затрат,  необходимых  для 
выполнения запроса. Этот процесс и называется оптимизацией запросов.
В  распределенной  СУБД  между  шагами  декомпозиции  и  оптимизации  запроса  включаются  еще 
два действия: локализация данных (data localization) и глобальная оптимизация запроса (global query 
optimization).
Исходной  информацией  для  локализации  данных  служит  исходное  алгебраическое  выражение, 
полученное  на  шаге  декомпозиции  запроса.  В  исходном  алгебраическом  выражении  фигурируют 
глобальные отношения без учета их фрагментации или распределения. Основная роль локализации 
данных заключается в том, чтобы локализовать участвующие в запросе данные, используя информацию 
об их распределении. На этом шаге выявляются фрагменты, реально участвующие в запросе, и запрос 
преобразуется к форме, где операции применяются уже не к глобальным отношениям, а к фрагментам. Как 
отмечалось выше, правила фрагментации выражаются посредством реляционных операций (селекции 
для  горизонтальной  фрагментации  и  проекции  для  вертикальной).    Распределенные  отношения 
реконструируются  путем  применения  инверсии  правил  фрагментации.  Это  называется  программой 
локализации. Программа локализации для горизонтально (вертикально) фрагментированного отношения 

54
представляет  собой  объединение  (union)  (соединение  (join))  соответствующих  фрагментов.  Таким 
образом, на шаге локализации данных каждое глобальное отношение запрос заменяется его программой 
локализации, а затем результирующий фрагментный запрос упрощается и реструктурируется с целью 
получения другого «хорошего» запроса. Для упрощения и реструктуризации могут использоваться те 
же  правила,  что  и  на  шаге  декомпозиции.  Как  и  на  шаге  декомпозиции,  окончательный  запрос  над 
фрагментами  может  быть  еще  далек  от  оптимального;  данный  процесс  лишь  исключает  «плохие» 
алгебраические запросы.
Исходной  информацией  для  третьего  шага  является  фрагментный  запрос,  т.е.  алгебраическое 
выражение над фрагментами. Цель глобальной оптимизации – найти стратегию выполнения запроса, 
близкую  к  оптимальной.  Напомним,  что  нахождение  оптимальной  стратегии  –  вычислительно 
трудноразрешимая  задача.  Стратегию  выполнения  распределенного  запроса  можно  выразить  в 
терминах  операций  реляционной  алгебры  и  коммуникационных  примитивов  (операций  send/receive), 
используемых  для  пересылки  данных  между  узлами.  На  предыдущих  шагах  запрос  уже  был  в 
определенной  мере  оптимизирован,  в  частности,  за  счет  удаления  избыточных  выражений.  Однако 
проведенная оптимизация не зависела от характеристик фрагментов, например их мощности. Кроме 
того,  на  предыдущих  шагах  еще  не  учитывались  коммуникационные  операции.  Путем  изменения 
порядка операций внутри одного фрагментного запроса можно получить много эквивалентных планов 
его выполнения. Оптимизация запроса заключается в нахождении «наилучшего» плана из множества 
возможных планов, исследуемых оптимизатором.
Оптимизатор  запросов  обычно  представляется  в  виде  трех  компонентов:  пространство  поиска, 
модель стоимости и стратегия поиска. Пространство поиска – это множество альтернативных планов 
выполнения  исходного  запроса,  которые  эквивалентны  в  том  смысле,  что  они  дают  один  и  тот  же 
результат, но различаются порядком и способами выполнения отдельных операций. Модель стоимос-
ти – это способ оценить стоимость данного плана выполнения запроса. Для достижения точности мо­
дель стоимости должна основываться на точных знаниях о среде параллельных вычислений. Стратегия 
поиска – это способ обхода пространства поиска и выбора наилучшего плана. Она определяет, какие 
планы и в каком порядке следует выбирать и оценивать.
В распределенной среде функция стоимости, часто определяемая в единицах времени, оценивает 
затраты  вычислительных  ресурсов,  таких  как  дисковое  пространство,  число  обменов  с  дисками, 
время центрального процессора, коммуникации и т.д. Обычно это некоторая взвешенная сумма затрат 
ввода­вывода,  центрального  процессора  и  коммуникаций.  В  распределенных  СУБД  применяется 
упрощенный подход, когда в качестве наиболее значимых рассматриваются лишь коммуникационные 
затраты.  Это  справедливо  для  глобальных  сетей,  где  из­за  ограниченной  пропускной  способности 
линий связи пересылки данных обходятся значительно дороже, чем при локальной обработке. Чтобы 
определить  порядок  выполнения  операций,  необходимо  оценить  стоимость  выполнения  планов  с 
другим порядком операций. Определение стоимости выполнения до реального выполнения запроса 
(статическая  оптимизация)  основано  на  статистике  фрагментов  и  формулах  для  оценки  мощности 
результатов  реляционных  операций.  Таким  образом,  решения,  принимаемые  в  ходе  оптимизации, 
зависят от имеющейся статистики фрагментов.
Важным  аспектом  оптимизации  запросов  является  порядок  выполнения  соединений,  поскольку 
его  изменение  может  привести  к  ускорению  на  несколько  порядков.  Базовый  метод  оптимизации 
последовательности  распределенных  операций  соединения  заключается  в  применении  операции 
полусоединения (semijoin). Основное преимущество полусоединений в распределенной системе – это 
сокращение размеров операндов, участвующих в соединениях, и, следовательно, коммуникационных 
затрат. Однако в более современных методах, учитывающих, наряду с коммуникационным расходами, 
также и затраты на локальную обработку, полусоединения не используются, поскольку они приводят 
к увеличению объема локальной обработки. Результатом работы глобального оптимизатора является 
оптимизированное  алгебраическое  выражение,  включающее  коммуникационные  операции  над 
фрагментами.
Параллельная обработка запросов в целом подобна распределенной обработке запросов. Она опи­
рается на преимущества внутризапросного параллелизма, а также межоперационного параллелизма. 
Под  внутризапросным  параллелизмом  понимается  одновременное  выполнение  сразу  нескольких 
операций (например, операций выборки), относящихся к одному и тому же запросу. Внутризапросный, 

55
как  и  межзапросный  параллелизм  реализуется  на  основе  разделения  данных,  аналогичного  го­
ризонтальному фрагментированию.
Внутриоперационный (intra­operation) параллелизм достигается за счет выполнения операции сразу 
на нескольких узлах многопроцессорной машины. Для этого необходимо предварительное разбиение 
операндов,  т.е.  их  горизонтальная  фрагментация  по  узлам.  Способ  разделения  базового  отношения 
относится  к  области  физического  проектирования  базы  данных.  Обычно  разделение  производится 
путем применения некоторой хэш­функции к тому атрибуту отношения, который будет часто являться 
атрибутом соединения. Набор узлов, в которых хранится отношение, называется домашним набором 
(home). Домашним набором узлов операции (home of an operation) называется набор узлов, в которых 
она  выполняется;  он  должен  совпадать  с  домашним  набором  узлов  ее  операндов,  чтобы  операция 
имела  доступ  к  своим  операндам.  Это  значит,  что  для  бинарных  операций,  таких  как  соединения, 
может  потребоваться  переразделение  (repartitioning)  одного  из  операндов.  В  некоторых  случаях 
оптимизатор,  возможно,  сочтет  целесообразным  провести  переразделение  обоих  операндов.  Для 
реализации внутриоперационного параллелизма в параллельных СУБД применимы некоторые методы, 
разработанные для распределенных баз данных.
Межоперационный  (inter-operation)  параллелизм  имеет  место,  когда  одновременно  выполняются 
две или более операции, независимые или связанные общим потоком данных. Термином поток данных 
(dataflow)  мы  обозначаем  форму  параллелизма,  реализуемую  методами  конвейерной  обработки 
(pipelining). При независимом параллелизме операции выполняются одновременно или в произвольном 
порядке. Независимый параллелизм возможен, только если операции не содержат в качестве операндов 
общих данных.
Распределенная и параллельная обработка запросов
Как  обсуждалось  выше,  на  этапе  глобальной  оптимизации  для  исходного  фрагментного  запроса 
генерируется  оптимальный  план  выполнения.  При  этом  принимаются  решения  относительно 
упорядочения операций, перемещений данных между узлами, выбора тех или иных локальных или 
распределенных  алгоритмов  выполнения  операций.  С  этим  шагом  связан  ряд  серьезных  проблем. 
К  ним  относятся  ограничения,  привносимые  стоимостной  моделью,  выбор  подмножества  языка 
запросов, соотношение между затратами оптимизации и затратами выполнения, интервал оптимизации/
реоптимизации.
Существует  естественная  связь  между  затратами  на  оптимизацию  и  качеством  результирующего 
плана выполнения. Высокие затраты на оптимизацию оправданы для регулярно выполняемых запросов, 
поскольку  стоимость  оптимизации  окупается  снижением  затрат  на  выполнение  и  амортизируется 
многократностью  выполнения.  Однако  нерационально  тратить  слишком  много  ресурсов  на 
оптимизацию однократно выполняемых сиюминутных запросов. Большую часть затрат оптимизации 
составляет  поиск  в  пространстве  решений,  представляющих  альтернативные  планы  выполнения. 
Для  распределенных  систем  характерны  большие  размеры  пространства  решений,  поскольку  число 
распределенных стратегий выполнения очень велико. Следовательно, важное значение здесь имеют 
исследования,  направленные  на  выработку  эффективных  методов  обхода  пространства  решений, 
исключающих его исчерпывающий перебор.
Глобальная оптимизация запросов производится заранее до их выполнения, поэтому она называется 
статической. Основная проблема, возникающая в связи с этим, заключается в том, что модель стоимости, 
которая  использовалась  при  оптимизации,  со  временем  становится  неточной,  как  из­за  изменения 
размеров фрагментов, так и из­за реорганизаций базы данных, проводимых для балансировки нагрузки. 
Таким  образом,  задача  состоит  в  том,  чтобы  определить  оптимальные  интервалы  рекомпиляции/
реоптимизации запросов с учетом соотношения затрат на их оптимизацию и выполнение.
Литература:
1. Griffiths Selinger P., Astrahan M.M., Chamberlain D.D., Lorie R.A. and Price T.G. Access Path Selection 
in a Relational Database Management System // SIGMOD. – 1979. – P. 23­25.
2. Baru C K, Fecteau G., Goyal A., Hsiao H., Jhingran A., Padmanadhan S., Copeland G. P., Wilson W.G. 
DB2 Parallel Edition // IBM Systems J. – 1995,  36, – № 2. – P. 293­296.

56
3. Koval V.N., Savyak V.V., Sergienko I.V. Tendencies of modern supercomputer systems development // 
Control Systems and Computers. – 2004,  6. – P. 31­44.
4. DB2 Information Center in the internet. – http://publib.boulder.ibm.com/infocenter/db2help.
5. Кузнецов С.Д. Методы оптимизации выполнения запросов в реляционных СУБД. – http://citforum.
ru/database/articles/art_26_12.shtml.
6. Sumit Ganguly, Akshay Goel, Avi Silberschatz. Efficient and Accurate Cost Models for Parallel Query 
Optimization // PODS’96 Montreal Quebec Canada. ­1996.– Р. 173, 175 – 177.
7. Shanakar Ramaswamy, Sachin Sapatnekar and Prithviraj Banerjee. A Convex Programming Approach 
for  Exploiting  Data  and  Functional  Parallelism  on  Distributed  Memory  Multicomputers  //  International 
Conference on Parallel Processing. ­1994. – P. 3 – 4.
Түйіндеме
Мақалада  таратылған  және  параллельді  мәліметтер  базасын  басқару  жүйесіндегі  сұратуларды 
орындалуын  оптимизациялау  сұрақтары  қарастырылған.  Мәліметтер  базасын  басқару  жүйесіндегі 
мәліметтерді сақтау құрылғыларымен тиімді жұмыс атқару және жүйе арқылы мәліметтердің  берілу 
уақыты жөніндегі кейбір сұрақтар қарастырылған.
Summary
In this article has shown all the matters of functions with optimical convex programming systems also, 
some matters for optimical exploiting dates on distributed memory on parallel processing.
ӘОЖ 004.421:004.715:316.772.5

жүктеу/скачать 7,65 Mb.

Достарыңызбен бөлісу: