Универзитет “св. Климент Охридски” БитолаЕкономски факултет – Прилеп

Статистичко кибернетска насока

Предмет: Деловна информатика

AНАЛИЗА И ДИЗАЈН НА БАЗИ НА ПОДАТОЦИ ВО ФУНКЦИЈА НА ЕФИКАСНИ БИЗНИС ПРОЦЕСИ

ДИПЛОМСКА РАБОТА

Ментор: Кандидат:

Проф. Д-р. Коста Сотироски Владимир Бојовски

ПРИЛЕП, 2014Содржина:DR@INA

СОДРЖИНА 2ВОВЕД 31. БАЗА НА ПОДАТОЦИ 8

1.1. Видови бази на податоци 81.1.1. Хиерархиски бази на податоци 91.1.2. Мрежни бази на податоци 111.1.3. Релациски бази на податоци 131.1.4. Објектно ориентирани бази на податоци 171.1.5. Објектно релациски бази на податоци 18

1.2. Организација и обработка на податоци 202. АНАЛИЗА И ДИЗАЈН НА БАЗИ НА ПОДАТОЦИ 23

2.1. Животен циклус на база на податоци 242.2. Архитектура на база на податоци 252.3. Дизајн на база на податоци 272.4. Моделирање на податоци 29

2.4.1. E-R модел на податоци (E-R дијаграм) 302.4.2. Постапка за креирање релациска база на податоци 36

3. СИСТЕМИ ЗА УПРАВУВАЊЕ СО БАЗА НА ПОДАТОЦИ (DBMS) 443.1. Microsoft Access 46

3.1.1. Креирање релациска база на податоци во Microsoft® Accessтм 2013 46ЗАКЛУЧОК 72КОРИСТЕНА ЛИТЕРАТУРА 73

2

ВОВЕД

Во тешки економски моменти или понекогаш и во подолги периоди, кога деловните субјекти се соочуваат со недостиг од финансиски средства, истите бараат начини сите процеси од нивното работење да ги направат поефкасни. Исто се случува и во економски погодни периоди, кога парите се подостапни и кога компаниите не се соочуваат со финансиски проблеми, во такви услови тие бараат начини како да го подобрат работењето и да го зголемат производството, а со цел да ги подобрат производите и услугите во надеж дека со тоа ќе привлечат повеќе корисници. Сите тие задачи и активности кои се извршуваат во деловните организации, а во насока на производство на одреден производ или услуга кој е наменет за одредени потрошувачи, претставува Бизнис процес. Секоја компанија, односно секоја деловна организација претставува збир од бизнис процеси кои се извршуваат низ повеќето функционални организациони единици на тој деловен субјект односно деловна организација. Како функционални единици кои најчесто се јавуваат во компаниите, можат да се споменат: сметководство, маркетинг, производство, човекови ресурси, истражување и развој, а може да има и други, во зависност од големината на организацијата, како и од типот на производите и услугите кои ги нуди истата. Покрај одделните организациони единици, во некои бизнис процеси можат да бидат вклучени и надворешни субјекти кои се директно поврзани со деловната организација, односно со нејзиното работење (партнери, добавувачи, купувачи, корисници). Додека, како извршители на разните бизнис процеси се јавуваат вработените од различни нивоа на организационата структура во компанијата, од извршните работници кои се директно вклучени во производството на производите и услугите, потоа менаџерите на различни нивоа, па се до врвниот менаџмент.

Сите учесници во бизнис процесите, имаат потреба од различни видови податоци и информации за деловното работење на компанијата. Некои од учесниците имаат потреба од поопшти податоци, некои имаат потреба од подетални податоци и информации, некои за тековното работење, некои за севкупното работење, но каква и

3

да е природата на потребните податоци и информации, истите треба да се обезбедат и да им се достават на располагање на содветните учесници, а се со цел да им се даде поддршка за донесување на релевантни деловни одлуки, избор на вистинските деловни решенија, преземање на соодветни деловни акции, или поедноставно кажано, за ефикасно спроведување на соодветните бизнис процеси.

Од предходно изнесеното, може да заклучиме дека податоците претставуваат едни од најзначајните ресурси на деловните субјекти. Без поседување на точни, релевантни и сигурни податоци како и точни и навремени информации за целокупното деловно работење на компанијата, за работењето на конкурентските компании, за економските случувања и појави во окружувањето, за светските економски движења, не можат да бидат донесени релевантни одлуки како и да биде направен вистинскиот избор на решенија, за успешно организирање и спроведување на бизнис процесите, односно неможе да се обезбеди успешно функционирање на компанијата.

Податоците во нивната изворна форма не се секогаш многу корисни и делотворни и не се погодно средство кое може да даде придонес во донесувањето на релевантни решенија и деловни одлуки, а со тоа да помогне во ефикасно спроведување на деловните процеси. Податоците, пред да бидат употребени од страна на одделните деловни функции, одделните служби, органи на управување и менаџери од различни нивоа во компанијата, истите мора да се обработат со цел да се доведат во форма која ќе биде соодветна на нивните потреби.

Денес сите операции со податоците, нивната обработка и манипулации се целосно автоматизирани, а посебно последниве години или поточно последнава деценија кога се случува еден од најважните настани во историјата на човештвото, познат како информациска револуција. Компјутерите, односно компјутерските системи и компјутерските мрежи стануваат или веќе се составен дел на деловните активности на сите деловни организации, па дури и на најмалите. Сета таа информациска технологија, сите тие компјутери и компјутерски системи овозможуваат олеснување на решавањето на деловните проблеми, зголемувањето на продуктивноста во работењето како и подобрување на квалитетот на производите и услугите. Па така и обработката на податоците во деловните организации веќе целосно се извршува со помош на компјутерите. Мноштвото операции кои се извршуваат над податоците во компјутерските системи, а со цел да се произведат информации се нарекува „циклус на обработка на податоците“ и истиот се состои од четири компоненти: внесување на податоци, складирање на податоци, обработка на податоци и излез на информации. Во целиот тој циклус на обработка на податоците, значајна улога имаат и крајните корисници на тие податоци, односно корисници на информациите кои ќе се произведат на крајот од циклусот на обработка. Крајните корисници се тие кои треба да посочат кои податоци треба да бидат внесени во системот, како да бидат организирани, ажурирани, складирани и каков да биде пристапот до нив.

При внесување на податоците во системот, истите се обележуваат со посебни обележја со цел да се олесни нивната подоцнежна обработка. Обработката на податоците може да се извршува во вид на „сериска обработка“ (се собираат поголема количина на податоци, па сите се обработуваат одеднаш) или обработката се врши во реално време. На крајот на циклусот на обработка на податоците, односно последна компонента на тој циклус е прикажувањето на излезните информации. Во текот на

4

извршувањето на сите три предходно наведени операции (внес, обработка и излез), податоците мора да бидат некаде складирани и тоа складирање мора да има одредена форма на организација на податоците. При складирање на податоците може да се користи моделот на датотеки, што претставува најстара форма на складирање на податоци или моделот на база на податоци.

При користењето на системите на датотеки се јавуваат доста проблеми околу дуплирањето на податоците, оваа појава на дуплирање на податоците е уште позната и како Редунданса или редунданост на податоците, односно еден ист податок може да се појави во повеќе датотеки. Тоа од своја страна предизвикува дуплирање и на активностите како што се влез и одржување на податоците. Потоа, при корекција на еден податок во една датотека истиот тој податок во друга датотека останува непроменет, што предизвикува неконзистентност на податоците, па доколку се работи за системи за обработка кои се заснивани на компјутерски системи со ограничени мемориски ресурси, се појавуваат проблеми со недостиг на меморија, бидејќи дуплирањето на податоците непотребно двојно го зголемува искористувањето на слободниот мемориски простор. Поради овие причини пристапено е кон промена на ваквите системи базирани на користење на датотеки со нова форма на складирање и организација на податоците позната како База на податоци (анг: Database).

База на податоци, според општо прифатена дефиниција од повеќе автори кои ја обработуваат оваа проблематика, претставува „колекција од поврзани податоци“. Базите на податоци првпат се појавиле во шеесеттите години од минатиот век и истите биле креирани со цел да ги решат проблемите на традиционалната „автоматска обработка на податоци“, односно на системите кои биле базирани на користење датотеки. Базите на податоци имаат многу предности во однос на системите на датотеки. Со користење на базите на податоци како форма на организирање и чување на податоците се обезбедува: конзистентност на податоците, интегритет на податоците, флексибилност, независност како и отстранување на редунданоста на податоците. Целта на користењето на базите на податоци е трансформирањето на податоците во корисни информации. Колку и како ќе може да се искористи базата на податоци зависи од тоа како е истата физички и логички структурирана. Кога зборуваме за физичкото организирање на базата, се мисли на конкретното физичко сместување на податоците. Кога зборуваме за логичкотото структурирање на базата се мисли на концептуалниот аспект на организирање на различните модели на податоците и врските помеѓу нив. Од тој аспект постојат три основни модели за логичко структурирање на базите на податоци: хиерархиски, мрежни и релациони бази на податоци.

Без ралика за кој модел на бази на податоци станува збор, базата на податоци секогаш претставува колекција од меѓусебно поврзани податоци и целта на нивното користење секогаш е иста, а тоа е: да се обезбедат релевантни делотворни информации кои се потребни во управувањето и раководењето на организациите, односно нивните бизнис процеси, а се со цел остварување поголем профит. Со цел базата на податоци да може да ги оствари целите за кои е создадена, потребно е при нејзиното конструирање, имплементирање или измена доколку се работи за веќе имплементирана база на податоци, да се запазат одредени правила и постапки. Во праксата има бројни примери кога поради погрешно водената постапка за имплементирање на нова технологија не се добиваат очекуваните деловни резултати. Токму ова укажува на потребата од примена

5

на посебна методологија при планирање, имплементација и одржување на базите на податоци, која е позната како Анализа и дизајн на бази на податоци. Со ваквата методологија, постапката на имплементирање на база на податоци во некоја деловна организација временски го опфаќа животниот век на базата на податоци и од тој аспект да се подели во следните неколку фази: анализа на потребите, моделирање на податоците, креирање на физичкиот и логичкиот дизајн на базата на податоци, имплементација, тестирање и одржување на базата на податоци. Само на овој начин конструирана и имплементирана база на податоци може да придонесе за ефикасно спроведување на сите бизнис процеси во деловните организации.

Во текот на деловното работење на компаниите, базите на податоци постојано се дополнуваат со нови податоци. Како што расте бројот на активности кои се извршуваат во деловните процеси така расте и базата на податоци. Кога базата на податоци ќе стане толку голема и сложена што веќе нема можност едноставно да се контролира текот и развојот на податоците, потребно е да се прејде на повисоко ниво на организација на податоците, односно потребно е воведување на систем за управување со базата на податоци. Денес, во време на револуционерен развој на информатичката технологија, базите на податоци се засновани на компјутерската технологија. Многу често се мешаат, односно се изедначуваат поимите база на податоци и систем за управување со базата на податоци иако се работи за два различни поими. Поимот „база на податоци“ се однесува строго на колекцијата на податоци, а софтверот односно програмата која ги контролира и управува податоците и врските помеѓу податоците и апликативните програми, претставува „систем за управување со базата на податоци“ (анг: DBMS, “DataBase Manaдement System”).

Системот за управување со базата на податоци ја обликува физичката структура на базата во согласност со бараната логичка структура, ги извршува сите операции со податоците во име на корисникот, а исто така се грижи за сигурноста на податоците и ги автоматизира сите работи околку одржувањето на базата на податоци. Податоците во базата се логички организирани во согласност со моделот на соодветните податоци. Моделот на податоци претставува збир од правила кои одредуваат како може да изгледа логичката структура на базата на податоци, односно го одредуваат моделот на базата на податоци. Најприфатен и најкористен модел на бази на податоци е релацискиот модел, кој е заснован на концептот на дводимензионални табели. Овој модел претставува многу флексибилен модел на база на податоци во кој не постои хиерархија на логичката организација на податоците, туку податоците се наоѓаат распоредени во повеќе табели. Главна предност на овој модел е неговата едноставност.Системите за управување со релациските бази на податоци се поддржани од повеќе софтверски пакети, од кои може да се издвојат следните: Microsoft Access, Oracle, Microsoft SQL Server, MySQL и други. Добро организиран систем за управување со базата на податоци ќе овозможи да се обезбеди и софтвер кој ќе му овозможи на корисникот лесно да комуницира со базата на податоци. Полесното комуницирање со базата на податоци ќе значи добивање на поточни, понавремени и порелевантни информации кои им се потребни на учесниците во деловните процеси, а тоа од своја страна ќе значи ефикасно извршување на бизнис процесите и остварување на целта на деловниот субјект, односно компанијата.

6

Во овој труд е прикажано значењето на базите на податоци во насока на ефикасно извршување на бизнис процесите. Најпрво се прикажани моделите на бази на податоци, редоследно според хиерархијата на развојот, со посебен акцент на релацискиот модел како најкористен модел во праксата. Потоа е прикажана организацијата на базата на податоци, односно организацијата и моделите на податоците во базата. Тука е прикажана и архитектурата, како и методологијата на креирање и одржување на базата на податоци со цел истата да биде погодно средство кое ќе ги обезбеди потребните релевантни податоци и информации кои се потребни за успешно организирање и реализирање на ефикасни бизнис процеси. На крајот, теоретски е објаснет еден систем за управување со бази на податоци (Microsoft®

Accessтм 2013), кој претставува еден од најсовремените софтверски решенија од таа област и во прилог на тоа објаснување, даден е конкретен пример на релациска база на податоци, со цел посликовито да се објаснат погодностите кои се кријат во нејзиното користење.

7

1. БАЗИ НА ПОДАТОЦИ

Што е база на податоци? База на податоци претставува организирана колекција од поврзани податоци кои се користат при организирање на секојдневното деловно работење. Без разлика дали се користи хартија или некоја компјутерска софтверска програма, се додека се собираат податоци на организиран начин и истите се чуваат во организирана форма за посебна намена, станува збор за база на податоци. Целта на користењето на базите на податоци е интегрирање на индивидуалните податоци, односно трансформирање на податоците или изолираните факти во информации. Кога податоците ќе бидат зачувани во базата на податоци, би требало да биде лесно од нив да се извлече информација, користејќи одредени критериуми за пребарување. Колку ќе биде лесно тоа пребарување и добивање на информации зависи од начинот на кој податоците во базата се сместени и организирани. И не само за пребарувањето, туку базата треба да биде така организирана, да биде лесен и начинот на внесување, исправка и бришење на податоци. Колку и како ќе може да се користи базата на податоци зависи од моделот на нејзината логичка и физичка организираност. Податоците во базата се организирани во зависност од нивниот модел, а со цел да се олесни и да се направи поефикасен начинот на пребарување и промена на податоците. Моделот на податоци претставува збир на правила кои одредуваат како ќе изгледа логичката структура на базата на податоци. Моделот на податоците ја претставува основата за конципирање, креирање и имплементација на базата на податоци.

