Sistem Manajemen Kegiatan Komunitas

Berikut adalah Desain ERD dari Sistem Manajemen Kegiatan Komunitas :

Berdasarkan ERD (Entity Relationship Diagram) yang terlihat di gambar, berikut adalah penjelasan mengenai relasi antar tabel:

1. Tabel admin

   • Atribut: id, username, password.
   • Tidak memiliki relasi langsung dengan tabel lain, tetapi ini biasanya digunakan untuk mengelola sistem (admin panel).

2. Tabel members

   • Atribut: id, name, role, email, contact, address.
   • Tidak ada relasi langsung yang terlihat di diagram, tetapi ini adalah tabel yang digunakan untuk mencatat data anggota komunitas.

3. Tabel events

   • Atribut: id, title, date, time, location, theme, poster.
   • Relasi:
     • Dengan tabel participants: Relasi satu ke banyak. Satu event (events.id) bisa memiliki banyak peserta (participants.event_id).
     • Dengan tabel feedback: Relasi satu ke banyak. Satu event (events.id) bisa menerima banyak feedback (feedback.event_id).

4. Tabel participants

   • Atribut: id, event_id, name, email.
   • Relasi:
     • Dengan tabel events: Relasi banyak ke satu. Banyak peserta bisa terkait dengan satu event melalui atribut event_id.

5. Tabel feedback

   • Atribut: id, event_id, rating, comment.
   • Relasi:
     • Dengan tabel events: Relasi banyak ke satu. Banyak feedback bisa diberikan untuk satu event tertentu melalui event_id.

6. Tabel gallery

   • Atribut: id, theme, image_path, description, upload_date.
   • Tidak ada relasi langsung yang terlihat di diagram, tetapi ini digunakan untuk menyimpan dokumentasi berupa gambar dari kegiatan.

Ringkasan Relasi:

• Events dan Participants: Satu event memiliki banyak peserta.
• Events dan Feedback: Satu event memiliki banyak feedback.
• Admin, Members, dan Gallery: Berdiri sendiri tanpa relasi langsung yang terlihat di diagram ini, tetapi biasanya memiliki peran mendukung pengelolaan dan dokumentasi kegiatan komunitas.

Berikut adalah Desain EERD dari Sistem Manajemen Kegiatan Komunitas :

Gambar 2 : DESAIN EERD SISTEM MANAJEMEN KEGIATAN KOMUNITAS

Berdasarkan EERD (Enhanced Entity-Relationship Diagram) yang terlihat, berikut adalah penjelasan mengenai relasi antar tabel:

Relasi Antar Tabel

1. Tabel admin

   • Atribut: id, username, password.
   • Tidak memiliki relasi langsung dengan tabel lain. Ini biasanya digunakan untuk mengelola seluruh sistem (akses oleh admin).

2. Tabel members

   • Atribut: id, name, contact, email, address, role.
   • Tidak terlihat relasi langsung dengan tabel lain, tetapi tabel ini menyimpan informasi anggota komunitas.

3. Tabel events

   • Atribut: id, title, date, time, location, theme, poster.
   • Relasi:
     • Ke tabel participants: Satu event (events.id) dapat memiliki banyak peserta (participants.event_id). Relasi ini menunjukkan bahwa peserta terhubung dengan event tertentu.
     • Ke tabel feedback: Satu event (events.id) dapat menerima banyak feedback (feedback.event_id). Relasi ini memungkinkan evaluasi event berdasarkan feedback peserta.

4. Tabel participants

   • Atribut: id, name, email, event_id.
   • Relasi:
     • Ke tabel events: Banyak peserta (participants.event_id) bisa terhubung ke satu event (events.id). Ini menunjukkan partisipasi dalam sebuah kegiatan.

5. Tabel feedback

   • Atribut: id, event_id, rating, comment.
   • Relasi:
     • Ke tabel events: Banyak feedback (feedback.event_id) terkait dengan satu event (events.id). Ini memungkinkan evaluasi untuk setiap event berdasarkan rating dan komentar.

6. Tabel gallery

   • Atribut: id, image_path, description, upload_date, theme.
   • Tidak ada relasi langsung yang terlihat di diagram ini, tetapi biasanya digunakan untuk menyimpan dokumentasi acara. Tabel ini dapat dihubungkan secara konseptual dengan tema (theme) dari tabel events.

Ringkasan Relasi

