Использование программы Oracle в ОАО "ММК"

ОАО "ММК" как динамично развивающаяся компания, уделяющая большое внимание техническому перевооружению, знакомство с особенностями использования программы Oracle на предприятии. Рассмотрение концепции построения распределенных базы данных в Oracle.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 13.12.2014
Размер файла 2,0 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

2

Использование программы Oracle в ОАО "ММК"

Введение

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

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

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

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

1. Предпосылки проекта, задачи, цели

1.1 Цели проекта

Рис.

Oracle Corporation - одна из крупнейших американских компаний, разработчик систем управления базами данных, инструментов для разработки баз данных, а также ERP-систем. Ведёт свою историю с 1977 года. Представительства действуют в 145 странах мира.

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

· Обеспечение руководителей предприятия оперативной, достоверной и полной информацией для принятия управленческих решений;

· Создание системы стратегического управления;

· Обеспечение возможности интегрированного планирования;

· Сокращение длительности производственных циклов и снижение производственной себестоимости;

· Повышение качества обслуживания клиентов за счет обеспечения большей достоверности информации о выполнении заказов и гибкого ценообразования;

· Обеспечение эффективных процедур ремонта и обслуживания оборудования;

· Оптимизация численности штатного персонала;

· Улучшение корпоративного имиджа и инвестиционной привлекательности компании.

В итоге была выбрана система Oracle E-Business Suite, зарекомендовавшая себя более чем 5000 внедрений, в том числе и металлургических. В пользу этого решения говорил и выбор двух крупных металлургических холдингов -- POSCO (Корея) и Alcoa (США) -- в пользу комплекса бизнес-приложений Oracle. Комплекс Oracle E-Business Suite отличает гибкость и перспективность технологий, надежность и расширенные возможности дальнейшего развития, он охватывает весь спектр задач, стоящих перед современными предприятиями (более 150 модулей), применены новейшие технологии в области хранения и обработки данных.

1.2 Пользователи Oracle

ОАО «Магнитогорский металлургический комбинат» входит в число двадцати крупнейших сталелитейных компаний мира. Это самый крупный в России металлургический комплекс с полным производственным циклом. ОАО «ММК» производит самый широкий ассортимент металлопродукции среди предприятий Российской Федерации и стран СНГ.

Рис.

Рис.

ММК экспортирует около 50% своей продукции в страны Юго-Восточной Азии, Ближнего Востока, Африки, Восточной Европы, а также Беларусь, Украину, Казахстан и другие государства СНГ.

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

ОАО «ММК» является динамично развивающейся компанией, уделяющей большое внимание техническому перевооружению. В новое тысячелетие Магнитка вступила полностью обновленной: реконструкция всех важных производственных объектов осуществляется в соответствии с общемировыми стандартами. Это в полной мере относится и к информационным технологиям. Важный шаг, который предприняло руководство ММК к построению высокоэффективного предприятия - создание интегрированной корпоративной системы управления.

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

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

Более 65 000 клиентов во всем мире используются полный набор прикладных решений Oracle для достижения превосходных результатов. Приложения Oracle Applications также предлагают клиентам полный выбора и безопасный путь, позволяющий использовать самые новейшие технологии. Oracle Applications Unlimited - это обязательство Oracle перед клиентами постоянно вкладывать средства и добавлять инновационные решения в текущие предложения приложений. Мощное сочетание комплексных решений обеспечивает повышенную производительность и помогает клиентам реализовать свою корпоративную и ИТ-стратегию, оптимизировать инвестиции в ИТ и использовать ИТ в качестве стратегического момента, отличающего среди конкурентов.

