Thiết kế Use Case và Mô hình Dữ liệu cho FTU Connect: Mạng Xã hội Nội bộ Trường Đại học Ngoại thương

1. Giới thiệu

Quá trình xây dựng một hệ thống phần mềm phức tạp như mạng xã hội nội bộ đại học đòi hỏi sự chuẩn bị kỹ lưỡng về mặt phân tích nghiệp vụ trước khi bước vào giai đoạn lập trình. Hai công cụ nền tảng trong kỹ nghệ phần mềm — biểu đồ use case và mô hình dữ liệu — đóng vai trò như bản vẽ kỹ thuật của một công trình: chúng xác định hệ thống cần làm gì và lưu trữ thông tin như thế nào trước khi bất kỳ dòng mã nào được viết ra.

Bài viết này phân tích thiết kế kỹ thuật cho FTU Connect — mạng xã hội nội bộ được đề xuất xây dựng cho Trường Đại học Ngoại thương. Dựa trên khung lý thuyết về mạng xã hội doanh nghiệp trong giáo dục (Chatterjee et al., 2021) và nghiên cứu về tương tác sinh viên với công nghệ giáo dục (Bond et al., 2020), chúng tôi xác định 22 use case cốt lõi, 19 thực thể dữ liệu, và ba lớp kiến trúc hệ thống tương ứng.

Mục tiêu không phải viết một tài liệu đặc tả kỹ thuật khô khan, mà là giúp đội ngũ quản lý, giảng viên và sinh viên FTU hình dung được "bản đồ" của hệ thống họ sắp dùng — ai dùng được gì, dữ liệu nào được lưu trữ, và các phần của hệ thống kết nối với nhau ra sao.

2. Phân tích tác nhân (Actor Analysis)

Trong kỹ nghệ phần mềm, tác nhân (actor) là bất kỳ thực thể nào tương tác với hệ thống từ bên ngoài. FTU Connect phục vụ năm nhóm tác nhân chính, mỗi nhóm có nhu cầu và quyền hạn khác nhau:

Ngoài năm tác nhân người dùng, hệ thống còn có hai tác nhân hệ thống đóng vai trò nền tảng: Hệ thống LMS (tự động đồng bộ danh sách lớp học phần) và Cổng xác thực FTU (SSO — Single Sign-On — đảm bảo mỗi tài khoản gắn với một cán bộ/sinh viên thực).

3. Danh mục Use Case

Dựa trên mô hình nghiên cứu về vai trò của mạng xã hội doanh nghiệp trong chia sẻ tri thức tổ chức (Chatterjee et al., 2021) và đặc thù môi trường đại học, chúng tôi xác định 22 use case chia thành sáu nhóm chức năng.

3.1 Nhóm Quản lý danh tính và hồ sơ

3.2 Nhóm Nội dung và tương tác

3.3 Nhóm Cộng đồng và nhóm

3.4 Nhóm Nhắn tin

3.5 Nhóm Tài liệu và sự kiện

3.6 Nhóm Quản trị hệ thống

5. Mô hình dữ liệu

Mô hình dữ liệu định nghĩa cách thông tin được tổ chức và lưu trữ trong cơ sở dữ liệu. Theo nguyên lý thiết kế mạng xã hội nội bộ tổ chức, vốn xã hội và chia sẻ tri thức trở nên hiệu quả hơn khi dữ liệu được cấu trúc xoay quanh người dùng và mối quan hệ giữa họ (Berraies et al., 2020). FTU Connect sử dụng 19 thực thể dữ liệu được tổ chức thành năm cụm chức năng.

5.1 Cụm người dùng (User Cluster)

User là thực thể trung tâm. Mỗi bản ghi User gắn với tài khoản FTU qua email_ftu (định danh duy nhất). Bảng User lưu thông tin xác thực; bảng Profile tách riêng thông tin học thuật để dễ mở rộng — bảng User được truy vấn mỗi lần xác thực (tần suất rất cao), Profile chỉ đọc khi xem hồ sơ (tần suất thấp hơn).

