Нормализација и подобрувања на дизајнот на базата

Подобро именување на атрибути

status од табела Room_Request -> request_status
status од табела Document -> document_status
start_date од табелата StudentTookRoom -> room_start_date
end_date од табелата StudentTookRoom -> room_end_date
is_available од Room -> room_is_available
capacity од Room -> room_capacity

R = { u_id, phone_number, first_name, last_name, email, pass, faculty_name, year_of_studies, is_exempt, gender, p_id, amount, payment_date, payment_month, d_id, d_comment, d_name, document_status,
upload_date, file_path, block_id, num_available_rooms, room_number, room_is_available , room_capacity, request_status, roommate_email, room_start_date, room_end_date}

Определување на функциски зависности

u_id -> phone_number, first_name, last_name, email, pass
u_id(Student) -> year_of_studies, is_exempt, gender
u_id(Employee) -> ( претставува редундантна вредност, исти атрибути како u_id -> ...)
p_id -> amount, payment_date, payment_month, student_id
d_id -> d_comment, d_name, d_status, upload_date, file_path, u_id (Студентот прикачува)
d_id -> emp_id ( Вработениот прегледува документ )
block_id -> num_available_rooms
room_number, block_id -> is_available, capacity
room_number, block_id, student_id -> status, roommate_email, employee_id, requested_time
student_id, room_num, block_id -> start_date, end_date

Кандидати за примарен клуч

• u_id
• p_id
• d_id
• room_number - како дел од композитен клуч
• block_id

За да го избереме примарниот клуч треба да одбереме кандидати кои ги покриваат сите атрибути од десно

u_id += { phone_number, first_name, last_name, email, pass } -> Ги содржи податоците само за корисниците на системот
p_id += { amount, payment_date, payment_month, student_id } -> Ги содржи податоците за плаќање и за корисникот кој го извршил плаќањето
d_id += { d_comment, d_name, d_status, upload_date, file_path, emp_id, student_id } -> Ги содржи податоците за документот кој го поставил студентот и вработениот кој го прегледал
Единствен избор за примарен клуч на целата релација R би бил (u_id, p_id, d_id, room_number, block_id)
Сега R е во прва нормализирана форма односно ги исполнува условите сите атрибути да се атомски, нема колони кои се повторуваат и има примарен клуч кој ги покрива сите атрибути.

Декомпозиција во 2НФ

Ги отстранувам сите атрибути зависни од u_id во табела User(u_id, first_name, last_name, phone_number, email, password)
Атрибутите is_exempt, faculty_name, year_of_studies исто се зависни од u_id но ги отстранувам во нова табела бидејќи ова е пример за наследство и за избегнување на null вредности - Student(u_id, is_exempt, faculty_name, year_of_studies)
Атрибутите amount, payment_date, payment_month се зависни од p_id па ги делам во табела Payment(p_id, amount, payment_date, payed_month, u_id (Student)) Атрибутите d_comment, d_name, document_status, upload_date, file_path зависат само од d_id па ги ставам во табела заедно со зависностите за Student и Employee - Document(d_id, d_comment, d_name, document_status, upload_date, file_path, u_id(Student), u_id(Employee))
num_available_rooms зависи од block_id па Block(block_id, num_available_rooms)
room_is_available , room_capacity зависат од заедничкиот парцијален примарен клуч (block_id, room_number) па Room(block_id, room_number, room_is_available , room_capacity)
request_status, roommate_email атрибутите се зависни од u_id(Student), u_id(Employee), room_number, block_id па табелата би била Room_request( u_id(Student), u_id(Employee), room_number, block_id)
room_start_date, room_end_date атрибутите зависат на (u_id(Student), room_number, block_id) и тоа би била посебна табела Student_Took_Room(u_id(Student), room_number, block_id, room_start_date, room_end_date)

Со оваа поделба е направено отстранување на парцијалните зависности па имаме декомпозиција до втора нормална форма

Декомпозиција во 3НФ

Сите релации остануваат исти како и во првичната база па немам дополнителни промени во тој однос, имам подобрување во именувањето на некои од атрибутите за избегнување на конфузија.