1.1. Видови на бази на податоци

8

Кога првпат се појавиле базите на податоци, истите биле креирани со цел да ги решат проблемите на предходните системи за обработка на податоци, односно на системите кои биле базирани на користење датотеки. Системите на бази на податоци имаат доста предности во однос на системите засновани на датотеки, тие пред се обезбедуваат: конзистентност на податоците, интегритет на податоците, флексибилност за известување, независност меѓу податоците и апликативните програми, заедничка поделба на податоци и информации, заштита и безбедност на податоците, централно управување со податоците како и отстранување на редунданоста на податоците.

Во зависност од моделот и структурата на податоците, операциите над податоците и ограничувања, се разликуваат следните видови бази на податоци: хиерархиски, мрежни, релациски, објектно ориентирани и објектно релациски бази на податоци.

Процесот на развој на системите за чување и обработка на податоци, хронолошки е прикажан на слика 1.1.

2000

1990

1980

1970

1960

1950

Пред 1950

Систем на датотеки

Хиерархиски бази на податоци

Мрежни бази на податоци

Релациски бази на податоци

Објектнo-ориентирани бази на податоци

Објектно-релациски бази на податоци

Слика 1.1. Хронолошки развој на базите на податоци

1.1.1. Хиерархиски бази на податоци

9

Хиерархискиот модел е првиот модел на база на податоци од компанијата IBM, првпат преставен во 1960 година. Хиерархиските бази на податоци се генерално многу големи бази со многу голема количина на податоци. Хиераркиските бази на податоци се релативно лесни за разбирање, пред се поради фактот што секојдневно, во многу области во општеството се среќаваме со некаква хиерархија. Доколку станува збор за деловното работење, неизбежно е да се споменат: извршни директори, менаџери, супервизори, извршни работници, односно сите учесници во деловните процеси и сите тие хиерархиски подредени според степенот на одлучување.

Кога зборуваме за база на податоци, хиерархијата во основа претставува метод на организирање на податоците во рангови или нивоа, каде секој ранг има предност над тој под него. Хиерархијата може да се замисли во вид на стебло, или поточно превртено стебло.

Хиерархијата претставува уредување на одредени објекти кои се нарекуваат „полиња“, а во кои се сместени одредени податоци, а таквите полиња се поврзани со линии или “гранки“. Тие линии или гранки претставуваат врска или конекција со следното повисоко ниво или ранг каде се сместени посложени информации. Полето на највисокото ниво се нарекува “корен“ на стеблото на хиерархијата или главно поле во базата на податоци. Полињата во хиерархиската база на податоци се меѓусебно поврзани во релација „родител-дете“, каде полето „родител“ е веднаш над полето „дете“. Повразаноста помеѓу полињата родители и полињата деца се воспоставува со врски кои се нарекуваат „покажувачи“. На слика 1.2. е претставено хиерархиско стебло на база на податоци на замислена продавница.

Слика 1.2. Хиерархиска база на податоци.

10

Продавница

Купувач Продавач

Пијалоци Храна Постојани СезонскиДруги намирници

Алкохол Сокови

Во нашиот пример претставен на Слика 1.2., полето „Продавница“, претставува корен на стеблото, односно претставува главно поле во базата на податоци. Секое поле, освен главното поле, поврзано е нагоре само со едно поле „родител“, а секое поле „родител“ може да биде поврзано надолу со повеќе полиња „деца“. Во нашиот случај, полето „Купувач“ е родител на полето „Пијалоци“, а бидејќи полето „дете“ секогаш е едно ниво директно под неговото поле „родител“, полето „Пијалоци“ е дете на полето „Купувач“.

Во хиерархискиот модел на база на податоци, релацијата родител-дете обезбедува системски пристап кон податоците. За да се пристапи кон некое поле, треба да се тргне со пребарување од почетното поле (корен, односно главно поле), да се продолжи кон соодветното поле дете од следното ниво, и така натаму, се додека не се стигне до бараното поле. Од ова може да се заклучи дека проблем кај овој систем е тоа што корисникот мора да ја знае структурата на стеблото за да може да најде каков било податок. Пребарувањето ќе биде олеснето само доколку бараниот податок се наоѓа во главното поле, кое нема свое поле родител и во тој случај не е воопшто потребно да се знае структурата на стеблото.

Моделот на хиерархиската база на податоци има одредени негативности кои произлегуваат пред се од строгите правила на врските. На пример, не може да се додаде запис во поле-дете се додека тоа не е поврзано со поле-родител. За илустрација, во нашиот пример, не може да се додаде Пијалок што не го купува ниту еден Купувач. Исто така во хиерархискиот модел на база на податоци, постои редунданост на податоците, а тоа се јавува бидејќи хиерархиската база на податоци работи само со релации еден наспроти многу, но не и со многу наспроти многу. Во погорниот пример, ако еден Пијалок е купуван од повеќе Купувачи, ќе се јави повторување на податоци, бидејќи податоците за ист Пијалок ќе бидат вклучени кај повеќе Купувачи. Во многу случаи се јавува потреба едно поле-дете да биде поврзано со повеќе полиња родители. На пример, природата на релацијата помеѓу полињата Купувач и Пијалок е многу наспроти многу. Тоа значи, дека еден Пијалок го купуваат повеќе Купувачи, но и еден Купувач купува повеќе Пијалоци. Друг проблем кај хиерархиската база на податоци може да се јави доколку се избрише едно поле родител. Во тој случај се бришат и сите негови полиња деца, односно се брише целото стебло под избришаното поле.

Главните предности на хиерархискиот модел на база на податоци се состојат во следното: работи со големата база на податоци, претставува проверена технологија која се користела долги години, лесно користење и разбирливост на хиерархијата односно структурата на стебло, како и брзината на системот.

1.1.2. Мрежни бази на податоци

11

Мрежниот модел на бази на податоци претставува продолжение или проширување на хиерархискиот модел. Овој модел обезбедувајќи повеќекратни релации родител-дете помеѓу полињата со податоци, а со цел да се реши проблемот со дуплирање на податоците кој е еден од најголемите проблеми на хиерархискиот модел.

Еден од недостатоците на хиерархискиот модел на база на податоци беше тоа дека едно поле-дете може да има еден и само еден родител, а како резултат на тоа при креирање на посложени релации се појавува дуплирање на полињата или табелите со податоци, односно редундација на податоците. На пример, доколку имплементираме евиденција на производите во една продавница, ќе ни треба најмалку три релации родител-дете за еден ист тип на производи, како што е прикажано на слика 1.3.

Слика 1.3. База на податоци во која се потребни повеќекратни врски родител-дете

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

Доколку во овој пример, за организација на податоците го искористиме хиерархискиот модел на база на податоци, во тој случај ќе треба да направиме три полиња „Производи“, по едно за секое од полињата-родител за секој производ. Таквите дуплирани полиња зафаќаат дополнителен простор од меморијата и го успоруваат процесот на обработка и пребарување. Во наведениот пример, со трите релации кон полето Производи, секој нов евидентиран производ мора да се внесе во сите три полиња-родител. Спротивно, на ова доколку користиме модел на база на податоци која дозволува секое поле-дете да има повеќе од еден родител, секој нов производ ќе може да се внесе само еднаш во соодветното поле и на тој начин да се реши проблемот на редунданост на податоците. Од ова, може да се заклучи дека мрежниот модел на база

12

Купувач

Производи

Продавач Добавувач

на податоци, како и претходниот модел има хиерархиска организација на полиња, со таа разлика што секое поле-дете може да има повеќе од едно поле-родител. Оваа релација се опишува како релација „повеќе кон повеќе“, а поврзаноста на полињата се остварува преку врски кои се нарекуваат покажувачи (pointers).

За да овозможи полињата-деца да имаат повеќе од еден родител, а со тоа да го реши проблемот со дуплирање на податоците, мрежниот модел на база на податоци го користи концептот на претставување на релациите во облик на множества.

Користејќи го мрежниот модел на база на податоци, базата на податоци која беше претставена на слика 1.3., можеме да ја претставиме со следната слика 1.4.

Слика 1.4. Мрежен модел на база на податоци

Иако мрежниот модел на база на податоци претставувал значително подобрување во однос на хиерархискиот модел, сепак бил далеку од совршен. Ваквиот модел на база на податоци бил тежок и многу комплициран за имплементирање и одржување, а тоа значело дека со нив можеле да работат и управуваат само професионални информатичари. Голем недостаток на мрежниот модел претставува потребата за однапред дефинирање на сите врски и полиња со податоци.

Како главна предност на овој модел на база на податоци се смета брзината, односно пократкото време кое е потребно при внесување и бришење на податоци, а пред се поради отстранувањето на дуплирањето на полињата со податоците.

1.1.3. Релациски бази на податоци

13

Купувач 1

Добавувач 2

Добавувач 1

Продавач 2

Продавач 1

Купувач 2

Пијалоци 1

Пијалоци 2

Храна 1

Храна 2

Средства за хигиена

1

Средства за хигиена

2

Множество производи

Релацискиот модел на база на податоци е најпопуларниот модел на база наподатоци кој се користи денеска. Овој модел претставува значително подобрување на предходните модели на бази на податоци и тоа пред се, од аспект на поедноставување на организирањето на податоците, пребарувањето на податоците, како и додавањето и бришењето на податоците од базата.

Релацискиот модел на база на податоци бил развиен во осумдесеттите години од минатиот век од страна на E.F. Codd, вработен во компанијата IBM, а со цел да ги реши проблемите на дотогаш постоечките модели. Релацискиот модел бил изграден врз математички концепти и во неговата основа е концептот на табела.

Основната единица за складирање на податоци во релациската база на податоци е табелата која претставува група од поврзани податоци. Секоја табела е составена од редови познати како ентитети и колони познати како атрибути. Во редовите се внесуваат поединечните податоци и истите се нарекуваат уште и записи (анг. records). Колоните ги содржат вредностите, односно својствата за сите редови, и истите се нарекуваат полиња (анг. fields). Табелите можат да се поврзуваат со други табели, преку колони со заедничка вредност кои се нарекуваат клучеви. Во релацискиот модел на база на податоци, дозволени се три видови на релации, односно врски помеѓу табелите и тоа: еден кон еден, еден кон повеќе и повеќе кон повеќе. Во ваквиот модел на база на податоци, една табела може да има потреба од постоење на некаков запис врз основа на постоење на таков запис во друга табела. Некои табели може да имаат потреба од еден или повеќе записи кои кореспондираат со еден или повеќе записи во друга табела. Следната слика 1.5. претставува илустрација на релациска база на податоци во една продавница, составена од повеќе табели.

Слика 1.5. Релациски модел на база на податоци.

14

Нарачки

Добавувачи ЗалихаПроизводи

Продавачи Купувачи

Како што може да се забележи и од сликата, во релацискиот модел на база на податоци нема главна табела (корен), иако помеѓу табелите има релации родител-дете и тоа секоја табела родител може да има повеќе табели деца, како и секоја табела дете може да има повеќе табели родител.

Секоја табела во релациската база на податоци се обележува со име. Името на табелата се користи од страна на системот за управување со базата на податоци за да ја најде точната физичка локација на табелата во складиштето, односно во меморијата, бидејќи зборуваме за бази на податоци засновани на компјутерската технологија. За разлика од предходните модели на бази на податоци каде корисникот за да може да пристапи до податоците и да изврши било какви операции врз истите мора да знае како податоците се организирани во базата, односно да ја знае структурата на базата, во овој модел за да може корисникот да ја користи табелата треба да го знае само нејзиното име и нема потреба да се грижи за тоа како податоците се организирани и каде се складирани. Во овој контекст, треба да се одговори на прашањето: како корисникот ги наоѓа податоците во релациската база на податоци, ако не ја знае структурата на базата, односно ако нема систем за следење, како што е системот на покажувачи во хиерархискиот модел на бази на податоци?

Во релацискот модел на бази на податоци, манипулирањето со податоците се врши врз основа на вредностите на самите податоци. Па така, ако корисникот сака да пристапи кон некој запис, односно ред во некоја табела, тоа треба да го направи со споредување на вредноста на податокот во рамките на одредена колона за тој ред со некој критериум за пребарување. Подетално објаснување на предходното може да се даде со следниот пример прикажан за слика 1.6., каде е прикажана релациска база на податоци за вработените во една компанија и нивните месечни примања.

Табела: ВработениИме Презиме Матичен број Улица и број Место

ПетарМирјана

...Петар

ЈовановскиДимитриевска

...Иваноски

01019724700010202973475002

...0303974470003

Гоце Делчев 11Јане Сандански 22

...Македонија 33

ТетовоПрилеп

...Скопје

Клучно поле

Табела: ПлатиМатичен број Месец Промет Раб. часови Плата

01019724700010202972475002

...0303974470003

6/147/14

...8/14

130000270000

...23000

162190...

180

1200016000

...15000

15

Слика 1.6. Релациска база на податоци.

Во примерот можеме да забележиме дека двете табели имаат едно заедничко поле, тоа е полето “матичен број“. Ова заедничко поле претставува клучно поле, а се користи за поврзување на податоците од двете табели. На пример, ако компанијата сака да ги испрати пресметките за исплата на плата на домашните адреси на вработените, најпрво се чита целиот запис (Име, Презиме, Матичен број, Улица и број, Место) од табелата “Вработени“, а потоа според прочитаниот матичен број се бара записот во табелата “Плати“ кој има ист матичен број (што би значело дека се однесува за ист вработен). Од пронајдениот запис во табелата “Плати“ се читаат податоците Месец, Промет, Часови и Плата, кои се потребни за пополнување на формуларот за исплата на плата кој треба да биде испратен на домашните адреси на вработените.

Ваквата методологија на пристапување кон податоците го прави релацискиот модел многу подобар во споредба со предходните модели на бази на податоци. Релацискиот модел на база на податоци е многу едноставен за проектирање, пребарување и одржување и овозможува поврзување на записи на начин кој не е однапред дефиниран, што е можеби и најголемата причина за сеуште големата популарност на релациските системи на бази на податоци.

Како главни бенефиции на релацискиот модел на база на податоци можат да се набројат следните:

Брз пристап до податоците, Структурата на базата е лесна за менување, Податоците се логички организирани, затоа корисниците нема потреба да ја

знаат структурата на базата, односно нема потреба да знаат каде точно податоците се сместени.

Лесно се постигнува интегритет на податоците. Лесно се поставуваат сложени критериуми за пребарување на податоци.

Како недостатоци можат да се наведат следните: Поради големата количина на податоци, базата може да биде составена од

