Информационни технологии & Интернет

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

Локални представи на потребителите

Чрез обследване и изучаване на локалните представи на потребителите (ЛПП) се съставят документи, наречени “профили” – профил на потребител, профил на работно място, профил на отдел и др.под.
Цялостното дефиниране на предметната област се извършва чрез обобщаване на локалните представи на потребителите и формирането на тяхната основа на единна логическа схема. Логическата схема отразява начина, по който проектантът на базата от данни вижда предметната област. Логическата схема е модел на предметната област. Този модел е съставен без оглед на никакви ограничения, които външната среда би могла да наложи.

Архитектура на системите с база от данни

След съставяне на логическата схема последователно се изграждат физическа, вътрешна схема на даните и външни (потребителски) схеми. Това е процес на преобразуване на логическата схема във физическа, вътрешна и външни схеми.
Моделирането на предметната област, извършено със средствата на избран модел на данните и при отчитане на ограниченията, налагани върху проекта на базата от данни, се нарича физическа схема. При използване на релационния модел на данните, физическата схема е набор от много таблици (всяка от които е изградена по схемата на някаква релация) и набор от ограничения за стойностите, които се въвеждат и съхраняват в таблиците. Схемите на таблиците и ограниченията за стойностите зависят от свойствата на предметната област и от информационните нужди на потребителите.
Описание на физическата схема, извършено с оглед на вътрешното представяне на данните и техните структури, се нарича вътрешна схема на базата от данни.
За отделните потребители на базата от данни е интересна само част от данните за предметната област. Това означава, че разглеждайки схемата като цяло, за отделните потребители трябва да се дефинират различни независими абстрактни понятия. Физическата схема се използва като еталон за отделяне и преобразуване на части на базата от данни, които са непосредствено свързани с приложенията. Такива части се наричат външни схеми. Моделът на данните, използван при построяване на физическата схема, се прилага също и за формиране на външните схеми. За една предметна област се съставя една физическа схема и голям брой външни схеми (примерно, по една или повече външни схеми за всеки потребител). При формиране на външните схеми се имат пред вид особеностите на избраната СУБД. Поради това създаването на външните схеми среща специфични трудности. За преодоляването им в съвременните системи с база от данни се създават няколко нива на външните схеми, отразяващи различните функции, свързани с управлението на информацията, управлението на приложенията и управлението на базата от данни.

Качество на схемата на база от данни

Качеството на проектираната схема на базата от данни се определя според степента на съответствие с критерии за качество (С1 – С5), базирани на следните три принципа:
Схемата на базата от данни следва да бъде съставена така, че да създава предпоставки СУБД автоматично да поддържа ограниченията за запазване на интегритета на данните. Тези ограничения са насочени главно към осигуряване на контрол над излишеството на данните и към отстраняване на аномалиите, които могат да се проявят при въвеждане, изтриване и актуализиране на данните.
Схемата на базата от данни се съставя така, че да бъде ориентирана към най-често извършваните запитвания и към критичните по време и (или) по мисия
запитвания (запитвания с висок приоритет). В схемата на базата от данни следва да се осигурят пътища за изпълнението на такива запитвания.
Схемата на базата от данни трябва да способства за осигуряване на
непроцедурност на операциите за манипулиране на данните.

Проектиране на информационни системи с база от данни

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

Главните цели на проектирането са:

1. създаване на информационна база;
2. създаване на приложна програмна система за работа с информационната база.

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

Основни изисквания

• Коректност на схемата на информационната база
• Схемата е коректна, когато на всеки обект от предметната област съответстват данни в информационната база, а на всеки процес в предметната област съответстват процедури на обработка на данните.
• Резултатът от един процес в предметната област трябва да съвпада с резултата от съответната процедура за обработка на данните. Може да се изисква периодично спазване на това съответствие, или може то да се изисква непрекъснато, във всеки момент от времето. Такава схема се нарича хоморфен модел на предметната област.
• Работоспособност при наложени ограничения. Това е способността на системата да функционира пълноценно при ограничения, налагани от апаратната платформа, операционната система и системата за управление на базата от данни. Най-съществени ограничения са обемът на достъпната оперативна памет и обемът на достъпното дисково пространство.
• Ефективност. Ефективност на информационната база означава, че желаните резултати от функционирането на системата се получават при минимално използване на ангажираните ресурси и максимално бързодействие (реактивност) на системата при обработка на запитвания за извличане (четене) на данни и модифициране на данни (вмъкване, изтриване, актуализиране). Информационната база от данни трябва да предоставя възможност за максимална ефективност на информационната система като цяло.
• Защитеност на данните при аварии, некоректни актуализации и неразрешен достъп до данните. Някои от функциите за осигуряване на защитеност на данните се изпълняват от СУБД, а други – от приложните програми. Информационната база трябва да облекчава изпълнението на тези функции.
• Допълнителни изисквания – Простота и удобство при експлоатация на информационната система.
• Интуитивен и ясен потребителски интерфейс. Защита срещу несръчни и неправилни действия  на потребителя.  Възможност за прекратяване и  възстановяване  на действията на потребителя във всеки момент от времето и без опасност за нарушаване интегритета на данните.
• Гъвкавост и адаптивност на информационната система
• Системата трябва да допуска да бъде развивана и адаптирана към измененията в предметната област и към нарастващите информационни нужди на потребителите.

(Допълнителните изисквания се вземат под внимание при сравняване на алтернативни проекти).
Задачите на процеса на проектирането са да се създаде система с база от данни, притежаваща задължителните изисквания и, по-възможност, с най-високи показатели на спазване на допълнителните изисквания. Казано с други думи, основните задачи са две:

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

Група за проектиране на информационната система

От практиката е известно, че проектирането на система с база от данни се извършва най-успешно от екип, съставен от 3 – 4 специалисти.
Обикновено, проектирането се ръководи от бъдещия администратор на информационната система. Ако той няма достатъчно опит в подобно проектиране, тогава му е необходим консултант по информационни системи. Задачите на консултанта са да насочва дейността на администратора, да подсказва алтернативни варианти, да помага при анализирането на слабите и силните решения в проекта.
За да се проектира информационна система, например с икономическо предназначение, администраторът на информационната система не трябва да бъде специалист в икономиката, а специалист по информационни системи. Той дори може доста смътно да си представя разликата между “дебит” и “кредит”. Ето защо му е необходим консултант, който познава предметната област (в примера – икономист).
Възложител на проекта е администраторът на предметната област. Възложители са и администраторите на секторите от предметната област – те са компетентни и упълномощени да вземат решения. Тези лица оказват влияние върху предметната област. Към възложителите могат да бъдат причислени и многобройните крайни потребители. Групата на проектантите, обаче, счита за възложител основният носител на сведения за предметната област. Той е и основният източник на изисквания към информационната система. Същото лице (или лица) носи отговорност за информацията, която предава на групата за проектиране. Най-често това е консултантът по предметната област.
В групата на проектантите се включва лице, което в трите фази на проектирането води документацията на разработваният проект.
Когато информационната система бъде готова и включена в действие, това лице оперативно контролира функционирането на системата и управлява колективното използване на информационната база от много потребители, както и следи разработването и настройването на нови приложения. Това лице се нарича супервайзор (диспечер).

Диспечерската дейност е много важна, тъй като при настройката на приложенията могат да възникнат конфликтни ситуации, които трудно се изясняват. Например, едно настройвано приложение вмъква в базата нови записи и след известно време се опитва да разпечата тези записи. Междувременно друг програмист настройва своя приложна програма за изтриване на записи. Диспечерът трябва да предотвратява (доколкото е възможно) подобни ситуации, като използва подсистемата на СУБД за даване права на достъп на потребителите до различните подмножества на данните.

Жизнен цикъл на информационните системи

Животът на информационната система започва с нейното проектиране (“хартиен” период). По-нататък следва реализацията на системата и, накрая, периодът на нейната експлоатация.
Жизнения цикъл на система с база от данни се състои от следните фази:

• Анализ.
• Проектиране.
• Разработване.
• Реализация.
• Поддръжка.
• Анализ

В края на тази фаза се получава резултат: два модела – концептуален модел на данните и концептуален модел на процесите в предметната област.

