ИНФОРМАЦИОНН a СИСТЕМА ЗА ТРАНСФЕР И …infdep.nbu.bg/11/1/diplomna...

Д И П Л О М Н А Р А Б О Т А

НА ТЕМА :

ИНФОРМАЦИОННA СИСТЕМА ЗА ТРАНСФЕР И ОБРАБОТКА НА ДАННИ В CCHellenic БЪЛГАРИЯ

Дипломант: Дипломен ръководител:

Иван Светославов Любомиров доц. Велина Славова

Спец.: „Информатика”

Фак. № F23456

СОФИЯ

Иван Любомиров 2

Съдържание

Увод 4

Coca–Cola в България – историята на едно начало 5

ГЛАВА ВТОРА

Анализ на предметната област 6

ГЛАВА ТРЕТА

Системи в CCHellinic 7

Phoenix 7

Системата BASIS 9

ERP Системата SAP/R3 11

SAP/R3 модули 13

Системата SAP Business Warehouse 15

Графика на пътя на данните в системите на CCHellenic 19

ГЛАВА ЧЕТВЪРТА

Бизнес нужда от създаване на алтернативно решение 20

Видове решения 22

IBM ISERIES ACCESS for WINDOWS 22

Външна фирма изпълнител 23

Microsoft Access 23


ГЛАВА ПЕТА

Проектиране 24

Външни източници на данни за Microsoft Access 27

Промяна на данните с актуализиращи запитвания 28

ODBC връзка 29

ГЛАВА ШЕСТ

Схема на дейността на CCHellenic 32

Описание на информационната система “DELORD” 33

Форма – MAIN FORM 33

Полета и бутони във формата на инф. система “DELORD” 35

Заявки (QUERIES) 37

Таблици (TABLES) 40

Модул в информационната система “DELORD” 42

Екран на модула в инф. система “DELORD” 42

ГЛАВА СЕДМА

Проблеми при разработката на инф. система “DELORD” 43

Комуникационен проблем 43

Проблеми при разработка на инф. система “DELORD” 45

Проблем при задаване на интервал от време за изтегляне на данни 46

Блок схема 47

ЗАКЛЮЧЕНИЕ 49


Глава първа

Увод