голем број на меѓусебно поврзани табели, што како последица може да предизвика успорено пребарување на базата и пристап кон податоците. Спорото пребарување и долгото време на пристап можат да придонесат за неефикасна обработка.

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

Корисниците мора да имаат добро познавање од областа на врски помеѓу табели.

Од сето претходно наведено може да се заклучи дека релацискиот модел на база на податоци претставува многу флексибилен вид на база на податоци кој се

16

карактеризира и со голема едноставност во манипулирањето со податоците (додавање, промена и бришење на податоци).

1.1.4. Објектно ориентирани бази на податоци

Последните неколку години, со користењето на програмските јазици како што се C++, Java и Visual Basic, објектно-ориентираното програмирање стана доста популарно. Објектно-ориентираните програмски јазици му овозможуваат на програмерот да работи со објекти при креирање апликации кои ќе може да работат со релациски бази на податоци.

Објектно ориентираните модели на бази на податоци се засновани на објекти кои претставуваат сегменти кои ги содржат податоците, како и програмски код кој ги опишува податочните елементи. На следната слика 1.7. е прикажана шема на објектно-ориентирана база на податоци.

Слика 1.7. Објектно-ориентирана база на податоци

17

Средства

Основни средства

Мирјана

Обртни средства

Готовина Побарувања Залихи

Матеј

Останато

Како што може да се забележи од сликата, објектно-ориентираните бази на податоци имаат хиерархиска поставеност. Секое хиерархиско ниво во објектно-ориентираната база на податоци се состои од класи на објекти. Класите претставуваат еквивалент на табелите во релациските бази на податоци. Класа на објекти претставува шаблон, во кој се дефинирани атрибутите кои треба да бидат вклучени во одреден тип на објект, така на сликата 1.7., полињата Средства, Обртни средства и Побарувања претставуваат класи на објекти. На последното ниво во хиерархијата се наоѓаат индивидуалните објекти. На секој индивидуален објект е назначен идентификатор кој има иста улога како улогата на примарниот клуч во релацисккиот модел на база на податоци.

Во објектно-ориентираните бази на податоци, покрај едноставните типови на податоци како што се стандардните текстуални и нумерички формати, можат да бидат чувани и обработувани и сложени типови на податоци како што се графикони, мапи, слики или звук.

Како главен недостаток на објектно-ориентираните бази на податоци е бавната работа, затоа во праксата често се комбинираат со релациските бази на податоци.

1.1.5. Објектно релациски бази на податоци

Објектно-релациска база на податоци (анг. ORD – Object Relational Database) е систем за управување со база на податоци (анг. DBMS – Database Management System) кој е составен од релациска база на податоци (анг. RDBMS - Relational DataBase Management System) и објектно-ориентирана база на податоци (анг. OODBMS – Object Oriented DataBase Management System). ORD поддржува компоненти од било кој модел на објектно-ориентиран модел на база на податоци во неговите шеми и користениот прашален јазик, како што се објекти и класи.

Иако постоела некоја груба поврзаност помеѓу објектно-ориентираните и релациските модели на бази на податоци, објектно-релацискиот модел бил развиен со цел да се поврзат релацискиот модел на база на податоци со објекто-ориентираниот стил на програмирање. Објектно-релацискиот модел требало да ги претставува најдобрите страни на двата аспекти (релацискиот и објектно-ориентираниот). Со други зборови, објектно-релацискиот модел на база на податоци се вели дека е посредник помеѓу релациските и објектно-ориентираните бази на податоци, бидејќи содржи карактеристики од двата модела. Во објектно-релацискиот модел, основниот пристап е базиран на релациските бази на податоци (анг. RDB - Relational DataBase), бидејќи податоците се сместени во традиционални бази на податоци и истите се раководени и пристапувани користејќи прашалници напишани во прашален јазик како што е SQL. ORD исто така покажува објектно-ориентирани карактеристики со тоа што базата на податоци се смета за продавница на објекти, односно се работи за софтвер кој е

18

напишан во некој објектно-ориентиран програмски јазик. Основната цел на ORD е да ја премости празнината помеѓу концептуалните техники на моделирање на податоци за релациските и објектно-ориентираните бази на податоци. Исто така има цел да ги поврзе релациската база на податоци и објектно-ориентираните техники на моделирање кои обично се користат во програмските јазици како што се Java, C# и C++.

На слика 1.8. е прикажан пример за имплементација на објетно-релацискиот концепт во систем за управување со релациски бази на податоци. Дадениот пример се однесува на база на податоци за евиденција на купувачи и производи во една продавница. Во примерот, креирани се две кориснички дефинирани табели: “купувач“ и “производ“. Секоја табела има колони кои содржат специфични податоци за колоната во основната табела “продавница“, обезбедувајќи на тој начин 3D ефект за податоците. Така, колоната “куп_инфо“ во основната табела “продавница“ е поврзана со табелата “купувач“. Табелата “купувач“ е поделена на специфични категории, односно полиња: “име“, “презиме“ и “ембг“ .

Како главни бенефиции од објектно-релацискиот модел на база на податоци е тоа што релациската база на податоци добива 3D архитектура.

Како главен недостаток на објектно-релацискиот модел на база на податоци е тоа што корисникот мора да ги разбира двата концепти, и објектно-ориентираниот и релацискиот.

Слика 1.8. Објектно-релациска база на податоци.

19

ПРОДАВНИЦА

_КУП ИНФО КУПУВАЧ

_ПРО ИНФО ПРОИЗВОДПРОД_ИНФО ПРОДАВАЧ

ПРОИЗВОД

ТИП VARCHARБРЕНД VARCHARКОЛИЧИНА VARCHAR

КУПУВАЧ

ИМЕ VARCHARПРЕЗИМЕ VARCHARЕМБГ VARCHAR

1.2. Организација и обработка на податоци

Податоците претставуваат еден од најзначајните ресурси за деловните субјекти. Постоењето на релевантни податоци не значи дека истите се и многу корисни и дека од истите може да се добијат и потребни релевантни информации. Компаниите мора да имаат подготвен лесен пристап до податоците, а крајните корисници треба да знаат како податоците се организирани и складирани и како може да се пристапи кон нив.

Организираноста на податоците значи нивна среденост. Организираноста на податоците во датотеки е начин на организирање со кој податоците физички се складираат на мемориските единици. Организацијата на податоците во датотеки може да биде од три типа: секвенцијална, директна и индекс-секвенцијална.

Множеството на операции кои се извршуваат врз податоците во компјутерските системи, а со цел да се произведат информации, се нарекува циклус на обработка на податоци. Циклусот на обработка на податоци ги опфаќа следните четири операции врз податоците:

Собирање и прифаќање на податоците, односно внес на податоците. Меморирање на податоците, односно складирање на мемориските единици. Обработка на податоците, односно нивно ажурирање. Прикажување на податоците, односно излез на информации.

Внесување на податоци. При внесување на податоците, влезните податоци се прифаќаат од страна на системот и се трансформираат во форма која е читлива за компјутерите. За да се олесни подоцнежната обработка, внесот на податоците е пропратен со следните подготвителни операции:

Класификација – се назначуваат кодови за идентификација на податоците.(пример: Кодови на производите во продавниците, кодови на сметки во сметководствениот план) .

Верификација – со оваа операција се обезбедува точност на внесените податоци, односно се прави проверка на податоците со цел да се спречат грешки при внесувањето на истите.

Пренесување – податоците веднаш по прифаќањето, се пренесуваат од една на друга локација за понатамошна обработка (пример: point-of-sale терминалите).

Со развојот на компјутерската технологија, скоро без исклучок сите системи за обработка на податоци кои се базирани на компјутерските системи. Податоците се прифаќаат од изворните документи на кои се наоѓа иницијалниот запис со податоци кои треба да се внесат. Изворните документи се внесуваат во системите со скенирање или преку тастатура. Со развојот на електронското работење, влезните податоци можат да се добијат и директно во дигитална форма и да се прифатат од системот за обработка на податоци на компанијата, со што значително се намалуваат нејзините трошоци.

20

Складирање на податоци. За поефикасна обработка на податоците, тие мора да бидат организирани така што да може лесно и ефикасно да се пристапи до нив. Во продолжение ќе ги објасниме основните поими кои се тесно поврзани за организацијата на податоците:

Податок претставува формализиран знаковен приказ на факти, поими и наредби, погоден за комуникација, толкување и обработка. Податок може да биде било каква форма во која е физички евидентиран некаков настан, набљудување или факт, односно форма која може да пренесе информација. Податокот може да се прикаже во облик на вредности, броеви, знаци, или симболи кои даваат некаква информација, а се распоредуваат по однапред определени правила.

Ентитет претставува било кој елементарен објект на разгледување, а е од интерес за компанијата и за кој се прибираат, складираат и обработуваат податоци, како би можело да се извлечат информации. Ентитетите обично се прикажуваат во облик на табели. Пример за ентитет се производите, купувачите, продавачите итн.

Секој ентитет има Атрибути, односно карактеристики кои го опишуваат, а треба да бидат складирани. На пример, атрибутите на ентитетот производи се цената на производите, типот на производите итн.

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

Знак. Знакот е една буква, број или специјален знак како што се знаците за интерпукција или знакот $.

Поле. Полето содржи множество поврзани знаци. На пример, на личната карта името на лицето е едно поле, презимето друго поле, името на улицата трето поле итн.

Запис. Записот е колекција од поврзани полиња. На пример, се што е запишано на личната карта на едно лице, е еден запис.

Датотека. Датотеката е колекција од поврзани записи. На пример, сите податоци од сите лични карти од еден град можат да формираат датотека.

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

Обработка на податоци. Под обработка на податоци се подразбира постојана обработка на настанатите промени и ажурирање на складираните податоци. Најчесто во процесот на обработка на податоците се врши додавање на нови записи, бришење на веќе складирани податоци, разни промени во постоечките записи, потоа разни пресметки, споредувања, филтрирање на податоците, како и преземање и складирање на податоци за дополнителна обработка и прикажување. Обработката на податоците може да се врши на два начини: првиот начин е batch обработка, а вториот начин е обработка во реално време. Со batch обработката, податоците се собираат во текот на определен период (неколку часа, денови или недели), а потоа сите се обработуваат одеднаш, како серија односно batch. Со обработката во реално време податоците се обработуваат во исто време кога се случуваат и промените на податоците. Користењето

21

на современите методи на електронско работење, подразбира исклучиво користење на обработката во реално време.

Излез на информации. Последниот чекор во обработката на податоците е прикажување на излезните информации. Излезните информации можат да бидат прикажани во разни форми на извештаи. Формата на извештаите зависи како од целта на самите извештаи така и од корисниците за кои се наменети, на пример: во рамките на компаниите, се изготвуваат извештаи наменети за менаџментот, а целта за кои би се користеле може да е донесување на разни одлуки за деловното работење.

22

2. АНАЛИЗА И ДИЗАЈН НА БАЗИ НА ПОДАТОЦИ

Постапката, односно методологијата за воспоставување, користење и одржување на базата на податоци се нарекува Анализа и Дизајн на база на податоци. Развивањето на системите е засновано на анализа на базата на податоци. Анализата на базата на податоци директно влијае на дизајнот, односно на тоа каква ќе биде базата на податоци, односно дали и колку истата ќе биде корисна. Анализата на базата на податоци може да се подели на два дела. Првиот дел е анализа на концептуалниот модел, а вториот е анализа на логичкиот модел.

Анализа на концептуалниот модел. Концептуалниот модел е абстракција и генерализација на реалниот свет. Тој дава опис на податоците, односно предметите и нивните меѓусебни врски, а со тоа ги задоволува корисничките потреби од податоци и информации. Моќна алатка на концептуалниот модел е E-R моделот (анг. Entity-Relationship model). E-R моделот е проблемски-ориентиран концептуален модел, кој што користи едноставен графички начин за објаснување на податоците од реалниот свет. Ваквото објаснување е многу поблиско до начинот на кој луѓето размислуваат, отколку до начинот на кој се претставени податоците во самата база на податоци и начинот на пристап до истите. E-R моделот се состои од разни видови предмети, односно видови ентитети, вредности на ентитетите и врски помеѓу ентитетите. Моделот на базата на податоци се заснова на изградба на E-R дијаграм.

Анализа на логички модел. Бидејќи концептуалниот модел е абстрактно изразување на потребите на корисниците, тој не може да биде поддржан од било каков специфичен систем за управување со база на податоци ( DBMS). Со цел да може да се воспостави соодветен систем, концептуалниот модел треба да се трансформира во логички модел, а со тоа би се завршило дизајнирањето на логичката структура на базата на подаатоци. Дизајнирањето, односно проектирањето на логичката структура на базата на податоци е поделено на два чекори. Првиот чекор е трансформација на E-R дијаграмот во E-R модел. Вториот чекор е оптимизирање на E-R моделот. Во целиот тој процес, постојат следните специфични чекори: ентитетот се претвора во врска, односно табела со податоци. Својствата на ентитетот се својства на табелата, односно својства на поле во табелата, а примарниот клуч е врската. Дијаграмот на логичкиот модел, кој всушност претставува анализа на полињата и на табелите, е заснован на E-R дијаграмот. После донесувањето на одлуката кои полиња и табели ни се потребни, ќе може да се креира моделот на база на податоци.

Дизајн на база на податоци. Кога ќе го имаме моделот на базата на податоци, ќе може да се премине кон дизајн, односно проектирање на базата на податоци. Во согласност со различните модели, може да се креираат различни бази на податоци, а се почнува од избраните полиња и табели.

23

2.1. Животен циклус на база на податоци

Воведувањето на база на податоци во некоја компанија или во некоја институција претставува сложена задача која бара тимска работа на експерти од разни профили и области. Тоа е проект кој може да се подели во пет фази, кои всушност го претставуваат животниот циклус на базата на податоци. Фазите на животниот циклус на базата на податоци се следните:

Анализа на потребите. Моделирање на податоците. Имплементација. Тестирање и Одржување.

Анализа на потребите. Во оваа фаза се проучуваат тековите на информациите во компанијата, се утврдуваат податоците кои треба да бидат складирани како и врските помеѓу нив. Потребите кои треба да ги задоволи базата на податоци се одредуваат во разговор како со добавувачите на податоци, така и со корисниците на тие податоци или информации.

Со анализата на потребите треба исто така да се опфати и анализата на операциите (трансакциите), кои се вршат над податоците, бидејќи тоа може да има влијание на содржината и конечниот облик на базата на податоци.

Резултат на анализата на потребите е документ кој се нарекува спецификација на потребите. Спецификацијата на потребите ги содржи потребните податоци кои ќе бидат обработувани, природата на врските и софтверската платформа за имплементација на базата на податоци.