Концептуалният модел на данните описва информацията, която се използва в предметната област. Описанието не е в термини, отнасящи се до компютърната сфера, а в термини, разбираеми за бъдещите крайни потребители (и за възложителя) работещи в предметната област. Един от проблемите при проектиране на система за голяма предметна област е, че трябва да се работи постепенно и на части – една по една. Не е възможно с един замах да се създаде тотално нова глобална по обхват система. Всяка подсистема трябва да бъде сглобена точно (“да пасне”) с останалите подсистеми и това може да се постигне на съвсем друг етап от разработката.
Концептуалният модел на данните осигурява контекст за разработване на по-детайлизиран проект и помага за поддържане на съгласуваността на една приложна област с друга.
Концептуалният модел на процесите описва функциите, изпълнявани в предметната област. Описанието е в термините на събитията (например, продажби, плащания, доставки,… ) и процесите, с които се изпълнява всяка функция. Този модел е основа за разработване на подробна спецификация на процесите. Със спецификацията се описват изискванията, налагани от деловата дейност в предметната област и които трябва да бъдат удовлетворени. (На този етап, обаче, не се иска описание на начина, по който да се постигне спазването на изискванията).

Проектиране

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

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

Разработване

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

Реализация

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

Поддръжка

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

Елементи на процеса на проектиране на система с база от данни

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

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

Фаза 0. Концептуално проектиране

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

Етап 0.1

Списък на секторите на предметната област, които ще бъдат обхванати от информационната система. Какви са перспективите за развитие на предметната област и кои сектори предстои да бъдат включени в информационната система при следващото й разширяване.
Какви са информационните нужди на всеки сектор (изясняване на съдържанието и характеристиките на информацията, необходима за всеки сектор от предметната област).
Списък на процесите по обработка на информацията (накратко: информационни процеси) и техните характеристики във всеки сектор. Към характеристиките се включват: честота на извършване на процесите, изисквания към времето за извършването им, специфични техни особености.
Списък на потребителите (и съответствие между потребителите и секторите). Списъкът на потребителите се разделя на именувани групи. Описват се специфичните характеристики на всяка група потребители, честота на техните запитвания за информация, какви процеси инициират потребителите.
Описание на съществуващата технология за събиране и обработка на информацията в предметната област.
6. Описание на съществуващата техническа база за обслужване на информационните процеси, скорост на обработката, честота на постъпване на данните, обем на информационните потоци. Къде са техните места в съществуващата информационна технология, които са причинили разработването на новата информационна система.

Етап 0.2

Определят се изискванията към разработваната нова информационна система:
Каква техническа база е необходима за новата информационна система.
Ако вече съществува компютърна информационна система, каква е нейната обща структура, какво е взаимодействието на информационната система с други автоматизирани системи (ако има такива) .
Експлоатационни характеристики на новата разработвана информационна система: време за реакция, степен на надеждност, гъвкавост (способност да се адаптира към възможните изменения на предметната област).
Технология на функционирането на новата информационна система. Как ще постъпва новата информация ? Как различните групи потребители взаимодействат със системата? Как се коригира информацията? Кои служби отговарят за правилността на постъпващата в системата информация?

Фаза 1. Логическо проектиране
Етап 1.1. Общ обзор на предметната област. Етап 1.2. Определяне на обектите.
Етап 1.3. Формализация на процесите. Анализ на очакваните запитвания към БД. Етап 1.4. Изясняване на връзките между обектите.
(Етапите 1.2, 1.3, 1.4 се извършват последователно за всеки сектор от предметната област. На Етап 1.5 резултатите се интегрират в логическа схема на данните за предметната област).
Етап 1.5. Съставяне на логическа схема и проверка за коректност на логическата схема (проверката се извършва съвместно с представител на възложителя -консултант по предметната област).
Фаза 2. Физическо проектиране
Етап 2.1. Изясняване на външните ограничения. Етап 2.2. Подбор и описание на СУБД-претенденти.
Етап 2.3. Моделиране на схемата на информационната база (извършва се за всяка СУБД – претендент).
Етап 2.4. Сравнителен анализ на моделите на информационната база.
Етап 2.5. Решение за избор на СУБД.
Фаза 3. Реализация
Етап 3.1. Конструиране на схемата за съхраняване на базата от данни (физическо проектиране на базата от данни).
Етап 3.2. Разработване на приложните програми.
Етап 3.3. Документиране на технологията за работа с информационната система.

Концептуален модел на данните

