Актуелна верзија - v.1.4

Дијаграм

Податочни побарувања

Ентитети

1. Users - ентитет со податоци за секој корисник. Родител-ентитет од кој произлегуваат 4 ентитети.

• idUser - serial, primary key, not null
• dateCreatedUser - Date, not null
• nameUser - varchar, not null
• emailuser - varchar, not null
• passwordUser - varchar, not null
• telephoneUser - varchar, nullable

2. Adopters - ентитет за корисниците кои сакаат да посвојат или привремено да чуваат милениче

• idUser* - serial, primary key, references User, not null
• freeTime - integer (enum: 0=low, 1=medium, 2=high), nullable
• funds - integer (enum: 0=low, 1=medium, 2=high), nullable
• hasOtherPets - boolean, nullable
• hasKids - boolean, nullable
• housing - integer (enum: 0=apartment, 1=house), nullable
• physicalActivityAdopters - integer (enum: 0=low, 1=medium, 2=high), nullable
• willFoster - boolean, nullable
• is_verified - boolean, not null

3. Surendees - ентитет за корисниците кои сакаат да дадат свое милениче на посвојување или да креираат оглас за некое милениче кое го нашле на улица и му е потребен дом

• idUser* - serial, primary key, references User, not null

4. Employees - ентитет за корисниците кои се вработени во прифатилишта и организации

• idUser* - serial, primary key, references User, not null
• position - varchar, not null
• isVerified - boolean, not null

5. Admin - ентитет за тип на корисник кој менаџира со базата и системот

• idUser* - serial, primary key, references User, not null

6. Donors - ентитет за корисниците кои сакаат да донираат средства кон организациите

• idUser* - serial, primary key, references User, not null
• isFromOrganisation - boolean, not null
• nameOrganisationDonor - varchar, nullable

7. Organisations - ентитет за организации за заштита на животни

• idOrganisation - serial, primary key, not null
• nameOrganisation - varchar, not null
• emailOrganisation - varchar, not null
• bilingInformation - varchar, not null

8. Shelters - ентитет за прифатилишта за животни

• idShelter - serial, primary key, not null
• addressShelter - varchar, not null
• telephoneShelter - varchar, not null
• nameShelter - varchar, not null
• emailShelter - varchar, not null

9. Posts - ентитет за оглас за посвојување на милениче

• idPost - serial, primary key, not null
• datePost - date, not null
• urlThumbanil - varchar, nullable
• ограничување: Post мора да биде во точно една од релациите surrendees_publishes_and_manages_posts или employee_publishes_and_manages_post, не смее да не биде во ниту една или пак во двете

10. Adoptions - ентитет за посвојување или привремено чување на милениче

• idAdoption - serial, primary key, not null
• startDate - date, not null
• endDateFoster - date, nullable (доколку станува збор за посвојување е null, а ако е привремено чување има вредност)
• approved - boolean, not null

11. Pets - ентитет кој чува податоци за миленици

• idPet - serial, primary key, not null
• urlPetImage - varchar, nullable
• ageGroup - integer (enum: 0=young, 1=adult, 2=elder), not null
• size - integer (enum: 0=xsmall, 1=small, 2=medium, 3=large, 4=xlarge), not null
• breed - varchar, nullable
• namePet - varchar, nullable
• species - integer (enum: 0=cat, 1=dog, 2=bird), not null
• gender - integer (enum: 0=male, 1=female), not null
• canBeFostered - boolean, not null

12. Categories - ентитет кој чува податоци за категории на миленици

• idCategory - serial primary key, not null
• nameCategory - varchar, not null

13. Food - Ентитет кој чува различни типови на храна за миленичиња

• IdFood - serial, primary key, not null (Бидејќи има многу производители и типови на храна, се одлучивме клучот да биде од тип serial, доколку одбереме било кој од другите атрибути ќе имаме проблем при разликување на типот на храната)
• manufacturer - varchar, not null
• nameFood - varchar, not null
• type - int (enum: 0=dry, 1=wetFood), not null