Моделирање на податоци. Глобалната шема, дијаграм на концептуален модел на податоци кој ги покажува сите податоци и нивните релации, се конструира односно се развива со помош на E-R дијаграмот. Конструираниот модел на податоци на крајот мора да биде трансформиран во нормализирани релации, односно табели. Со E-R дијаграмот се анализираат и моделираат потребните податоци. Потребните операции кои се извршуваат врз податоците се изразуваат со природен јазик, разбирлив за корисниците.

Кога се работи за поголем проект и кога повеќе луѓе се вклучени во анализа на потребите, се појавуваат и повеќе погледи на податоците. Со цел да се елиминираат редундацијата и неконзистентноста на податоците од моделот, тие погледи треба да се рационализираат и на тој начин да се соединат во еден глобален поглед.

Функционалните зависности (анг. FDs – Functional dependencies) се добиваат од дијаграмот на концептуалниот модел на податоци и од анализата на потребите, односно од спецификацијата на потребите. Одредените релациони табели кои се поврзани со

24

сите функционални зависности се нормализираат (односно, табелите се разделуваат на помали табели), со користење на стандардни техники. На крајот, редунданоста на податоците во одредените нормализирани табели се анализира за понатамошно елиминирање, со одредени ограничувања кои ќе обезбедат интегритет на податоците.

Физичкиот дизајн на базата на податоци вклучува избор на методите на пристап, поделба и групирање на податоците. Интегритетот на податоците е обезбеден со нормализација на одредените табели креирани кога концептуалниот модел на податоци се трансформира во релациски модел. Целта на физичкиот дизајн е да ги оптимизира перформансите колку е можно повеќе.

Имплементација. Врз основа на шемите и под-шемите, како и со помош на системот за управување со база на податоци, базата на податоци физички се реализира на компјутерската единица. Во DBMS-от обично постојат параметри со кои може да се влијае на физичката организација на базата на податоци. Параметрите се подесуваат така да се обезбеди ефикасно работење на најважните трансакции. Во оваа фаза се развива множество од програми кои реализираат поединечни операции со што ги задоволуваат потребите на разните апликации или корисници. Иницијално, на почетокот базата се полни со податоци.

Тестирање. Корисниците, на почетокот пробно работат на базата и проверуваат дали ги задоволува сите потреби. Во оваа фаза се настојува да се откријат грешките кои можеле да се појават во предходните фази на развој на базата на податоци. Грешките во пораните фази имаат потешки последици, па затоа би било добро таквите пропусти да се откријат пред имплементацијата. Затоа, во поново време, пред фазата на имплементација, се развиваат прототипи на базта на податоци и тие им се покажуваат на корисниците.

Одржување. Оваа фаза се одвива во време кога базата е веќе во употреба. Оваа фаза се состои од следното: поправка на грешки кои не биле откриени во фазата на тестирање, воведување на промени поради нови потреби на корисниците, подесување на параметри во системот за управување со базата на податоци во насока на подобрување на перформансите. Одржувањето бара постојано да се следи работата со базата на податоци, но тоа следење да не им пречи на корисниците.

2.2. Архитектура на база на податоци

Архитектура на база на податоци е колекција од спецификации, правила и процеси кои налагаат како податоците ќе бидат сместени во базата и каков ќе биде пристапот од компонентите на системот кон податоците. Архитектурата вклучува видови на податоци, релации и конвенции за именување. Архитектурата на базата на податоци ја опишува организацијата на сите објекти во базата и како тие заедно функционираат. Таа исто така влијае и на интегритетот, односно целокупноста, на

25

сигурноста и перформансите на базата на податоци и вклучува се она што ја одредува природата на податоците, структурата на податоците или текот на податоците. Архитектурата на база на податоци се состои од три нивоа, и тоа:

Физичко ниво Глобално логичко ниво и Локално логичко ниво.

На следната слика 2.1. е даден графички приказ на трите нивоа на Архитектурата на база на податоци.

Слика 2.1. Архитектура на база на податоци

Глобално логичко ниво. Глобалното логичко ниво се однесува на логичката структура на целата база на податоци. Тоа е ниво кое го гледа проектантот на базата, односно администраторот. Записот на логичката дефиниција се нарекува шема (анг. schema). Шемата е текст или дијаграм кој ја дефинира логичката структура на базата,

26

Локално логичко

ниво

Глобално логичко ниво

Физичко ниво

Датотеки Датотеки

Распоред на складирање

Шема

Апликациска програма 1

Апликациска програма 3

Апликациска програма 2

Поглед 1 Поглед 3Поглед 2

односно се именуваат и се дефинираат сите типови на податоци и врски помеѓу тие типови, а во склад со правилата на зададениот модел. Шемата, исто така воведува и ограничувања со кои се обезбедува интегритетот на податоците.

Локално логичко ниво. Локалното логичко ниво се однесува на логичкото прикажување на тој дел од базата што го користи некоја поединечна апликација. Тоа е ниво кое го гледаат корисникот и апликацискиот програмер. Записот на една локална логичка дефиниција се нарекува поглед (анг. view) или под-шема. Тоа е текст или дијаграм со кој се именуваат и дефинираат сите локални типови на податоци и врски помеѓу тие типови и повторно во склад со правилата на користениот модел. Исто така, со погледот се прави пресликување (анг. mapping), со кое од глобалните податоци и врски се изведуваат локални.

Физичко ниво. Физичкото ниво се однесува на физичкиот приказ и распоред на податоците на мемориските единици. Ова ниво го гледаат само системските програмери кои го развиваат системот за управување со базата на податоци (DBMS). Самото физичко ниво може понатаму да се подели на повеќе поднивоа на абстракција, од конкретните блокови и цилиндри на дискот, па се до абстрактните поими како што се на датотеки и записи кои ги среќаваме во класичните програмски јазици. Распоредот на складирање опишува, како елементите на логичката дефиниција на базата на податоци се пресликуваат на физичките уреди.

За создавање на база на податоци потребно е да се зададат само шемата и погледите. Тогаш системот за управување со базата на податоци автоматски ги генерира потребниот распоред на складирање и физичката база, а администраторот може само делумно да влијае на физичката изградба со подесување на одредени параметри кои му се достапни.

Програмите и корисниците не пристапуваат директно на физичката база на податоци, туку добиваат или складираат податоци со посредство на системот за управување со базата на податоци (DBMS-от). Комуникацијата на програмата, односно корисникот со DBMS-от се остварува на локалното логичко ниво.

2.3. Дизајн на база на податоци

За било која работа, од било која област од секојдневниот живот, за нешто да почнеме да правиме, да креираме, најнапред е потребно да направиме одреден дизајн и нацрт, а пример за припрема на храна потребен е рецепт, за изградба на куќа потребен е проект, односно дизајн како куќата ќе изгледа итн.

При креирање на база на податоци, исто така потребно е да се организираат податоците и да се одредат целите. Целите на дизајнирањето, односно креирањето се следни:

Да се елиминираат вишокот непотребни податоци. Да се овозможи брзо пронаоѓање на поединечни податоци.

27

Да се овозможи едноставно одржување на базата на податоци.

Клучните активности при креирање на база на податоци се следните:

Моделирање на апликациите. Дефинирање на податоците кои се неопходни за апликациите Организирање на податоците во табели. Воспоставување на релации помеѓу табелите, на барањата за индексирање и

вреднување на податоците, како и изработка и снимање на сите потребни прашалници во врска со апликациите.

Моделирањето на апликациите се однесува на постапката при која ги дефинираме задачите кои треба да ги изврши апликацијата. Би било добро дефинираните задачи да ги специфицараме во одреден документ кој ќе ни помогне да бидеме фокусирани на задачата на нашата програма.

Под нормализирање на податоци се подразбира елиминирање на непотребните податоци. Резултат на нормализирањето на податоците е секој податок во базата на податоци да се јавува само еднаш. Ако податоците се појавуваат повеќе пати, во тој случај се губи простор во меморијата и ако дојде до некои измени, ќе мораме новата информација да ја внесуваме во сите полиња на кои таа се однесува. Но, ако направиме повеќе табели каде секој податок се појавува само еднаш, во случај на некаква измена новата информација ќе ја запишуваме само еднаш. Друг начин да се нормализираат податоците е да се формира т.н. табела “дете“. Табелата дете е табела во која сите внесени податоци делат една заедничка информација која е сместена во некоја друга табела. Табелата за пребарување е уште еден начин за сместување на информации со цел спречување на појава на непотребни информации и зголемување на точноста на внесување на податоци. Кога ги нормализираме податоците, меѓусебно поврзаните информации ги сместуваме во неколку табели. Меѓутоа, кога сакаме да пристапиме до податоците и сакаме да ги видиме информациите од сите табели на едно место, за да го постигнеме тоа мораме да формираме множества од записи кои ги обединуваат меѓусебно поврзаните информации од неколку табели. Тоа множество од записи се формира со употреба на наредби напишани во некој програмски јазик (пример. SQL, ODBC, OLE DB, ADO) кој е поддржан од системот за управување со базата на податоци, во кои ги наведуваме саканите полиња, локацијата на полињата и врските помеѓу табелите и тие наредби можеме да ги сместиме како прашалници во базата на податоци.

Добро креирана база на податоци овозможува: минимално време за пронаоѓање на записите, сместување на податоци на најефикасен начин, така што базата на податоци нема да стане премногу голема, наједноставно ажурирање на податоци, како и вклучување на нови функции кои може да бидат побарани од програмот.

28

2.4. Моделирање на податоци

Најважен дел на секој бизнис процес е чувањето на записи со податоци. Во денешното развиено информатичко општество, најголем дел од компјутерска моќ е посветена на одржување и користење на бази на податоци. Разни видови на бази на податоци се среќаваат речиси во секој бизнис. Сите видови на податоци, од електронска пошта и информации за контакти, па се до финансиски податоци и податоци за продажби, се сместени во некаков вид на база на податоци.

Моделот на податоци претставува апстрактен приказ на податоците. Моделот на податоци ги опишува податоците, односно множествата на податоци и врските помеѓу нив. Со други зборови, моделот на податоци е концептуална презентација на стуктурата на податоците во базата на податоци. Структурата на податоците се состои од објекти, врските помеѓу објектите, како и правила кои ги регулираат операциите кои се вршат врз објектите. Моделот на податоци насочен е пред се кон тоа какви податоци се потребни и како истите се организирани, а не кон тоа какви операции се извршуваат врз податоците. Моделот на податоци не ги претставува податоците на начин на кој што се прикажани во базата на податоци, туку ги прикажува на начин на кој крајните корисници ги гледаат во реалниот живот.

Моделирањето на податоците е процес кој почнува со анализирање и утврдување на потребите на корисниците за информации, а завршува со изградба на соодветна база на податоци. Во зависност од потребите што се јавуваат во текот на изградбата на базата на податоци, се разликуваат три вида на модели на податоци: концептуален, логички и физички модел на податоци. Описот на објектите и нивните врски се нарекува концептуален опис на податоците. Во склад со концептуалниот опис, треба да се одреди и распоредувањето на податоците во датотеките и табелите, таквиот опис се нарекува логички опис на податоците. Последниот чекор е одредување на физичкото сместување на податоците на мемориската единица и како на истите да се пристапува. Таквиот опис се нарекува физички опис на податоците.

Целта на моделот на податоци е да обезбеди сите објекти во базата на податоци да бидат целосно и точно претставени. Бидејќи моделот на податоци користи лесно разбирливи обележја, тој може да биде прегледан и проверен од страна на крајните корисници. Моделот на податоци треба исто така да биде и доволно детален, така да може да биде користен од страна на програмерите како шематски план при изградба на физичката структура на базата на податоци.

Има две главни методологии кои се користат за креирање на модел на податоци: E-R модел (анг. Entity-Relationship model ) и Oбјектен модел (анг. Object Model). E-R моделот е најчесто користен метод за изградба на модели на податоци за релациони бази на податоци.

29

2.4.1. E-R модел на податоци (E-R дијаграм)

E-R моделот го дефинира концептуалниот поглед на базата на податоци и истиот се користи во фазата на концептуално моделирање на податоците при дизајнирање на база на податоци. E-R моделот на податоци е сосема независен од системот за управување со базата на податоци, од хардверската конфигурација, како и од апликациските програми. E-R моделот е графички модел со кој реалниот или замислениот свет се прикажува со односот помеѓу трите основни елементи, односно три класи на објекти:

Ентитети (анг. Entities) Атрибути (анг. Atributes) и Релации, односно врски (анг. Relations)

Во концепцијата на E-R моделот како графичко средство се користат дијаграми, а еден од најпознатите е E-R дијаграмот (анг. Entity-Relationship Diagram). E-R дијаграмот е специјализиран дијаграм кој служи за опишување на односите помеѓу ентитетите во базата на податоци. На слика 2.2. е даден графички приказ на E-R дијаграм.

30

Ентитет

Атрибут Атрибут

Ентитет

Атрибут

Релација

Атрибут

Атрибут

Ентитет

Релација

Атрибут

Слика 2.2. Графички приказ на E-R дијаграм.Ентитети. Ентитет е нешто за кое што сакаме да собереме податоци и

информации, нешто што е во состојба да постои и да се идентификува. Ентитет може да биде објект, настан или појава. Наједноставно кажано Ентитет е се што може да се дефинира. Примери за ентитети се: вработен, оддел, студент, куќа, локација, некој натпревар, празник и слично. Во E-R моделот ентитетите се претставуваат со правоаголник, а името на ентитетот најчесто е именка и истото се впишува во правоаголникот, како што е прикажано на следната слика 2.3.

Слика 2.3. Приказ на ентитетот “Вработен“ во некој E-R модел

Во системот можат да се дефинираат два вида на ентитети “јаки“ и “слаби“ ентитети. Иако во моделот улога на ентитет имаат “јаките“ објекти, во системот можат да се јават и “слаби“ ентитети, односно ентитети кои зависат од друг јак ентитет. На пример, ентитетот “Работен стаж“, претставува слаб ентитет чие постоење е во директна зависност од ентитетот “Вработен“ кој претставува јак ентитет. Слабите ентитети се претставуваат со правоаголник со двојни линии, како што е прикажано на слика 2.4.

Слика 2.4. Приказ на слабиот ентитет “Работен стаж“ во некој E-R модел.

Атрибути. Атрибутите претставуваат карактеристики на ентитетите кои даваат детален опис на истите. Секое поединечно јавување на атрибутот во ентитет или релација се нарекува вредност на атрибутот. Има два типа на атрибути:

Идентификатори и Дескриптори

31

Работен стаж

Вработен

Идентификатор (Клуч) е атрибут кој се користи за еднозначно да го одреди јавувањето на ентитетот, односно да го идентификува ентитетот.

