A
Đăng nhập

Chương 5: Quan hệ Dữ liệu & Bảng (Data Relationships)

AppSheet Data Relationships

"Sức mạnh thực sự của AppSheet nằm ở chữ 'Relationship' (Mối quan hệ)."

Nếu bạn chỉ dùng một bảng duy nhất, bạn đang dùng AppSheet như một cái "Excel View" đắt tiền. Để xây dựng hệ thống quản trị, bạn phải biết cách kết nối các bảng lại với nhau giống như các bánh răng trong một cỗ máy.

5.1 Bản chất của Quan hệ (Relational Database)

Hãy hình dung mối quan hệ Cha - Con (Parent - Child):

  • Cha (Parent): Khách hàng (1 người).
  • Con (Child): Đơn hàng (Nhiều đơn).

Một khách hàng có thể có nhiều đơn hàng. Nhưng một đơn hàng chỉ thuộc về một khách hàng duy nhất. Đây là quan hệ 1-n (One-to-Many).

5.2 Kiểu dữ liệu Ref (Reference)

Trong AppSheet, chúng ta dùng kiểu Ref để tạo mối quan hệ này.

  • Bạn đặt cột CustomerID ở bảng Con (Orders) là kiểu Ref.
  • Trỏ nó về bảng Cha (Customers).

Điều kỳ diệu xảy ra:

  1. Dropdown thông minh: Khi nhập đơn hàng, bạn không cần gõ tên khách, mà chọn từ danh sách khách hàng.
  2. Inline View (Danh sách con): Ngược lại, khi xem chi tiết một khách hàng, bạn sẽ thấy danh sách các đơn hàng của họ ngay bên dưới.
  3. Is a part of?: Nếu bạn tích chọn tùy chọn này, bảng Con sẽ dính liền với bảng Cha. Khi xóa Cha, Con cũng mất theo (Cascade Delete).

5.3 Dereference: "Mượn" dữ liệu từ bảng khác

Khi đã có mối quan hệ Ref, bạn có thể "mượn" bất kỳ thông tin nào của bảng Cha để dùng ở bảng Con mà không cần dùng hàm VLOOKUP phức tạp.

Cú pháp: [TênCộtRef].[TênCộtMuốnLấy]

  • Ví dụ: Trong bảng Đơn hàng, bạn muốn lấy Số điện thoại của khách hàng (đang nằm bên bảng Khách hàng).
  • Công thức: [CustomerID].[Phone].

Lưu ý: Dereference chỉ hoạt động khi bạn có cột Ref. Nó nhanh hơn VLOOKUP gấp 10 lần vì AppSheet đã index sẵn mối quan hệ.

5.4 EnumList Base Type Ref (Quan hệ n-n)

Đôi khi, một công việc được giao cho nhiều nhân viên cùng làm.

  • Lúc này, cột NguoiThucHien sẽ là kiểu EnumList.
  • Và Base Type là Ref (trỏ về bảng Nhân viên).

Điều này cho phép chọn nhiều người: "Hùng, Lan, Tuấn" cùng lúc.

5.5 Spec (Schema Viewer) & Tư duy Tối ưu Quan hệ

Sơ đồ quan hệ Spec

Khi vào Info > Spec (hoặc Settings > Data > Column Structure), bạn sẽ thấy một biểu đồ mạng lưới các "bong bóng" (bubbles).

5.5.1 Tại sao lại cần View "Bong bóng" này?

Thoạt nhìn, nó có vẻ lộn xộn và "khó chịu" hơn sơ đồ quan hệ truyền thống (như trong Access hay Power BI). Nhưng đây là một tính năng "nhìn lâu mới thấy thích":

  • Interactive UX Preview: Khác với sơ đồ tĩnh, khi bạn bấm vào một Table hoặc Slice bất kỳ, màn hình Preview bên phải sẽ lập tức hiển thị View thực tế của dữ liệu đó. Bạn kiểm tra được ngay: "Bảng này lên hình trông ra sao?", thay vì chỉ nhìn thấy tên cột khô khan.
  • Visual Debugging: Bạn nhìn thấy rõ Slice nào sinh ra từ Table nào, View nào đang dùng Slice nào.

5.5.2 Chiến lược "Loose Coupling" (Quan hệ lỏng)