В России решениями, построенными на Oracle пользуются: ЦБ РФ, Сбербанк России, ГАС «Выборы», МВД РФ, ГТК РФ, МНС РФ, ФСБ, ФСНП РФ, Министерство образования РФ, Вымпелком, МТС, Соник Дуо, ПромстройБанк, ABN-Amro, Петербургская телефонная сеть, Comstar, Магнитогорский Металлургический Комбинат, Объединенная Металлургическая Компания, Чусовской Металлургический завод, «РАО ЕЭС России», Ингосстрах, МТУ Информ, «Уралкалий», «Метафракс», СИБУР, РОСНО, «КапиталЪ-Страхование», Альфастрахование, Банк Москвы, Связьинвест, «Казахтелеком», Ростелеком, Equant, Фарлеп, УТЕЛ, RTComm. RU, Хантымансийскокртелеком, Порт Ванино, Галоген, Сармат, ЦВ «Протек», Шрея Копрорейшнл, авиакомпания «Сибирь» и многие другие.

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

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

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

· Недостаточная полнота и достоверность получаемой информации увеличивает риск ошибочного решения;

· Малая наглядность полученной информации. Из-за этого руководитель теряет время на составление «портрета» проблемы из малоинформативных колонок цифр вместо решения проблемы;

· Невозможность «поиграть» данными. Статичность получаемых отчетов, отсутствие возможности моделирования приводят к тому, что руководитель в лучшем случае «видит», а не «предвидит» положение и их дальнейшее развитие.

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

Внедрение в 2005 году Корпоративной Информационной системы (КИС) ОАО «ММК» на базе Oracle E-Business Suite. Проект внедрения КИС был признан крупнейшим успешным проектом внедрения Oracle в регионе EMEA (Европа, Ближний Восток и Африка).

1.3 Результаты проекта на ОАО «ММК»

По проведенному консалтинговой компанией Mainstay Partners мониторингу результатов восьмилетнего использования КИС на Магнитогорском металлургическом комбинате бизнес-выгода для предприятия составила более чем 80 млн долл. Результаты проекта:

· Повышение прозрачности бизнес-процессов;

· Повышение производственной дисциплины;

· Повышение качества выполняемых работ;

· Оптимизация процессов контроля над транспортировкой;

· Сокращение времени простоя ж/д транспорта и издержек из-за простоев;

· Оптимизация складских запасов;

· Сокращение численности персонала;

· Уменьшение количества ошибок;

· Сокращение времени на получение информации по любой сфере деятельности предприятия;

· Полная финансовая и бухгалтерская отчетность.

1.4 Модули КИС

Консалтинговая группа «Борлас» на протяжении многих лет занимается созданием для металлургических компаний полнофункциональных автоматизированных систем управления ресурсами класса ERP на базе решений Oracle. Комплекс бизнес-приложений Oracle E-Business Suite включает в себя более 150 программных модулей, позволяющих эффективно решать весь спектр бизнес-задач, стоящих перед металлургическим предприятием. Oracle E-Business Suite -- первый в истории отрасли и единственный полный интегрированный комплекс приложений для электронного бизнеса, работающий в корпоративном Интранет и глобальном Интернет. Oracle E-Business Suite -- комплекс бизнес-приложений, предназначенный для создания корпоративных Систем Управления Ресурсами Предприятия (Enterprise Resource Planning), Систем Управления Взаимоотношениями с Клиентами (Customer Relationship Management) и электронных торговых площадок (Exchange).

Управление активами предприятия (Ремонты)

Модуль КИС «Ремонты» позволяет автоматизировать процесс обслуживания и ремонта оборудования.

Активы (Основные средства)

Модуль КИС «Активы» является комплексным программным решением для учета основных средств, нематериальных активов и незавершенного строительства. Модуль предназначен для ведения оперативного и бухгалтерского учета всех видов указанных активов и обеспечивает оптимальную стратегию выплаты налогов и бухгалтерского учета.

Проекты, УКС

Модуль КИС «Проекты, УКС» предоставляет средства комплексного управления рядом крупных долгосрочных и инвестиционных проектов, начиная с подготовки предварительной оценки бюджета и заканчивая полным выполнением проекта.

Управление собственностью

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

Закупки