Проектирането на база от данни по метода “отгоре-надолу” започва с концептуално моделиране. Целта е да бъде описана информацията, използвана в предметната област, по начин независещ от условията на прилагането й и от подробностите на това прилагане (създаване на концептуален модел на информационните дейности в предметната област). Картината на предметната област лесно се вижда чрез концептуалния модел. Този модел не съдържа технически подробности, така че при обсъждането му успешно могат да участват бъдещи потребители, които не са специалисти по информационни системи с база от данни.
В тази фаза на изучаване и обследване на предметната област (Фаза 0), проектантите тясно взаимодействат с представителя на възложителя (консултанта по предметната област). Първоначалното запознаване с предметната област се извършва при първата среща между възложителя и проектантите. Целта е да се формира началната представа за предметната област. По време на тази среща не се обсъждат детайлите. Проектантите не са длъжни да изучават предметната област на нивото на възложителя. Ако един проектант реши незабавно да усвои всички детайли, предметната област ще му се стори необятна, а проблемите – нерешими.
След първоначалното запознаване с предметната област започва детайлното изучаване на всички нейни сектори. Крайните потребители имат своя представа за всеки сектор (ЛПП, локални представи на потребителите за предметната област). Ето защо всички следващи срещи с този вид възложители се различават от първата среща. Сега инициативата принадлежи на проектантите. Те подготвят списък с въпроси, но така, че потребителите да отговарят с “ДА”, “НЕ” или с числен параметър.
Полезно е да се обясни на потребителите, че техните неточни отговори на поставените въпроси ще имат за последствие допълнителни разходи за преработване на проекта или дори на готовата система, ще се намали ефективността й, ще се оскъпи обслужването й. Ето защо се налага писмено документиране на въпросите и отговорите, като всеки от протоколите се подписва от представителя на възложителя, който е дал отговорите. Данните, съдържащи се в протоколите, формират профил на потребителя (и, съответно: профил на работното място, на отдел и т.н). По този начин проектантите планомерно опознават предметната област в онзи обем, който е необходим за разработване на информационната система. Секторите от предметната област се изучават последователно. Сведенията за поредния сектор се интегрират към сведенията за предходните сектори. Тази именно интеграция формира логическата схема на предметната област.
Анализ на информацията, събрана при изпълнението на Фаза 0, се извършва във Фаза 1 – логически проектиране. През тази фаза се дефинират същностите (обектите) в предметната област, дефинират се техните атрибути (характеристики и свойства на същностите) и се дефинират отношенията между същностите в термините на ограниченията за запазване на интегритета на данните. В резултат се получава
Определяне на обектите
За определяне на обектите, проектантите се запознават (за всеки сектор) с всички разновидности на входните и изходните документи (справки, запитвания, …).
Първо се определя какъв тип информационна система предстои да бъде създадена -  фактографска  или  документална.   Ако  новата  система  ще  бъде  хибридна
(документално-фактографска), каква е разновидността на информацията, представяна в съответните документи.
В документалната система, обект на съхраняването и обработката са документите. Тогава, следва да се определи каква е възможната структура на всеки от използваните документи.
Във фактографската система се борави със същности (ентитети, обекти). Сведенията за същностите могат да се съдържат в множество документи (и съобщения), които имат нееднакви формати. Във фактографските системи, интерес за предметната област не е документът, съдържащ някакви сведения, а самите сведения.
Определянето на обектите е итеративен процес. Той започва със съставяне на списък на атрибутите. Отначало списъкът на атрибутите се съставя по едно съобщение (документ) или по група съобщения (документи). Това се извършва за всеки сектор. Когато разновидностите на съобщенията (документите) не са много на брой, може едновременно да се съставят анотации на документите от няколко сектора. След като бъдат обработени документите от всички групи, списъкът на атрибутите е завършен. Следва формиране на релации от атрибутите. Всяка релация съдържа данни за един тип обект от предметната област.
В предметната област обектите са реални и абстрактни. Реалните обекти са осезаеми. Абстрактните обекти не са осезаеми (например, дата на раждане). Абстрактните обекти отразяват събития или съобщения. От гледна точка на модела на базата от данни, събитията са обекти, които задействат изпълнението на информационни процеси. Въпреки абстрактния характер на събитията, те имат свойства, така че на тях се приписват атрибути, описващи свойствата на събитията. Събитията имат отношения едно спрямо друго. Тези отношения трябва да бъдат изяснени и описани в процеса на проектирането (точно както осезаемите обекти). С абстрактните обекти е свързана една голяма трудност – да се определи дали обектът да се класифицира като събитие или като отношение между събития.
Някои същности съществуват само като съобщения в съществуваща (електронна или не) информационна система. Като лист хартия, една рецепта за лекарства е осезаем обект, но е съмнително дали трябва да бъде първокласен участник в модела на данните, защото при различни ситуации нейните функции могат еднакво добре да бъдат изпълнявани по друг начин, например във вид на електронна поръчка до аптеката на лечебното заведение.
Когато се разглежда нова група документи и съобщения, в списъка се добавят нови атрибути. На следващата итерация, проектантът решава в кои, вече определени обекти, да се включат атрибутите или, може би, да се формира нов обект (обекти).
При разработване на документална система, анализирайки всеки пореден документ, проектантът определя структурата на документа в термините: таблица, ред, колона. При фактографската система, на тази стъпка се изяснява същността на всеки атрибут.
Съставяне на списък на атрибутите
Списъкът с атрибути представлява таблица, в която се вписва името на атрибута, обширен коментар за установяване смисъла на атрибута и, накрая, сведения за съобщенията, в които се съдържа този атрибут. Препоръчва се името на атрибута да бъде в единствено число (например, Номер_на_телефон, а не Номера_на_телефони)
След като анализира няколко съобщения (документа), проектантът може да установи, че един и същ по смисъл атрибут се среща в различните съобщения под различни имена. Това е синонимия. Проектантът трябва да избере едно име, което е подходящо за всички съобщения и документи, в които се използва даденият атрибут.
(Това е един от случаите, когато формализираното описание на предметната област може да доведе до нейното изменение. Например, до изменение формата на някои документи).
При анализа на няколко документа може да се срещне и омонимия – атрибути с еднакви имена, но с различен смисъл. Такива атрибути трябва да получат различни имена.
Избирането на подходящи имена на атрибутите има важна роля при проектирането. На практика, в документите се срещат многословни имена. Те са неудобни за използване в проектирането и затова се препоръчва на всеки атрибут да се даде кратко име, разбираемо и за проектанта и за възложителя. При това, за да не се загуби част от важната информация, в списъка на атрибутите може да се включи и колона за коментар [5]. Алтернативата е в списъка на атрибутите да се съдържат две колони -една с пълното име на атрибута, поясняващо неговия смисъл и втора, съдържаща кратко обозначение на атрибута.
За всеки от атрибутите в списъка трябва да се реши дали:
атрибутът е необходим или е виртуален (неговите стойности могат да бъдат изчислени от стойностите на други атрибути в списъка). По правило виртуалните (изчислителните) атрибути няма защо да се съхраняват в базата от данни – те могат винаги да бъдат изчислени при необходимост;
ако атрибутът е необходим, задължително ли е да притежава реални стойности или може да съдържа и неопределени, условно дадени или неизвестни (NULL) стойности. Това решение се взема след консултация с бъдещите потребители, на базата на установената практика в предметната област.
Съставяне на релации
След като списъкът с атрибути бъде съставен, поредната задача е тяхното включване в релации. В методиката за пряко проектиране на релационна база от данни, общият списък на атрибутите се приема като една глобална първоначална релация. За тази релация първо се дефинират функционалните зависимости между атрибутите, избира се първичен ключ на глобалната релация и се извършва нейната нормализация.
При проектиране по метода “същност-връзка” (Епту-РеюНопБгф, E-R), за съставяне на релации се прилага следния алгоритъм.
Алгоритъм за съставяне на релации чрез агрегатиране на атрибутите Стъпка 1.
Анализира се типът на съответствие между атрибутите. Подбират се атрибути с тип на съответствие 1:1 и се агрегатират в един обект. На този обект се дава име. Определя се на коя същност от предметната област съответства формализираният обект.
Стъпка 2.
След формиране на обектите с атрибути от типа на съответствие 1:1, се решава
съдбата на останалите атрибути в списъка. Последователно се анализира всеки
атрибут, останал в списъка. Нека това е атрибутът Xj. Анализът започва с проверка:
има ли сред формираните обекти обект (Yj), такъв че T(Xj, Yj)=1:1. Ако такъв обект бъде
намерен, атрибутът X се включва в обекта Yj. Анализът продължава със следващият
атрибут в списъка.
Ако обект Y не бъде намерен, изяснява се дали сред формираните обекти има такива (например^ и Y2), за които е в сила условието:
T(Xj, Y1) = T(Xj, Y2) = 1:M
При такъв тип съответствие също има функционална зависимост, така че атрибутът Xj се включва в състава на обектите Y1 и Y2. обаче, в случая, съответствието 1:M означава, че една стойност на атрибута X може да се срещне в няколко екземпляра, например, в обекта Y1, т. е. стойностите на атрибута се дублират.
Ако не се намери съответствие 1:M за никой от формираните обекти, тогава трябва да се създаде нов обект и анализираният атрибут X да бъде включен в новия обект. При следващите итерации в новия обект могат да бъдат включени и други нови атрибути.
Стъпка 3.
След Стъпка 1 и многократно изпълнение на Стъпка 2 целият списък с атрибути е обработен, така че се формира множество от обекти (релации). За нуждите на нормализацията, която предстои да бъде извършена, е необходимо за всяка релация да бъде определен първичен ключ. Може, обаче, да се установи, че някоя релация няма подходящо множество от атрибути, които да бъдат избрани за първичен ключ. Това е белег, че в релацията липсват атрибути, следователно трябва да се допълни множеството от атрибути в тази релация. За целта, най-добре е да се изясни, заедно с възложителя, дали при обследването на предметната област не са пропуснати документи, съдържащи атрибут (атрибути), подходящи за първичен ключ на релацията.
Важно е стойността на първичния ключ да бъде уникална и да присъства във всеки екземпляр на обекта. При равни други условия се избира първичен ключ, чиито стойности трябва да се коригират рядко или никога (условие за неизменност на стойностите на първичния ключ).
Ако въпреки всичко не се намери подходящ кандидат-ключ, тогава проектантът въвежда свой идентификатор на екземплярите на обекта (изкуствен първичен ключ, сурогат).
Стъпка 4.
Проверява се дали релациите съответстват на условията за съответствие на
нормалните форми. Релациите се нормализират чрез декомпозиране.
След дефиниране на релациите (през Фаза 1) им се дават подходящи имена. Препоръчва се имената на релациите да бъдат кратки (без да се загубва смисъла) и в множествено число (например, релация Студенти, а не Студент).
Избор на подходяща СУБД
Важността на Фаза 2 от проектирането (физическото проектиране) се определя от това, че СУБД е най-важният компонент на информационната система.
Изборът на СУБД оказва влияние върху:

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

Методиката за избор на СУБД включва: изясняване на външните ограничения, подбор на СУБД – претенденти, моделиране на информационната база за всяка от СУБД – претендентите, сравнителен анализ на получените модели и избор на СУБД.
Външни ограничения са ограниченията на средата, в която се реализира информационната система. Когато през Фаза 0 се обследва предметната област, описанието й представлява формализация на представата на проектанта за предметната област. Тази представа изобщо не е свързана със средата, в която предстои да бъде реализирана информационната система. Схемата на информационната база, създавана на Фаза 1, е ориентирана към някаква идеална среда. Тя отразява какво иска заявителят (т. е. всъщност вече проектантът) от информационната система, но не отразява как тя ще бъде осъществена и изобщо възможно ли е осъществяването й. Всяка реална среда се различава от идеалната. Тя налага технически и организационни ограничения, а от там – и ограничения на структурите на данните, на алгоритмите и реализиращите ги програми. Техническите ограничения се определят от конфигурацията на изчислителната система и от операционната система. Към организационните ограничения се отнасят сроковете за разработка, възможностите за преподготовка на специалистите и за обучение на крайните потребители.
При моделирането на информационната база се извършва преобразуване на логическата схема във физическа схема на базата от данни, която може да бъде поддържана от СУБД. Определя се структурата на данните и стратегията на сравняването им в базата, както и разходите за цялостното реализиране на информационната система и за нейната експлоатация.
При сравнителния анализ на моделите на информационната база се извършва преценка на следните фактори:

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