• User — id, email_ftu, full_name, role [student/lecturer/staff/admin/alumni], avatar_url, status [active/suspended/deleted], created_at, last_login_at
• Profile — user_id FK, display_name, department, student_code, graduation_year, bio, skills JSON, social_links JSON, privacy_setting
• Connection — follower_id FK→User, following_id FK→User, created_at — quan hệ theo dõi một chiều

5.2 Cụm nội dung (Content Cluster)

• Post — id, author_id FK→User, group_id FK→Group nullable, content_text, media_urls JSON, post_type [text/image/video/document_share], visibility [public/group/private], is_pinned, created_at, updated_at, deleted_at nullable
• Comment — id, post_id FK→Post, author_id FK→User, parent_comment_id FK→Comment nullable, content_text, created_at — hỗ trợ bình luận lồng nhau 2 cấp
• Reaction — id, user_id FK, target_type [post/comment], target_id, reaction_type [like/insightful/helpful/celebrate], created_at — thiết kế polymorphic
• Tag — id, slug, display_name, category [subject/club/topic/department]
• PostTag — post_id FK, tag_id FK — bảng junction nhiều-nhiều
• Report — id, reporter_id FK, target_type, target_id, reason, status [pending/resolved/dismissed], created_at

5.3 Cụm cộng đồng (Community Cluster)

• Group — id, name, slug, description, group_type [class/club/department/topic], visibility [public/private/secret], owner_id FK, member_count, created_at, is_archived
• GroupMember — group_id FK, user_id FK, role [owner/admin/moderator/member], joined_at, invited_by FK nullable
• JoinRequest — id, group_id FK, requester_id FK, status [pending/approved/rejected], created_at

5.4 Cụm giao tiếp (Communication Cluster)

• Conversation — id, type [direct/group_chat], title nullable, last_message_at
• ConversationParticipant — conversation_id FK, user_id FK, joined_at, is_muted
• Message — id, conversation_id FK, sender_id FK, content_text, attachment_url nullable, message_type [text/image/file], created_at, deleted_at nullable
• MessageRead — message_id FK, user_id FK, read_at

5.5 Cụm hoạt động (Activity Cluster)

• Document — id, title, description, file_url, file_size_kb, author_id FK, group_id FK nullable, category, download_count, is_public, created_at
• Event — id, title, organizer_id FK, group_id FK nullable, start_time, end_time, location_text, capacity nullable, event_type [online/offline/hybrid], registration_deadline
• EventRegistration — event_id FK, user_id FK, registered_at, status [registered/cancelled/attended], check_in_at nullable
• Notification — id, recipient_id FK, actor_id FK nullable, notification_type [reaction/comment/mention/follow/group_invite/event_reminder/system], title, body, ref_type, ref_id, is_read, created_at

6. Sơ đồ mô hình dữ liệu (ERD)

Biểu đồ dưới đây minh họa 19 thực thể và các mối quan hệ chính giữa chúng. Mũi tên chỉ chiều của khóa ngoại (foreign key):

Hình 2: Sơ đồ mô hình thực thể FTU Connect (19 thực thể / 5 cụm chức năng)

7. Kiến trúc hệ thống và tích hợp

Thiết kế kỹ thuật tốt không chỉ dừng lại ở mức dữ liệu — nó cần định nghĩa cách các thành phần giao tiếp với nhau. FTU Connect được thiết kế theo kiến trúc ba lớp:

Hình 3: Kiến trúc ba lớp của FTU Connect

Điểm tích hợp quan trọng nhất là Cổng SSO FTU: khi sinh viên đăng nhập lần đầu, hệ thống tự động tạo bản ghi User với role được ánh xạ từ hệ thống quản lý đào tạo (SIS), loại bỏ hoàn toàn nhu cầu đăng ký thủ công. LMS Sync Service định kỳ đồng bộ danh sách học phần để tự động tạo nhóm lớp tương ứng (Group với group_type = 'class'), giúp giảng viên và sinh viên cùng lớp được kết nối ngay khi học kỳ bắt đầu.

8. Một số quyết định thiết kế đáng chú ý

Bên cạnh mô hình tổng thể, một số lựa chọn thiết kế đặc thù đáng được giải thích để tránh hiểu lầm trong quá trình triển khai.