Модуль «Закупки» является полноценным программным продуктом, позволяющим осуществлять полный цикл снабжения: от заявки до поступления на склад и последующего списания в подразделение - заказчик. Основными направлениями «Закупок» являются ведение реестра поставщиков, формирование потребности структурных подразделений, учет закупаемого сырья и материально-технических ресурсов. Модуль «Закупки» является одним из наиболее интегрированных направлений OEBS.

Oracle Sourcing (Электронная торговая площадка) Основной функцией модуля Oracle Sourcing является учет предложений поставщиков и проведение процедуры выбора поставщика. Выбор поставщика осуществляется в online режиме путем проведения аукциона, либо путем сбора предложений от поставщиков (запрос на предложение). Интегрирован с модулем «Закупки». Позволяет создать ЗП на основании результатов проведения процедуры выбора поставщика.

Запасы

Модуль «Запасы» является механизмом для управления запасами предприятия. Функциональность модуля позволяет вести учет прихода и расхода запасов, проводить общую инвентаризацию, отслеживать наличное и доступное количество. Модуль «Запасы» интегрирован с модулями «Закупки» и «Управление заказами».

iSupplier Portal (Портал поставщика)

Модуль iSupplier Portal является инструментом взаимодействия с поставщиками, позволяет осуществлять взаимодействие между компанией и ее поставщиками посредством Internet в интерфейсe web-броузера. Модуль iSupplier Portal дает возможность поставщику отслеживать всю цепочку от закупки до оплаты Система управления персонала. Является комплексным программным решением для учета кадров, табельного и персонифицированного учетов, расчета заработной платы и т.д. Система позволяет при относительно небольшой численности сотрудников, занятых в управлении персонала, значительно уменьшить количество операций и минимизировать количество ошибок, а также повышает оперативность в работе с персоналом.

Рис.

Модуль «Учет кадров» позволяет:

· вести организационную структуру предприятия;

· вести штатные расписания (как плановые, так и физические);

· вести реестр рабочих мест, включая аттестацию рабочих мест (с учетом требований пенсионного фонда РФ);

· вести справочники профессий и должностей;

· вести учет о приеме работников и их увольнении с предприятия;

· оперативно переводить работника внутри предприятия;

· правильно рассчитывать стаж работника;

· вести учет образования работников (любой формы обучения, включая курсы переподготовки);

· вести военный учет; вести учет трудовой дисциплины трудящихся.

Подсистема модуля «Учет кадров» - «Электронные заявки на обучение» позволяет:

· формировать заявки на обучение;

· оперативно вносить изменения в график и состав групп обучения;

· отслеживать исполнение заявок;

· вести электронный архив заявок.

Модуль «Табельный учет» позволяет:

· вести ежедневный учет использования рабочего времени трудящихся;

· ввести отклонение от графика работы;

· назначить перемещение внутри цеха или предприятия;

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

Модуль «Заработная плата» позволяет:

· рассчитывать заработную плату работников (вести учет начислений и удержаний);

· вести отчеты перед налоговой инспекцией;

· оперативно оформлять перечисления в банк;

· вести расчеты с внешними организациями;

· осуществлять обмен данными с расчетно-кассовым центром.

Подсистема модуля «Заработная плата» - модуль Планирование ФОТ и ЕСН является комплексным программным решением планирования Фонда оплаты труда и единого социального налога, определяет план по труду в разрезе штатных позиций и мест возникновения затрат, а также предусматривает возможность формирования сводных отчетов по всем подразделениям ОАО «ММК» и предприятию в целом. Планирование ФОТ и ЕСН позволяет осуществлять:

· краткосрочное планирование фонда оплаты труда (от 1 месяца);

· среднесрочное планирование фонда оплаты труда (от 2 месяцев до года) с возможностью выгрузки данных в произвольном формате;

· долгосрочное планирование фонда оплаты труда (от 1 года) с возможностью выгрузки данных в произвольном формате;

· оперативно произвести масс - корректировку премии (либо других составляющих заработной платы) в связи с изменениями тарифных ставок на предприятии.

Модуль «Персонифицированный учет» позволяет:

