Changes between Version 1 and Version 2 of DatabaseProgramming

Timestamp:

05/26/26 15:01:09 (27 hours ago)

Author:

231511

Comment:

--

DatabaseProgramming

@@ -271 +271 @@
 7. **Заклучок:**  
 `catalog_object` претставува централен механизам за каталогизација во системот, кој обезбедува конзистентност, автоматизација и намалување на човечки грешки при внес на археолошки податоци.
+
+= Тригери =
+
+
+=== Тригер 1: Валидација на хиерархија на фрагменти (trg_fragment_check) ===
+
+1. **Намена:**  
+Тригерот `trg_fragment_check` е наменет за автоматска валидација на записите во табелата `Fragments`. Неговата главна цел е да спречи внесување или ажурирање на фрагмент кој истовремено е директно поврзан со археолошки предмет (`object_id`) и со друг фрагмент (`parent_fragment_id`).
+
+2. **Случај на употреба:**  
+Во системот за управување со културно-археолошко наследство, фрагментите имаат важна улога затоа што претставуваат делови од артефакти, остатоци од предмети или под-фрагменти кои се пронајдени на локалитет. Поради тоа, секој фрагмент мора да има јасна логичка припадност.
+
+Фрагментот може:
+ * директно да припаѓа на археолошки предмет преку `object_id`
+ * да биде дел од друг фрагмент преку `parent_fragment_id`
+
+Но не смее истовремено да припаѓа и на предмет и на друг фрагмент, бидејќи тоа би создало нејасна и двојна хиерархија.
+
+3. **Причина за избор на тригер:**  
+Овој тригер е избран затоа што се работи за доменско правило кое мора да се провери автоматски пред секој внес или ажурирање. Иако во табелата `Fragments` постои и `CHECK` ограничување за ова правило, тригерот дополнително овозможува појасна контрола и експлицитна порака за грешка.
+
+Со ова се добива подобра разбирливост при тестирање и при работа со апликацијата, бидејќи корисникот добива конкретна порака:
+
+{{{
+Фрагмент не може да има и object и parent
+}}}
+
+4. **Имплементација:**  
+
+Тригер функцијата е:
+
+{{{
+CREATE OR REPLACE FUNCTION trg_fragment_validation()
+RETURNS TRIGGER AS $$
+BEGIN
+    IF NEW.object_id IS NOT NULL AND NEW.parent_fragment_id IS NOT NULL THEN
+        RAISE EXCEPTION 'Фрагмент не може да има и object и parent';
+    END IF;
+
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+}}}
+
+Тригерот се активира:
+
+{{{
+CREATE TRIGGER trg_fragment_check
+BEFORE INSERT OR UPDATE ON Fragments
+FOR EACH ROW
+EXECUTE FUNCTION trg_fragment_validation();
+}}}
+
+5. **Логика на работа:**  
+Тригерот се извршува пред секој `INSERT` или `UPDATE` врз табелата `Fragments`. Тој ја проверува новата вредност која треба да се внесе или ажурира преку `NEW`.
+
+Доколку и `NEW.object_id` и `NEW.parent_fragment_id` имаат вредност различна од `NULL`, записот се одбива и се фрла исклучок.
+
+Ова значи дека базата не дозволува фрагментот да има двојна припадност.
+
+6. **Бизнис логика:**  
+Овој тригер ја имплементира логиката за зачувување на археолошкиот контекст на фрагментите. Во реална археолошка евиденција, важно е точно да се знае дали еден фрагмент е директен дел од предмет или е под-фрагмент од друг фрагмент.
+
+Ако ова правило не постои, би можело да се случи ист фрагмент да биде прикажан во две различни структури, што би предизвикало погрешни извештаи, неточна реконструкција на предметите и неконзистентна научна документација.
+
+7. **Пример на неправилен внес:**  
+
+{{{
+INSERT INTO Fragments (object_id, parent_fragment_id, status_id)
+VALUES (1, 2, 1);
+}}}
+
+Овој внес се одбива затоа што фрагментот има и `object_id` и `parent_fragment_id`.
+
+8. **Заклучок:**  
+`trg_fragment_check` е важен тригер за зачувување на правилната хиерархија на фрагментите. Тој спречува нелогични релации во археолошката документација и обезбедува секој фрагмент да има јасна и единствена припадност.
+
+
+
+=== Тригер 2: Проверка на одобрен истражувачки пристап (trg_access_check) ===
+
+1. **Намена:**  
+Тригерот `trg_access_check` е наменет за валидација на записите во табелата `Researcher_Access`. Неговата цел е да спречи внесување на одобрен истражувачки пристап доколку не е наведен конкретен археолошки предмет.
+
+2. **Случај на употреба:**  
+Во системот, истражувачите можат да побараат пристап до конкретни предмети за научна обработка, анализа или конзерваторска документација. Пристапот не смее да биде апстрактен или општ, туку мора да се однесува на точно определен артефакт.
+
+Одобрување пристап без конкретен предмет би било логички невалидно, бидејќи системот не би знаел до кој објект истражувачот добил дозвола.
+
+3. **Причина за избор на тригер:**  
+Тригерот е избран затоа што ова правило е поврзано со бизнис логиката на процесот на одобрување пристап. Иако `object_id` во табелата `Researcher_Access` е дефиниран како `NOT NULL`, тригерот додава дополнителна проверка за конкретен случај: кога статусот на пристап е одобрен.
+
+На тој начин правилото е експлицитно документирано во базата и директно се поврзува со статусот `access_status_id = 6`, кој во податоците се користи за статусот „Одобрено“.
+
+4. **Имплементација:**  
+
+Тригер функцијата е:
+
+{{{
+CREATE OR REPLACE FUNCTION trg_block_access()
+RETURNS TRIGGER AS $$
+BEGIN
+    IF NEW.access_status_id = 6 AND NEW.object_id IS NULL THEN
+        RAISE EXCEPTION 'Не може одобрен пристап без објект';
+    END IF;
+
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+}}}
+
+Тригерот се активира:
+
+{{{
+CREATE TRIGGER trg_access_check
+BEFORE INSERT ON Researcher_Access
+FOR EACH ROW
+EXECUTE FUNCTION trg_block_access();
+}}}
+
+5. **Логика на работа:**  
+Тригерот се извршува пред внесување нов запис во `Researcher_Access`.
+
+Проверува дали:
+ * `access_status_id = 6`, односно пристапот е одобрен
+ * `object_id IS NULL`, односно не е наведен предмет
+
+Доколку двата услови се исполнети, внесот се блокира.
+
+6. **Бизнис логика:**  
+Овој тригер ја имплементира контролата на истражувачки пристап. Во контекст на културно наследство, предметите можат да имаат чувствителни информации, како точна локација на пронаоѓање, состојба, вредност, конзерваторски третмани или научна важност.
+
+Затоа секој одобрен пристап мора да биде поврзан со конкретен предмет. Ова спречува нејасни дозволи и овозможува прецизна ревизија на тоа кој корисник добил пристап до кој артефакт.
+
+7. **Заклучок:**  
+`trg_access_check` обезбедува дополнителна безбедност и логичка исправност во процесот на одобрување истражувачки пристап. Тој спречува креирање на невалидни записи и помага системот да одржи точна евиденција за дозволите на истражувачите.
+
+
+
+=== Тригер 3: Спречување публикација без главен автор (trg_publication_check) ===
+
+1. **Намена:**  
+Тригерот `trg_publication_check` е наменет за проверка на научните публикации пред нивно внесување или ажурирање. Неговата цел е да спречи публикација да постои без дефиниран главен автор.
+
+2. **Случај на употреба:**  
+Во системот се чуваат научни публикации поврзани со археолошки предмети. Публикацијата може да има повеќе автори преку табелата `Publication_Authors`, но мора да постои еден главен автор во табелата `Publications` преку полето `main_author_id`.
+
+Главниот автор е важен затоа што претставува примарно лице одговорно за публикацијата, нејзината содржина и академската евиденција.
+
+3. **Причина за избор на тригер:**  
+Тригерот е избран затоа што се работи за бизнис правило кое мора да важи и при внесување и при ажурирање на публикации. Иако ова правило може делумно да се реализира со `NOT NULL` constraint, тригерот овозможува експлицитна контрола и јасна порака за грешка.
+
+Дополнително, тригерот е корисен бидејќи во моделот `main_author_id` може да биде `NULL` на ниво на дефиниција на табела, но бизнис логиката бара да не се дозволува реално внесување публикација без главен автор.
+
+4. **Имплементација:**  
+
+Тригер функцијата е:
+
+{{{
+CREATE OR REPLACE FUNCTION trg_pub_author_check()
+RETURNS TRIGGER AS $$
+BEGIN
+    IF NEW.main_author_id IS NULL THEN
+        RAISE EXCEPTION 'Публикацијата мора да има главен автор';
+    END IF;
+
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+}}}
+
+Тригерот се активира:
+
+{{{
+CREATE TRIGGER trg_publication_check
+BEFORE INSERT OR UPDATE ON Publications
+FOR EACH ROW
+EXECUTE FUNCTION trg_pub_author_check();
+}}}
+
+5. **Логика на работа:**  
+Тригерот се извршува пред секој `INSERT` или `UPDATE` врз табелата `Publications`.
+
+Доколку новата вредност за `main_author_id` е `NULL`, внесот или ажурирањето се прекинува и се фрла исклучок.
+
+6. **Бизнис логика:**  
+Овој тригер ја имплементира академската логика на системот. Во археолошки и научен контекст, секоја публикација мора да има одговорен автор.
+
+Без ова правило, системот би можел да содржи публикации без јасна одговорност, што би довело до проблеми при цитирање, библиографска обработка и научна документација.
+
+7. **Заклучок:**  
+`trg_publication_check` обезбедува секоја научна публикација да има главен автор. Со тоа се зачувува академскиот интегритет на податоците и се спречува внесување нецелосни публикации.
+
+
+
+=== Тригер 4: Автоматско поставување статус на фрагмент (trg_fragment_auto_status) ===
+
+1. **Намена:**  
+Тригерот `trg_fragment_auto_status` е наменет за автоматско поставување статус на нов фрагмент при негово внесување во табелата `Fragments`.
+
+2. **Случај на употреба:**  
+Кога се внесува нов фрагмент кој е поврзан со конкретен археолошки предмет преку `object_id`, системот автоматски му поставува иницијален статус.
+
+Ова е корисно затоа што при теренска работа или масовно внесување податоци може да се внесат голем број фрагменти, па рачното поставување статус за секој од нив би било подложно на грешки.
+
+3. **Причина за избор на тригер:**  
+Тригерот е избран затоа што статусот треба автоматски да се постави во моментот на внесување, врз основа на вредноста на `object_id`.
+
+Ова правило е динамично: ако фрагментот е поврзан со предмет, тогаш добива статус. Затоа е соодветно да се користи `BEFORE INSERT` тригер, кој може да ја промени вредноста на `NEW.status_id` пред записот да биде зачуван.
+
+4. **Имплементација:**  
+
+Тригер функцијата е:
+
+{{{
+CREATE OR REPLACE FUNCTION trg_auto_fragment_status()
+RETURNS TRIGGER AS $$
+BEGIN
+    IF NEW.object_id IS NOT NULL THEN
+        NEW.status_id := 1;
+    END IF;
+
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+}}}
+
+Тригерот се активира:
+
+{{{
+CREATE TRIGGER trg_fragment_auto_status
+BEFORE INSERT ON Fragments
+FOR EACH ROW
+EXECUTE FUNCTION trg_auto_fragment_status();
+}}}
+
+5. **Логика на работа:**  
+Тригерот се активира пред секој внес во `Fragments`.
+
+Ако новиот фрагмент има вредност во `object_id`, тогаш автоматски се поставува:
+
+{{{
+NEW.status_id := 1;
+}}}
+
+Со тоа фрагментот добива иницијален статус без корисникот да мора рачно да го внесе.
+
+6. **Бизнис логика:**  
+Овој тригер ја имплементира автоматизацијата на теренската и лабораториската евиденција на фрагменти. Во систем за културно наследство, фрагментите често се внесуваат во голем број, особено при археолошки ископувања или лабораториска обработка.
+
+Автоматското поставување статус обезбедува секој фрагмент кој е поврзан со предмет да има валиден почетен статус, што го олеснува понатамошното следење, класификација и конзервација.
+
+7. **Заклучок:**  
+`trg_fragment_auto_status` ја намалува можноста за човечка грешка при внесување фрагменти и обезбедува поголема конзистентност во базата. Тој е особено корисен при масовно внесување археолошки материјал.
+
+
+
+=== Тригер 5: Проверка на совпаѓање помеѓу проект и предмет кај истражувачки пристап (trg_researcher_access_project_match) ===
+
+1. **Намена:**  
+Тригерот `trg_researcher_access_project_match` е наменет за проверка дали конзерваторскиот проект наведен во `Researcher_Access` навистина се однесува на истиот предмет за кој се бара истражувачки пристап.
+
+2. **Случај на употреба:**  
+Во системот, истражувачкиот пристап може да биде поврзан со конкретен конзерваторски проект преку `conservation_project_id`. Секој конзерваторски проект во табелата `Conservation_Projects` е поврзан со точно одреден предмет преку `object_id`.
+
+Проблемот се јавува ако истражувач побара пристап до еден предмет, но во барањето наведе конзерваторски проект кој реално припаѓа на друг предмет. Таков запис би бил логички неконзистентен и би можел да доведе до погрешно одобрување на пристап.
+
+3. **Причина за избор на тригер:**  
+Овој тригер е избран затоа што правилото бара споредба на вредности од две различни табели:
+
+ * `Researcher_Access.object_id`
+ * `Conservation_Projects.object_id`
+
+Обичен `FOREIGN KEY` може да провери дали `conservation_project_id` постои во `Conservation_Projects`, но не може сам да провери дали тој проект се однесува на истиот `object_id` кој е наведен во барањето за пристап.
+
+Затоа се користи тригер, бидејќи тој може да изврши дополнителен `SELECT`, да ја прочита вредноста `object_id` од проектот и да ја спореди со новиот запис во `Researcher_Access`.
+
+4. **Имплементација:**  
+
+Тригер функцијата е:
+
+{{{
+CREATE OR REPLACE FUNCTION trg_validate_project_object_match()
+RETURNS TRIGGER AS $$
+DECLARE
+    v_project_object_id BIGINT;
+BEGIN
+    IF NEW.conservation_project_id IS NULL THEN
+        RETURN NEW;
+    END IF;
+
+    SELECT object_id
+    INTO v_project_object_id
+    FROM Conservation_Projects
+    WHERE project_id = NEW.conservation_project_id;
+
+    IF v_project_object_id <> NEW.object_id THEN
+        RAISE EXCEPTION 'Конзерваторскиот проект % не припаѓа на објектот %. Пристапот е одбиен.',
+            NEW.conservation_project_id, NEW.object_id;
+    END IF;
+
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+}}}
+
+Тригерот се активира:
+
+{{{
+CREATE TRIGGER trg_researcher_access_project_match
+BEFORE INSERT OR UPDATE ON Researcher_Access
+FOR EACH ROW
+EXECUTE FUNCTION trg_validate_project_object_match();
+}}}
+
+5. **Логика на работа:**  
+Тригерот се активира пред секој `INSERT` или `UPDATE` во `Researcher_Access`.
+
+Прво проверува дали `NEW.conservation_project_id` е `NULL`.
+
+Ако нема поврзан проект, нема што да се проверува и записот продолжува.
+
+Ако постои поврзан проект, тригерот го пронаоѓа `object_id` од табелата `Conservation_Projects` за тој проект:
+
+{{{
+SELECT object_id
+INTO v_project_object_id
+FROM Conservation_Projects
+WHERE project_id = NEW.conservation_project_id;
+}}}
+
+Потоа го споредува тој `object_id` со `NEW.object_id`.
+
+Ако вредностите не се исти, записот се одбива.
+
+6. **Бизнис логика:**  
+Овој тригер имплементира едно од најважните правила за контрола на истражувачки пристап. Во системот, пристапот не смее да се одобри преку проект кој не се однесува на истиот предмет.
+
+На пример, ако конзерваторски проект е креиран за предмет А, истражувачот не смее да го користи тој проект како основа за пристап до предмет Б. Тоа би создало сериозна неконзистентност во системот и би можело да доведе до неовластен пристап до погрешен артефакт.
+
+Ова е особено важно кај културното наследство, бидејќи предметите можат да имаат различен степен на заштита, различни истражувачки ограничувања и различна институционална сопственост.
+
+7. **Зошто не е доволен FOREIGN KEY:**  
+Стандардниот `FOREIGN KEY` constraint може да провери само дали вредноста `conservation_project_id` постои како `project_id` во `Conservation_Projects`.
+
+Но правилото овде е посложено. Треба да се провери дали:
+
+{{{
+Researcher_Access.conservation_project_id -> Conservation_Projects.project_id
+}}}
+
+и истовремено дали:
+
+{{{
+Researcher_Access.object_id = Conservation_Projects.object_id
+}}}
+
+Ова е меѓутабеларна логичка проверка и затоа е соодветно имплементирана со тригер.
+
+8. **Заклучок:**  
+`trg_researcher_access_project_match` обезбедува логичка конзистентност помеѓу истражувачките барања, предметите и конзерваторските проекти. Овој тригер спречува сериозни грешки во пристапот и ја зајакнува безбедноста и точноста на системот.