Накрая, през Фаза 3: Реализация, се реализира физическата и вътрешната схема на информационната база и се разработват необходимите приложни програми. Описва се (документира се) технологията за работа с информационната система, която включва:

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

Формализация на процесите

Анализ на очакваните запитвания към базата от данни

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

група „А”,
група „Н”,
група „Н”

Към групи „Н” и “П” се отнасят запитванията при нормативно (планово) функциониране на системата. Това са запитванията, за удовлетворяване на които изобщо съществува информационната система. Към тези групи спадат запитвания за:

• Оперативни данни;
• Нормативно-справочни данни.

Проектантът анализира онези запитвания за оперативните данни, за които той е преценил, че ще бъдат извършвани най-често (група “Н”, тези запитвания са известни като FAQ: Frequently Asked Queries) и запитвания с висок приоритет (“П”, тези запитвания са известни като HPQ: High Priority Queries).
Най-често извършваните запитвания са критични по честота. От ефективното обслужване на тези запитвания зависи общото натоварване на системата и свързаните с него разходи на системата (в единици за време или в парично изражение).
Запитванията с най-висок приоритет са критични по мисия. Тяхната честота може да не е висока, но за обслужването им е необходима максимална реактивност на системата (т. е. минимално време за отговор на такова запитване и гаранция, че отговор ще бъде получен дори при евентуална авария в част от системата). При анализ на такива запитвания, разходите за обслужването им не са съществен критерий и обикновено не се вземат предвид.
Обикновено, запитванията за нормативно-справочните данни не са критични нито по честота, нито по мисия. Очаква се, че запитванията за нормативно-справочните данни ще се извършват рядко от транзакциите на крайните потребители.
Към група “А” спадат запитванията при авариен режим. Те никога не се извършват от транзакции на крайните потребители при нормален експлоатационен режим и затова се разглеждат отделно от запитванията в групи “Н” и “П”. Запитванията от група “А” се извършват от екипа на администраторите в процеса на възстановяване на базата от данни след авария. За целта се използват предварително подготвени, тествани и настроени сервизни програми.
При анализ на най-често използваните запитвания (“Н”) се определят следните параметри за всяко запитване, извършено от обикновена потребителска транзакция за по-продължителен период от време (години, месеци, …):

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

Данните за запитванията и таблиците се описват в Таблица 1:
Таблица 1: Параметри на запитванията (транзакциите) от група “Н”

Запитване    Релация (таблица)    Честота на актуализация    Честота на четене    Тип на запитването

Данните от Таблица 1 се обобщават в Таблица 2, която има следната структура:
Таблица 2: Обобщени параметри на запитванията (транзакциите) от група “Н”

Релация (таблица)    Размер (в байтове)    Честота на актуализация    Честота на четене    Зависими релации

Честотата на актуализациите и четенията е много важна при проектиране на разпределените системи. При системи с централизирано съхраняване на данните тези честоти също са важни – те помагат да се вземе решение дали запитванията да се обслужват от оригиналните релации, от подходящи образи или от моментни фотографии на данните. В последният случай четенето се насочва към образ (или моментна фотография) на данните, а актуализацията – към оригиналните релации. Данните в образа се освежават чрез копиране от оригиналните релации, което се извършва координирано след всяка актуализация или при поискване от приложната програма (при всички случаи, обаче, се препоръчва образите на данните да се използват само за четене).
Поддържането и използването на образи на данните намалява натоварването на системата в случаите, когато актуализациите са редки, а за обслужването на запитванията е необходима продължителна релационна операция (например, релационно съединение).
При чести четения и актуализации може да се постигне намаляване на натоварването и подобряване на реактивността на системата чрез хоризонтално фрагментиране на големи по обем релации. Хоризонталното фрагментиране е разделяне на оригиналната релация на две или повече по-малки релации, като кортежите, включени във всеки фрагмент удовлетворяват зададен критерий.

Пример

Дадена е релацията:

Студенти (Факултетен номер, Име, Курс, Група, Специалност,… )
Нека в конкретен университет тази релация да има кардиналност 8000 (брой на кортежите). Търсенето на студент чрез последователно преглеждане на записите е твърде продължително. Ако релацията Студенти се раздели на четири малки релации със студентите от 1-ви, 2-ри,… , 4-ти курс, тогава търсенето в малките релации е много по-бързо. Такова фрагментиране, обаче, има и сериозен недостатък – всяка учебна година студентите масово преминават в по-горен курс (но не всички студенти ©) и тогава кортежите за тях вече не ще изпълняват критерия за поместване в стария им фрагмент. По-подходящо е хоризонталното фрагментиране по факултети (или по специалности), тъй като смяната на факултета (или специалността) не е масово събитие.
Разбира се, индексирането на оригиналната релация би повлияло да се избегне последователното търсене в оригиналната релация, но съчетаването на фрагментиране и индексиране на всеки фрагмент дава най-добри резултати (поддържат се малки по размер индекси; реиндексирането им се извършва бързо).
До тук се имат пред вид запитвания от вида “изведи данните за студент с факултетен номер = ХХХХХХ”. При такова запитване се очаква резултат, съдържащ данни за най-много един студент. Такова запитване се нарича точково запитване.
Има и втори вид запитвания, наречени интервални запитвания, например: “Изведи данните за всички студенти от 4-ти курс, положили успешно изпита по дисциплината “База от данни”. Очаква се резултатът от обработката на запитването да съдържа данните на повече от един (©) студент.
При фрагментиране, обработката на интервални запитвания може да бъде свързана с достъпа до два или повече фрагмента, а това може да намали ефективността на системата. Такъв, например, е случаят със запитване от вида “Изведи средният успех по “ПИК – втора част” за студентите от втори курс, всички специалности”. Тук никакъв вид индексиране не помага (така или иначе ще бъдат сканирани всички данни), а фрагментирането забавя изпълнението на операциите.
Препоръчва се проектантът (при експлоатация на системата -администраторът) да определи експериментално (при готова схема на базата от данни) кой подход е най-добър, с оглед честотата на извършване на запитванията. Трябва да се има предвид, че зареждането в оперативната памет на голяма релация може да не бъде възможно. Тогава СУБД зарежда само няколко страници (от диска) и в процеса на обработка на запитването обменя тези страници между оперативната памет и дисковата база от данни. При такива условия не е възможно едновременното зареждане в оперативната памет на всички данни, необходими за запитването. Последователното отваряне, зареждане в паметта и обработване на страница след страница повишава натоварването на системата и удължава времето за отговор на запитването.

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

Критерии за оценка на система с база от данни

За оценка на качеството на система с база от данни се прилагат следните критерии (главно при сравняване на алтернативни проекти).
(1)    Критерий за функционалност ( CF )
CF = m / N; 0 < CF < 1 където:
m е брой на запитванията от клас “Н” (неприоритетни запитвания с висока честота), извършени в системата за дълъг период от време, които са получили отговор от системата;
N е общ брой на запитванията от клас “Н”, извършени в системата за същия дълъг период от време.
Разликата N-m отразява броя на отхвърлените от системата запитвания, т.е. запитвания, които не са получили отговор. Възможните причини за отхвърляне на такива запитвания са:
липса на данни в сървърите за данни;
недостъпност на данните в системата;
-    изпълнение на локални задания с висок приоритет (“П”), които не могат да бъдат прекъсвани от запитвания от клас “Н”.
(2)    Критерии за ефективност
Има два критерия за ефективност, наречени реактивност и общо време за изпълнение на запитванията.
-    Реактивност (R). Това е времето за изпълнение на едно запитване с висок приоритет – от клас “П”.
-    Общо време за изпълнение на всички неприоритетни запитвания (t0).
Това е сумарното време за изпълнение на всички неприоритетни запитвания (клас”Н’) за дълъг период от експлоатацията на системата.

(а)    Реактивност на системата (R)
Приоритетните запитвания са предварително дефинирани (не се задават ad hoc) и за тяхното изпълнение са подготвени съответни процедури с висока надеждност. Коефициентът на функционалност за тези запитвания е гарантирано равен на единица. Отчита се средната реактивност (за “типично” запитване) и най-продължителната реактивност. По-добър подход е да се изчислят вероятните оценки (или да се наблюдават реално стойностите) на реактивностите и да се изчисли тяхното статистическо разпределение. Тогава за реактивност на системата като цяло може да се приеме медианата на разпределението.