(Цитат - http://www.coca–cola.bg)

Кока-Кола е изобретена в Атланта, Джорджия, от д-р Джон Стайт Пембъртън, местен аптекар през 1886 година. Дали случайно или не новият сироп бил смесен с газирана вода и така се получила напитката, която познаваме и до днес. Първите продажби са реализирани на 8 май 1886 г. в Атланта.

Считайки, че две „KK“ ще изглеждат по-добре в рекламите, г-н Франк М. Робинсън, съдружник и счетоводител на д-р Пембъртън, предлага името Кока-Кола и изписва известната сега търговска марка с уникален шрифт. Първата вестникарска реклама на Кока-Кола се появява във вестник „Атланта Джърнъл”, приканваща гражданите да опитат „новата и популярна газирана напитка“. По витрините на магазините се появяват изрисувани с маслени бои плакати с надпис Кока-Кола. Д-р Пембъртън обаче не осъзнава потенциала на напитката и започва да продава части от компанията си на други съдружници. Малко преди смъртта си през 1888 г., той продава цялата останала част от компанията на Ейза Дж. Кендлър от Атланта - човек с голям търговски нюх. Г-н Кендлър продължава да изкупува останалите дялове докато не придобива 100% от компанията.


Coca–Cola в България – историята на едно начало

(Цитат - http://www.coca–cola.bg)

През 1965 г. ДСП “Тексим” и Софийският градски народен съвет (СГНС) сключват договор за изграждане на предприятие за производство на газирани безалкохолни напитки. Съгласно този договор СГНС предава реконструирана сграда на бул. Христо Ботев, а ДСП “Тексим” доставя от Франция oборудване. Така в края на година започва производството на напитката “Оранжада” с портокалов концентрат от Израел и Гърция. В същият този цех е произведена и първата стъклена бутилка Coca–Cola за България. Това става възможно благодарение на договор, подписан между ДСП “Тексим” и компанията Coca–Cola на 01.07.1965 г. Уникалните контурни бутилки са били доставени от Алжир, а металните капачки от Италия.

На 14.11.1991 г. е подписан меморандум за намерение между ЦКС, Tria Epsilon Group of Companies и ТПК “Тексим 90” – Пловдив за създаване на първото смесено дружество за производство на продуктите на Компанията Coca–Cola. На 13.01.1992 г. между ЦКС и “Кла рина Холдинг” е подписан договор за създаване на дружество с ограничена отговорност – “Пловдив Ботълинг Къмпани”. С решение на УС на ЦКС от 12.12.1991 г. се постановява създаването на смесени дружества между “Кла рина Холдинг”, ЦКС кооперациите в Търговище, Плевен и Бургас. Решено е да се създаде и смесено дружество между ЦКС, Кока-Кола и “Кла рина” на база на съществуващото предприятие “Колина”. Договорът за създаване на това дружество е подписан в присъствието на министър прецедателя Филип Димитров, на 13.08.1992 г. в гр. София - НДК ,от Панчо Иванов, председателя на ЦКС, Джордж Дейвис – за Левентис Груп и Мутар Кент - за Coca–Cola в Европа.

Вторият продукт на компанията Coca–Cola, появил се на българският пазар, е търговската марка Sprite. Производството на напитка започва през 1992 г., последвано от Fanta Orange – 1993 г., Kinley Tonic Water и Fanta Lemon – 1994 г. , Kinley Soda Club – 1995 г. През 1995 г. е построен най-модерният завод в страната за производство на безалкохолни напитки в Костинброд. Тогава започва производството на газирани напитки в метални кутии.


Година по-късно на пазара се появява новата 0.25л. стъклена контурна бутилка на Coca–Cola.

Днес в семейството от продукти на Coca-Cola на българския пазар ще откриете търговските марки Coca-Cola, Fanta, Sprite, Kinley, Lift, Schweppes, Burn, Cappy, Blak Cola, минерална вода Банкя.

Глава втора

Анализ на предметната област

„Кока-Кола Хеленик Ботълинг Къмпани България” АД е eдин от най-големите производители на безалкохолни напитки в България. Компанията има огромен асортимент от над сто и седем вида артикули и разфасовки, като всеки един от тях неизменно присъства в абсолютно всички търговските обекти в страната, независимо дали това е магазин, заведение, нощен клуб или училищна лавка.

Обслужването на такъв брой клиенти не може да се извършва ръчно на хартиен носител. Процеса по обработка на данните трябва да бъде максимално автоматизиран.

Светът на бутилиращия бизнес се променя и развива непрестанно, което задължава компанията “Кока–Кола Хеленик” да оптимизира процесите на работа спрямо условията на пазара, което несъмнено се отразява в системите на компанията.

Чрез непрестанното оптимизиране и развитие на процесите, системите на „Кока–Кола Хеленик” трябва да предоставят възможност всяко едно бизнес решение да бъде внедрено в ежедневната работа на служителите.

Доверието, което компанията е изградила към своите клиенти е от основен приоритет за всяко едно взаимоотношение между търговец и клиент. Ако системите не отговарят на изискванията на пазара и на клиентите, то това доверие много лесно ще се загуби, което неимоверно ще урони престижа и имиджа на компанията.


Като уважаваща себе си корпорация, „Кока–Кола Хелиник” не може да си позволи технологично изоставане поради голямото разрастване и развитие на пазара. За целта се използват няколко вида системи, с помощта на които се обработва цялата информация, постъпваща от ежедневните поръчки на търговските обекти.

Глава трета

Системи в CCHellenic

Всички държави в корпорацията „Coca-Cola Hellenic” използват системите Phoenix, BASIS, SAP/R3, SAP Business Warehouse. Всички сървърни машини се намират в град Виена, Австрия. България макар и малка страна и от скоро членуваща в Европейския съюз не отстъпва по нищо на останалите страни от организацията. Дори в определени системи заема лидерска позиция спрямо останалите 28 държави. България се отличава и с това, че успява да използва пълните функционалност и капацитет на системите, с които разполага.

Системата Phoenix

Phoenix системата е решение, което автоматизира дневните дейности на Търговския отдел, също така оптимизира и подобрява работата на търговските представители на компанията.

Phoenix се състои от два модула: - Phoenix Client – представлява софтуер, които се инсталира на

HHT устройства или PDA устройства. Използва се от търговските представители.

Phoenix Client е софтуер за мобилни устройства, предоставящ възможност на търговските представители да извършват всички дейности свързани с тяхната работа в даден обект напълно


автоматизирано. Този софтуер се синхронизира и комуникира с Phoenix сървъра, които приема цялата информация от мобилните устройства. Системата Phoenix също така комуникира с други системи използвани от компанията Кока–Кола Хеленик - BASIS и SAP.

Вторият модул е Phoenix Admin – средство инсталирано на сървъра, което се използва от администратора.

Поръчките първо преминават и се обработват от системата Phoenix. Повечето поръчки се взимат от търговски представители, които всеки ден посещават почти всички търговски обекти в страната (супермаркети, кафенета, нощни клубове, училища и т.н.). Всяка поръчка се взима чрез мобилно устройство Symbol MC70, което е разработка на Motorola (CPU 624MHZ, 64/128mbRAM, Windows Mobile 2005), чрез специално разработения софтуер на име “Phoenix Client”. С помощта на този софтуер търговският представител има възможност да направи инвентаризация на всеки обект, да сканира всяко едно от хладилните съоръжения, да прави проучвания свързани с развитието на обекта спрямо цялостното състояние на пазара, както и специални поръчки за смяна на хладилни съоръжения и др. След като търговският представител приключи с дейностите в търговския обект информацията се изпраща през GPRS предавател и интранет връзка директно в Phoenix Системата в град Виена. В центъра за обработка на информацията поръчката се обработва от системата Phoenix. Извършва се проверка дали е вярно въведена, дали има направени проучвания за дадения обект, акуратно създадени ли са и др. След като приключи проверката, информацията се изпраща чрез интерфейс директно към BASIS системата за следваща обработка и проверка.


Системата BASIS

Beverage Advanced Standard Information System

BASIS е създадена през 1973 г. от компанията GBS (Global Bottling Company) специално за нуждите на бутилиращите предприятия работещи с компанията The Coca–Cola Company.

С помощта на BASIS “Кока–Кола Хеленик България” АД въвежда, обработва, разпределя и оформя в краен вариант своите поръчки. Системата предоставя възможност за въвеждане на заявки постъпили от “Центъра за телефонни поръчки” на компанията. Също така в системата BASIS пристигат заявките, взимани от търговските представители чрез системата Phoenix. Извършва се също промяна и подмяна на кодове на артикули, разпечатване на фактури, изписване на маршрути, определяне се наряди на шофьори и всичко свързано с дейността по обработката и доставка на всяка една поръчка.

След въвеждането й постепенно все по-голям процент от заявките преминават през системата. По този начин с годините тя се утвърждава като една от основните и надеждни системи в организацията „Кока–Кола Хеленик”.


ЕRP Системата SAP/R3

(Цитат - http://www.feb.uni-sofia.bg./FEBA/, http://www. sap.com)

ERP системата е организационно-интегрирана, състояща се от свързани помежду си приложения, които координират бизнес дейностите и поддържат информационните потоци в предприятието.

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

• Единна база данни;

• Функционална всеобхватност;

• Максимална гъвкавост като възможност за реакция на промени;

• Пълна и незабавна използваемост на всички данни;

• Пълна информационна свързаност на всички потребители.

Софтуерните системи от клас ERP представляват набор от предефинирани и предварително програмирани интегрирани програми, които автоматизират основните бизнес процеси. Тези “пакети за бизнес интеграция” се създават от софтуерни корпорации. Базирани са на даден бизнес модел, посредством които осъществяват най-добрите бизнес практики, без да се реализират специфичните нужди на крайния потребител. Основните технологични функционални характеристики са:

• Системи от типа клиент/сървър (използват технологията клиент/сървър);

• Централизирана база данни;

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


• Специфични приложения за отделни отрасли, чиито функции са по-тесни и специализирани, във връзка с по-особени цели или изисквания. Ядрото на системата е централизирана база данни, която съхранява и извежда данни в модулните приложения, обслужвайки виртуално всички дейности на фирмата.

От самото си начало през 1972 г. SAP е признатият лидер в предоставянето на бизнес решения за всички видове индустрии.

Със седалище във Валдорф, Германия SAP е най-големият световен производител на бизнес софтуер и третият най-голям независим производител на софтуер въобще. Служителите на SAP са повече от 28 900 в дъщерни фирми в повече от 50 страни по света. Основавайки се на богатия си опит SAP представя mySAP Business Suite - цялостна серия от бизнес решения за днешната икономика. mySAP Business Suite позволява на служители, клиенти и бизнес партньори да работят успешно заедно - навсякъде и по всяко време. mySAP Business Suite е отворена и гъвкава платформа и поддържа работа с бази данни, приложения, операционни системи и хардуер от почти всички големи производители. С използването на най-добрите технологии, услуги и програмни ресурси SAP създаде бизнес платформа, която предоставя важни информационни ресурси, подобрява ефективността на логистичните вериги и изгражда силни връзки с клиентите.


SAP/R3 модули:

(Цитат - http://www.feb.uni-sofia.bg./FEBA/)

• Accounting - Счетоводство

• Financial Accounting (module FI) – Финансов счетоводен модул

• Asset Accounting (module FI-AA) – Осчетоводяване на активи

• Controlling (module CO) - Контролен модул

• Investment Management (module IM) – Инвестиционен модул

• Project System (module PS) – Модул за проекти

• Logistics – Модул за логистика

• Materials Management (module MM) – Управление на материалите

• Production Planning Control (module PP) – Контрол на производство

• Plant Maintenance (module PM) – Профилактика на фабрики

• Sales & Distribution (module SD) – Продажби и доставки

• Logistics Execution (module LE) – Модул за извършване на

логистична дейност

• Customer Service (module CS) – Поддръжка на клиента

• Quality Management (module QM) – Управление на качество

• Human Resources (module HR). – Човешки ресурси


Жизнен цикъл на ERP системите

(Цитат - http://www.feb.uni-sofia.bg./FEBA/)

Жизненият цикъл на ERP системите според модела на Естевес и Пастор включва 6 отделни фази, през които системата преминава през цялото си съществуване в приемната организация:

• Анализ на бизнеса и решение за внедряване на ERP;

• Избор на доставчик и закупуване;

• Внедряване - настройка, конфигуриране, параметизиране и адаптиране на софтуерния пакет, съобразно специфичните нужди на организацията - извършва се от системен интегратор, който осигурява методиката за внедряване на ноу-хау и обучение на персонала;

• Експлоатация и поддръжка – функционалността, използваемостта и адекватността на системата са от съществено значение. Веднъж внедрена системата трябва да бъде поддържана, отстраняват се грешки, оптимизират се функции и се извършват подобрения на системата като цяло;

• Развитие на системата – добавяне на допълнителни възможности чрез еволюция “нагоре” – допълнителни модули, data warehouses, BI и еволюция “отвън” – добавят се модули CRM, SCM, Ecommerce. На следващ етап натрупаната в data warehouse информация се анализира и представя в подходящ вид на потребителите. За целта се прилага OLAP технология. OLAP осигурява ефективен достъп на потребителите за извличане на информация от data warehouse чрез методи като ad-hoc заявки и многоизмерен анализ. OLAP технологията се прилага чрез изграждане на разностранна структура на данните, при която се създават n-мерни кубове. Всеки такъв куб съдържа информация за конкретни показатели, която се изменя по множество критерии представени чрез дименсии. Така създадените многодименсионни масиви от данни могат да се разглеждат в различни разрези по отношение на дефинираните дименсии и йерархичните нива в тях. Данните могат лесно и бързо да се агрегират, дезагрегират и ротират според специфичните изисквания на мениджърите, които ги анализират в даден момент;


• Отпадане на системата – когато се появят нови технологии или когато този подход не отговаря повече на нуждите на бизнеса.

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

Между системите BASIS и SAP/R3 има изграден интерфейс, чрез които процеса по прехвърляне на данните е напълно автоматизиран.

Системата SAP Business Warehouse

Системите за складиране на данни служат главно за събиране на информация от различни източници. Справките създадени от информацията, складирана в системата, са основата за успешен бизнес процес в компанията. Този тип от системи може да бъде използван от всички в компанията от обикновения служител до ръководители и началници на отдели. Ръководителите на компанията се нуждаят от основен източник с ежедневно обновяваща се информация за всяка една от бизнес областите, в която оперира предприятието.

SAP предоставя чрез SAP BW платформа за бизнес анализи, която съдържа набор от инструменти за анализ с добавена функционалност за съхранение и обработка на данни. Също така осигурява всички необходими инструменти за моделиране, извличане, съхранение и достъп до данните. Данните от различни източници могат да се комбинират с цел разширяване на анализационните възможности.


Място на системата SAP Business Warehouse:

Системите SAP Business Warehouse и SAP/R3 са свързани помежду си и голяма част от данните, които се прехвърлят от BASIS в SAP/R3 се трансферират автоматично в информационните кубове на SAP BW.

Чрез SAP Business Warehouse крайният потребител има възможността най-бързо, най-лесно и най-безопасно да достъпи определена информация, касаеща работата му, без да се притеснява, че след негова некоректна манипулация данните няма да могат да се възстановят.

Данните винаги могат да бъдат възстановени от първоизточника (системите BASIS и SAP/R3).

BASIS SAP R3 SAP BW

Краен Потребител Поръчки

Поръчки


Структура на системата SAP Business Warehouse:

Данните в SAP Business Warehouse се намират в така наречените информационни кубуве. Всеки един от информационните кубове е уникален сам по себе си тъй като информацията която се зарежда в него е строго специфична. Всеки един от информационните кубове има структура и рестрикции чрез които се ограничава зареждането на некоректни данни.

SAP Business Warehouse също така разполага с въможности за акумулиране на специфични данни от няколко на брой информационни кубове. Това са така наречените “Мулти кубове”. Чрез “Мулти куба” крайният потребител има възможност да извлече информация от няколко информационни куба.


Данните от информационните кубове в SAP Business Warehouse са достъпни чрез така наречените заявки (Queries). Заявката предоставя възможност на крайния потребител да дефинира точно какъв тип данни да бъдат извлечени от информационния куб.

Графика на пътя на поръчките в системите на CCHellеnic

Phoenix Система

Мобилни Устройства

1) Поръчката се трансферира от Мобилното устройство към Phoenix Системата. 2) След обработка Phoenix Системата прехвърля заявката към систамата BASIS 3) Поръчката от систамата BASIS се прехвърля в SAP/R3 4) Последната стъпка е когато данните за заявката се прехвърлят от SAP/R3 към Складовата система SAP BW


Глава четвърта

Бизнес нуждата от създаване на алтернативно решение

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

Основен принцип в развитието и подпомагането на обектите е ръководството на компанията и отдел “Продажби” да има възможност да проследява ежедневните продажби на определена група обекти или за определена група артикули от асортимента на компанията. Физически невъзможно и е неефективно проследяването на продажбите в търговските обекти

Вариант този процес да се проследи е от информацията, която съпътства всяка една поръчка, постъпваща в системите на „Кока–Кола Хеленик Ботълинг Къмпани България” АД. Чрез системите могат да се проследяват ежедневните продажби за всеки един търговски обект в страната или за всеки един артикул.

Информацията от продажбите не е достатъчна, за да могат да се правят анализи дали даден обект има проблеми с продажбата на определен артикул или на група от артикули. Нужна е и информацията от ежедневните доставки във всеки един от търговските обекти. С информацията за доставките може да се наблюдава дали поръчката, подадена от търговския представител, е коректно изпълнена.

Най–лесният начин за тази информация да бъде достъпна за служителите на компанията е тя да се намира в информационен куб в системата SAP Business Warehouse. Системата осигурява възможност за лесен достъп до информацията на повечето служители в предприятието. По този начин се гарантира възстановяването на данните при евентуална некоректна манипулация.

Източника на данни е системата BASIS. По принцип не би трябвало да има проблем данните да се заредят в SAP Business


Warehouse от SAP/R3, все пак има изграден интерфейс помежду им.

Зареждането на данните от SAP/R3 системата може да се направи чрез напълно автоматизиран процес, без намесата на човешки фактор или отделяне на какъвто и да е ресурс на компанията. Единственият проблем е, че данните които се зареждат в SAP/R3 системата не съдържат подробна информация за ежедневните продажби и доставки към търговските обекти, каквито реално са в системата BASIS. За да бъдат достъпни тези данни в SAP BW се изисква да се създаде информационна система, която да изтегля данните от BASIS, да ги обработва и да ги прехвърля към SAP Business Warehouse.

Чрез информационната система ще се изгради реално интерфейс между първоизточника на информация - система BASIS и крайната дестинация на данните - SAP Business Warehouse.

Обработка на данните се налага поради атомарността на данните между двете системи.

Основните разлики са:

- Разлика в данните на двете системи е формата на годината. - Разлика в наименованието на полетата.

Ежедневният трансфер на данни от едната към другата система са огромни. Понякога се е случвало да се изтеглят файлове от над 1 000 000 записа. Ръчната обработка на такъв обем от информация би отнело голяма част от ресурса на даден служител на компанията. Този проблем налага разработката на информационна система, която да прави цялата обработка на данните автоматично, с което да ограничи до минимум отнемането на ресурса на дадения служител.

Задача за изграждането на такава информационна система ми беше възложена от директора на отдел “Информационни системи” на „Кока–Кола Хеленик България” АД.


Видове решения

Данните намиращи се в системата BASIS могат да бъда изтегляни по няколко начина:

IBM ISeries Access for Windows

Чрез това приложение на IBM е възможно да се тегли информация директно в Excel. По този начин информацията може да се запази във файл във формат .csv и да се прехвърли в SAP/BW ръчно, след което отново ръчно да се стартират информационните кубове, в които да се заредят данните. Но колкото и да е лесен този подход е също толкова рискован, поради това, че някои стойности като формата на годините не е един и същ в BASIS и SAP/BW, ограничеността в бройката записи, която има Microsoft Excel XP (65653 записа), липсата на каквито и да е индекси в коя колона какви данни са записани и др.

Поради тези причини работата с IBM ISeries Access е ограничена, основно, защото дневните продажби и доставки за всеки артикул заемат много повече от 65000 реда.

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


Външна фирма изпълнител

Възлагането на разработката на специален софтуер, чрез които да се осъществи изтеглянето и обработката на определен тип данни има своите предимства и недостатъци.

За изпълнението на тази задача, на фирмата изпълнител трябва да се предостави документация за изискванията, а тя след запознаване с условията следва да предложи оферта за изграждането на такава системата. След разработването на специалния софтуер трябва да се извършат огромен брой тестове за стабилност на комуникацията, стабилност на изтеглянето на данните, както и стабилност на самия софтуер. Това ще отнеме много голям период от време, през което няма да може да се предостави на ръководителите на компанията нужната информация.

Голям недостатък е също така и сервизната поддръжка на тази информационна система от фирмата изпълнител. Възможността за бърза намеса и реакция при дадена ситуация е от критично значение.

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

Microsoft Access

За изпълнението на подобен проект най-добрият вариант е да се използва програмата Microsoft Access. Microsoft Access предоставя възможност за изграждане на програма, която да автоматизира процеса за извличане на данните от системата BASIS. Освен това Microsoft Access предоставя възможност за автоматично обработване на данните, както и тяхно прехвърляне към SAP


Business Warehouse системата, от където ще бъдат заредени в информационните кубове.

По този начин човешкият фактор е намален до минимум, с което се намалява и допускането на евентуални грешки при обработването на такъв голям брой записи от данни.

Избягват се доста неудобства от финансова гледна точка, като поддръжка и евентуално подобрение на системата.

Глава пета

Проектиране

(Цитат - http://www-it.fmi.uni-sofia.bg/courses/wdb/db.htm)

Поради сложността на проекта, информационната система много внимателно трябваше да се проектира. Условията, зададени ми от ръководството на отдел “Информационни системи” бяха:

- Информационната система да бъде лесна за употреба; - Процесът по изтегляне и обработка на данните да бъде

максимално автоматизиран; - Времето за обработката на данните от информационната

система да бъде максимално кратко;

При разработката на автоматизирани информационни системи се наблюдава тенденция към насочване вниманието на специалистите от проблемите на обработката на данните към проблемите на подходящо дефинираната им структура и съдържание. Потребностите от интегриране на възможно повече звена от дейността на обекта в една информационна система затруднява значително проектирането на БД с подходяща структура, а това е от първостепенно значение. Всъщност базата данни се явява „гръбнакът" на информационната система. Правилното й построяване предопределя адекватността на системата към промените в обектите и явленията от реалния свят. Ето защо


изграждането на такава БД е процес, нуждаещ се от методологическа и теоретическа обосновка.

Базата данни представлява една оптимално организирана

съвкупност от логически свързани помежду си данни, които са логически независими от обработващите програми. Релационната база от данни е реализация на релационния подход при представяне на данните. Тя се представя логически като съвкупност от таблици. Колоните в таблиците се наричат атрибути и наборът им определя структурата на таблицата. Самите редове в таблиците се наричат кортежи и съответстват на конкретните представители на данните, т.е. те са съдържанието на БД. Множеството от допустими стойности на даден атрибут се нарича домен.

В теорията на съвременните релационни БД се е наложило и значението на атрибут „неизвестно" или „няма смисъл", което обикновено се отбелязва като NULL. Понякога е недопустимо за атрибут да има стойност NULL, например ако атрибутът влиза в състава на първичния ключ на таблица. Всяка таблица трябва да има избран първичен ключ, който представлява съвкупност от един или няколко атрибута и трябва да отговаря на две условия:

• уникалност - в произволен момент от времето да не се допуска съществуването на два кортежа, които да имат еднакви значения за тази група атрибути като цяло;

• минималност - нито един от тези атрибути, влизащи в състава на ключа, да не може да бъде изключен, без да се наруши изискването за уникалност.

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

• същности - обикновено отразяват обектите от предметната област;

• връзки - обикновено отразяват процесите и взаимодействието между обектите на предметната област.

Във връзка с това съществуват т.нар. външни ключове, които се срещат като набор от стойности на първичния ключ в дадена таблица-същност и участват със същия набор от стойности в други таблици-връзки. Всъщност това е първичният ключ на една таблица, който е добавен към друга (или същата) таблица. Следователно


външния ключ отразява участието на един обект във взаимодействие (процес) с други обекти (или със самия себе си).

В релационния модел за таблиците се налагат изисквания за цялостност в два аспекта:

• цялостност по същности - не може атрибут, участващ в първичния ключ да има неопределено значение (NULL), както и да няма първичен ключ за таблица;

• цялостност по връзки (референциална цялостност) -стойностите на всеки външен ключ да фигурират съответно някъде като стойност на първичния ключ.

В допълнение, извън релационния модел върху данните могат да бъдат наложени и специфични за приложението ограничения.

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

• „едно към едно” (1:1); • „едно към много” (1: М) или „много към едно" (М : 1); • „много към много" (М : М) - позволена само на ниво

проектиране на логически модел. При физическия модел връзки от този тип водят до поява на нова таблица, свързана към двете таблици с множественост М : 1.

Необходимо е да се отчете, че на етапа проектиране се разработват два типа модели на данните:

• логически - обхващат отношенията като набор от атрибути, заедно с техните типове и типовете на връзките между отношенията;

• физически - обхващат конкретната реализация на логическия модел в зависимост от избраното СУБД, т.е. таблиците и колоните в тях (с техните точни имена и типове, с които ще се използват в програмите). Тук типовете на полетата при създаване на физически модел за различните СУБД са различни.

В същността си релационния подход при разработване структурата на БД изисква минимално дублиране на данните в модела. При това се избягват възможни нарушения на целостта в БД и двусмислия при извличане и интерпретация на данните. За постигане на оптималност при определяне структурата на представяне на данните (като набор от таблици и като начин на разпределянето на атрибутите в тях) се прилагат правилата за нормализация. За целта се изследват зависимостите, съществуващи между атрибутите в таблиците. Някои от тези


зависимости са желателни, а други - нежелателни (водят до аномалии и странични ефекти). Налага се да се заменят някои таблици с други с цел да се премахнат вредните зависимости и именно това се осъществява чрез процеса на нормализация. При това последователно се привежда всяка таблица в I, II и III нормални форми. За добре проектирана база се счита тази, в която всички таблици са доведени до III НФ. Понякога във връзка с улесняване на обработката са допустими и дублирания на данните, при което някои таблици да не са в III НФ.

Съществуват два основни подхода при проектиране схемата на БД:

1. Подход на атрибутите („Attribute driven”) - първоначално се прави списък на всички атрибути и по правилата за нормализация се обособяват в таблици;

2. Подход на отношенията („Entity driven”) - откриват се същностите (т.е. номенклатурите, списъците) за предметната област с всички принадлежащи им атрибути, след което се оформят взаимодействията между тях (т.е. процесите, събитията) под формата на връзки със съответни атрибути, които ги характеризират.

Външни източници на данни за Microsoft Access

(Цитат - http://www-it.fmi.uni-sofia.bg/courses/wdb/db.htm)

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

При присъединяване (link) на данни се създава динамична връзка между една база от данни, наречена източник на данни (data source), и друга, наречена местонахождение (destination). Данните не се копират или конвертират, а се предават през връзка от


източника към местонахождението. Присъединените данни изглеждат като част от базата данни, но остават в рамката на външния източник на данни в оригиналния си файлов формат. Това предоставя възможност да се използват данните в Access, а потребителите на източника да продължават да ги използват и обновяват в оригиналната програмна среда.

В Access може да се импортират, експортират и присъединяват данни от няколко формата бази данни, електронни таблици и текстови файлове.

Access работи с:

- Файлове с бази от данни, създадени от dBase, Microsoft Exchange, Microsoft Outlook и Paradox

- С SQL (Structure Query Language) таблици, създадени от Microsoft FoxPro, Microsoft SQL Server и Oracle, като се използват ODBC (Open Database Connectivity) връзки.

- Със списъци на HTML, като може да експортира таблици и списъци за използване в Active Server Pages (ASP).

- Файлове на Microsoft Word във формат Rich Text Format (RTF).

- Файлове с електронни таблици, създадени на Excel и Lotus 1-2-3.

- Текстови файлове, създадени с текстообработващи програми, използвайки формата ASCII, MS-DOS и ANSI като полетата се отделят с разделители или с фиксирана дължина.

Промяна на данните с актуализиращи запитвания

Понякога се налага да се правят големи промени в данните, съхранявани в таблиците на базата от данни. Например, ако се прецени, че стипендиите на студентите от Стопанска академия трябва да бъдат увеличени с 10%, то може да се използват два подхода за тази актуализация. Първият се свежда до редактирането на всички данни запис по запис, което може да отнеме няколко дни


работно време, а другият – това да се извърши с една операция, за няколко секунди, посредством актуализиращо запитване.

Общо описание на актуализиращите запитвания С актуализиращите запитвания могат да се създават нови

таблици или да се актуализират данните в съществуващи таблици. Access предоставя няколко типа актуализиращи запитвания:

Make-table query – за създаване на нова таблица от една или

няколко таблици.

Delete query – за изтриване на записи от таблица или таблици.

Append query – за добавяне на група записи от една или

няколко таблици в друга таблица или таблици

Update query – за промяна на данните в група записи.

ODBC ВРЪЗКА

(Цитат - http://www-it.fmi.uni-sofia.bg/courses/wdb/db.ht m)

ODBC, съкращение от Open DataBase Connectivity (връзка между отворени бази данни). За ODCB може да се мисли, като за универсален конектор. Това е един от най-популярните интерфейси за бази данни на РС-съвместимите компютри и бавно завоюва позиции и на другите платформи. Ако искаме да дефинираме с едно изречение какво представлява ODBC, то ще е (Roberts, Helar, Earnest, 2000): “ODBC предоставя функции за операции над бази данни от език за програмиране включително добавяне, модифициране и изтриване на данни, намиране на различни параметри на базите данни, таблиците, виртуалните таблици и индексите.”


Всяко приложение, поддържащо ODBC, се състои от пет логически слоя:

• Приложение; • Интерфейс към ODBC; • Диспечер на драйверите; • Драйвер и източник на данни;

Слоят "приложение" осъществява потребителския интерфейс и изчислителната част на програмата и е написан на език като Java, Visual Basic или C++. Приложението използва функциите за работа с ODBC от интерфейса за ODBC. Диспечерът на драйверите е част от ODBC на Microsoft. Той управлява наличните драйвери зарежда необходимия драйвер, насочва извикванията към него, предоставя информация за драйвера на приложението. Тъй като една програма може да взаимодейства с база данни, диспечерът на драйверите се грижи всяка система за управление на база данни (СУБД) да получава съответстващите й извиквания и данните от базите да бъдат безпроблемно предавани на приложенията. Драйверът е компонент, който съответства на конкретната база данни, например драйвер за Access, за SQL Server или Oracle. В интерфейса към ODBC има набор от функции като SQL заявки, управление на свързването, запитвания за информация относно бази данни и др. Изпълнението им се осъществява именно от драйвера. За някои бази данни той трябва да симулира изпълнението на функции, които не се поддържат пряко от съответната СУБД. Всъщност работата на драйвера се състои в изпращането на заявки към базата, получаването на данни и препращането им към приложението. За бази данни в локални мрежи или Internet, драйверът управлява мрежовия обмен. В контекста на ODBC източникът на данни може да бъде СУБД или просто набор от файлове върху твърд диск.

Нива на съвместимост с ODBC

(Цитат - http://www-it.fmi.uni-sofia.bg/courses/wdb/db.ht m)

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


интерфейса. Вместо това са дефинирани нива на съвместимост с ODBC по отношение на програмния интерфейс и синтаксиса на SQL заявките. Единственото изискване е когато драйверът отговаря на някакво ниво на съвместимост да поддържа всички функции от това ниво, независимо от това дали те са включени в СУБД. Таблицата от Приложение А обобщава нивата на съвместимост за програмния интерфейс и SQL. Драйверът трябва да емулира ODBC функциите, които не се поддържат от използваната СУБД по такъв начин, че за интерфейса към ODBC реализацията на СУБД да няма значение. Приложенията използват функции от програмния интерфейс, като SQLGetFunctions и SQLGetInfo, за получаване на информация за поддържаните от драйвера функции.

За да може работната станция да се сдобие с такъв драйвер и информационната система да функционира задължително трябва да има инсталиран BASIS софтуер. Без този софтуер информационната система не може да изгради връзка със системата BASIS.


Глава шеста Схема на дейността на търговската компания CCHellenic

Трансфер заявки

Phoenix Сървър

Заявки към BASIS BASIS сървър

Трансфер на данни от BASIS към SAP/R3

Трансфер на данни от SAP/R3 към SAP/BW

Трансфер на данни от BASIS към DELORD

Трансфер на данни от DELORD към SAP/BW

Справки SAP/BW достъпни от HHT

1) Търговкият представител събира поръчки от пазара

5) Трансфер на данни от BASIS към SAP/R3

9)Обработка и трансфер на данните от инф. ситема DELORD

4)Поръчките се трансферират в BASIS чрез ОЕ60 файл.

2) Поръчките се въвеждат в мобилните устройства