Дескриптор е атрибут кој се користи за да се наведат повеќекратните карактеристики на поединечните јавувања на ентитетот.

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

Во E-R дијаграмот атрибутите се претставуваат со елипса, а името на атрибутот се запишува внатре во елипсата. Атрибутите се поврзани со линија со ентитетите кои ги карактеризираат. На слика 2.5. е даден графички приказ на атрибут поврзан со соодветен ентитет.

Слика 2.5. Приказ на атрибутот “име“ кој е карактеристика на ентитетот “Вработен“

Клучните атрибути, односно идентификаторите во E-R дијаграмот се претставени со подвлечен текст. На следната слика 2.6. е претставен ентитетот “Вработен“ со еден атрибут идентификатор, односно еден клуч и два атрибути дескриптори.

Слика 2.6. Атрибутот “ембг“ е клуч (идентификатор), а останатите два атрибути “име“и “занимање“ се дескриптори.

Релација. Релацијата претставува врска помеѓу еден, два или повеќе ентитети и како таква таа зависи само од поврзаноста на ентитетите. Релациите се објаснуваат од аспект на: степенот, поврзаноста и постоењето. Во E-R дијаграмот релациите се

32

Вработен име

Вработен име

ембг

занимање

прикажуваат со ромб, името на релацијата се впишува во ромбот или покрај ромбот и најчесто името е глагол кој означува некакво дејствие помеѓу поврзаните ентитети.Графички приказ за релација помеѓу два ентитети е даден на следната слика 2.7.

Слика 2.7. Приказ на релацијата “работи во“, помеѓу ентитетите “Вработен“ и “Оддел“.

Степен на релацијата претставува бројот на ентитетите кои се ставени во меѓусебна врска или кои учествуваат во релацијата. Во зависност од степенот, релацијата може да биде: бинарна, тернарна, n-арна и рекурзивна.

Бинарната релација е релација од втор степен и истата поврзува два ентитети. Ова е најчесто застапувана врска во реалниот свет и најчесто застапувана врска во еден E-R модел и многу системи за моделирање го користат овој тип на релација. Релацијата претставена на слика 2.7. е бинарана релација.

Тернарната релација е релација од трет степен и таа претставува врска помеѓу три ентитети. Овој тип на релација е потребна кога бинарните релации не се доволни точно да ја опишат релацијата. Тернарната релација графички во E-R моделот се претставува со ромб поврзан со линии со три ентитети. На слика 2.8. даден е графичкиот приказ на тернарна релација во E-R дијаграм.

Слика 2.8. Приказ на тернарна релација која поврзува три ентитети, во E-R дијаграм.

33

Вработен Оддел

“работи во“

“продава“Продавач Производ

Купувач

Општа форма за релација од кој било n степен се нарекува n-арна релација и во таквата релација учествуваат n ентитети.

Рекурзивна релација е релација која поврзува еден ист ентитет сам со себе. Оваа релација се нарекува рекурзивна, бидејќи ентитетот се поврзува со друго негово јавување. На слика 2.9. даден е графичкиот приказ на тернарна релација во E-R дијаграм.

Слика 2.9. Приказ на рекурзивна релација, каде одделен вработен е поврзан со друг вработен преку управувањето.

Поврзаноста на релацијата го претставува бројот на можните јавувања на ентитетите во релацијата, тој број на можни јавувања уште се вика и кардиналност на релацијата. Вредности на кардиналноста се “еден“ или “многу“. Постојат три вида кардиналност кај бинарните релации, и тоа: 1:1, 1:М, М:N.

На следните три слики 2.10, 2.11 и 2.12, прикажани се трите вида на кардиналност на врските меѓу ентитетите.

Слика 2.10. Приказ за кардиналност од видот 1:1.

34

Вработен управува

подреден

управувач

“е управуван од“

Оддел Вработен1 1

“има“

Оддел Вработен1 М

Слика 2.11. Приказ за кардиналност од видот 1:М.

Слика 2.12. Приказ за кардиналност од видот М:N.

Во случајот на кардиналност 1:1 (слика 2.10), ентитетот “Оддел“ е управуван од точно еден Вработен и секој Вработен управува точно еден Оддел. Затоа, и минималната и максималната кардиналност на релацијата “е управуван од“ се точно еден за двата ентитети “Вработен“ и “Оддел“.

Во случајот на кардиналност 1:М (слика 2.11), ентитетот “Оддел“ е поврзан со многу “Вработени“, затоа на страната на ентитетот “Вработен“ е дадена максимална кардиналност (многу) како непозната вредност М, а минималната кардиналност е еден. На страната на ентитетот “Оддел“, минималната и максималната кардиналност се еден, бидејќи секој Вработен работи точно во еден Оддел.

Во случајот на кардиналност М:N (слика 2.12), поединечен Вработен може да работи на многу Проекти и секој Проект може да има многу Вработени. Се гледа дека максималната кардиналност за ентитетите “Вработен“ и “Проект“ во двата правци е М (или N, односно многу), а минималната кардиналност на двете страни е дефинирана да биде 1 (еден).

Постоењето на ентитетот во релацијата е дефинирано како мандаторно (задолжително) или опционално, а со тоа и релацијата е мандаторна или опционална. Релацијата е мандаторна (задолжителна), ако ентитетот на едниот крај мора да биде во врска со ентитетот на другиот крај, во спротивно релацијата е опционална (незадолжителна). На следните две слики 2.13 и 2.14, графички се претставени мандаторна и опционална релација.

Слика 2.13. Приказ на опционална (незадолжителна) релација.

35

“работи на“

Вработен ПроектМ N

“е управуван од“

Оддел Вработен1 1

Слика 2.14. Приказ на мандаторна (задолжителна) релација.

Во примерот на слика 2.13, ентитетот “Вработен“ може или немора да биде управуван од некој Оддел, правејќи ја на тој начин релацијата на ентитетот Оддел со ентитетот Вработен опционална. Опционалноста дефинирана со нула на линијата за поврзување помеѓу ентитетот и релацијата, дефинира минимум кардиналност од нула.

Во примерот на слика 2.14, релацијата “е зафатена од“ помеѓу ентитетите “Канцеларија“ и “Вработен“ подразбира дека во Канцеларијата може да се сместат од нула до максимум М Вработени, но одреден Вработен мора да се смести во точно една Канцеларија, тоа е мандаторност (задолжителност) и затоа таа релација е мандаторна.

2.4.2. Постапка за креирање на релациска база на податоци

Постапката за креирање на релациска база на податоци започнува со конструкција на E-R моделот. Конструкцијата на E-R моделот е итеративен процес, поради што препорачливо е да се направат неколку верзии, па со нивно преработување и дополнување да се дојде до онаа верзија која е најдобра, поаѓајќи притоа од фактот дека нема совршено решение, туку од повеќето решенија се избира најдоброто.

Процесот на конструкција на моделот ги опфаќа следните чекори:

1. Идентификување на ентитетите – се прави листа на сите типови на ентитети кои се од интерес во системот. Во овој чекор најдобро би било да се внесат многу ентитети, а покасно непотребните да се отфрлат.

2. Отстранување на ентитетите кои се дуплираат.3. Одредување атрибутите за секој ентитет.4. Одбележување на примарните клучеви кои ги идентификуваат ентитетите,

односно нивните јавувања.5. Дефинирање на релациите.

36

“е зафатена од“

1 МКанцеларија Вработен

0

6. Опишување на кардиналноста и опционалноста на релациите.7. Отстранување на редундантните релации.

По конструирањето на E-R моделот, следи втората фаза од процесот на креирање на релациска база на податоци, преведување на E-R моделот во релациска шема. Преведувањето на E-R моделот во релациска шема, опфаќа:

Преведување на ентитетите. Преведување на слабите ентитети. Преведување на бинарните релации меѓу ентитетите.

Преведување на ентитетите. За секој ентитет од E-R моделот се креира релација (табела) која ги содржи сите атрибути на ентитетот. Односно, атрибутите на ентитетот во табелата се појавуваат како колони, а секое индивидуално јавување на ентитетот се појавува како редица, односно запис. При преведувањето на ентитетот во релација (табела), името на ентитетот станува име на табелата, а еден од клучните атрибути, односно атрибутот идентификатор станува примарен клуч на релацијата. На следната слика 2.15, е даден приказ на општиот изглед на релација (табела) запишан текстуално и даден во табела.

ИМЕ_НА_ТАБЕЛА (примарен клуч, атрибут2, атрибут3, ..., надворешен клуч)

ИМЕ_НА_ТАБЕЛАпримарен клуч атрибут2 атрибут3 надворешен клуч

Слика 2.15. Општ приказ на релација (табела).

Од предходниот пример:- Име_на_табела, претставува име на ентитетот кој е преведен во табела, па

затоа и табелата го има истото име.- примарен клуч , е примарен атрибут на ентитетот кој во табелата станува

примарен клуч.- атрибут1 и атрибут2, претставуваат два атрибути на ентитетот.- надворешен клуч, е атрибут кој е примарен клуч во некоја друга табела и

надворешниот клуч не е задолжителен за секоја табела. Табелата може да има повеќе надворешни клучеви, односно може да има надворешен клуч од секоја табела со која е поврзана.

37

Преведување на слабите ентитети. При преведување на слабите ентитети, примарниот клуч од јакиот ентитет се придодава на примарниот клуч од слабиот ентитет и на тој начин се создава сложен примарен клуч. Во ваков случај, јакиот и слабиот ентитет мора да бидат поврзани со релација 1:М. На следната слика 2.16, даден е пример за поврзување на јак и слаб енитет во релација 1:М и даден е текстуален и табеларен приказ на преведување на слабиот ентитет и создавање на сложен примарен клуч.

КОМПАНИЈА (ембс, број_вработени)ВРАБОТЕНИ (ембг, ембс, име, позиција, стаж)

КОМПАНИЈА ембс број-вработени

ВРАБОТЕНИембг ембс име позиција стаж

Слика 2.16. Поврзување на јак и слаб енитет во релација 1:М. Текстуален и табеларен приказ на преведување на слабиот ентитет и создавање на сложен примарен клуч.

38

1 МК

“има“

КОМПАНИЈА ВРАБОТЕНИ

ембс

број_вработени стажпозиција

имеембг

Правила за преведување на бинарните врски меѓу ентитетите. Процесот на преведување на врските во релациски модел зависи од степенот на релацијата од кардиналноста и од опционалноста на релацијата.

Релации 1:1. Пред да пристапиме кон преведување на оваа релација, најпрво треба да ја знаеме нејзината опционалност. Има три можности кои релацијата може да ги има:

Да биде мандаторна на двата краја. Да биде мандаторна на едниот крај, а опционална на другиот крај. Да биде опционална на двата краја.

Мандаторна на двата краја. Доколку релацијата е мандаторна на двата краја, тогаш е можно двата ентитети да се спојат во еден или да останат раздвоени.

Доколку двата краја се спојат во еден, тогаш:

- Резултатот од таквото спојување е дека сите атрибути на послабиот ентитет стануваат атрибути на појакиот ентитет.

- Клучот на слабиот ентитет станува нормален атрибут.- Доколку постојат атрибути кои се повторуваат, тогаш дупликатите се

отстрануваат.- Примарниот клуч на новиот ентитет кој се добил со спојување на двата

ентитети и всушност истиот примарен клуч од појакиот ентитет.

ВРАБОТЕН (шифра_вработен, име, бр_договор, почеток, позиција, плата)

Слика 2.17. Релација 1:1, која е мандаторна на двата краја.

39

позиција“има“

1 1ВРАБОТЕН ДОГОВОР

шифра_вработен

име плата

почетокбр_договор

Доколку двата краја останат одвоени, тогаш тие ќе бидат поврзани со надворешен клуч, односно кога имаме ваков случај, тогаш:

- Двата ентитети претставуваат два ентитети од реалниот свет.- Ентитетите се во многу релации со други ентитети.- Примарниот клуч од едниот ентитет станува надворешен клуч во другиот.- Во секој ентитет нема надворешен клуч.- Двата ентитети се претвораат во посебни релации (табели).

Ако во овој случај го искористиме примерот од слика 2.17., ваквата релација ќе можеме да ја претставиме со следниот начин:

ВРАБОТЕН (шифра_вработен, име)ДОГОВОР (бр _ договор , почеток, позиција, плата, шифра_вработен)

и обратно:

ВРАБОТЕН (шифра_вработен, име, бр_договор)ДОГОВОР (бр _ договор , почеток, позиција, плата)

Мандаторна на едниот крај, опционална на другиот крај. На слика 2.18 е претставен пример на релација 1:1 која е мандаторна на едниот крај, а опционална на другиот, каде секој вработен може да има најмногу еден договор, а тоа ја прави релацијата опционална на едниот крај.

Слика 2.18. Релација 1:1, која е мандаторна на едниот крај, а опционална на другиот крај.

40

“има“

1 10

ДОГОВОР

позиција

ВРАБОТЕН

шифра_вработен

име плата

почетокбр_договор

Доколку релацијата е мандаторна на едниот крај, а опционална на другиот крај, тогаш:

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

- Примарниот клуч на ентитетот на мандаторната страна се додава како надворешен клуч на ентитетот на опционалната страна.

Ако во овој случај го искористиме примерот од слика 2.18., ваквата релација ќе можеме да ја претставиме со следниот начин:

ВРАБОТЕН (шифра_вработен, име)ДОГОВОР (бр _ договор , почеток, позиција, плата, шифра_вработен)

Опционална на двата краја. На слика 2.19 е претставен пример на релација 1:1 која е опционална на двата краја.

Слика 2.19. Релација 1:1, која е опционална на двата краја.

Доколку релацијата е опционална на двата краја, тогаш:

- Двата ентитети остануваат раздвоени и не можат да се спојат во еден, а со тоа не можат да имаат еден заеднички примарен клуч.

- Ентитетите се во многу релации со други ентитети.- Примарниот клуч од едниот ентитет станува надворешен клуч во другиот.- Во секој ентитет нема надворешен клуч.- Двата ентитети се претвораат во посебни релации (табели).

41

ДОГОВОР

позиција

ВРАБОТЕН

шифра_вработен

име плата

почетокбр_договор

“има“

1 100

Ако во овој случај го искористиме примерот од слика 2.19., ваквата релација ќе можеме да ја претставиме со следниот начин:

ВРАБОТЕН (шифра_вработен, име)ДОГОВОР (бр _ договор , почеток, позиција, плата, шифра_вработен)

и обратно:

ВРАБОТЕН (шифра_вработен, име, бр_договор)ДОГОВОР (бр _ договор , почеток, позиција, плата)

Релации 1:М. При преведување на 1:М релации, примарниот клуч од страната 1 на релацијата се додава на стрната М (многу), како надворешен клуч. Пример:

Слика 2.20. Приказ на релација 1:М.