· вести анкетирование трудящихся;

· осуществлять назначение и перерасчет пенсии;

· выдавать индивидуальные сведения для Пенсионного фонда РФ;

· автоматически получать соответствующие отчеты.

Подсистема модуля «Персонифицированный учет» - «Дополнительное пенсионное обеспечение» позволяет:

· рассчитывать сумму взноса предприятия на личные счета работников в негосударственном пенсионном фонде;

· автоматически рассчитывать сумму взноса при увольнении работника;

· осуществлять обмен данными с НПФ;

· формировать данные для расчета единого социального налога;

· распределять инвестиционный доход на счетах работников.

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

· СВА - Система внутреннего аудита;

· СМК - Система менеджмента качества;

· ССП - Система сбалансированных показателей;

· СЭМ - Система экологического мониторинга;

· СУПБОТ - Система промышленной безопасности и охраны труда.

Модуль «КВП (Касса взаимопомощи)» предназначен для упрощения взаимосвязи между КВП и ГРОТ (Группа расчетов оплаты труда), что позволяет систематизировать удержания из заработной платы и отчетности по проведенным удержаниям.

Модуль «СКД (Система контроля доступа)» позволяет:

· упорядочить и автоматизировать выдачу пропусков;

· обеспечить доступ транспорта и работников на территорию предприятия;

· разграничить уровни доступа на объекты предприятия;

· организовать выявление нарушений трудовой дисциплины.

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

Модуль «ХК Арена «Металлург» - позволяет автоматизировать систему по продаже билетов на хоккейные матчи для работников ОАО «ММК» и обществ Группы компаний ОАО «ММК» с последующим удержанием из заработной платы, а также систематизировать отчетность по проведенным удержаниям.

Управление запасами

Модуль КИС «Управление запасами» автоматизирует процесс учета движения сырья, полуфабрикатов, отходов и готовой продукции по цеховым складам: поступление, расход в производство, списание со склада и оприходование на склад, перемещение внутри склада, передача на склад цеха дальнейшего передела, отгрузка готовой продукции.

Управление разработкой продукции

Модуль КИС «Управление разработкой продукции» обеспечивает поддержку единых справочников сырья, продукции и полуфабрикатов и рецептур для их производства, а также управление рецептами и технологическими маршрутами производства на основе установленных правил.

Управление производством и контроль операций

Модуль КИС «Управление производством и контроль операций» предназначен для оперативного учет производства цехов в натуральных единицах (тоннах): нормативное и фактическое количество израсходованных сырья и полуфабрикатов, произведенных продуктов, полуфабрикатов и отходов, время начала операций и их продолжительность.

Планирование выпуска продукции и потребности в материалах

Модуль КИС «Планирование выпуска продукции и потребности в материалах» является программным решением по формированию запланированных производственных заказов и плана производства в цехах энергокомплекса.

Управление качеством

Модуль КИС «Управление качеством» является инструментом для формирования спецификаций поставщика и спецификаций заказчика, контроль их соответствия базовым спецификациям, описывающим качественные характеристики материалов и необходимые проверки на соответствие заданному качеству, обеспечивает формирование заявок на отбор проб и анализ результатов испытаний.

Управление затратами

Модуль КИС «Управление затратами» является комплексным программным решением учета связанных с производством затрат в натуральном и стоимостном выражениях: прямые затраты (сырье, полуфабрикаты) и накладные затраты (вспомогательные материалы, топливо, электроэнергия, ремонты, зарплата и т. д.) - и обеспечивает калькулирование плановой и фактическое себестоимости продукции.

Дебиторы

Модуль «Дебиторы» позволяет автоматизировать учет взаиморасчетов с Заказчиками. Модуль предназначен для ведения оперативного и бухгалтерского учета всех видов документов при взаиморасчетах между ОАО «ММК» и Заказчиками, а также позволяет формировать отчетность о дебиторской задолженности.

Кредиторы