(б)    Критерий за производителност (t0)
Този критерий се дефинира с общото време за изпълнение на всички неприоритетни запитвания (клас “Н”) за дълъг период от време.
Проблем е дали критерият t0 да обхваща и времето (timeout), отнасящо се до отхвърлените запитвания, които не са получили отговор.
(3)    Критерий за паралелна работа на работните станции (CP)
Най-важният критерий за ефективност е степента на паралелна работа на работните станции (възлите в мрежата). Този критерий (с обозначение CP) се дефинира като отношение на фактическото общо време t0, за паралелно изпълнение на всички транзакции, към общото време ts, необходимо за последователно изпълнение на същите транзакции:
CP = t0 / ts ;
t0 < ts ;
0 < CP < 1
При такова дефиниране, стойностите на критерия CP са нормирани между нула и единица. Стойностите на числителя и знаменателя могат да бъдат изчислени, като се отбелязват времената на началото (begin transaction) и края (end of transaction) за всяка транзакция.
(4)    Критерий за натоварване на системата (CL)
Този критерий отразява натоварването на системата като цяло:
CL = t0 / tw ;
t0 < tw ; 0 < CL < 1
където:
t0 е общото време за паралелно изпълнение на всички операции;
tw е плановото работно време на работните станции (това е организационно време, равно на сумата от продължителността на всички работни дни или работни часове за разглеждания период). Плановото работно време се отнася за работните станции, а не и за постоянно назначените (фиксирани) сървъри за данни, които може би изобщо не се изключват.

(5)    Критерий за полезна работа (CU)
Изразява се с отношението на продължителността на подготвителните и заключителните операции tp в системата към продължителността на същинските операции tu, генериращи отговорите на запитванията. Например, подготвителна операция е трансферът на данни (от сървър за данни към запитващ клиент), необходими за генериране на отговор на запитване в клиентската страна. Пример за заключителна операция е разпространението на актуализациите, извършени от транзакциите, по репликите на данните в системата. Продължителностите на операциите се изразяват в единици за време.
За нормиране на стойностите на този коефициент (от нула до единица), в знаменателя се помества сумарната продължителност t0 на всички операции (t0 = tp + tu):
CU = tp / t0 0 < CU < 1
(6)    Критерий за достъпност на данните (RA)
Критерият RA (Replication Availability) е вероятностна характеристика на системата. Данните в една система са достъпни, когато поне едно тяхно копие е достъпно за потребителите или за приложенията. Ако е възможно (според преценката на проектанта на системата или на основата на натрупана статистика) да се определи максималният брой на едновременно недостъпните сървъри за данни (DDS, Deactivated Data Servers), съхраняващи копия на необходимите данни, тогава за осигуряване на достъпност е необходимо в системата да се поддържат RA на брой реплики на данните:
RA > DDS + 1
В граничния случай: RA = DDS + 1 = Rt.
Величината Rt се нарича критичен фактор на достъпността и представлява минималният брой на копията на всеки елемент от данните, които трябва да се поддържат в системата.

(7) Критерий за капацитета на дисковите устройства (CD)
Данните в една система трябва да бъдат разполагани така, че да не се превишава предварително зададеното за всеки диск максимално достъпно пространство (Dmax) за съхраняване на данните.
CD < Dmax
По същество това не е точно критерий, а начално условие за приложимост на системата с база от данни, но при сравняване на алтернативни проекти на системи с база от данни, стойността на CD може да се използва именно в качеството на критерий за избор на алтернатива. При равни други параметри, по-компактната база от данни е за предпочитане.

Секретност и безопасност на данните

Съдържание:

• Източници на неправилни данни.
• Мерки за секретност и ограничаване на достъпа до данните.
• Идентификация и автентификация на потребителите.

Термините “секретност”, “безопасност” и “защита” се използват в контекста на базите от данни в смисъл на предотвратяване на неразрешен достъп до данните, тяхното изменение или разрушаване.

Източници на неправилни данни

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

• запазване на интегритета на данните (предотвратяване на неволните грешки). Интегритетът се поддържа чрез спазване на ограничения. СУБД трябва да осигурява възможност за деклариране на такива ограничения за запазване на интегритета;
• управление на достъпа на потребителите до данните.

Всяка функционално пълна СУБД трябва да разполага със средства за:

предотвратяване на заселването на неправилни данни в базата от данни;
забраняване или ограничаване на достъпа на потребителите до различните подмножества на данните.

Мерки за секретност и ограничаване на достъпа до данните

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

• физическа защита;
• криптография;
• идентификация
• автентификация на потребителите;

-    предоставяне и поддържане на права на потребителите за достъп до определени данни.
Физическото атакуване на базата от данни включва широк диапазон от умишлени действия – от преодоляване на паролата до кражба на дисковите устройства. Защитата срещу такива действия обхваща разнообразни мерки – от алармена система и човешка охрана на машинните зали до модифициране на физическата система за вход-изход с параметри, описани в локалната схема на базата от данни на всяко работно място.
Криптографията е системно шифриране и дешифриране на данните при въвеждане и извеждане от базата от данни. Този вид защита може да се възложи на СУБД (както е при Ingres II) или на приложните програми. Тя се осъществява в момента на обработка и на мястото на обработка на данните.
Идентификацията и автентификацията на потребителите се състои в разпознаване на потребителя и проверка дали потребителят е този, за когото той сам се представя.
За предоставяне и поддържане на потребителските права се прилагат два подхода:
системата поддържа авторизираща матрица (таблица) с правата, дадени на всеки потребител за достъп до всяка отделна част на базата от данни. Предоставянето на права се извършва от администратора на базата от данни. Потребител, който е собственик на подмножество от данните, може да предава определени права върху тези данни на други потребители.
механизмът на защита е основан на парола. Не е необходимо да се поддържа авторизираща матрица с правата за достъп. Предоставянето на права се извършва извън системата – чрез съобщаване на паролата.

Идентификация и автентификация на потребителите

Системата, осигуряваща безопасност на данните, не трябва да допуска изпълняване на каквато и да било операция над данните, ако на потребителя не е разрешено да извършва такава операция. Тогава, за всеки потребител системата трябва да поддържа по един или повече записи, описващи “профил на потребителя”. Профилът на потребителя посочва елементите от данните, до които потребителят има разрешение за достъп и операциите, които потребителят може да изпълнява над тези данни. Алтернативно, системата може да поддържа по един запис за всеки елемент от данните (“профил на обектите”), който задава потребителите, на които е разрешен достъп до конкретния обект, както и вида на достъпа (за изпълнение на какъв тип операция).
Преди да получи достъп до данните, потребителят трябва да се идентифицира (например, с въвеждане на потребителско име или потребителски номер). Тази стъпка насочва системата към съответния потребителски профил. След това, потребителят потвърждава своята идентификация, т.е. доказва, че е този, за когото се представя. Това се нарича автентификация. Най-често се въвежда парола, която е известна само на системата и на потребителя. Системата за идентификация и автентификация може да използва карта, емблема или в най-простия случай -лична потребителска дискета. Съществуват и системи за разпознаване на гласа и на пръстовите отпечатъци на потребителя, ириса на окото и др. под.

Системата за автентификация използва въвеждане от потребителя на информация, която е известна само на лицето (освен паролата). Това могат да бъдат отговори на въпроси, задавани от системата, например въпроси от подробната биография на лицето, неговите родители или други близки (например, “Какво е моминското фамилно име на майка Ви?”).

Пример

Първо, системата предлага на потребителя едно псевдослучайно число Х.
След това, потребителят извършва няколко прости умствени трансформации Т над Х и въвежда в системата резултата Y = T(X). Системата извършва същите трансформации Т и проверява дали резултатът съвпада с Y.
Всеки потенциален инфилтратор ще може да види най-много стойностите на Х и Y, но от тях не е възможно по обратен път да се определи каква точно е трансформацията Т.
Може, например, трансформацията Т да се състои в сумирането на първата, третата и петата цифри от Х, повдигане на сумата на втора степен и събиране с текущия час от денонощието, в който се извършва автентификацията.

Защита на личните данни

Съдържание:

• Понятие за лични данни. Закон за защита на личните данни.
• Ограничения при събиране, записване, организиране, съхраняване, изменение, възстановяване, употреба, предоставяне и заличаване на лични данни.
• Комисия за защита на личните данни.
• Администратор на лични данни.
• Защита на личните данни.
• Права на физическите лица.
• Предоставяне на лични данни на трети лица.

Понятие за лични данни. Закон за защита на личните данни