14. Therapies - Ентитет кој чува здравствени проблеми кои миленичињата може да ги имаат и за кои треба да примаат терапија

• IdTherapy - serial, primary key, not null
• healthProblem - varchar, not null
• startDate - date, nullable
• endDate - date, nullable

15. VetClinics - Ентитет кој чува ветеринарни клиники

• idVetClinic - serial, primary key, not null
• telephoneVetClinic - varchar, not null
• addressVetClinic - varchar, not null
• nameVetClinic - varchar, not null

Слаби Ентитети

1. PersonalProfile - Ентитет кој ќе ги чува личните карактеристики на миленичињата

• idPet - serial, primary key (references Pets), not null (Овој атрибут ќе биде референциран од ентитетот Pets, бидејќи секое милениче има свои различни карактерни особини)
• friendlyToKids - int (enum: 0=low, 1=medium, 2=high), not null
• friendlyToPets - int (enum: 0=low, 1=medium, 2=high), not null
• attention - int (enum: 0=low, 1=medium, 2=high), not null
• physicalActivity - int (enum: 0=low, 1=medium, 2=high), not null
• groomingNeeded - int (enum: 0=never, 1=rarely, 2=often), not null

1-1 Релации

1. pet_has_personal_profile - Релација помеѓу ентитетите Pets и PersonalProfile, оваа релација има за цел да го поврзе секое милениче со своите карактерни особини, бидејќи секое милениче има само 1 комбинација од карактерни особини и една карактерна особина е врзана за едно милениче, релацијата е 1-1 и има тотално учество од двете страни.

2. pet_is_listed_in_post - Релација помеѓу ентитетите Pets и Posts и го поврзува секое милениче со својот оглас за посвојување. Секое милениче има само 1 свој оглас и 1 ограс е составен од само 1 милениче

1-М Релации

1. employee_verifies_adopter - Оваа релација е помеѓу ентитетите Adopters и Employees и служи за да ги поврзе двата типа на корисници за да може секој од корисниците кои сакаат да посвојат да бидат верифицирани од страна на обучен вработен дека е соодветен за да посвои милениче. Еден Adopter е верификуван од еден Employee. Еден Employee може да верификува повеќе Adopters. Целта на оваа релација е да служи за проверка дали некој Adopter е валиден и смее да посвои.

2. adopters_want_adoptions - Оваа релација ги поврзува ентитетите Adopters и Adoptions и го поврзува соодветниот посвојувач со посвојувањеето кое го посакува. Секој Adoption мора да се однесува на точно еден Adopter.

3. adoptions_for_pets - Оваа релација ги поврзува ентитетите Pets и Adoptions и го поврзува миленичето со посвојувањеето кое е наменето за тоа милениче. Секој Adoption мора да се однесува на точно еден Pet.

4. surrendees_publishes_and_manages_posts - Релација која поврзува Surrendees со Posts, еден Surrendee објавува и менаџира со повеќе Posts, еден Post е објавен и менаџиран од еден Surrendees.

• ограничување: Post мора да биде во точно една од релациите surrendees_publishes_and_manages_posts или employee_publishes_and_manages_post, не смее да не биде во ниту една или пак во двете

5. еmployee_works_at_shelter - Релација која поврзува Employee со Shelters, еден Employee работи во точно еден Shelter, еден Shelter има повеќе Employees.

6. shelter_is_from_organisation - Релација која поврзува Shelteer со Orginisation, еден Shelter прпаѓа на еден Organisation, еден Organisation има повеќе Shelters.

7. pet_is_in_shelter - Релација која поврзува Pets со Shelter, еден Pet го има во eден Shelter, еден Shelter има повеќе Pets.

8. employee_publishes_and_manages_post - Релација која поврзува Employee со Posts, еден Employee објавува и менаџира со повеќе Posts, еден Post е објавен и менаџиран од повеќе Employees

• ограничување: Post мора да биде во точно една од релациите surrendees_publishes_and_manages_posts или employee_publishes_and_manages_post, не смее да не биде во ниту една или пак во двете