• Satu event (events.id) memiliki banyak peserta (participants.event_id).
• Satu event (events.id) menerima banyak feedback (feedback.event_id).
• Gallery berdiri sendiri, tetapi atribut theme memungkinkan untuk dihubungkan secara tematik ke tabel events.

Berikut adalah studi kasus berdasarkan ERD dan EERD tersebut

Studi Kasus: Sistem Manajemen Kegiatan Komunitas

Deskripsi Kasus:

Sebuah komunitas memiliki sistem untuk mengelola kegiatan mereka. Sistem ini memungkinkan admin untuk menambahkan anggota, membuat acara, mencatat peserta yang hadir, mengumpulkan feedback dari acara, dan mendokumentasikan acara dalam galeri. Berikut adalah skenario penggunaannya:

Skenario 1: Pengelolaan Data Admin

• Tujuan: Admin dapat mengakses sistem untuk mengelola seluruh data.
• Detail:
  • Admin login ke sistem menggunakan username dan password yang tersimpan di tabel admin.
  • Setelah berhasil login, admin dapat membuat, memperbarui, atau menghapus event dan mengelola data peserta.

Skenario 2: Menambah Data Anggota Komunitas

• Tujuan: Komunitas mencatat semua anggotanya.
• Detail:
  • Admin menambahkan anggota baru ke dalam tabel members.
  • Data anggota mencakup nama, peran di komunitas (misalnya Ketua, Anggota), email, kontak, dan alamat.
  • Tidak semua anggota harus terlibat dalam setiap kegiatan, tetapi data mereka tetap ada di sistem.

Skenario 3: Membuat Kegiatan (Events)

• Tujuan: Admin dapat menambahkan kegiatan yang akan diadakan komunitas.
• Detail:
  • Admin membuat kegiatan baru di tabel events.
  • Admin mengisi data seperti judul acara, tanggal, waktu, lokasi, tema acara, dan mengunggah poster acara.
  • Kegiatan yang sudah dibuat akan muncul di sistem untuk dicatat kehadirannya.

Skenario 4: Pendaftaran Peserta ke Kegiatan

• Tujuan: Peserta dapat mendaftar untuk menghadiri kegiatan.
• Detail:
  • Setiap peserta yang ingin menghadiri acara dicatat di tabel participants.
  • Data peserta yang dicatat meliputi nama, email, dan event_id dari acara yang dihadiri.
  • Sistem memungkinkan banyak peserta untuk mendaftar ke satu acara.

Skenario 5: Mengumpulkan Feedback dari Kegiatan

• Tujuan: Setelah acara selesai, peserta memberikan feedback.
• Detail:
  • Setelah acara selesai, peserta diminta memberikan rating (misalnya skala 1--5) dan komentar tentang acara.
  • Feedback dicatat di tabel feedback, dengan relasi ke event_id dari acara yang dihadiri.
  • Admin dapat menganalisis feedback untuk evaluasi acara di masa mendatang.

Skenario 6: Menambahkan Dokumentasi ke Galeri

• Tujuan: Admin mendokumentasikan kegiatan ke dalam galeri komunitas.
• Detail:
  • Setelah acara selesai, admin mengunggah foto atau video dokumentasi ke tabel gallery.
  • Data dokumentasi mencakup tema kegiatan, deskripsi, path file media (misalnya URL gambar), dan tanggal unggahan.
  • Galeri ini menjadi arsip visual kegiatan komunitas.

Penerapan Relasi dalam Studi Kasus

1. Relasi Events dan Participants

   • Contoh: Acara "Workshop Programming" (event ID = 1) dihadiri oleh 30 peserta, dan semua peserta dicatat di tabel participants dengan event_id = 1.

2. Relasi Events dan Feedback

   • Contoh: Setelah acara "Workshop Programming" selesai, peserta memberikan rating dan komentar seperti:
     • Rating: 5, Komentar: "Acara sangat bermanfaat."
     • Rating: 4, Komentar: "Lokasi perlu ditingkatkan."
       Semua feedback terkait dengan event_id = 1.

3. Relasi Galeri dan Kegiatan

   • Contoh: Foto dari acara "Workshop Programming" diunggah ke galeri dengan tema "Workshop Programming" dan deskripsi "Foto kegiatan belajar bersama."

Mungkin Lebih Jelaskan Bisa Kita Saksikan Pada Video Youtube saya Beriukut :