После преведувањето, ќе произлезат следните релации, односно табели:

НАСОКА (шифра _ насока , име_насока)СТУДЕНТ (бр_индекс, име, датум_раѓање, шифра_насока)

Доколку ентитетот е содржан во неколку 1:М релации, тогаш ќе се примени истото правило при додавањето на примарниот клуч како надворешен клуч од страната 1 на релацијата на стрната М (многу), во секоја релација.

42

1 М“запишан“

СТУДЕНТ

име

НАСОКА

име_насока датум_раѓање

бр_индексшифра_насока

Релации М:N. Доколку има М:N релации во E-R моделот, тие се преведуваат на следниот начин:

- Се создава нова релација која ги содржи примарните клучеви од двете страни на релацијата.

- Тие примарни клучеви формираат сложен примарен клуч.- Доколку самата врска помеѓу ентитетите содржи атрибути, тогаш тие

стануваат атрибути на новата релација.

Слика 2.21. Приказ на релација М:N.

После преведувањето, ќе произлезат следните релации, односно табели:

ПРОИЗВОД (шифра_ производ , име_производ, цена)ПРОДАВАЧ (шифра _ продавач , име, адреса)ПРОДАВА (шифра _ продавач , шифра_ производ , бр _ продажба , износ)

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

43

шифра_производ

“продава“

ПРОДАВАЧ

име

ПРОИЗВОД

име_производ адреса

шифра_продавачбр_продажба

износцена

М N

3. СИСТЕМИ ЗА УПРАВУВАЊЕ СО БАЗА НА ПОДАТОЦИ (DBMS)

Систем за управување со база на податоци или накратко DBMS (анг. Database Management System), претставува технологија која овозможува лесен и ефикасен пристап на сите корисници до базата на податоци. DBMS служи како врска за комуникација, односно како интефејс помеѓу корисниците и базата на податоци. DBMS исто така обезбедува софтверски алатки кои се потребни за креирање, примена, пристапување и ажурирање на базата на податоци, управува и со влезно – излезните операции, а води грижа и за тајноста на податоците. DBMS овозможува независност на податоците, што значи дека апликациските програми можат да се менуваат без притоа да се влијае на меморираните податоци.

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

Вообичаено, податоците биле организирани во датотеки. DBMS претставува сосема нов концепт кој бил воведен со цел да се поправат сите недостатоци на претходниот начин на управување со податоците организирани во датотеки.

Најсовремените системи за управување со податоци ги имаат следните карактеристики:

Објекти од реалниот свет. Современите DBMS се многу реални и користат објекти од реалниот свет при дизајнирање на нивната архитектура.

Табели засновани на релации. DBMS овозможуваат објектите и врските помеѓу нив да се претстават во вид на табела.

Мала редунданост. DBMS ги почитува правилата на нормализација, кои овозможуваат разделување на табелата кога кај некој од нејзините атрибути има дуплирање на вредности. Со нормализацијата се овозможува целата база на податоци да содржи колку што е можно помалку дуплирани податоци.

Конзистентност. Конзистентноста е состојба кога секоја релација (табела) во базата на податоци е постојана.

Query јазик. DBMS е опремен со прашален (query) јазик, која го прави системот поефикасен при пребарување и обработка на податоците. Корисниците на тој начин можат да користат многу различни опции за филтрирање на податоците – ова не било можно кај системите за организација на податоците во датотеки.

44

Повеќекориснички и истовремен пристап. DBMS поддржува околина за повеќе корисници и им дозволува паралелен пристап и манипулација со податоците.

Повеќекратни погледи. Ова значи дека DBMS нуди повеќекратни погледи за различни корисници. На пример: корисник кој е во одделот за продажба ќе има различен поглед на базата на податоци од корисникот кој работи во производството. Тоа им овозможува на корисниците да имаат пристап до базата на податоци само во рамките на нивните потреби.

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

Системите за управување со бази на податоци се користат од различни корисници за различни намени. Некои од нив можеме да ги опишеме на следниот начин:

Администратори. Тоа се група од корисници кои го одржуваат DMBS и се одговорни за раководењето со базата на податоци. Тие се одговорни за следење на начинот на користење на базата и од кого е истата користена. Креираат пристапи на корисниците и ставаат ограничувања заради сигурност.

Дизајнери. Тоа се група на луѓе кои работат на дизајнирање на базата на податоци или на одредени нејзини делови. Тие внимаваат какви податоци ќе бидат сместувани во базата и во каков формат. Тие ги одредуваат и дизајнираат сите објекти, релации, ограничувања и погледи.

Крајни корисници. Оваа група ја сочинуваат луѓето кои всушност ги користат погодностите на системот на база на податоци. Крајни корисници можат да бидат набљудувачи на пазарните движења или пазарните цени, но можат да бидат и професионални бизнис аналитичари.

Системите за управување со релациски бази на податоци можат да се поделат во две главни категории според тоа, дали за основа имаат датотека или сервер. DBMS базирани на датотека се чуваат во една датотека (на пример: Microsoft Access), лесно се дистрибуираат, но немаат премногу добри перформанси. Од друга страна DBMS базирани на сервер (на пример: Microsoft SQL server) имаат подобрени перформанси, можат да поддржат повеќе истовремени корисници, но се покомплицирани за одржување како и за дистрибуција. При одлуката за креирање на база на податоци може да се избере некој од следните системи за управување:

Microsoft® Accessтм

Microsoft SQL server MySQL Oracle

45

3.1. Microsoft® Accessтм 2013

Microsoft® Accessтм е систем за управување со релациски бази на податоци (анг. RDBMS – Relational Database Management System), развиен од страна на компанијата Microsoft како составен дел од Microsoft® Officeтм пакетот. Сите стандарди кои важат за Microsoft® Windows и останатите програми од Microsoft® Officeтм пакетот важат и за Microsoft® Accessтм (целосно стандардизиран кориснички интерфејс, стандардизиран помошник (Help), како и унифицирани процедури и функции, на пример: пребарувачот во Microsoft® Accessтм функционира исто како и во Word и Excel).

Microsoft® Accessтм е предвиден пред се за креирање на релативно мали бази на податоци со релативно мали количини на податоци, на пример за водење на разни лични евиденции како што се адресари, евиденција на книги, филмови, за евиденција на работни книги, за деловна евиденција во мали и средни компании итн.

Microsoft® Accessтм обезбедува целосно управување со релациската база на податоци, како и интегритет и сигурност на базата на ниво на комјутерската единица на која се наоѓа, што спречува непотполно ажурирање и бришење.

Во Microsoft® Accessтм овозможен е влез и излез на податоци од други формати, односно од други апликации, како што се: Excel, dBase, Fox Pro, SQL Server, Oracle, HTML формат, текстуални формати итн.

3.1.1. Креирање релациска база на податоци во Microsoft® Accessтм 2013

База на податоци креирана во Microsoft® Accessтм е структурирана на тој начин што истата е составена од објекти како што се табели, форми, прашалници и извештаи. На следниот приказ (слика 3.1.) е даден опис на типот на објектите од кои е составена една база на податоци креирана во Microsoft® Accessтм..

За разлика од многу други апликации каде сите објекти се снимаат во посебни фајлови, во Microsoft® Accessтм целокупната база на податоци се снима како еден фајл, со формат или екстензија .mdb. На тој начин Microsoft® Accessтм функционира како еден голем склад.

Основни објекти за градба на база на податоци се табелите, каде иницијално се внесуваат податоците. За секој тип на информација се креира посебна табела. На пример: ако водиме евиденција за залихата на производи, потребно е да се креираат три одделни табели, и тоа табела за добавувачите, купувачите, како и табела за тековната залиха. Во овој случај табелата за залиха ќе содржи и податоци за купувачите и

46

добавувачите и на тој начин таа споделува исти информации со останатите две табели, што укажува на тоа дека тие се поврзани.

Објект ОписТабели (Tables) Претставуваат место каде се внесуваат и чуваат податоци.

Секоја табела се состои од колони (полиња) и редови (записи).

Прашалници (Queries) Прашалниците овозможуваат со поставување на одредени критериуми (прашања) да се изврши организирање, комбинирање и филтрирање на податоци со цел да се добијат само посакуваните информации.

Форми (Forms) Формите служат за преглед, внесување и промена на податоци надвор од табелата, односно обезбедуваат интеракција меѓу корисниците и табелите.

Извештаи (Reports) Овозможуваат печатење на информации добиени од табелите и прашалниците, во соодветна форма.

Страни (Pages) Web страни кои се поврзани со базата на податоци.Макро-и (Macros) Служат за автоматизирано извршување на серија од

наредби.Модули (Modules) Служат за поставување на процедури и функции поставени

и напишани од корисникот. Програмскиот код во модулот се пишува во Visual Basic..

Слика 3.1. Основни објекти на Microsoft® Accessтм релациска база на податоци.

Креирање на база на податоци.Со овој труд ќе биде опфатена најновата верзија од Microsoft® Accessтм, а тоа е

Microsoft® Accessтм 2013.Пред да почнеме со креирање на база на податоци, најпрво треба да го

стартуваме Microsoft® Accessтм. Стартувањето се прави преку десктоп иконата (која претставува кратенка за активирање на програмата) доколку е истата предходно креирана или најчесто од старт менито на Windows оперативниот систем, односно со командата Start > All Programs > Microsoft Office 2013 > Access 2013.

По стартувањето на Microsoft® Accessтм се отвора прозорец кој е прикажан на слика 3.2. преку кој треба да започнеме со креирање на нова база на податоци (или да ја отвориме постоечката база доколку веќе ја имаме креирано).

47

Слика 3.2. Почетен прозорец при стартување на Microsoft® Accessтм 2013.

Креирање на нова база на податоци се прави со избирање на опцијата Blank desktop database. Притоа се отвора нов дијалог прозорец (слика 3.3), на кој во полето File name треба да го наведеме името на базата која сакаме да ја креираме, а преку малата икона која има изглед на фолдер ја избираме локацијата каде што сакаме истата да биде снимена.

Слика 3.3. Прозорец за креирање нова база на податоци во Microsoft® Accessтм 2013.

48

После внесувањето на името на новата база на податоци и изборот на локацијата каде истата ќе биде снимена, кликнуваме на иконата Create, со што на екранот се појавува нова празна база на податоци која е спремна за складирање на податоци. Во овој прозорец се извршуваат најголемиот дел од операциите со објектите на базата на податоци. На следната слика е претставен почетниот прозорец на новата база на податоци:

Слика 3.4. Почетен прозорец на нова креирана база на податоци.

Копчињата за манипулација со прозорецот кои се наоѓаат на десната горна страна служат за максимизирање, минимизирање и затворање на прозорецот.

Насловната лента содржи податоци за името на базта на податоци, како и за локацијата каде истата е снимена.

На горната страна на прозорецот се наоѓа лентата со наредби, која е замена за старите палета Menu и палета со алатки кои беа користени во Microsoft Office програмите до верзијата 2003, на која се наоѓаат разни функции организирани во влошки (анг. tabs):

FILE – се користи за извршување на основните операции над базата (снимање, отворање на постоечка база или креирање на нова база)

HOME – содржи алатки за обработка на текст, сортирање, наредби за копирање, одсечување и прилепување.

CREATE – се користи за изработка на објекти – табели, прашалници, форми и извештаи.

EXTERNAL DATA – содрши алатки за контрола на внесените податоци. DATABASE TOOLS – содржи алатки за средување и поправка на базата,

алатки за прикажување на релациите и зависните објекти, Visual Basic едитор...

Кога е отворен некој објект во базата се отвораат дополнителни влошки, на слика 3.4. прикажана е нова влошка Алатки за табели (Table tools), која се појавила

49

после креирањето табела. Во лентата на секоја картица се наоѓаат функции на картицата организирани во логички групи.

Лентата со алатки за брз пристап (Quick Access Toolbar), кој служи за брз пристап до најчесто користените алатки.

На левата страна на прозорецот се наоѓа вертикална палета на која се прикажани сите објекти на базата:

Табели (Tables). Прашалници(Queries). Форми(Forms). Извештаи(Reports).

Табели. Табелата е објект кој ја сочинува основата на базата на податоци. Табелите во базата на податоци служат за складирање на податоци. Сите други објекти во базата можат само да манипулираат со податоците, но не и да ги складираат. Базата на податоци во Microsoft® Accessтм може да содржи стотина табели, а бројот на записите кои може да се сместат во сите тие табели не е со ништо лимитиран, освен со слободниот простор на мемориската единица.

Табелата по својата форма личи на мрежа и е составена од колони и редови. Колоните во табелата содржат полиња, а редовите записи. Полиња се категории, како: цена, телефонски број, шифра на корисник, во кои се внесуваат информации. Записи се сите информации од полињата кои се однесуваат на еден ентитет, како: вработен, оддел, добавувач итн. Пресекот помеѓу колона и ред претставува ќелија (анг. Cell).

Процесот на креирање на табела опфаќа неколку фази, а започнува со креирање на структурата на табелата. Прво, потребно е да се направи список на полиња со податоци. Секое поле во табелата мора да има име, кое би требало лесно да се памети и врз основа на него да се препознае намената на полето. Покрај името, секое поле треба да биде од одреден тип, а типот на полето зависи од видот на податоците кои ќе се чуваат во колоната.

Потоа, потребно е да се поврзат податоците во логичка целина, а со тоа ќе настанат табели. Табелите меѓусебно се повразуваат, со цел податоците од една табела да бидат достапни во друга табела. Таквото поврзување се прави со врски, односно релации кои се воспоставуваат помеѓу табели кои делат исти вредности.

Во Microsoft® Accessтм 2013 има два методи за креирање на табели:

Table Design – Се користи опцијата Design View за форматирање на табелата, односно за правење на структурата на табелата.

Table (Create) – Се користи за креирање на табели со директно внесување на податоци при иницијалното отворање на нова табела.

При креирање на нова табела во Microsoft® Accessтм, најчесто се користи Design View методот.

При креирање на нова база на податоци во Microsoft® Accessтм 2013, програмот отвора празна табела за внесување на податоци. За да се пристапи на Design View, со цел да се структурира табелата потребно е да се кликне на иконата View од влошката

50

Home, а потоа да се избере опцијата Design View. Доколку понатаму сакаме да креираме нова дополнителна табела, потребно е да се кликне на влошката Create и да се избере опцијата Table Design (слика 3.6.).

Слика 3.6. Икона за активирање на Design View опцијата.

Креирање табела со помош на Table Desiдn. Со избирање Table Design опцијата, иницијално се појавува тоа што се нарекува Design View. Design View прозорецот овозможува внесување на имиња на полињата, дефинирање на типот на податоците за секое поле и доделување на незадолжителен дополнителен опис на секое поле, како и дефинирање на одредени специфични својтва на полињата. Design View прозорецот е прикажан на слика 3.7.