Visibility tại hai cấp độ. Cột visibility trong bảng Post hoạt động song song với trạng thái của Group. Một bài đăng visibility = 'group' trong một nhóm visibility = 'secret' chỉ hiển thị với thành viên nhóm — đây là cơ chế bảo vệ nội dung học phần không bị lộ ra ngoài.

Polymorphic Reaction. Thay vì tạo hai bảng riêng PostReaction và CommentReaction, cột target_type và target_id cho phép một bảng Reaction phục vụ cả hai đối tượng. Khi cần mở rộng sang Document, chỉ cần thêm một giá trị enum cho target_type mà không cần thay đổi schema.

Soft delete thay vì hard delete. Các bảng Post, Comment, Message đều có cột deleted_at nullable. Thay vì xóa hẳn bản ghi, hệ thống đánh dấu thời điểm xóa. Điều này cho phép quản trị viên khôi phục nội dung khi cần điều tra vi phạm, đồng thời giữ nguyên liên kết parent_comment_id không bị mất tham chiếu.

JSON cho fields linh hoạt. Các trường skills, social_links trong Profile và media_urls trong Post được lưu dạng JSON thay vì tách bảng riêng. Lý do: tần suất truy vấn toàn bộ danh sách cao hơn nhiều so với việc lọc theo từng kỹ năng — JSON tối ưu hơn về hiệu suất trong trường hợp này.

Notification không tham chiếu trực tiếp. Bảng Notification dùng cặp ref_type + ref_id (tương tự polymorphic) thay vì khóa ngoại cứng. Điều này cho phép gửi thông báo về bất kỳ đối tượng nào trong hệ thống mà không cần thêm cột FK mỗi lần mở rộng.

9. Lộ trình triển khai theo nhóm use case

Không phải tất cả 22 use case được xây dựng cùng một lúc. Nghiên cứu về tương tác sinh viên với nền tảng công nghệ giáo dục chỉ ra rằng việc ra mắt theo lớp — ưu tiên chức năng nền tảng trước, bổ sung dần các tính năng nâng cao — giúp người dùng thích nghi tốt hơn và giảm nguy cơ hệ thống quá tải trong giai đoạn đầu (Bond et al., 2020). [Phân tích của tác giả]

Hình 4: Lộ trình triển khai use case theo ba giai đoạn

10. Kết luận

Phân tích 22 use case và 19 thực thể dữ liệu cho FTU Connect không phải bài tập lý thuyết — đây là bản thiết kế nền tảng mà đội ngũ phát triển sẽ dựa vào để viết code, thiết kế giao diện và lên kế hoạch kiểm thử. Mỗi quyết định trong mô hình dữ liệu — từ soft delete, polymorphic reaction, đến JSON column — đều phản ánh sự cân nhắc về hiệu suất, khả năng mở rộng và tính bảo trì lâu dài.

Quan trọng hơn, tài liệu này mời cộng đồng FTU — sinh viên, giảng viên, cán bộ — tham gia vào quá trình xây dựng. Phản hồi về use case còn thiếu, dữ liệu cần bổ sung, hay luồng nghiệp vụ cần điều chỉnh nên được thu thập ngay trong giai đoạn Beta để tránh chi phí sửa đổi lớn sau khi hệ thống đi vào vận hành chính thức. Một mạng xã hội nội bộ thực sự phục vụ cộng đồng FTU phải được thiết kế cùng với cộng đồng đó — không chỉ cho họ.

Tài liệu tham khảo

Berraies, S., Lajili, R., & Chtioui, R. (2020). Social capital, employees' well-being and knowledge sharing: does enterprise social network matter? Journal of Intellectual Capital, 22(1), 15–42. https://doi.org/10.1108/jic-01-2020-0012

Bond, M., Buntins, K., & Bedenlier, S. (2020). Mapping research in student engagement and educational technology in higher education: A systematic evidence map. Journal of Educational Technology & Society, 23(1), 1–14. https://doi.org/10.1186/s41239-019-0176-8

Chatterjee, S., Chaudhuri, R., & Vrontis, D. (2021). Enterprise social network for knowledge sharing in MNCs: Examining the role of knowledge contributors and value co-creation. International Journal of Information Management, 60, 102374. https://doi.org/10.1016/j.intman.2021.100827