Абстракции
Абстрахирането е подход за проектиране, реализация и управление на сложни системи: участващите специалисти се разделят на категории според профила си и всяка категория определя как изглежда системата от нейната гледна точка — само с концепциите и елементите, които са в компетентността ѝ. Останалото се игнорира — специалистите се абстрахират от него.
Софтуерните системи са много сложни обекти — не е по силите на отделен специалист да вникне във всички аспекти. Затова сложният проект се разбива на нива на абстракция, с всяко от които се заема екип със съответната компетентност.
Четирите нива
Ниво на крайния потребител (възложител)
Най-високото ниво. Крайният потребител се нуждае от софтуерен продукт за ежедневната си дейност, но обикновено не познава нито моделите за структуриране на данните, нито формализираните езици, нито СУБД. Затова описва нуждите си единствено на естествен език (+ нормативни документи, примери от дейността). Пример: „Училището ни се нуждае от ИС с данни за учениците, служителите, библиотеката, доставчиците за стола… Ще е необходимо да могат да бъдат получавани тези и тези справки."
Ниво на бизнес анализатора
Бизнес анализаторите вникват в работата на крайния потребител, анализират процесите и превеждат описаното на естествен език в инструмент за формализирано описание — изготвят ER диаграмата на бъдещата ИС. Това не може да стане без участието на крайния потребител — установяват се елементи, от които той се е абстрахирал. Анализаторът не се интересува кой модел за структуриране ще се ползва (може да препоръча най-подходящия), нито от конкретната СУБД.
Ниво на разработчика
Разработчиците познават инструментите за реализация. Те „превеждат" ER модела на езика на избраната СУРБД: за всеки обект — таблица; планират и таблици без аналог в ER модела (за връзките между обекти); добавят атрибути, които анализаторът не е предвидил — идентификатори и външни ключове; определят заявките за справките и подготвят инструкция за крайния потребител. Разработчикът се абстрахира от това къде физически са данните и какви са мерките срещу загуба.
Ниво на администратора на данни
Системните администратори на компютъра, върху който работи ИС, се грижат за физическото разположение и опазването на данните — и се абстрахират от това как са структурирани и кои структури какво съдържат.
Бележка
Срещат се съвместявания — краен потребител с качества на анализатор, разработчик, който прави и бизнес анализа. Това не отменя добрата практика дейностите да се извършват на всяко от нивата, без да се намесва друго ниво.
Аномалии
Когато базата не е нормализирана, при отношения между обектите възникват аномалии. Илюстрация: таблица Учител с колони (ID, IDУчилище, Предмет, Преподавател, E-mail), където ключът включва IDУчилище, а учителят Иванов преподава в две училища (два реда).
| Аномалия | Какво се случва |
|---|---|
| На вмъкването | Нов учител, още неназначен в училище, не може да бъде добавен — IDУчилище е част от ключа и не позволява null. |
| На обновяването | Иванов има два реда. Обновим ли e-mail само в единия, имаме две различни стойности без начин да различим актуалната. |
| На изтриването | Закрием ли училище АЕГ и изтрием кортежите му, губим данните за Петрова — тя преподава единствено там. |
Ключово
И трите аномалии се избягват с правилно проектиране на базата чрез нормализация — учителите в отделна таблица, назначенията в друга.
Въпроси от учебника
Ако със съучениците си създавате ИС на вашето училище: кой би бил най-естественият краен потребител? Бизнес анализатор? Разработчик? И как трябва да се промени базата от примера, за да се избегнат аномалиите?
Какво трябва да запомниш
- Нива на абстракция: всеки екип вижда системата само от своята компетентност.
- Краен потребител → словесно описание; бизнес анализатор → ER модел; разработчик → БД; администратор → работеща ИС.
- Разработчикът добавя идентификатори, външни ключове и таблици за връзките.
- Аномалии: на вмъкването, на обновяването, на изтриването.
- Лекарството е нормализация.