Фаза 2: DDL, податоци, погледи

Оваа фаза опфаќа генерирање на DDL за релациониот модел, полнење на базата со реалистични податоци и креирање на погледи (views) за потребите на апликацијата.

Фаза 2А: DDL и ограничувања

Истакнати ограничувања (Constraints):

• Додадени се проверки за исправност на форматот на email адресите со користење на регуларни изрази: CHECK (email ~* '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$').
• Поставени се логички ограничувања на ниво на колони, како што се проверка на возраст кај изведувачите CHECK (date_of_birth <= CURRENT_DATE) и проверка на лимитот за попуст CHECK (percent >= 0 AND percent <= 100).
• Дефинирани се DEFAULT вредности ('Anonymous') за корисничките имиња и презимиња во случај на недостаток на внес.

Фаза 2Б: Податоци и погледи

Податоци: Базата е наполнета со реалистични податоци со користење на Python скрипта и Faker библиотека. Големината на табелите го одразува реалното користење на продукциската апликација. Некои од најголемите табели во системот се:

• Табела Ticket: ~8.900.000 редици
• Табела Reservation: ~5.000.000 редици

Погледи (Views): Креирани се погледи кои ги спојуваат клучните табели за приказ во апликацијата. SQL кодот за креирање на овие погледи се наоѓа во базата.

1. new_event_ticket_sales_status

• Опис: Овој поглед врши агрегација на продадени билети по настан и сектор. Се користи за генерирање извештаи за пополнетост на капацитетот на објектите.

2. new_user_ticket_history

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

3. new_active_events_3_months

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