От 1 януари 2002 г. в Република България действа Закон за защита на личните данни. С този закон се урежда защитата на правата на физическите лица при обработването на личните им данни.
Целта на закона е гарантиране на неприкосновеността на личността и личния живот чрез осигуряване на защита на физическите лица при неправомерно обработване на свързаните с тях лични данни в процеса на свободно движение на данните.
Лични данни са информация за физическо лице, която разкрива неговата физическа, психологическа, умствена, семейна, икономическа, културна или обществена идентичност. Лични данни са всяка информация, отнасяща се до физическо лице, което е идентифицирано или може да бъде идентифицирано пряко или непряко чрез идентификационен номер или чрез специфични признаци, свързани с неговата физическа, физиологична, генетична, психическа, психологическа, икономическа, културна или социална идентичност.
Човешки геном е съвкупността от всички гени в единичен набор от хромозоми на дадено лице.
Обработване на лични данни е всяко действие или съвкупност от действия, които могат да се извършват по отношение на личните данни, като събиране, записване, организиране, съхраняване, адаптиране или изменение, възстановяване, консултиране, употреба, разкриване чрез предаване, разпространяване, предоставяне или по друг начин, актуализиране или комбиниране, блокиране, заличаване или унищожаване. (Блокиране е складирането на лични данни с временно прекратяване на обработката им).
Законът се прилага за обработката на лични данни, съставляващи или предназначени да съставляват част от регистър. (Законът не се прилага за обработването на лични данни, извършвано от физически лица за техни лични или домашни дейности). Регистър на лични данни е всяка структурирана съвкупност от лични данни, достъпна по определени критерии, централизирана, децентрализирана или разпределена на функционален или географски принцип. Обработката на личните данни се извършва от администратор на лични данни.
Администратор на лични данни е физическо или юридическо лице, както и орган на държавната власт или на местно самоуправление, който обработва лични данни. Администраторът на лични данни обработва тези данни самостоятелно или чрез възлагане на обработващ данните.

Ограничения при събиране, записване, организиране, съхраняване, изменение, възстановяване, употреба, предоставяне и заличаване на лични данни

Обработването на лични данни е допустимо само в случаите, когато е налице поне едно от следните условия:
обработването е необходимо за изпълнение на нормативно установено задължение на администратора на лични данни (например, юридическо лице – администратор, набира, съхранява, употребява и актуализира данните за своя персонал с цел да води счетоводна отчетност за възнагражденията на служителите, да внася осигурителни вноски и др. Тези задължения на работодателя са установени с Кодекса на труда, Кодекса за социалното осигуряване и Данъчнопроцесуалния кодекс);
физическото лице, за което се отнасят данните, е дало изрично своето съгласие. (Съгласие на физическото лице е всяко свободно изразено, конкретно и информирано волеизявление, с което физическото лице, за което се отнасят личните данни, се съгласява те да бъдат обработвани);
обработването е необходимо за сключване и изпълнение на договор, по който физическото лице, за което се отнасят данните е страна;
обработването е необходимо, за да се защитят животът и здравето на физическото лице, за което се отнасят данните (например, пострадал при пътно произшествие се нуждае от спешна помощ. За целта той трябва да бъде идентифициран чрез данни, свързани с неговата физическа и физиологична идентичност – име, възраст, адрес, физиологични белези – кръвна група, зъбен статус и др.);
обработването е необходимо за изпълнението на задача, която се осъществява в обществен интерес;
обработването е необходимо за упражняване на правомощия, предоставени със закон на администратора на лични данни или на трето лице, на което се разкриват данните;
обработването е необходимо за реализиране на законните интереси на администратора на лични данни или на трето лице, на което се разкриват данните, освен когато пред тези интереси преимущество имат интересите на физическото лице, за което се отнасят данните.
Обработването на лични данни е допустимо и в случаите, когато то се извършва единствено за целите на журналистическата дейност, литературното или художественото изразяване, доколкото това обработване не нарушава правото на личен живот на лицето, за което се отнасят данните.
Забранено е обработването на лични данни, които:

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

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

Комисия за защита на личните данни

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

Администратор на лични данни

Администраторът на лични данни е длъжен да подаде заявление за регистрация, когато е налице поне едно от следните условия:

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

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

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

Защита на личните данни

Администраторът на лични данни предприема необходимите технически и организационни мерки, за да защити данните от случайно или незаконно унищожаване, или от случайна загуба, от неправомерен достъп, изменение или разпространение, както и от други незаконни форми на обработване. Администраторът взема специални мерки за защита, когато обработването включва предаване на данните по електронен път. Мерките за защита трябва да съответстват на съвременните технологични постижения и да осигуряват ниво на защита, което съответства на рисковете, свързани с обработването и на естеството на данните, които трябва да бъдат защитени. Тези мерки се определят с инструкция на администратора на лични данни.
Комисията за защита на личните данни определя с наредба минималното ниво на технически и организационни мерки, както и допустимия вид на защитата. Наредбата се обнародва в “Държавен вестник”.
Администраторът обработва данните сам или чрез възлагане на обработващ данните. За вреди, причинени на трети лица от действия или бездействия на обработващия данните, администраторът отговаря солидарно с него. Обработващият извършва обработката на личните данни само по указание на администратора, освен ако в закон е предвидено друго.
След постигане на целта на обработване на личните данни администраторът е длъжен да ги:
(1)    унищожи, или
(2)    прехвърли на друг администратор, като предварително уведоми
за това комисията, ако прехвърлянето е предвидено в закон и е налице
идентичност на целите на обработването.
След постигане на целта на обработване на личните данни администраторът ги съхранява само в предвидените в закона случаи. Когато администраторът иска да съхрани обработените лични данни като анонимни данни за исторически, научни или статистически цели, той уведомява за това комисията.
Анонимни данни са лични данни, приведени във форма, която не позволява те да бъдат свързани със съответното лице, за което се отнасят.
Комисията може да забрани такова съхраняване, ако администраторът не е осигурил достатъчна защита като анонимни данни.

Права на физическите лица

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

Физическото лице има право по всяко време (но, безплатно -веднъж на 12 месеца) да поиска от администратора на лични данни:
потвърждение за това, дали отнасящите се до него лични данни се обработват, каква е целта на това обработване, какви са категориите на данните, кои са получателите, на които данните се разкриват;
съобщение до него в разбираема форма, съдържащо личните му данни, които се обработват, както и всяка налична информация за техния източник;

информация за логиката на всяко автоматизирано обработване на лични данни, отнасящи се до него.
Информацията може да бъде във вид на устна или писмена справка или преглед на данните отстрана на физическото лице или упълномощено от него лице. Физическото лице може да поисква копие от обработваните лични данни на предпочитан носител или предоставянето им по електронен път.
Физическото лице има право по всяко време да поиска от администратора на лични данни да:
заличи, коригира или блокира негови лични данни, обработването на които не отговаря на изискванията на Закона за защита на личните данни;
уведоми третите лица, на които са били разкрити личните му данни, за всяко заличаване, коригиране или блокиране, с изключение на случаите, когато това е невъзможно или е свързано с прекомерни усилия.
Администраторът взема решение по искането и уведомява лицето лично срещу подпис или по пощата с обратна разписка. Липсата на уведомление се смята за отказ.

Предоставяне на лични данни на трети лица

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

Защита на класифицираната информация

Съдържание:

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

Понятие за класифицирана информация