Слика 3.7. Design View прозорец.

Прозорецот е поделен на два дела: во горниот дел се внесуваат имињата на полињата (Field Name), типот на податоците (Data Type) и детален опис кој не е

51

задолжителен (Description – optional), а во долниот дел се дефинираат специфичните својстава на полињата (Field Properties).

Field Name – Тоа е името на полето и ја претставува неговата содржина како “Име“, “Адреса“, “Позиција“ итн. Името не може да биде подолго од 64 карактери и може да содржи празно место.

Data Type – тоа е типот на вредноста која треба да биде внесена во полето. Во паѓачкото мени на полето Data Type се наоѓаат и можат да се изберат следните опции:

Short Text – Текстуален тип податоци кој дозволува каква било комбинација од букви и броеви, и може да содржи најмногу до 255карактери по запис.

Long Text – Ова поле е замена за полето Memo од претходните верзии на Microsoft® Accessтм, и тоа е од текстуален тип кое може да содржи најмногу до 65.536 карактери.

Number – Полето со ваков тип на податоци може да содржи само броеви. Date/Time – Полето со ваков тип може да содржи датум, време или

комбинација од двете. Currency – Содржи нумерички податоци во формат на валута. AutoNumber – Ваквиот тип на поле, кога се креира нов запис автоматски

генерира нов единствен цел број за новиот запис. Ова својство дава да се избере едно од двете можности: Increment и Random. Increment прави автоматски инкрементирање, односно зголемување за 1 на секој нов број за секој нов внесен запис. Опцијата Random избира случајни броеви.

Yes/No – Се користи за внесување на логички тип на податоци што одговара на True/False, On/Off или за избор на било која една, од две можни вредности.

OLE Object – OLE (Object Linkinд and Embeddinд) објект е звук, слика или друг тип на објект како Word документ кој е креиран во друг програм, а може да се вгради во табелата, со помош на OLE техниката.

Hyperlink – Ова е тип на врска која упатува на Интернет срана, на e-mail или на друга локација во базата на податоци.

Lookup Wizard... – Ваквото поле прикажува вредности кои можат де се изберат, а таквите вредности се содржани во друга табела или прашалник или пак се директно внесени.

Description – Во оваа колона се внесува поопширен опис на полето, односно неговата намена. Текстот што се внесува е ограничен на 255 карактери вклучително и празните места.

Field properties – Во овој дел од Design View прозорецот се внесуваат специфичните својства, односно карактеристики на секое поле. Field properties, овозможува поголема контрола на податоците кои се внесуваат во полињата од табелата.

Како најважни најчесто употребувани својства на полињата се следните:

Field size – Го одредува ограничувањето на големината на полето во однос на бројот на карактери кои можат да се внесат.

52

Format – Го одредува обликот, односно форматот во кој ќе бидат прикажани податоците.

Input mask – Претставува шаблон за внесување на сите видови податоци од текстуален тип и податоци од типот датум/време.

Caption – Претставува ознака (етикета) на полето, која се прикажува на формите и извештаите.

Required – Одредува дали внесувањето на податоци во одредено поле е задолжително или не.

Indexed – Се одредува индекс на полето, односно означува дали полето е индексирано или не.

Format е својство на полето кое одредува во каков облик ќе бидат прикажани податоците кои се внесени во одредено поле. Форматот зависи од предходно избраниот тип на поле:

Тext типови на полиња (Text & Memo data types)@ Задолжителен текстуален знак или празно место.& Незадолжителен текстуален знак или празно мест.< Претворање на голема буква во мала. (lowercase)> Претворање на мала буква во голема. (UPPERCASE)

Нумерички типови на полиња (Numeric & Currency data types)

. (точка) Претставува сепаратор на илјадарки.

, (запирка) Претставува сепаратор на стотки.0 (нула) Резервирано место за некоја цифра или доколку е празно се прикажува

0.# Резервирано место за некоја цифра или доколку е празно не се

прикажува ништо.% Вредноста се множи со 100 и се додава знакот %.

Input Мask својството ги одредува правилата за внесување на податоците во полето, односно претставува шаблон за внесување на сите видови податоци од текстуален тип и податоци од типот датум/време. Ова својство го олеснува коректното и безбедно внесување на податоците во полето.

За креирање на влезната маска (Input Mask), се користат следните знаци:

53

Влезна маска (Input Mask)0 Задолжитело е број од 0-9. Знаците “+“ и “-“ не се задолжителни.9 Опционални се број или празно место. Знаците “+“ и “-“ не се

дозволени.# Број и празно место се опционални. Празните места се прикажуваат

како празни места, но се отстрануваат при снимање на внесените податоци. Знаците “+“ и “-“ не се дозволени.

L Буква од A-Z е задолжително.? Буква од A-Z е опционално.A Задолжително е буква или број.a Опционално е буква или број.& Задолжително било каков знак или празно место.C Опционално било каков знак или празно место.. Ознака за децимално место., Сепаратор на илјадарки.

:;-/ Сепаратори за датум и време.< Сите знаци кои следат се претвораат во мали (lowercase).> Сите знаци кои следат се претвораат во големи (uppercase).! Знаците кои се пишуваат ја пополнуваат маската одлево надесно.

Знакот ! може да се вметне каде било во влезната маска.\ Знакот кој следи се прикажува како самиот знак.

После креирањето на табелата во Design View, доделувањето на име на полињата и дефинирање на специфичните својства, пред да прејдеме на снимање на табелата, потребно е да го одредиме примарниот клуч (анг. Primary Key).

Примарниот клуч е поле (или полиња) кое еднозначно го идентификува секој запис во табелата. Примарниот клуч се користи за да се воспостави врска помеѓу табели, со што се овозможува комбинирање и добивање на податоци од нив. Примарниот клуч е од суштинско значење за ефикасно работење на базата на податоци.

За креирање на примарен клуч, потребно е прво да се отвори табелата во Desig View, да се креира полето кое е предифинирано да биде примарен клуч, потоа тоа поле се селектира и со кликнување на иконата Primary key опцијата која се наоѓа во лентата со алатки, пред селектираното поле се појавува икона со клуч која означува дека тоа поле е примарен клуч на табелата.

Пред да се премине на пополнување на табелата со податоци, потребно е истата да се сними.

Релации меѓу табелите (Tables Relationship). Со поставувањето на релации табелите се поврзуваат меѓусебно, со што се

овозможува да се комбинираат податоците кои се сместени во секоја од нив.Еден од двата начина за воспоставување на релации во Microsoft® Accessтм 2013,

е со избирање на опцијата Relationship во Database Tools влошката.Но, пред да се направи релација:

54

- Две табели мора да имаат едно заедничко поле.- Полето во едната табела треба да биде означено како примарен клуч.- Соодветното поле во втората табела кое одговара на полето во првата е

познато како надворешен клуч.

Поврзувањето се прави едноставно со “drag & drop” со глувче, односно со кликнување и повлекување на полето од едната табела до соодветното поле во другата табела и испуштање врз второто поле., при што се појавува дијалог прозорец Edit Relationship кој е прикажан на слика 3.8, каде се прикажани и креирани релации помеѓу повеќе табели.

Слика 3.9. Прозорец за уредување на релации.

Референцијален интегритет (Referential Inteдrity). За обезбедување на конзистентност на врските помеѓу табелите, Microsoft®

Accessтм 2013 користи референцијален интегритет (анг. Referential Integrity), кој претставува систем од правила. Овој вид интегритет обезбедува да не може да се внесе запис во полето кое претставува надворешен клуч во некоја табела, доколку тој запис не постои во полето кое претставува примарен клуч во друга табела која е во релација со табелата на надворешниот клуч. Референцијален интегритет се обезбедува преку механизмот за воспоставување на релации меѓу табелите.

55

Во дијалог прозорецот Edit Relationship (слика 3.10) се наоѓа опцијата Referental Integrity, во рамките на која има две можности:

Cascade Update Related Fields. Cascade Delete Related Records.

Слика 3.10. Дијалог прозорец Edit Relationship.

Првата можност Cascade Update Related Fields обезбедува секоја промена направена на записите во примарниот клуч, да биде направена и во поврзаните табели каде тој примарен клуч се јавува како надворешен клуч.

Втората можноста Cascade Delete Related Records обезбедува доколку настане било какво бришење на записите во полето кое е примарен клуч во една табела, бришењето автоматски ќе биде спроведено во сите записи во сите поврзани табели каде тој примарен клуч се јавува како надворешен клуч. Оваа опција најчесто не се препорачува, бидејќи со нејзино користење може да се изгубат потребни податоци.

За да се направи бришење на некоја релација, потребно е само да се позиционира глувчето на линијата која ги поврзува табелите, да се кликне на десното копче на глувчето и да се избере опцијата Delete и веднаш потоа опцијата Yes за да се потврди бришењето.

Прашалници. За селекција на податоците од една или повеќе табели се користат прашалници (Queries). Со поставување на соодветни услови, од множеството на податоци од табелите, може да се издвојат само оние податоци кои ги задоволуваат

56

поставените услови. Прашалникот може да биде едноставно прашање за податоци кои се наоѓаат во една табела, а може да биде и сложено прашање кое се однесува на податоци разместени во повеќе табели. Како резултат на тоа се добива табеларен преглед во кој се прикажани само редовите и колоните кои се зададени во прашалникот.

Прашалниците можат да се изработуваат на два начина, и тоа со помош на волшебник или во дизајнерски режим на работа, односно:

Query Wizard Query Design

Microsoft® Accessтм 2013 располага со многу волшебници со чија помош може многу брзо и едноставно да се создаде одреден објект на базата на податоци. Но, поради нефлексибилноста на волшебниците, нивните решенија не ги задоволуваат барањата на корисниците, па поради тоа во такви случаи се користи дизајнерскиот режим за креирање на објектите, меѓу кои спаѓаат и прашалниците.

Постојат неколку видови прашалници, и тоа:

Select. Parameter. Crosstab. Action.

Select прашалникот е најчесто користен тип на прашалник. Овој вид на прашалник ги зема податоците од една или повеќе табели и резултатите ги прикажува во нова табела, притоа може да се прави и групирање на записите, пресметување суми, пребројување, како за други видови пресметки.

За креирање на Select прашалник со помош на волшебник во Microsoft® Accessтм

2013, во влошката Create се избира Query Wizard, при што се појавува дијалог прозорец New Query, каде по изборот на првата опција се добива нов дијалог прозорец за креирање на прашалници Simple Query Wizard.

Во овој дијалог прозорец се избираат табелите кои ги содржат бараните полиња.Веднаш под менито за избор на табелите, се наоѓа листа со достапни полиња за секоја избрана табела. Со копчињата “>“, “>>“, “<“ и “<<“ се избираат само оние полиња од секоја табела кои што се потребни во прашалникот.

Во следниот чекор по кликнување на командата “Next“ се појавува нов дијалог прозорец кој дава можност да се избере една од две можни опции, односно:

- Detail (детален прашалник)- Summary (збирен прашалник)

Во следниот чекор, по изборот на командата “Next“ се појавува последниот дијалог прозорец, каде се задава името на прашалникот и истиот се снима со самото избирање на копчето “Finish”.

57

За креирање на прашалници во Design View, потребно е да се избере опцијата Query Desig која се наоѓа во влошката Create, по што ќе се појави дијалог прозорец за креирање нов прашалник (иницијалното име на новиот прашалник е “query1“), заедно со Show Table прозорец (слика 3.11), од кој може да се изберат потребните табели или прашалници. Избраните табели и прашалници, како и релациите кои постојат помеѓу тие табели или прашалници, се појавуваат во query1 прозорецот. По што, прозорецот Show Table треба да се затвори и да се премине на следниот чекор.

Слика 3.11. Прозорците query1 и Show Table за креирање прашалници во Design View.

По затворањето на Show Tableпрозорецот, потребно е во долниот дел на прозорецот на новиот прашалник, во полињата Field и Table да се изберат бараните табели и полиња. Сортирањето на записите во растечки или опаѓачки редослед на определено поле се дефинира во редот именуван како Sort. Редот Show дава опција за прикажување или прикривање на одредено поле во табеларниот преглед на прашалникот. Во редот Criteria се дефинира критериумот во прашалникот, односно условот што треба да го исполнат записите во избраните табели, односно прашалници. Поставениот критериум служи за филтрирање на записите, со што ќе се прикажат само оние записи кои во целост го исполнуваат тој услов. На слика 3.12 прикажан е пример за поставен критериум со употреба на операторот Like, со кој се бара од прашалникот да ги прикаже само оние податоци за нарачките кои се однесуваат на добавувачот Витаминка.

58

Слика 3.12. Поставен критериум во прашалникот “Нарачки по Добавувачи“, со кој се врши прикажување само на нарачките доставени од добавувачот Витаминка.

Во следната табела се прикажани некои симболи и оператори кои се користат при креирање на критериуми во прашалниците.

Симболи и оператори за дефинирање критериуми во прашалници и нивно значење.* Означува произволен број на знаци.< Означува “помало од“

>= “Поголемо од или еднакво на“<> “Различно од“

Between “Помеѓу“Is Null Наоѓа записи без вредност.

Is Not Null Наоѓа записи со вредност.Like “Почнува со“And “И“Or “Или“

После селектирањето на табелите и полињата и поставувањето на критериумите, прашалникот се стартува со избирање на опцијата, односно копчето Run од лентата со алатки.

59

Форми. Формите (шаблони или обрасци) се користат како алтернативен начин за внесување на податоци во табели на базата на податоци. Формите овозможуваат полесен начин на внесување и промени на податоците, а служат и за прикажување на записите од табелите при што овозможуваат да бидат прикажани сите потребни полиња од сите поврзани табели истовремено. Една форма може да се користи и како контролна табла (анг. Switchboard), преку која ќе се отвораат други форми и извештаи. Формите се едни од основните елементи на т.н. кориснички интерфејс. Во Microsoft®

Accessтм 2013 има неколку начини за креирање на форми, но најкористени се двата начина кои се користат и за креирање на други објекти на базата на податоци, со помош на волшебник (Form Wizard) и во дизајнерски режим (Form Design).

Волшебникот за креирање на форми е корисен метод кој дозволува да се избере кои полиња да се појавуваат на формата. Идејата е да се создаде едноставен кориснички интерфејс кој ќе овозможи индиректно да се пристапи до табелите во базата на податоци, со цел да може да се додаваат нови записи, како и да се бришат и ажурираат веќе постоечките.

Креирањето на форма преку волшебникот, се прави на тој начин што се избира опцијата Form Wizard од Create влошката, по што се појавува дијалог прозорецот Form Wizard (слика 3.13).

Слика 3.13. Form Wizard дијалог прозорец.