Có một nghịch lý: Đôi khi các App chạy nhanh nhất là các App... sơ đồ ít mũi tên nhất.

  • Vấn đề: Khi bạn tạo quá nhiều mối quan hệ Ref (đặc biệt là Is a part of), AppSheet dệt nên một mạng lưới phụ thuộc chằng chịt. AppSheet phải tải và kiểm tra tính toàn vẹn của tất cả các bảng liên quan khi Sync.
  • Giải pháp: Tối ưu bằng cách lược bỏ Ref không cần thiết.
    • Thay vì dùng Ref cứng nhắc, hãy dùng Enum hoặc Valid_If để tạo Dropdown chọn giá trị.
    • Khi nào dùng: Khi bạn không cần Dereference (mượn dữ liệu) và không cần Inline View (bảng con).
    • Ví dụ: Trong bảng Logs (Nhật ký), chỉ cần lưu UserEmail (Text) thay vì Ref sang bảng Users. Giúp bảng Logs nhẹ hơn và không làm chậm quá trình load Users.

Đúc kết: Hãy dùng Ref cho các quan hệ nghiệp vụ cốt lõi (Cha - Con). Dùng kết nối lỏng (Enum/Valid_If) cho các quan hệ tham chiếu đơn giản để tối ưu hiệu năng.

5.6 Thực hành (Guided Practice)

Mục tiêu: Kết nối các bảng trong hệ thống CRM.

5.6.1 Kết nối Opportunities -> Customers

  1. Vào AppSheet -> Data -> Columns -> Bảng Opportunities.
  2. Tìm cột CustomerID.
  3. Đổi Type thành Ref.
  4. Trong phần Source table, chọn Customers.
  5. Tích chọn Is a part of? -> ON.
    • Tại sao?: Vì Cơ hội bán hàng luôn gắn liền với một Khách hàng. Khách hàng là "Cha", Cơ hội là "Con".

5.6.2 Tạo bảng Activities (Nếu chưa có)

Để quản lý lịch sử chăm sóc (Gọi điện, Gặp mặt), ta cần thêm bảng Activities.

  1. Vào Google Sheets, tạo Sheet mới Activities gồm: ActivityID, OpportunityID, Type (Call/Meeting), Note, Date.
  2. Vào AppSheet -> Data -> Add New Table -> Chọn Activities.
  3. Vào Columns của bảng Activities:
    • Cột OpportunityID: Đổi Type thành Ref, trỏ về bảng Opportunities. Tích Is a part of?.

5.6.3 Kiểm tra kết quả (Inline View)

  1. Lưu App (Save).
  2. Vào xem chi tiết một Khách hàng (Customers Detail View).
  3. Bạn sẽ thấy một danh sách con (Inline) các Opportunities của khách đó.
  4. Bấm vào một Opportunity, bạn sẽ thấy danh sách con các Activities của Deal đó. -> Đây chính là cấu trúc phân cấp 3 tầng: Khách hàng -> Cơ hội -> Hoạt động.

5.7 Vận dụng (Your Project)

Câu hỏi:

  1. Tìm mối quan hệ Cha-Con: Trong công việc của bạn, đâu là Cha, đâu là Con?
    • Gợi ý: Dự án (Cha) - Công việc (Con). Chuyến xe (Cha) - Điểm giao hàng (Con). Phiếu nhập (Cha) - Chi tiết vật tư (Con).
  2. Thay thế VLOOKUP: Bạn có đang dùng VLOOKUP trong Excel để lấy tên khách hàng, địa chỉ khách hàng sang bảng đơn hàng không? -> Hãy thay bằng Ref và Dereference ([MaKhach].[DiaChi]) để App nhẹ hơn.

5.8 Lời kết: Sức mạnh của sự kết nối

Bạn đã hoàn thành phần "xương sống" của ứng dụng: Dữ liệu và Mối quan hệ.

  • Dữ liệu đã chuẩn hóa.
  • Các bảng đã kết nối chặt chẽ với nhau qua Ref.

Giờ là lúc khoác lên bộ khung xương ấy một lớp áo giao diện (UX/UI) đẹp mắt và thân thiện. Làm sao để tạo các View xem danh sách, xem chi tiết, hay biểu đồ Dashboard? Chương 6: "Chiến lược UX & Views" sẽ giúp bạn biến dữ liệu khô khan thành trải nghiệm người dùng tuyệt vời.

5.9 Tài liệu tham khảo (Google Docs)

Bài trước Bài tiếp theo