Модуль «Кредиторы» позволяет автоматизировать учет взаиморасчетов с Поставщиками. Модуль предназначен для ведения оперативного и бухгалтерского учета всех видов документов при взаиморасчетах между ОАО «ММК» и Поставщиками, а также позволяет формировать отчетность о кредиторской задолженности.

Движение денежных средств

Модуль «Движение денежных средств» позволяет автоматизировать процессы управления финансовыми потоками ОАО «ММК», а также формировать отчетность о движение финансов предприятия.

Главная книга

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

Налоговый учет

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

Рис.

Учет ЖД тарифа

Модуль «Учет ЖД тарифа» позволяет автоматизировать процесс выверки взаиморасчетов за предъявленный ОАО «РЖД» и выставленный в адрес других контрагентов ЖД тариф.

Казначейство

Модуль «Казначейство» позволяет автоматизировать процесс управления денежными средствами в рамках Группы компаний ММК. Позволяет отслеживать движение и остатки денежных средств на счетах предприятий входящих в Группу ММК.

Договоры. Претензии и иски.

Модуль КИС «Договоры» предназначен для реализации основных бизнес-процессов ведения договоров, контроля их исполнения и претензионно-исковой работы по ним.

Управление взаимоотношениями с клиентами (CRM).

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

Управление заказами

Модуль «Управление заказами» автоматизирует и упорядочивает процессы формирования, изменения и исполнения заказов на продажу.

Расширенное ценообразование. Формирование счетов-фактур.

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

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

Отгрузка

Модуль «Отгрузка» является комплексным программным решением для оперативного учета отгруженной и неотфактурованной товарной продукции ОАО «ММК». Модуль предназначен для анализа производства товарной продукции.

2. Архитектура СУБД Oracle

2.1 Распределенные БД в Oracle и Oracle в распределенных БД

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

Концепция построения распределенных БД в Oracle основана на децентрализованной их организации. Серверы взаимодействуют друг с другом с помощью уже знакомого нам протокола SQL*Net. Ссылки друг на друга - так называемые каналы связи БД (database links) - серверы хранят в качестве объектов БД. В свою очередь полное имя объекта может включать в себя канал связи (т. е. вместо самого объекта в локальной базе данных может храниться как бы ссылка на него): это, безусловно, требует обеспечения уникальности имен серверов ("сервисов" в терминологии Oracle) в сети, что достигается с помощью иерархической организации доменов, подобной существующей в Internet.

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

2.2 Синхронная связь без тиражирования данных

oracle база данный

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

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

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

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

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

2.3 Тиражирование данных

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

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

2.4 Промышленные системы

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

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

2.5 Варианты тиражирования данных в Oracle

Самым простым (и исторически реализованным первым) вариантом тиражирования в Oracle является механизм так называемых неизменяемых снимков (read-only snapshots). Он подразумевает создание удаленной копии таблицы (или ее подмножества), которая доступна только на чтение и обновляется по заданному сценарию и расписанию. Точнее, снимок определяется так же, как представление - view, т. е. он может быть основан и на нескольких таблицах.

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

Последним "атомарным" вариантом тиражирования в Oracle (ибо возможны также любые комбинации) является тиражирование с множественными хозяевами (multi-master site replication). При данном варианте полностью тиражируются целые наборы объектов БД (в них помимо таблиц могут входить индексы, представления, триггеры, пакеты хранимых процедур, синонимы, генераторы последовательностей). При этом тиражируются все определения и атрибуты объектов, так что в результате все хозяева их копий становятся равноправными. Любые изменения тиражированных данных непосредственно передаются ("распространяются") всем хозяевам (в отличие от варианта изменяемых снимков, где несколько снимков одного объекта могут обменяться изменениями только через посредство хозяина этого объекта). Такое решение, в частности, приводит к тому, что в системе не будет ни одного сервера, единичный выход из строя которого означал бы невозможность продолжения работы с набором тиражированных объектов.

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

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

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