8)Достъп на мобилни устройсвта към справки в SAP/BW

6) Трансфер на данни от SAP/R3 към SAP/BW

3) Поръчките се прехвърлят от HHT към Phoenix системата чрез GPRS


Описание на информационната система DELORD

Информационната система DELORD (съкращение от думите DELIVERY & ORDER) е изградена с цел да изтегля на ежедневно доставките и поръчките към “Кока–Кола Хеленик България” АД от системата BASIS. След като изтегли данните, информационната система DELORD обработва информацията във формат, които позволява зареждането и в система SAP Business Warehouse.

ФОРМА - MAIN FORM

Снимка 1

Формите предоставят редица предимства при работа с данните от базата данни. Възможно е едновременно показване в една форма на всички полета от един запис, както и показване на всички записи в една форма.

Формите в Access се използват за:

- представяне на данните в атрактивен формат със

специални шрифтове и други графични ефекти като цвят и сенки;


- представяне на данните във вид, близък до традиционните

хартиени форми с които са свикнали потребителите;

- пресмятане на общи стойности;

- показване на зависимостите по графичен начин;

- показване на данни от няколко таблици едновременно;

- автоматично изпълнение на зададени операции;

Цялата информация във формата се извежда в контроли (controls). Контролите са обекти на формата, чрез които се извеждат данните, задават се операции или се ползват за декориране на формата.