9. аdmin_verifies_employee - Релација која поврзува Admin со Employee, еден Employee е верификуван од еден Admin. Целта на оваа релација е да служи за проверка дали некој Employee е валиден и смее да менаџира со посвојувања.

М-М Релации

1. donor_donates_to_organisation - Релација која поврзува Donor со Organisation , еден Donor донира на повеќе Organisations, еден Organisation може да добие донации од повеќе Donors.

2. pet_belongs_to_category - Релација која поврзува Pets со Category, еден Pet може да припаѓа на повеќе, еден Category има повеќе Pets.

3. pet_needs_therapy - Релација која поврзува Pets со Therapies, еден Pet може да има повеќе Therapies, еден Therapy може да е примен од повеќе Pets.

4. pet_preferably_eats_food - Релација која поврзува Pets со Food, еден Pet со повеќе Food, еден Food со повеќе Pets.

• quantityADay - integer, not null

5. pet_needs_intervention_in_vet_clinic - Релација која поврзува Pets со VetClinics, еден Pet може да му е потребна интервенција во повеќе VetClinics, во една VetClinic може да имаат интервенција повеќе Pets

• dateOfInterventing - date, not null
• description - varchar, nullable

Историјат:

Верзија	Датум	Што беше променето
v.1.0	2022.11.09	Иницијална верзија
v.1.1	2022.11.12	Корекции според забелешки од демонстраторот: Од релацијата employee_verifies_adopter го отстранивме атрибутот is_verified и го додадовме како атрибут на Adopter. Променивме Adoption да има тотално учество во релациите со Adopter и Pet бидејќи не смее да постои посвојување кое не е во двете релации. Изменивме во релацијата еmployee_works_at_shelter да има тотално учество од страна на Employee бидејќи во Shelter мора да има Employee. Во релацијата pet_has_personal_profile изменивме од двете страни да има тотално учество бидејќи секое милениче мора да има профил и секој профил мора да припаѓа на миленик. Релациите pet_preferably_eats_food и pet_needs_intervention_in_vet_clinic беа променети во М-М релации.
v.1.2	2022.11.17	Корекции според забелешки од професорот: Беа преименувани релациите employee_publishes_and_manages_post и surrendees_publishes_and_manages_posts за да не бидат исти. Ограничувањето дека Post мора да биде во точно една од релациите surrendees_publishes_and_manages_posts или employee_publishes_and_manages_post го додадовме во описот и во дијаграмот.
v.1.3	2022.12.14	Корекции направени при изработка на Ф2: При изработка на табелите се одлучивме атрибутот telephoneUser на User да го промениме да не биде повеќевредностен атрибут. Исто така ја отстранивме врската М-М adopte_views_post бидејќи одлучивме дека не ни е потребна таа табела/релација, чијашто цел беше да го чува пресметаниот атрибут compatibility. Решивме овој атрибут да го пресметуваме во имплементацијата на апликацијата. Го отстранивме тоталното учество од страна на Adopter во релацијата employee_verifies_adopter бидејќи ентитетот смее да постои без да биде во релацијата, а верификацијата е потребна понатаму за во техничката имплементација. Додадовме атрибут nameOrganisationDonor на ентитетот Donor, атрибути nameShelter и emailShelter на ентитетот Shelter, nameVetClinic на VetClinic и атрибут description на М-М релацијата pet_needs_intervention_in_vet_clinic.
v.1.4	2022.12.20	Корекции направени при изработка на Ф3: Додека ја изработувавме оваа фаза забележавме некои недостатоци во нашиот дизајн кои ги поправивме. Додадовме атрибут "approved" на ентитетот Adoption за во база да се разликуваат записите за барања за посвојување од записите за одобрено посвојување од огласувачот/прифатилиштето. Додадовме атрибут "isVerified" на ентитетот Employee и 1-М релација admin_verifies_employee. Целта на ова е да можат корисниците да се регистраат како вработени во прифатилиште, но во база да ги разликуваме оние кои админот ги одобрил и кои не се одобрени.

---

​Назад кон почетна