УПРАВЛЕНИЕ НА ДАННИТЕ В ИНФОРМАЦИОННИТЕ СИСТЕМИ

Въведение.

Нови форми на информационните ресурси.

Информационните ресурси са данните и информацията под формата на документи и съдържание.

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

Информацията под формата на документи (електронни или хартиени) и уеб съдържанието увеличават размера на БД, които организациите управляват. С дигиталния звук, изображения, снимки, видео и 3D модели размерът на файловете нараства значително. За разлика от структурираните данни, тези неструктурирани форми на информацията не е лесно да бъдат индексирани, за да се използват за различни по-нататъшни цели.

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

Управлението на информационните ресурси възниква като дейност от началния период, в който данните се съхраняват във файлове или архиви. След това се създават корпоративните бази от данни, които са добре дефинирани структури и се администрират от ИТ департаментите на организациите. По-нататък терминът разшири съдържанието си като включи информацията, т.е. данните, които съобразно със своето съдържание притежават определен смисъл, за този, който ги използва. В тази категория се включват корпоративни доклади, архиви по теми, знания в определена област. С използването на интернет възникна и терминът управление на съдържанието – текст, звук, графика, видео и анимация.

Дефиниции

· Данните включват факти, необвързани с определен смисъл или значение, като смисълът и значението се определят от конкретното използване.

· Информацията представлява данни в определен контекст (връзка), което означава, че данните имат ясно определено значение в специфичен контекст. Използва се и терминът съдържание в контекста на информацията, най-често във връзка с интернет. Съдържанието включва информация, представена в различни носители – графика, текст, звук, глас, анимация, снимки, диаграми, видео.

· Знанието е информация с определена насока или значение, което се определя от конкретни стратегии или цели.

Например – данните са цифрите 1 и 1,46933 (фиг. 1) – това са само цифри, които не означават много. Но, ако се поставят в определен контекст – например съотношение между две валути, положението се променя. Съответно, може да се трансформира в графика вариацията на съотношението между валутите за определен период от време, което означава много за анализаторите и бизнесмените.

Фиг.1

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

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

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

Управление на данните

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

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

По отношение на данните се въвеждат правила и процедури, за да се осигури целостта и коректността им. Например, правило – ако се изтегли от сметка сума по-голяма от 500, балансът по сметката трябва да бъде най-малко – 700.

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

СУБД са основани на два основни подхода – създаване на концептуален модел на 3 нива и разработване на алтернативни модели за организация на данните.

Концептуален модел на 3 нива (James Bradley, James Martin)

Фигура 1

Софтуерна трансформация

Софтуерна трансформация

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

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

Ниво 3 е физическо ниво, или ниво на съхранение. Специфицира начините за физическо съхранение на данните – записи, полета и допълнителни типове, свързани с обработката на данните - броячи, флагове. Тези допълнителни типове не интересуват крайния потребител, а са свързани с операциите върху данните.

Предимството на този подход е, че при промяна на начина на съхранение на данните на ниво 3, не е необходимо да се извършва промяна в приложенията на ниво 1, а ниво 2 поема промените. Данните само трябва да са съхранени на ниво 2 и различните програми ще ги използват и ще създават необходимите връзки.

Четири модела на данните.

Йерархичен

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

Мрежови

Разработен е като множество от стандарти и спецификации от Conference on Data Systems Languages (Data Base Task Group). Този подход е сравнително по-гъвкав, съдържа записи под формата на дърво, но моделът позволява всеки запис да има много родители и съответно – деца, които образуват структура, подобна на решетка, или мрежа.

Достъпът до данните се осъществява чрез индекс (pointer), съхранен към данните. В сравнение с йерархичния модел, този модел позволява по-бърз достъп до данните.

През 1970 г. Charles Bachman комбинира двата модела, като по този начин се съчетават предимствата им – по-лесно използване и по-бърз достъп. Използват се правила за навигация при търсенето като се въвеждат термините следващ/предишен, първи/последен, нагоре/надолу.

Релационен

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

На всеки запис се присвоява ключ, който е уникален. Например за служител – ЕГН, за БМ – инвентарен номер. Чрез този ключ се осъществява връзка на същността с други същности.

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

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

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

Най-мощните ИТ компании – IBM, Sybase, Informix, Oracle, Microsoft разработиха СУБД и SQL (Structured Query Language) стандартен език за управление на данните.

Пример.

Нормализация на база от данни

През 1970 г. E. F. Codd дефинира 3 правила за проектиране на база от данни, наречени нормални форми. След това се оформят още такива правила.

Чрез нормализирането на базата от данни се постигат следните резултати:

• Идентифицират се зависимостите между данните
• Излишните данни (и свързаните с тях проблеми) намаляват
• Моделът на данни става гъвкав и лесен за поддържане

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

Таблиците, върху които още не е прилаган процес на нормализация, са в 0НФ – нулева нормална форма.

1 НФ – Първа Нормална Форма – Премахване на повтарящи се атрибути

Разгледайте таблица Student:

За същността Student ни е необходимо да пазим информация за име, фамилия, ..., завършени степени (ако има бакалавърска или магистърска степени), кога са завършени или са в процес на завършване. Тъй като е възможно да има повече от една степен, се предвиждат две. Възниква въпрос: ако има с три степени? Трябва да променяме таблицата? И за всички онези, които имат само по една степен в процес на вземане, ще има излишни 8 атрибута. Решението е да се приведе таблицата в 1НФ чрез елиминиране на повтарящите се групи от атрибути и изнасянето им в нова същност.

2 НФ – Втора Нормална Форма – Премахване на частичните зависимости от ключа.

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

Да разгледаме диаграма, подобна на предишната, с един допълнителен атрибут DegreeCreditsRequired.

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

Решението е да се приведе таблицата в 2НФ чрез създаване на нова същност Degree и да се създадат съответните връзки.

Нарушение на 2НФ може да се получи при съставни първични ключове (повече от един атрибут).

3 НФ – Трета Нормална Форма – Премахване на зависимости между неключови атрибути

Да разгледаме същността Class:

Разгледайте внимателно всеки неключов атрибут и си задайте въпроса: Дали този атрибут зависи единствено и само от първичния ключ?

При така избраното представяне TeacherFirstName и TeacherLastName зависят от TeacherID, a CourseName зависи от CourseNumber.

Решението е да се приведе таблицата в 3НФ чрез създаване на нови същности и да се създадат съответните връзки.

Чрез привеждане в 3НФ се премахват излишните данни.

Съществува и обратен процес – денормализация – когато се обединяват същности с цел по-бързо изпълнение на заявки към базата от данни. Дори ако погледнете в примера за 1НФ има още повтарящи се групи от атрибути – например Billing Address – но от бизнес гледна точка е решено, че няма да се пазят повече от два адреса и затова не е направена нормализация по този атрибут.

Обектно ориентиран

Разработен е на основата на обектно ориентирания подход при системите.

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

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

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

Корпоративни данни

Администриране на данните и информацията – управление на всички компютеризирани ресурси в организацията.

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

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

Подходът, при който данните са водещия ресурс (data driven) изисква да се въведе административен контрол върху данните, както и при проектиране и разработване на БД. Стартира се с описание на данните, които са нужни на предприятието. Избира се подход, който да удовлетворява изискванията към данните и приложенията в зависимост от краткосрочните и дългосрочните цели.