Някои от контролите са свързани с полета от таблица или запитване и така чрез тях може да се извеждат данните от таблицата или запитването, също така е възможно въвеждане и редактиране на данните.

Други контроли са само като допълнение към формата и подобряват нейния дизайн, такива контроли са линиите, правоъгълниците и други такива, които правят формата по-атрактивна.

Формата в информационната система “DELORD” служи за стартиране на свързани последователно помежду си заявки. В информационната система “DELORD” не може да се въвеждат изкуствено данни в таблици, след което да се обработват, а само се изтегля готова информация.

Програмата обработва несъответстващия формат данни от едната система към формата на другата, след което трансферира обработените данни до системата SAP Business Warehouse.


Полета и бутони в MAIN FORM на DELORD

- В полето FROM DATE се въвежда датата, от която сe изтеглят данните от системата BASIS. При отваряне на формата курсорът се намира в това поле. Полето е с формат YYYY.MM.DD. След като се натисне бутонът ENTER на клавиатурата или TAB, курсорът се премества на следващото поле TILL DATA.

- В полето TILL DATE се въвежда датата до която искаме да се изтеглят данните включително. Формата на полето е идентично на полето FROM DATE YYYY. MM.DD.

- В полето CHOOSE DATA e “combo box”, чрез което оператора на програмата има възможност да избере кои тип данни информационната система да обработи. Възможностите са две:

- FLATDEL - ежедневни доставки;

- FLATORDER - ежедневни поръчки;

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


- Бутонът Export from BASIS стартира последователно свързаните помежду си заявки, с които се изтеглят данните от системата “BASIS”. Информацията се обработва и записва в точно определена таблица, от която след направената проверка се трансферира в SAP/BW.

- Бутонът EXPORT CSV изпълнява функцията само за трансферирането на данните към системата SAP/BW чрез ODBC връзка, от предварително направени таблици.

- CHECK бутонът стартира заявки, които проверяват изтеглените данни от системата BASIS. Ако открие грешка в данните се създават таблици, в които се отбелязват грешните полета.

- EXIT бутонът служи за излизане и затваряне на информационната система.


ЗАЯВКИ (QUERIES) в DELORD

Снимка 2

PASS_FLATDEL_REAL – представлява “Pass Through” заявка, чрез която SQL код генерира и изпраща оператори към BASIS сървърът чрез ODBC връзка. Под строго специфични критерии се изтеглят данните за всички дневни доставки. След изтегляне на данните Append Query ги обработва и ги изпраща към точно определена таблица в информационната система.


- PASS_FLATORDER_REAL – представлява заявка, идентична на PASS_FLATDEL_REAL, генерираща друг SQL код към други полета и библиотеки в системата BASIS отново чрез зададена на компютъра ODBC връзка. След изтегляне на данните “APPEND Query” ги обработва и ги прехвърля към точно определена таблица в системата DELORD.