Обществените отношения, свързани със създаването, обработването и съхраняването на класифицирана информация, както и условията и реда за предоставяне на достъп до нея са уредени със Закон за защита на класифицираната информация (обнародван на 30 април 2002 г.).
Целта на закона е защитата на класифицираната информация от нерегламентиран достъп.
Класифицирана информация е информацията, представляваща държавна или служебна тайна, както и чуждестранната класифицирана информация.
Държавна тайна е информацията, определена със Закона за защита на класифицираната информация, нерегламентираният достъп до която би създал опасност или би увредил интересите на Република България, свързани с националната сигурност, отбраната, външната политика или защитата на конституционно установения ред, с икономическата сигурност на страната.
Служебна тайна е информацията, създавана или съхранявана от държавните органи или органите на местното самоуправление, която не е държавна тайна, нерегламентирания достъп до която би се отразил неблагоприятно на интересите на държавата или би увредил друг правозащитен интерес.
Достъп до класифицирана информация се предоставя само на лица, получили разрешение за достъп, при спазване на принципа “необходимост да се знае”. Принципът “необходимост да се знае” се състои в ограничаване на достъпа само до определена класифицирана информация и само за лица, чиито служебни задължения или конкретно възложена задача налагат такъв достъп.
Нерегламентиран достъп до класифицирана информация е разгласяване,   злоупотреба,   промяна,   увреждане,   предоставяне, унищожаване на класифицирана информация, както и всякакви други действия, водещи до нарушаване на защитата й или до загубване на такава информация.
За нерегламентиран достъп се счита и всеки пропуск да се постави съответен гриф за сигурност, както и всяко действие или бездействие, довело до узнаване от лице, което няма съответното разрешение.
Гриф за сигурност е маркировка върху материал, съдържащ класифицирана информация, която показва нивото на класификация.
Материал е всеки документ или всякакъв друг предмет от техническо естество, съоръжение, оборудване, устройство или въоръжение, произведени или в процес на производство, както и съставни части за тях, използвани за производството им.
Документ е всяка записана информация, независимо от физическата й форма или характеристика, включително следните носители на информация: ръчно или машинно написан материал, програми за обработка на данни, печати, карти,таблици, снимки, рисунки, оцветявания, гравюри, чертежи или части от тях, скици, чернови, работни бележки, индигов лист, мастилени ленти или възпроизвеждане чрез каквито и да е средства или процеси на звук, глас, магнитни записи, видеозаписи, електронни записи, оптични записи в каквато и да е форма, портативни съоръжения или уреди за автоматизирана обработка на данни с постоянен носител на информация или с преносим носител на информация и други.
Политиката на Република България за защита на класифицираната информация се осъществява от Държавна комисия по сигурността на информацията.

Видове класифицирана информация и нива на класификация

Нивата на класификация за сигурност на информацията и техния гриф са:

• “Строго секретно”;
• “Секретно”;
• “Поверително”;
• “За служебно ползване”.

Маркирането на класифицираната информация с гриф за сигурност съдържа:

• ниво на класификация;
• дата на класифициране;
• дата на изтичане на срока на класификация;
• правното основание за класифициране.

Съхраняване и срокове за защита на класифицираната информация

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

• за информация, маркирана с гриф “Строго секретно” – 30 години;
• за информация, маркирана с гриф “Секретно” – 15 години;
• за информация, маркирана с гриф “Поверително” – 5 години;
• за информация, класифицирана като служебна тайна – 2 години.

Видове защита на класифицираната информация

Физическата сигурност на класифицираната информация включва система от организационни, физически и технически мерки за предотвратяване на нерегламентиран достъп до материали, документи, техника и съоръжения, класифицирани като държавна тайна или като служебна тайна.
Системата от мерки включва защита на сградите, помещенията и съоръженията,в които се създава, обработва и съхранява класифицирана информация, и контрола върху достъпа до тях.
Физическата сигурност се прилага за защита на класифицираната информация от всякаква заплаха или вреда в резултат на:
терористична дейност или саботаж;
нерегламентиран достъп или опит за нерегламентиран достъп.
За предотвратяване на нерегламентиран достъп до класифицирана информация се определят:
-    зони на сигурност;
административни зони (около зоните за сигурност), в които се извършва контрол на хора и транспортни средства и които са с най-ниско ниво на сигурност;
контролиран режим на влизане, движение и излизане от зоната на сигурност;
контрол над зоните за сигурност и административните зони чрез служители (охрана);
- специален режим на съхраняване на ключове от помещения, каси и други съоръжения, служещи за съхраняване на класифицирана информация.
Документалната сигурност се състои в система от мерки, способи и средства за защита на класифицираната информация при създаването, обработването и съхраняването на документи, както и при организирането и работата на регистратури за класифицирана информация.
Криптографската сигурност представлява система от криптографски методи и средства, които се прилагат с цел защита на класифицираната информация от нерегламентиран достъп при нейното създаване, обработка, съхраняване и пренасяне.
Индустриалната сигурност представлява система от принципи и мерки, които се прилагат по отношение на кандидати – физически лица, при сключването или изпълнението на договор, свързан с достъп до класифицирана информация, с цел защитата й от нерегламентиран достъп.

Сигурност на автоматизираните информационни системи

Сигурността на автоматизираните информационни системи или мрежи представлява система от принципи и мерки за защита от нерегламентиран достъп до класифицираната информация, създавана, обработвана, съхранявана и пренасяна в системите или мрежите.
Задължителните общи условия за сигурност на автоматизираните информационни системи или мрежи обхващат компютърната, комуникационната, криптографската, физическата и персоналната сигурност, сигурността на самата информация на всякакъв електронен носител, както и защитата от паразитни електромагнитни излъчвания.
Задължителни специфични изисквания се изготвят на етапа на проектирането (!!!) на автоматизираните информационни системи или мрежи и при необходимост се изменят и допълват в процеса на изграждане и развитие на системата.
Не се допуска включването на автоматизирани информационни системи или мрежи, предназначени за събиране, обработка, съхраняване и пренасяне на класифицирана информация към публични мрежи като Интернет и други подобни електронни комуникационни мрежи.
Пренасянето на материали, съдържащи класиицирана информация се извършва с куриери, по пощата (включително военна пощенска свръзка) или чрез автоматизирани информационни системи или мрежи.
Материали с класификация “Строго секретно” се пренасят само чрез специална куриерска служба. Материали с класификация “Секретно” или “Поверително” се пренасят чрез куриери или автоматизирани информационни системи или мрежи.
Пренасянето на документи, съдържащи класифицирана информация по автоматизирани информационни системи или мрежи се извършва по сертифицирани такива системи (доверена комуникационна връзка) или по несертифицирани системи (недоверена комуникационна връзка), но с използване на одобрени за съответното ниво на класификация криптографски методи и средства.

Защита на обществената информация

Съдържание:

• Понятие за обществена информация.  Закон за достъп до обществена информация.
• Официална и служебна обществена информация.
• Обществени отношения и право на достъп до обществена информация.
• Ред за предоставяне на достъп до обществена информация.

Понятие за обществена информация. Закон за достъп до обществена информация

Законът за достъп до обществена информация (обнародван на 7 юли 2000 г.) урежда обществените отношения, свързани с правото надостъп до обществена информация.
Обществена информация е всяка информация, свързана с обществения живот в Република България идаваща възможност на гражданите да си съставят собствено мнение относно дейността на задължените по Закона за достъп до обществена информация субекти. Информацията е обществена независимо от вида на нейния материален носител.
Материален носител на обществена информация е текст, план, карта, фотография, изображение, дискета, аудио или видеокасета и други подобни.
Законът за достъп до обществена информация се отнася за информация, която се създава или съхранява от държавните органи или органите на местното самоуправление в Република България. Законът се прилага и за достъп до обществена информация, която се създава и съхранява от:
публичноправни обекти;
физически и юридически лица само относно извършваната от тях дейност, финансирана със средства от консолидирания държавен бюджет;
средствата за масова информация и е свързана с прозрачността на тяхната дейност.
Всеки гражданин на Република България има право на достъп до обществена информация. Осъществяването на това право не може да бъде насочено срещу правата и доброто име на други лица, както и срещу националната сигурност, обществения ред, народното здраве и морала. Достъпът до обществена информация е свободен.

Основните принципи при осъществяване правото на достъп до обществена информация са:

1. откритост, достоверност и пълнота на информацията;
2. осигуряване на еднакви условия за достъп до обществена информация;
3. осигуряване на законност при търсенето и получаването на обществена информация;
4. защита на правото на информация;
5. защита на личната информация;
6. гарантиране на сигурността на обществото и държавата.

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

Официална и служебна обществена информация

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

Обществени отношения и право на достъп до обществена информация

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

Ред  за   предоставяне   на   достъп   до   обществена информация

Достъп до обществена информация се предоставя въз основа на писмено заявление или устно запитване.
Заявлението за предоставяне на достъп до обществена информация съдържа:
трите имена, съответно наименованието и седалището на заявителя;
описание на исканата информация;
предпочитаната форма за предоставяне на достъп до исканата информация;
адреса за кореспонденция със заявителя.
Формите за предоставяне на достъп до обществена информация
са:

• преглед на информацията – оригинал или копие;
• устна справка;
• копия на хартиен носител;
• копия на технически носител.

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

Защита на статистически бази от данни

Съдържание:

• Понятие за статистическа база от данни.
• Защита на статистическите бази от данни.

Понятие за статистическа база от данни