Как уже упоминалось, возможны два режима тиражирования: синхронный, когда все изменения данных распространяются немедленно, и асинхронный, когда по отношению к этим изменениям применяется алгоритм "запомнить и передать" (store and forward), а момент передачи выбирается по заданному правилу (или явно инициируется, например, после восстановления связи).

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

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

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

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

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

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

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

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

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

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

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

2.6 Поддержка резервной копии БД

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

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

Если это реляционные СУБД (MS SQL Server, Informix, Sybase, DB2, CA Ingres), можно использовать так называемые прозрачные шлюзы для объединения их с Oracle. Для пользователя такого шлюза полностью имитируется функциональная среда сервера Oracle при доступе к данным, хранящимся в "чужих" СУБД.

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

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

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

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

2.7 Администрирование распределенных систем на примере Oracle

Немного поговорим о тех средствах, которые Oracle предлагает в помощь администратору распределенной информационной системы.

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

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

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

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

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

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

3. Oracle на практике в отделе снабжения

3.1 Обязанности отдела снабжения

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

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

3.2 Информационное обеспечение комплексных задач

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

Данная СУБД была выбрана по следующим причинам:

· простота средств реализации,

· легкость освоения инструментарием разработчика ,

· наглядность визуализации информации.

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

Связи между таблицами можно разбить на четыре базовых реляционных типа с отношениями:

· один-к-одному;

· один-ко-многим;

· многие-к-одному;

· многие-ко-многим.

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

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


Подобные документы

  • Краткая история развития СУБД ORACLE, основные понятия и определения, архитектура. Принципы работы с СУБД ORACLE. Разработка баз данных, средства и технологии их реализации; возможности процедурного языка PL/SQL. Приемы администрирования СУБД ORACLE.

    презентация [609,2 K], добавлен 14.02.2014

  • Важнейшая задача компьютерных систем управления - хранение и обработка данных. Особенности применения в ОАО "ММК" системы управления реляционными базами данных "Oracle", предназначенной для одновременного доступа к большим объемам хранимой информации.

    курсовая работа [87,6 K], добавлен 04.12.2014

  • Резервные базы данных под управлением Oracle Data Guard. Создание физической резервной базы. Защита резервных копий баз данных и базы данных разработчиков. Восстановление базы данных на удаленной машине. Стратегия резервирования и восстановления.

    дипломная работа [499,7 K], добавлен 04.06.2013

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

    курсовая работа [1,0 M], добавлен 10.06.2014

  • Общее описание функций Oracle SQL, их особенности, классификация и типы, преобразование регистра символов и манипулирование строками. Работа со строковыми функциями. Арифметические операции с датами. Функции преобразования и основные операции над ними.

    курсовая работа [464,4 K], добавлен 24.12.2014

  • Объекты модели хранения данных базы данных ORACLE. Взаимосвязь между логическими структурами. Средства манипулирования данными языка SQL, данными языка SQL. Структура выполнения простейших запросов. Формирование критерия отбора. Сортировка данных.

    презентация [120,1 K], добавлен 14.02.2014

  • Виды и практические примеры теоретико-множественных операций в Oracle: соединение, объединение, пересечение. Соединение трех и более таблиц. Синтаксис соединения ANSI SQL/92 и ограничения ANSI SQL/86. Типы внешних соединений: левое, правое, полное.

    презентация [379,6 K], добавлен 14.02.2014

  • Язык описания данных Oracle. Предназначение базы данных для хранения информации. Создание и изменение таблиц с помощью операторов Create и Alter table. Правила именования таблицы. Операторы Rename и Truncate. Метод создания и удаления представления.

    презентация [82,7 K], добавлен 14.02.2014

  • Возможности репликации в СУБД Oracle. Основные шаги по настройке баз данных (Startup open) и tnsnames.ora. Табличное пространство и пользователь Streams. Dblink между исходной и целевой базами данных. Использование PL/SQL API для настройки репликации.

    курсовая работа [2,7 M], добавлен 14.07.2012

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

    курсовая работа [1,1 M], добавлен 14.08.2014

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.