Идеята на тези заявки е да се достъпи по възможно най-бързия начин системата BASIS, с което да се гарантира и изтеглянето на данните за най–кратък период от време. По този начин служителят, които оперира с информационната система няма да отделя много от работното си време за тази дейност.

Представлява заявка, която добавя и обработва данните от заявката PASS_FLATDEL_REAL, като променя формата на полето “Дата”. Например формата на датата в системата BASIS e “1080622”/ YYY. MM.DD. За да е възможно зареждането на данните в системата SAP Business Warehouse формата на информацията намираща се в полето “Дата” трябва да е “20080622”/YYYY.MM.DD. Чрез тази заявка се изчистват всички видове различия в типа и формата на данните. След отстраняването на различията данните се записват в таблица, на която предварително са дефинирани полета. По този начин не се позволява записването на некоректни записи.

По аналогичен начин както в “APPEND_FLATDEL_REAL” заявка добавя и обработва данните от заявката PASS_FLAORDER_REAL и ги прехвърля в таблица, от която данните вече се зареждат в CSV файл в системата SAP Business Warehouse.

Чрез append запитване е възможно да се добавят записи от

една таблица в друга съществуваща таблица. Възможно е да се добавят записи към таблица от същата или друга база от данни.


За изтриването на записи от таблица се създава т.нар. Delete Query. Чрез запитване от този вид се отстраняват цели записи.