Базите от данни, които се категоризират като “статистически” (такива са, например, данните от преброяване на населението) имат две особености:

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

Дефиниция

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

• Потребителят има неограничен достъп до данните и може да изпълнява всички типове операции над данните.
• Потребителят няма достъп до никое подмножество от данните и не може да извършва никакви операции.
• Потребителят може да чете някакво подмножество от данните, но не може да изменя стойностите на данните в това подмножество.
• Потребителят може да чете точно един запис (този потребител е собственик на конкретния запис), но не може да изменя стойностите в записа.
• Потребителят може да чете точно един запис (собственик е на този запис) и може в този запис да изменя стойностите на зададени (но не на всички) атрибути, например, може да изменя Име и Адрес.
• Потребителят може да чете само стойностите на зададени атрибути (например, Номер, Име, Адрес и Отдел) и във всеки запис може да изменя само стойностите на някои атрибути (например, Адрес).
• Потребителят може да чете зададени атрибути (например, Номер и Заплата), може да изменя стойностите в зададен атрибут (например, Заплата), но само в часовете от 9 сутринта до 17 след обяд и само от работна станция, разположена в счетоводството.
• Потребителят може да чете зададени атрибути и във всеки запис може да изменя стойността на атрибута Заплата, само ако текущата стойност на атрибута Заплата е по-малка от минималната работна заплата.
• Потребителят може да изпълнява оператори, които обобщават атрибута Заплата (средно аритметично, сума на заплатите в даден отдел), но не може да чете или изменя отделни стойности в колоната Заплата.
• Потребителят може да чете атрибутите Номер и Кабинет и във всеки запис
• може да изменя стойността на Кабинет, ако и само ако конкретният потребител
• (извършващ изменението) е началник на отдела, идентифициран със съответна
• стойност в атрибута Номер.

Защита на статистически бази от данни

Системите за защита със специално предназначение налагат друг вид ограничения. Обикновено на потребителите на една статистическа база от данни се разрешава да извършват само операцията четене (select в SQL). Допускат се запитвания към статистическа база от данни само, ако за тези запитвания се връща обобщен резултат: сума, средно аритметично, брой на елементи от група и др. под.
Счита се, че защитата на статистическата база от данни е компрометирана, ако някой потребител, дори и да използва само разрешени запитвания, може да узнае индивидуални данни за конкретен обект.

Трудностите при защита на статистическа база от данни идват от това, че в обобщената информация се съдържат следи от оригиналната информация. Чрез обработка на достатъчно голям брой запитвания може да бъде реконструирана оригиналната информация. Именно това се счита за компрометиране на защитата на базата от данни. Конкретен подход за компрометиране (за възстановяване на оригиналната информация) се нарича трекер (tracker). Различават се индивидуален и генерален трекер.

Пример

За илюстриране на начините за компрометиране на статистическа база от данни ще бъде използвана таблицата СЛУЖИТЕЛ.
Условие:
Потребител, който по-нататък ще бъде наричан инфилтратор, има намерение да узнае каква е заплатата на служителя Ангелов. Нека от външни източници инфилтраторът е узнал, че Ангелов е мъж и длъжността му е “програмист”. (Полът може да бъде узнат от ЕГН, така че за удобство може да се счита, че в таблицата СЛУЖИТЕЛ има колона ПОЛ с две стойности: “мъж” и “жена”).

Случай 1.
За достъпа до данните е наложено ограничението, че може да се използват само оператори за обобщаващи операции (например, SUM) и оператор SELECT.
В този случай защитата на базата от данни може да бъде компрометирана само с две запитвания:
Q1: select COUNT (*)
from СЛУЖИТЕЛ
where Пол = “мъж” AND Длъжност = ‘програмист’;
Резултат: 1 (инфилтраторът забелязва, че резултатът съдържа само един запис!)
Q2: select SUM (Заплата)
from СЛУЖИТЕЛ
where Пол = “мъж” AND Длъжност = ‘програмист’; Резултат: 190 лв.

Случай 2.

Проектантът на защитата на базата от данни си е взел поука от Случай 1 и е въвел ново ограничение, според което системата няма да отговаря на запитване, ако отговорът на това запитване съдържа данни, извлечени само от един ред от
таблицата СЛУЖИТЕЛ.
Системата ще извежда резултата от запитването само, ако броят на обхванатите в отговора редове е по-голям или е равен на зададено число К (кардиналност на отговора). Ако общият брой на редовете в таблицата СЛУЖИТЕЛ е N, тогава нека K > (N/2).
В примера, N = 10 и K = 5.
Сега, защитата на базата от данни може да бъде компрометирана със следните 4 запитвания:
Защита на статистически бази от данни Q1: select count (*)
from СЛУЖИТЕЛ;
Резултат R1: 10 (кардиналността на резултата е по-голяма от 5). Q2: select count (*)
from СЛУЖИТЕЛ
where NOT(Пол = “мъж” AND Длъжност = ‘програмист’); Резултат R2: 9 (кардиналността на резултата е по-голяма от 5). Сега R1 – R2 = 1 (Ангелов е единствен мъж с длъжност “програмист”). Q3: select SUM (Заплата)
from СЛУЖИТЕЛ;
Резултат R3: 2410
Q4: select SUM (Заплата) from СЛУЖИТЕЛ
where NOT(Пол = “мъж” AND Длъжност = ‘програмист’); Резултат R4: 2220
Сега R3 – R4 = 2410 – 2220 = 190 (това е заплатата на Ангелов).
В Случай 2, компрометирането е възможно не защото кардиналността на отговорите е малка, а защото разликата между кардиналностите е малка!
Случай 3.
Проектантът на защитата на базата от данни си е взел поука и от Случай 2 и е въвел ново ограничение – допускат се запитвания, отговорите на които имат кардиналност К, която е най-малко равна на зададена константа С, където
C < K < (N – C)
При N = 10, нека С = 2, тогава N – C = 8 и 2 < K < 8.
Сега защитата на базата от данни може да бъде компрометирана със следните 4 запитвания:
Q1: select COUNT (*)
from СЛУЖИТЕЛ
where Пол = ‘мъж’; Резултат R1: 5 (2 < 5 < 8). Q2: select COUNT (*)
from СЛУЖИТЕЛ
where Пол = “мъж” AND NOT(Длъжност = ‘програмист’);
Резултат R2: 4 (2 < 4 < 8; извод: има само един мъж, който е програмист и това е Ангелов).
Q3: select SUM (Заплата) from СЛУЖИТЕЛ
where Пол = ‘мъж’;
Резултат R3: 1490 (това е заплатата на 5 души; 2 < 5 < 8).
Q4: select SUM (Заплата) from СЛУЖИТЕЛ
where Пол = “мъж” AND NOT(Длъжност = ‘програмист’);
Резултат R4: 1300 (това е заплатата на 4 души; 2 < 4 < 8)
Сега R3 – R4 = 1490 – 1300 = 190 лв. (това е заплатата на Ангелов).
От примерите се вижда, че компрометирането на защитата на статистическа база от данни винаги е възможно, стига инфилтраторът да разполага с достатъчно дълго време и неограничен брой на достъпите до статистическите данни.

Сходни статии:

1. Архитектура на База Данни. Етапи на проектиране. Модели бази данни Понятие за архитектура на База Данни Архитектурата на База Данни включва 3 нива Информационни връзки. Модели на данни. При проектирането на база данни се преминава през няколко етапа. Най напред...
2. Разпределени бази данни. Предимства и недостатъци на работата с база данни Осигурява икономия при използването на персоналните компютри, намалява грешките от централизацията на данните и нараства отговорностите към мениджърските нужди. Данните могат да бъдат разделени на части и базирани на регионален,...
3. Системи за управление на база данни (СУБД) Основни функции на СУБД (DBMS) - създаване на база данни, актуализация, коригиране, достъп, търсене, изискване, сортиране. СУБД представя данните чрез т.нар. модел на данните. Моделът представлява логическо свързване на данните,...
4. База данни, въведение, използване и цели Класификация на икономическата информация и връзка между информация и бизнес управление. Правна която се отнася до правната уредба Нормативна – подзаконови актове, информационно свързана с нормативните актове Счетоводна – сравнително...
5. Специализирани типове системи за управление на база данни Обектно – ориентирани системи за управление на база данни (OODBMS) Конвенционалните СУБД – проектиране за хомогенни данни, които могат да бъдат лесно структурирани в предварително дефинирани полета и записи. Много...