Во Form Wizard дијалог прозорецот се избираат сите табели или прашалници, како и полињата од тие табели кои сакаме да бидат прикажани на формата која ја креираме. Откако ќе бидат избрани саканите полиња, со избирање на копчето “Next”. Во наредните чекори се појавуваат за избор опции поврзани со распоредот на полињата во формата, како и избор на стилот, односно дизајнот на формата.

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

60

Слика 3.14. Изглед на готова форма.

Извештаи. Извештаите (Reports) се слични на формите, имаат слични својства и се користат за прикажување на податоци. Извештаите претставуваат специјализиран облик за прикажување на податоците од табелите и прашалниците, кој е прилагоден за печатење. Табелите и прашалниците претставуваат извор на податоци за извештаите, при што не е задолжително во извештајот да бидат прикажани сите полиња од табелите или прашалниците.

Содржината на извештајот ја одредува корисникот за кој е наменет извештајот. Записите во извештаите можат да се групираат на повеќе нивоа, каде што можат да вклучат различни функции за пресметка, како збир, просек, минимум, максимум итн.

Слично како и кај изработката на формите и за изработка на извештаите има неколку методи, од кои обично се користат:

Report Wizard (изработка со помош на волшебник) Report Design (дизајнерски начин на изработка)

За креирање на извештај со помош на волшебник, едноставни во Create влошката се избира опцијата, односно копчето Report Wizard, по што се појавува Report Wizard дијалог прозорец (слика 3.15) во кој е дадена можност да се изберат табелите или прашалниците што ги содржат потребните полиња. По изборот на табелите, односно прашалниците и потребните полиња, се избира копчето Next, со што се отвора вториот чекор (слика 3.16) за креирање на извештјот, во кој се прави групирање на записите во зависнот од врските помеѓу табелите. Со избирање на копчето Next се преминува на следниот чекор, каде се прави сортирање и додавање збирни информации (слика 3.17).

61

Слика 3.15. Изглед на Report Wizard дијалог прозорец.

Слика 3.16. Групирање на записите во извештајот.

62

Слика 3.17. Сортирање на записите во извештајот.

По изборот на копчето Next се преминува на следните чекори во креирањето на извештајот: дефинирање на стилот на распоред на полињата и избор на изгледот на извештајот. Во последниот чекор се прави именување на извештајот, во овој дел може да се избере една од дадените две можности кои би се активирале по избор на копчето Finish, односно дали по завршување на креирањето и изборот на копчето Finish да се отвори извештајот во форма на преглед или да се отвори во форма за модифицирање, со што завршува креирањето на извештајот (слика 3.18).

Слика 3.18. Последен чекор именување и завршување на извештајот.Пример 1. Постапка за креирање база на податоци за следење на нарчки и залихата на

производи во замислена компанија, со сите потребни објекти. Називот на базата на податоци е “Контрола на нарачки“

63

1. Идентификација на ентитетите.

ДОБАВУВАЧИ – Компанијата има регистрирани добавувачи кои постојано доставуваат производи.

ВРАБОТЕНИ – Компанијата има одредено вработени кои се задолжени за правење нарачки на потребни производи.

ПРОИЗВОДИ – Компанијта набавува разновидни производи наменети за продажба.КАТЕГОРИИ – Производите со кои работи компанијата се поделени во разновидни

категории.НАРАЧКИ – Нарачките треба да се евидентираат, како според добавувачот, така и

според количината и вработениот кој ги прави.

2. Определување на атрибутите и клучот за секој ентитет

ДОБАВУВАЧИ – Шифра на Добавувач, Назив на Добавувач, Лице за Контакт, Адреса, Град, Држава, Телефонски број, Број на факс.

ВРАБОТЕНИ – Шифра на Вработен, Име, Презиме, Позиција, e-mail адреса, телефон на работа.

ПРОИЗВОДИ – Шифра на Производ, Производ, Опис на производ, Сериски број, Цена, Попуст.

КАТЕГОРИИ – Шифра на категорија, Категорија.НАРАЧКИ – Шифра на нарачка, Датум на нарачка, Датум на испорака.

3. Поставување на конечната релациска шема.

Добавувачи – ШифраДобавувач, НазивДобавувач, Име Контакт, Адреса, Град, Дршава, Телефонброј, ФаксБрој.

Вработени – ШифраВработен, Име, Презиме, Позиција, e-mail_адреса, Тел_работа.

Производи – Шифра на Производ, ИмеПроизвод, ОписПроизвод, ШифраКатегорија, СерискиБрој, Цена, Попуст.

Категории – Шифра на категорија, ИмеКатегорија.Нарачки – ШифраНарачка, ШифраДобавувач, ШифраВработен, ДатумНарачка,

ДатумПрием, ШифраПроизвод.Следење на нарачките – ШифраПрием, ДатумПрием, ШифраПроизвод,

ШифраНарачка, Цена, КоличинаНарачка, ПрименаКоличина, ПродаденаКоличина.

4. Претворање на релациската шема во табели на базата на податоци.

Табела Добавувачи:ШифраДобавувач, Data Type = AutoNumber,

64

НазивДобавувач, Data Type = Text, Field Size = 50,Име Контакт, Data Type = Text, Field Size = 50, Адреса, Data Type = Text, Field Size = 255,Град, Data Type = Text, Field Size = 50,Држава, Data Type = Text, Field Size = 50,Телефонброј, Data Type = Text, Field Size = 30,

Input Mask = !\(999") "00\-000\-000ФаксБрој. Data Type = Text, Field Size = 30,

Input Mask = !\(999") "00\-000\-000

Табела Вработени:ШифраВработен, Data Type = AutoNumber,Име, Презиме, Data Type = Text, Field Size = 50,Позиција, Data Type = Text, Field Size = 50,e-mail_адреса, Data Type = Text, Field Size = 50,Тел_работа. Data Type = Text, Field Size = 30,

Input Mask = !\(999") "00\-000\-000

Табела Производи: Шифра на Производ, Data Type = AutoNumber, ИмеПроизвод, Data Type = Text, Field Size = 50,ОписПроизвод, Data Type = Text, Field Size = 255,ШифраКатегорија, Data Type = Number,СерискиБрој, Data Type = Text, Field Size = 50,Цена, Data Type = Currency,Попуст. Data Type = Yes/No

Табела Категории:Шифра на категорија, Data Type = AutoNumber,ИмеКатегорија. Data Type = Text, Field Size = 50,

Табела Нарачки: ШифраНарачка, Data Type = AutoNumber, ШифраДобавувач, Data Type = Number,ШифраВработен, Data Type = Number,ДатумНарачка, Data Type = Date/Time,

Input Mask = 99.99.00;0ДатумПрием, Data Type = Date/Time,

Input Mask = 99.99.00;0ШифраПроизвод. Data Type = Number

Табела Следење на нарачките: ШифраПрием, Data Type = AutoNumber,ДатумПрием, Data Type = Date/Time

Input Mask = 99.99.00;0,

65

ШифраПроизвод, Data Type = Number,ШифраНарачка, Data Type = Number,Цена, Data Type = Currency,КоличинаНарачка, Data Type = Number,ПрименаКоличина, Data Type = Number,ПродаденаКоличина. Data Type = Number,

5. Поставување на релациите помеѓу табелите во базата на податоци.

Поставените релации помеѓу табелите во базата на податоци “Контрола на нарачки“ прикажани се на слика 3.18.

Слика 3.19. Релации помеѓу табелите во базата на податоци “Контрола на нарачки“

6. Креирање на Формите за внесување на податоци во табелите.

Формите се креирани со помош на волшебникот за креирање форми (FormWizard). Притоа креирани се форми за табелите: Добавувачи, Вработени, Категории, Производи, Нарачки.

Во оваа фаза креирани се и две потформи во кои се вклучени и дополнителни пресметки, односно креирана е потформа Нарачки во која е пресметан вкупниот износ во пари за целата количина на секој нарачан производ и потформа Производи во која се

66

внесени и податоци за количината на продадените производи. На слика 3.20 е преставена формата Нарачки, а на слика 3.21 е претставена формата Производи.

Слика 3.20. Изглед на формата “Нарачки“

67

Слика 3.21. Изглед на формата “Производи.

7. Креирање на прашалниците.

Во оваа фаза направени се три прашалници за што е користен дизајнерскиот начин за нивно креирање. Притоа направени се прашалници со кои се врши пребарување на нарачките според неколку критериуми.

Направен е прашалник во кој се прикажуваат нарачките врз основа на вработените кои ги направиле, при што има можност да се стави дополнителен услов со што ќе може да се прегледаат нарачките на секој вработен пооделно.

Вториот прашалник ги прикажува добавувачите кои ни ги доставиле нарачките, при што исто така може да се стави критериум за прикажување на доставените нарачки на конкретни добавувачи.

Во третиот прашалник се прикажани сите нарачки според редоследот на нивното креирање, а прикажани се и производите по назив, количините на набавените производи, количините на примените производи, цените на производите, како и продадените производи, со што целосно може да се следи било која направена нарачка.

На сликите 3.22 и 3.23, прикажан е прашалникот “Нарачки по вработени“, во дизајнерски режим и во табеларна форма, без назначени посебни критериуми.

68

Слика 3.22. Изглед на прашалникот “Нарачки по вработени“ во Desing View.

Слика 3.23. Изглед на прашалникот “Нарачки по вработени“ во табеларна форма.

69

8. Креирање на извештаите.

Во базата на податоци “Контрола на нарачките“ креирани се два извештаи, од кои едниот ги прикажува количините и цените на производите кои се нарачани. Додека другиот ги прикажува и продадените количини, како и преостанатите залихи.

На следната слика 3.24 е прикажан изгледот на извештајот “Преглед на нарачките по цени и количини“.

Слика 3.24. Изглед на извештајот “Преглед на нарачките по цени и количини.

На следната слика 3.25 е прикажан изгледот на извештајот “Детали за нарачките и залихите на производите“.

70

Слика 3.25. Изглед на извештајот “Детали за нарачките и залихата на производите.

Со креирањето на извештаите завршено е креирањето на базата на податоци “Контрола на нарачките“. Со добивањето на точни податоци во извештаите и прегледите се потврдува ефикасното функционирање на базата на податоци.

71

ЗАКЛУЧОК

Бизнис процесите се вистинска причина за постоењето на базите на податоци. Важноста на базите на податоци е во тоа што во голема мерка го олеснуваат организирањето на податоците кои се потребни за секојдневното деловно работење. Базите на податоци овозможуваат достапност и прегледност на податоците кои се наоѓаат на едно место, со што работењето го прават да биде поедноставно и поквалитетно.

Релациските бази на податоци претставуваат најчесто користената технологија која ги подобрува бизнис процесите до нивната максимална ефикасност, пред се со нивно автоматизирање. Недостатокот на ефикасно пребарување на информации, редунданост на податоците и безбедност на податоците е главен проблем кој најчесто се среќава во таквите автоматизирани процеси. На пазарот се наоѓаат моќни технологии за работа со бази на податоци, а главни играчи на тој пазар се Oracle и Microsoft (SQL server и MS Access) кои обезбедуваат напредни сервиси. За безбедно и максимално искористување на тие производи за работа со бази на податоци, потребно е внимателно спроведување на дизајнот на базите на податоци. Бидејќи добриот дизајн е основата на секоја база на податоци, за да се постигне истиот потребно е внимателно анализирање на бизнис целите и потребите за креирање на базите на податоци.

При практично работење со бази на податоци се доаѓа до потврда на предходно изнесениот став за значењето на дизајнот на базата и анализа на вистинските потреби за нејзино креирање и одржување, од тие причини во последното поглавје на овој труд беше креирана база на податоци за измислена компанија. За да се добијат точни информации и прегледни извештаи, во посочениот пример потребно беше да се направи добра анализа на тоа што базата ќе содржи и што ќе се бара да прикажува, а за сето тоа беше потребно да се направи и соодветен дизајн на базата на податоци.

72

КОРИСТЕНА ЛИТЕРАТУРА:

[1] проф. Д-р Коста Сотироски, Д-р. Илија Христоски, “Деловна информатика“, Економски факултет - Прилеп, Прилеп, 2010

[2] Harmon P., “Business Process Chanдe Secon edition“, Morgan Kaufmamm in print of Elsevier Inc., Burlington, 2007

[3] Hajo A. Reijers, “Desiдn And Control Of Workflow Processes“, Springer-Verlag Berlin Heidelberg, NewYork, 2003

[4] Д-р. Сашо Јосимовски, “Информациски технологии“, Економски факултет - Скпоје, Скопје, 2011

[5] M. Varga, “Baze podataka – Konceptualno, loдičko i fizičko modeliranje podataka”, DRIP, Zagreb 1994

[6] Robert Manger, “Baze Podataka”, Sveučilište u Zagrebu, Zagreb, 2008[7] David M. Kroenke, David J. Auer., “Database concepts“ - 6th ed., Prentice Hall, New

Jersey, 2013[8] Peter Rob, Carlos Coronel, “Database Systems: Desiдn, Implementation, and

Manaдement, Seventh Edition“,Thomson Learning, Inc., Boston, 2007[9] Hector Garcia-Molina, Jeffrey D. Ullman, Jennifer Widom, “Databese systems

The Complete Book Second Edition“, Pearson Prentice Hall, New Jersey, 2009[10]  Avi Silberschatz, Henry F. Korth, S. Sudarshan, “Database System Concepts, Fourth

Edition“, McGraw−Hill, NewYork, 2001[11] Toby J. Teorey, Sam S. Lightstone, Thomas P. Nadeau, “Database Modelinд and

Desiдn: Loдical Desiдn Fourth Edition “, Morgan Kaufmamm in print of Elsevier Inc., San Francisco, 2006

[12] Slavomir Vukmirovic, “Modeliranje i analiza podataka u poslovanju“, Ekonomski fakultet Sveucilišta u Rijeci, 2013

[13] Gavin Powell, “Beдinninд Database Desiдn“,Wiley Publishing, Inc., Indianapolis, 2006

[14] Ryan K. Stephens, Ronald R. Plew, “Database Desiдn“, Sams Publishing, Indianapolis, 2001

[15] Steven Roman, “Access Database Desiдn & Proдramminд, 3rd Edition“, O’Reilly & Associates Inc., Sebastopol, 2002

[16] Teresa Hennig, Rob Cooper, Geoffrey Griffith, Jerry Dennison, “Microsoft Access 2010 Programmer’s Reference“, Wiley Publishing, Inc., Indianapolis, 2010

[17] Joyce Cox, Joan Lambert, “Microsoft Access 2013 Step by Step“, Microsoft Press, Washington, 2013

[18] Raghu Ramakrishnan, Johannes Gehrke, “Database Management System 3rd Edition“, McGraw−Hill, NewYork, 2002

73