Обикновено се отстраняват записи само от една таблица. Когато в таблиците съществуват дефинирани правила за цялостност има известни особености при ползването на този вид запитвания.

Чрез тези две заявки се изтриват записите в таблиците “FLATDEL” и “FLATORD” на информационната система, с което не се допуска презареждане на вече налични данни в системата SAP Business Warehouse.

Посредством make-table query се създава нова таблица, като в

нея се включват записи или части от записите от изходната таблица (таблици). Този вид запитване се ползва най-често при:

- Създаване на отчет, ползващ данни към определен период от време;

- Създаване на резервно копие на таблица; създаване на таблица съдържаща стари записи (history table);

- Разработване на варианти на форми и отчети, базирани на много таблични запитвания и др.

С тези две заявки се цели проверка на акуратността на данните, които да предотвратят грешки при зарежданията в SAP BW. По този начин се спестяват доста усилия и нерви при изтриване на грешни зареждания от информационната система “DELORD”.


ТАБЛИЦИ (TABLES) в DELORD

Снимка 3

Таблиците в информационната система “DELORD” представляват склад, който е последна спирка на данните преди те да бъдат прехвърлени в SAP BW системата. Единственият начин да не може да се запишат данни в таблицата е тя да не е част от зададените колони в полета. По време на зареждане на историческите данни установих, че капацитета на записите, които може да побере дадена таблица е около 4 000 000 записа. Естествено изключително трудно е да се направи корекция на данните даже това е почти невъзможно.


Полета в таблиците FLATDEL и FLATORDER

ТАБЛИЦА FLATDEL

Таблица FLATORDER.


Модул в информационната система „DELORD”

Съставянето на модул в информационната система “DELORD” се наложи поради невъзможността да се изгради в заявка “Pass Through” параметър, който да задава интервал от време на данните от системата “BASIS”. В следствие на този проблем се наложи да се напише код на MySQL чрез който да се въведе в модула самата заявка, към нея да се прикрепи код, който да указва към кое поле във формата се отнася този параметър. На това място се задава интервал от време, за който ще се изтеглят данни от системата “BASIS”.

Екран на модула в информационната система

“DELORD”


Глава седма

Проблеми при разработката на информационната

система “DELORD”

Проблемите при разработването на информационната система “DELORD” бяха доста поради определените условия, които трябва да изпълнява:

- Да работи бързо, с което да не забавя процеса на работа на служителя опериращ с нея.

- Да бъде лесно достъпна и работата с нея да не представлява трудност.

- Да не коства голям ресурс на компанията като хора и средства за постигането на желаният краен резултат.

Комуникационен проблем

Първият проблем, с които се сблъсках при разработването на информационната система беше с връзката, която CCHellenic България има до основния си информационен център в град Виена.

Мрежовата линия, по която се прехвърля потокът от данни е оптична с капацитет 5Mbps.Скоростта на мрежата е достатъчна за да може информационната система "DELORD" да изпълнява функцията си. Но оптичната мрежова линия на “Кока–Кола Хеленик Ботълинг Къмпани България” АД е с много специфична приоритизация. На първо място основните системи на които се крепи компанията SAP/R3 и BASIS използват най–голям капацитет от скоростта на връзката, след това са другите системи Phoenix и SAP Business Warehouse, след тях следват системи за комуникация по електронен път e-mail и т.н. докато стигнем до Microsoft Access на които в крайна сметка е отделен много малък капацитет от оптичната линия.


Така се появиха първите проблеми по-време на тестовете на програмата. Първоначално програмата нямаше проблем да изтегля данните за определен период от време (например един месец). Операцията отнемаше около един час за обработка на данните и записването им в таблица намираща се в информационната система. Обаче следваше процедурата по прехвърляне на csv файла обратно до системата SAP Business Warehouse в Австрия. За съжаление този процес протичаше прекалено бавно и така се затрудняваше значително работата на служителите на компанията. След проведените тестове и консултации с колегите от отдел “Инфраструктура и мрежи” установих, че информационната система “DELORD” не може да бъде алокирана на локална машина в офиса на “Кока–Кола Хеленик” в България. Единственото решение на проблема беше самата информационна система да се прехвърли по мрежата във Виена и да се запише на сървърна машина.

С което се решават и следните проблеми:

- Проблемът с комуникацията;

- Процедурата по изпълнение на операцията за изтегляне, обработване и прехвърляне на данни от системата BASIS в системата SAP Business Warehouse се подобри значително, отколкото, ако информационната система се намира в България на локален компютър;

Причината за намаляване на времето за изпълнение на процедурата се дължи не на по-мощната сървърна машина, а на това, че се избягва използване на мрежовата оптичната линия изградена между България и Австрия.

След направените промени комуникационният проблем на информационната система “DELORD” беше отстранен.


Проблем при разработването на

информационната система “DELORD”

Вторият проблем, с които се сблъсках беше при самото разработване на информационната система. Той се дължи на факта, че самото изтегляне на данни беше съставено по доста различен начин от крайния вариант.

Идеята на разработката беше чрез добавени таблици от BASIS (които виждате на снимка3 страница 40) ·да са източникът, от който ще се изтеглят данните. Критерият за изтегляне на данните е зададен от заявки. Техническото изпълнение не беше трудно, всичко вървеше добре, докато не се стигна до теста за изтегляне на данните.

Система BASIS се нуждае от време да намери данните в библиотеките, от които трябва да бъдат изтеглени и записани в информационната система “DELORD”. Библиотеките с данните са огромни, като тази операция отнемаше прекалено много време и ODBC връзката прекъсваше. Колкото и да увеличавах диапазона на ODBC връзката на заявките, проблемът не се отстрани. Информационната система винаги показваше едно и също съобщение, което гласеше, че ODBC връзката се е разпаднала.

Единственото решение на проблема беше да започна отначало с разработка на друго решение за изтегляне на данните от системата BASIS.


Проблем при задаване на интервал от време

за изтегляне на данните

Третият и най–голям проблем, с който се сблъсках беше със задаването на интервал от време за изтегляне на данните от системата BASIS. Изтеглянето, обработването и прехвърлянето на данните беше перфектно. Скоростта за изпълнениото на задачата от информационната система “DELORD” беше доста добро и не се забавяше работата на служителите. Единственият проблем беше как заявката изтегляйки данните да определи точно за кой ден или месец да e информацията. На този етап не можех да открия начин как Pass Through заявката да изпълни подобна операция.

Решението на проблема не съм го измислил сам. След много търсене и четене в интернет пространството и в най–различни международни форуми видях колега, който е имал същия проблем, но го е решил като е създал модул, който имитира чрез поле във формата работата на заявката, която изтегля данните от системата BASIS, но с една малка подробност. Чрез предоставената ми възможност от Visual Basic модула в Microsoft Access създадох копие на заявката, която изтегля данните от първоизточника, но на полето е добавена препратка към параметър отговарящ за полето дата на информационната система. Стойността на този параметър се записва във формат, отговарящ на формата на системата BASIS. С това проблемът за филтрирането на данните беше решен.

MySQL код за определяне на интервал от време в Pass Through заявка:

MySQL = MySQL & "AND ((TX10.TX10_delDAT) >= " & Str([Forms]![MainForm]![Date_From] - 19000000) & ") " & vbNewLine

MySQL = MySQL & "AND ((TX10.TX10_delDAT) <= " & Str([Forms]![MainForm]![Date_Till] - 19000000) & ") " & vbNewLine


Блок схемата (страница 47) описва обработката на заявките по време на работния ден. Ясно се вижда, че задаването на времеви интервал е основна функционалност, която трябва да бъде налична в информационната система “DELORD”. Причината за това изискване е, че данните които зареждат не са от актуалния работен ден.

Проектът нямаше да е успешен, ако отсъстваше функционалността за определяне на интервал от време на данните в информационната система. На ръководителите на предприятието нямаше да им се предоставят актуални справки, с които да анализират състояниято на пазара в страната.

Първоначално имаше идея да се заобиколи този проблем като се предприемат няколко извършвания на процедурата за изтегляне на данните от BASIS по време на работния ден. Този подход се оказа грешен, защото целият процес отнема човешки ресурси, които предприятието не може да отдели. Акуратността на данните не можеше да се гарантира. От Блок Схемата (стр. 47) ясно се вижда, че обработката на данните продължава доста след приключване на работния ден.

Зареждането на данните е в 13:00 часа. Причината поради, която се избра точно този период от работния ден е заради ненатовареността на системата. При ненатоварена система се намалява рискът от ненужно забавяне на работата на служителите. Също така се намалява и рискът натоварването на системите да усложни зареждането на данните в информационния куб на SAP BW.

За да се избегнат подобни проблеми служителят, който зарежда данните проверява до каква степен са натоварени системите. След като се увери, че системите не са натоварени и операцията, която ще извърши няма да наруши или забави работата на останалите служители от компанията пристъпва към действие.


ЗАКЛЮЧЕНИЕ

Настоящата информационна система обезпечева поставените от мен приоритетни моменти, изразяващи необходимостта от създаването й, като по време на разработка и се премина през следните етапи:

• Анализ на предметната област, който обхваща всички особенности и изисквания на информационните системи в CCHellenic България АД. Изследване и изучаване на особенностите на данните свързани с Търговския отдел и Отдел Дистрибуция.

• Проектиране – релационни бази данни, определяне на таблиците – полета и особенности, модел на данните – логически и физически.

• Реализация – определяне на формите – описание, извършвани действия и тяхната последователност, код за осъществяване, основни функции на системата; изходяща информация.

При разработването на настоящата информационна система бяха съблюдавани всички значими моменти от дейността на дружеството, като бе извършено допитване и задълбочено проучване във всеки един отдел, имащ пряко отношение с обработката на информационните потоци описани подробно в съответните глави от дипломната ми работа. Обърнато бе внимание на всеки един фактор, затрудняващ ефективността при трансфера и обработката на данни, като бе избран оптимален вариант, отчитащ фактора “качество – време”. Системата е реализирана така, че да бъде лесно разширяема и адаптируема съобразно нови изисквания и допълнения. Независимо от множеството срещнати трудности при разработването и реализирането на информационната система, считам, че тя удовлетворява поставените цели.


Използвани материали и литература:

- BW 305 Business Information Warehouse – Report &Analysis, my SAP Business Intelligence Participant Handbook – copyright 2003 SAP AG

- BASIS PTF 52.3 Documentation – Coca Cola Computer Services G.m.b.H , Austria, Vienna

- http://www-it.fmi.uni-sofia.bg/courses/wdb/db.htm

- http://www.feb.uni-sofia.bg./FEBA/

- http://www.sap.com

- http://www.coca–cola.bg

ИНФОРМАЦИОНН a СИСТЕМА ЗА ТРАНСФЕР И …infdep.nbu.bg/11/1/diplomna...

Documents