Phân tích chi tiết về Pivot và Unpivot trong Power BI​

Trong Power BI, Pivot và Unpivot là hai kỹ thuật cơ bản và hữu ích để xử lý, biến đổi dữ liệu nhằm chuẩn bị cho mô hình hóa và phân tích. Dữ liệu dạng Pivot thường trực quan nhưng gây khó khăn cho việc xây dựng một mô hình dữ liệu hiệu quả. Dạng Unpivot (chuẩn hóa) lại dễ dàng hơn để thực hiện các phân tích phức tạp và tương thích tốt với các yêu cầu về Data Modeling.

Dưới đây là phân tích và hướng dẫn chi tiết, áp dụng các ví dụ đã nêu.

1. Power BI và Dữ liệu dạng Pivot​

Pivot là gì trong Power BI?​

Pivot trong Power BI là quá trình tổ chức dữ liệu bằng cách biến các giá trị từ một cột thành các cột riêng biệt. Dữ liệu dạng Pivot giúp trực quan hóa dữ liệu tốt và thường được sử dụng trong các báo cáo, bảng tổng hợp hoặc Excel như đã trình bày trong ví dụ.

Ví dụ:​

Dữ liệu ban đầu dạng Pivot khi tải lên Power BI:

• Trực quan: Các sản phẩm (Bikes, Components, Clothing) được tổ chức thành cột riêng biệt. Doanh số của từng sản phẩm nằm trong các cột, rất dễ nhìn khi đọc trực tiếp trong bảng này.
• Khó khăn trong Data Modeling:
  • Các sản phẩm là các cột, thay vì các dòng. Điều này gây khó khăn khi cần phân tích doanh thu theo sản phẩm hoặc xử lý dữ liệu tổng quát.
  • Nếu có sản phẩm mới (ví dụ: Accessories), bạn cần thêm một cột mới, làm phức tạp bảng dữ liệu và khó mở rộng mô hình.

2. Power BI và Dữ liệu dạng Unpivot​

Unpivot là gì trong Power BI?​

Unpivot là kỹ thuật ngược lại Pivot. Unpivot chuyển các cột thành dòng, giảm số lượng cột xuống chỉ còn các thành phần chính như Ngày, Tên sản phẩm, và Doanh số. Đây là cách tổ chức dữ liệu chuẩn hóa, rất hữu ích trong Power BI để xây dựng mô hình dữ liệu linh hoạt.

Ví dụ chuyển Pivot sang Unpivot:​

Dữ liệu sau khi Unpivot:

Lợi ích trong Power BI:​

1. Phù hợp với Data Modeling:
   • Dạng Unpivot tổ chức danh mục sản phẩm (Bikes, Components, Clothing) thành một cột duy nhất (cột Sản phẩm), giúp dễ dàng thực hiện mô hình hóa dữ liệu trong Power BI.
   • Mô hình hóa các mối quan hệ trở nên dễ dàng hơn khi chỉ cần một số ít bảng và cột.
2. Xử lý dữ liệu:
   • Tính tổng doanh số (SUM(Doanh số)) hoặc nhóm doanh thu theo sản phẩm (GROUP BY Sản phẩm) cực kỳ đơn giản bằng DAX.

3. Pivot và Unpivot trong Power Query (Power BI)​

Power BI tích hợp Power Query, công cụ mạnh mẽ để xử lý hình dạng dữ liệu. Trong Power Query, bạn có thể áp dụng chức năng Pivot hoặc Unpivot chỉ với vài bước.

Unpivot Data:​

Thực hiện trong Power Query:​

1. Tải dữ liệu lên Power BI và vào Power Query Editor.
2. Chọn các cột dạng giá trị (Bikes, Components, Clothing) trong bảng Pivot.
3. Nhấp chuột phải và chọn Unpivot Columns. Lúc này, các cột được chuyển thành dòng.
4. Power Query sẽ tạo thêm hai cột mới:
   • Một cột Attribute: Hiển thị tên sản phẩm (Bikes, Components, Clothing).
   • Một cột Value: Hiển thị doanh số tương ứng (10, 14, 35,...).

Kết quả:​

• Bạn có thể đổi tên cột Attribute thành Sản phẩm và Value thành Doanh số, phù hợp với mục tiêu phân tích.

Ứng dụng Pivot:​

Ngược lại, nếu bạn cần chuyển dữ liệu Unpivot trở lại dạng Pivot, bạn có thể thực hiện các bước sau:

Thực hiện trong Power Query:​

1. Chọn cột cần giữ nguyên như Ngày.
2. Nhấp vào Pivot Columns và chọn cột Sản phẩm làm nhãn cho các cột mới.
3. Tập hợp giá trị cho các cột Pivot từ Doanh số.

Kết quả:​

4. Tác động đến Data Modeling trong Power BI​

Dữ liệu Pivot:​

• Không thích hợp để làm mô hình hóa dữ liệu:
  • Không thể thực hiện các mối quan hệ dễ dàng.
  • Cần xử lý phức tạp khi viết công thức DAX.
  • Không tương thích tốt với các nguyên tắc chuẩn hóa.

Dữ liệu Unpivot:​

• Phù hợp hơn cho Data Modeling:
  • Linh hoạt, dễ mở rộng.
  • Tích hợp tốt với các bảng khác trong mô hình quan hệ.
  • Phân tích dễ dàng và trực tiếp với DAX như SUM, COUNT, CALCULATE.

5. Kết luận​

• Pivot: Dữ liệu dạng Pivot phù hợp để trình bày báo cáo, nhưng nó không phù hợp để xây dựng mô hình dữ liệu trong Power BI.
• Unpivot: Dữ liệu dạng Unpivot được tối ưu hóa cho việc thiết kế bảng mô hình hóa dữ liệu, truy vấn linh hoạt và thích hợp với nguyên tắc chuẩn hóa.

Khi làm việc với Power BI, nếu đặt mục tiêu phân tích dữ liệu hoặc xây dựng mô hình, hãy luôn chuyển dữ liệu về dạng Unpivot để đảm bảo xử lý thuận tiện và hiệu quả hơn.

1. Database Normalization​

Normalization (Chuẩn hóa dữ liệu) là quá trình tổ chức các bảng và cột trong cơ sở dữ liệu quan hệ (Relational Database) nhằm giảm thiểu dữ liệu dư thừa và giữ vững tính toàn vẹn của dữ liệu. Chuẩn hóa thường được sử dụng để:

1. Loại bỏ dữ liệu dư thừa (Eliminate redundant data):
   • Giảm kích thước bảng, tối ưu dung lượng lưu trữ, và cải thiện tốc độ xử lý.
2. Giảm thiểu sai sót và bất thường (Minimize errors and anomalies):
   • Hạn chế các lỗi phát sinh khi thực hiện các thao tác dữ liệu như:
     • Thêm dữ liệu (Insert).
     • Sửa dữ liệu (Update).
     • Xóa dữ liệu (Delete).
3. Đơn giản hóa truy vấn (Simplify queries) và cấu trúc cơ sở dữ liệu (Structure the database):
   • Tối ưu hóa cách tổ chức dữ liệu để dễ dàng phân tích và truy vấn ý nghĩa từ dữ liệu.

Ý tưởng chính (💡):

• Trong một cơ sở dữ liệu được chuẩn hóa, mỗi bảng chỉ nên phục vụ một mục đích cụ thể duy nhất. Ví dụ:
  • Bảng Thông tin sản phẩm lưu các thông tin về sản phẩm.
  • Bảng Giao dịch bán hàng lưu các thông tin liên quan đến giao dịch.
  • Bảng Thông tin khách hàng chứa thuộc tính khách hàng.
  • Bảng Chi tiết cửa hàng lưu thông tin cửa hàng.

Giải thích về ví dụ (Phân tích bảng dữ liệu):​

Dữ liệu ban đầu (chưa chuẩn hóa) được hiển thị như sau:

Phân tích vấn đề trong dữ liệu chưa chuẩn hóa:​

1. Dữ liệu dư thừa (Redundant Data):
   • Thông tin sản phẩm như product_brand, product_name, product_sku, và product_weight bị lặp đi lặp lại cho mỗi giao dịch. Ví dụ:
     • Nationeel Grape Fruit Roll xuất hiện hai lần cho hai ngày khác nhau (1/1/1997 và 1/7/1997).
   • Việc lưu trữ thông tin lặp vừa làm tốn dung lượng lưu trữ vừa dễ gây lỗi sai trong dữ liệu.
2. Thiếu sự tách biệt giữa mục đích của bảng:
   • Bảng hiện tại gộp chung nhiều thông tin (giao dịch, sản phẩm) vào một bảng duy nhất. Điều này làm cho bảng trở nên khó cập nhật và truy vấn:
     • Nếu thông tin sản phẩm thay đổi (ví dụ: trọng lượng product_weight đổi từ 17 thành 15), ta phải tìm và cập nhật cho tất cả hàng liên quan đến sản phẩm này, dẫn đến rủi ro sai sót.
3. Vấn đề ở quy mô lớn:
   • Với quy mô nhỏ (chỉ vài dòng dữ liệu), vấn đề lặp dường như không đáng kể. Nhưng khi cơ sở dữ liệu mở rộng đến hàng triệu dòng, các vấn đề dư thừa và lỗi sẽ trở nên rất khó kiểm soát.

Dữ liệu chuẩn hóa:​

Các thông tin được chuẩn hóa thành nhiều bảng như sau:

Bảng 1: Thông tin sản phẩm​

• Lưu trữ thông tin cố định của sản phẩm, không bị lặp lại.

Bảng 2: Giao dịch bán hàng​

• Lưu trữ các thông tin thay đổi theo từng giao dịch.

Lợi ích của dữ liệu chuẩn hóa:​

1. Loại bỏ dư thừa:
   • Thông tin sản phẩm chỉ được lưu một lần duy nhất trong bảng sản phẩm. Việc chỉnh sửa thông tin sản phẩm trở nên dễ dàng.
2. Giảm lỗi và bất thường:
   • Khi có thay đổi về một giá trị (như product_weight), ta chỉ cần sửa một dòng trong bảng sản phẩm. Điều này giảm thiểu khả năng sai sót khi phải sửa nhiều dòng.
3. Tăng hiệu suất và giảm chi phí:
   • Cấu trúc chuẩn hóa giúp giảm số lượng dữ liệu lặp, từ đó giảm dung lượng lưu trữ và tăng tốc độ truy vấn.
4. Dễ dàng mở rộng:
   • Với hệ thống chuẩn hóa, việc thêm thông tin mới (như store details) chỉ yêu cầu thêm một bảng mới, không cần thay đổi cấu trúc bảng hiện tại.

2. Các loại chuẩn hóa và giải thích​

2.1. First Normal Form (1NF) - Chuẩn hóa bậc 1:​

Định nghĩa:​

Một bảng đạt chuẩn 1NF khi mỗi ô dữ liệu trong bảng chỉ chứa một giá trị duy nhất, và các giá trị trong cột đều có cùng loại dữ liệu.

Ví dụ:​

Bảng chưa đạt chuẩn 1NF:

• Vấn đề:
  • Một ô dữ liệu có nhiều giá trị (ô Số điện thoại của khách hàng Minh chứa 2 số).
  • Gây khó cho việc truy vấn và sửa đổi thông tin.

Chuyển sang dạng 1NF:​

• Lợi ích:
  • Mỗi ô chỉ chứa một dữ liệu duy nhất.
  • Bảng được tổ chức hợp lý, dễ truy vấn.

2.2. Second Normal Form (2NF) - Chuẩn hóa bậc 2:​

Định nghĩa:​

Một bảng đạt chuẩn 2NF nếu:

1. Bảng đã đạt chuẩn 1NF.
2. Mỗi cột không khóa phụ thuộc hoàn toàn vào khóa chính (Primary Key), không tồn tại phụ thuộc từng phần.

Ví dụ:​

Bảng chưa đạt chuẩn 2NF:

• Vấn đề:
  • Tên khách hàng và Địa chỉ phụ thuộc vào ID khách hàng, không phải Mã đơn hàng. Đây là phụ thuộc từng phần, làm dữ liệu dư thừa.
  • Nếu khách hàng Minh thay đổi địa chỉ, ta phải chỉnh sửa nhiều dòng có liên quan.

Chuyển sang dạng 2NF:​

Tách bảng thành 2 bảng:

Bảng 1: Khách hàng​

Bảng 2: Đơn hàng​

• Lợi ích:
  • Không còn dư thừa thông tin Tên khách hàng và Địa chỉ.
  • Dễ dàng cập nhật dữ liệu khách hàng mà không ảnh hưởng đến dữ liệu đơn hàng.

2.3. Third Normal Form (3NF) - Chuẩn hóa bậc 3:​

Định nghĩa:​

Một bảng đạt chuẩn 3NF nếu:

1. Bảng đã đạt chuẩn 2NF.
2. Không có cột phụ thuộc gián tiếp vào khóa chính.

Ví dụ:​

Bảng chưa đạt chuẩn 3NF:

• Vấn đề:
  • Tên phòng ban phụ thuộc vào Mã phòng ban, không phải ID Nhân viên (khóa chính). Đây là phụ thuộc gián tiếp, dẫn đến dư thừa dữ liệu.
  • Nếu phòng ban Kế toán đổi tên, phải sửa nhiều dòng tương ứng.

Chuyển sang dạng 3NF:​

Tách bảng thành 2 bảng:

Bảng 1: Nhân viên​

Bảng 2: Phòng ban​

• Lợi ích:
  • Xóa bỏ phụ thuộc gián tiếp.
  • Thay đổi thông tin phòng ban chỉ cần cập nhật tại bảng Phòng ban.

3. Hệ quả chuẩn hóa - Ưu điểm và nhược điểm​

Ưu điểm của chuẩn hóa:​

1. Loại bỏ dư thừa dữ liệu:
   • Dữ liệu được tránh việc lặp đi lặp lại trong nhiều dòng, giảm kích thước cơ sở dữ liệu.
2. Cập nhật dễ dàng:
   • Khi chỉnh sửa thông tin, chỉ cần thay đổi tại một nơi duy nhất.
3. Bảo đảm toàn vẹn dữ liệu:
   • Dữ liệu không bị sai lệch do dư thừa.
4. Dễ truy vấn và mở rộng:
   • Các bảng có mục đích rõ ràng giúp dễ dàng lọc, tìm kiếm, và thêm dữ liệu.

Nhược điểm của chuẩn hóa:​

1. Yêu cầu nhiều bảng hơn:
   • Khi chuẩn hóa, dữ liệu bị chia thành nhiều bảng nhỏ hơn, làm các truy vấn phức tạp hơn.
2. Hiệu suất giảm trong một số trường hợp:
   • Truy vấn yêu cầu kết nối bảng (Joins) thường phức tạp và tốn nhiều tài nguyên nếu cơ sở dữ liệu lớn.

4. Kết luận​

• Chuẩn hóa (Normalization) là bắt buộc trong thiết kế cơ sở dữ liệu, đặc biệt với các hệ thống lớn để giảm dư thừa, bảo toàn tính chính xác, và đảm bảo dữ liệu dễ quản lý.
• Tuy nhiên, tùy vào mục tiêu sử dụng, đôi khi các hệ thống phi chuẩn hóa (Denormalization) lại được áp dụng (ví dụ: khi tối ưu hóa hiệu suất trong báo cáo).

Các cấp độ từ 1NF đến 3NF thường là mức chuẩn hóa được sử dụng phổ biến nhất trong thực tế. Hy vọng giải thích trên cung cấp cái nhìn rõ ràng và dễ hiểu về chuẩn hóa cơ sở dữ liệu! 😊

Phân biệt OLTP và OLAP: Data Modeling có khác nhau không?​

1. Phân biệt OLTP và OLAP​

OLTP (Online Transaction Processing):​

OLTP là hệ thống xử lý giao dịch trực tuyến, tập trung vào việc lưu trữ và thực hiện các giao dịch nhanh chóng, nhất quán. Đây là các hệ thống hệ điều hành/máy chủ cơ sở dữ liệu hỗ trợ công việc hàng ngày.

Đặc điểm:​

• Chức năng chính: Lưu trữ và quản lý giao dịch (thêm, sửa, xóa dữ liệu).
• Dữ liệu: Chi tiết, động (real-time), thường liên quan đến giao dịch trong doanh nghiệp (ví dụ: đơn hàng, thanh toán, nhập/xuất hàng).
• Thời gian truy vấn: Cần tốc độ cao cho các thao tác cơ bản.
• Mục tiêu chính: Đảm bảo tính toàn vẹn và nhất quán của mỗi giao dịch.
• Cấu trúc dữ liệu: Dữ liệu thường được chuẩn hóa (Normalization) để giảm dư thừa và duy trì toàn vẹn.

Ví dụ:​

• Hệ thống quản lý bán hàng, hệ thống ERP (Enterprise Resource Planning), hệ thống CRM (Customer Relationship Management).

OLAP (Online Analytical Processing):​

OLAP là hệ thống hỗ trợ phân tích dữ liệu nhanh chóng và hiệu quả, đặc biệt dành cho báo cáo, đưa ra quyết định dựa trên dữ liệu lịch sử. Đây là nền tảng của hệ thống Business Intelligence.

Đặc điểm:​

• Chức năng chính: Phân tích, trực quan hóa, và báo cáo dữ liệu.
• Dữ liệu: Tích hợp từ nhiều nguồn, lịch sử (historical data), thường là dữ liệu tóm tắt (aggregate data).
• Thời gian truy vấn: Có thể chậm hơn (phân tích dữ liệu lớn đa chiều cần nhiều thời gian).
• Mục tiêu chính: Cung cấp góc nhìn toàn diện để hỗ trợ ra quyết định.
• Cấu trúc dữ liệu: Dữ liệu thường được phi chuẩn hóa (Denormalization) hoặc tổ chức theo multi-dimensional schemas (star schema hoặc snowflake schema).

Ví dụ:​

• Power BI, Tableau, hoặc kho dữ liệu DW (Data Warehouse) cho phân tích doanh thu, xu hướng thị trường, hiệu quả kinh doanh.

2. Điểm khác biệt giữa Data Modeling cho OLTP và OLAP​

3. Data Modeling khác nhau hay giống nhau giữa hai loại dự án?​

Dự án OLTP (Quản lý giao dịch):​

Data Modeling trong dự án quản lý giao dịch chủ yếu dựa trên chuẩn hóa dữ liệu để:

1. Tối ưu hóa lưu trữ:
   • Loại bỏ dư thừa (giảm kích thước dữ liệu).
   • Duy trì tính toàn vẹn của dữ liệu.
2. Đảm bảo tính toàn vẹn tham chiếu (Referential Integrity):
   • Mối quan hệ giữa các bảng phải rõ ràng (ví dụ: One-to-Many).
   • Cấu trúc dữ liệu thường theo mô hình cơ sở dữ liệu quan hệ (Relational Data Model).
3. Truy vấn nhanh chóng cho giao dịch:
   • Chỉ tập trung vào các thao tác CRUD (Thêm, Sửa, Xóa, và Xem chi tiết dữ liệu).

Ví dụ:​

• Mô hình OLTP: Một hệ thống quản lý bán hàng có thể gồm các bảng chuẩn hóa:
  • Sales: Lưu đơn hàng (Sale_ID, Sale_Date).
  • Customers: Lưu thông tin khách hàng.
  • Products: Lưu danh mục sản phẩm.
  • Sale_Product: Lưu chi tiết sản phẩm trong mỗi giao dịch.

Kết quả:​

• Dữ liệu chi tiết từng giao dịch.
• Mô hình chuẩn hóa (Normalization) giúp tăng hiệu suất lưu trữ và xử lý CRUD.

Dự án OLAP (Phân tích dữ liệu):​

Data Modeling trong dự án phân tích tập trung vào việc phi chuẩn hóa dữ liệu và schema đa chiều để:

1. Tăng tốc độ truy vấn cho phân tích:
   • Dữ liệu phi chuẩn hóa giúp giảm số lượng Logic Join trong truy vấn.
2. Hỗ trợ phân tích đa chiều:
   • Sử dụng Star Schema hoặc Snowflake Schema để mô hình hóa dữ liệu.
   • Các bảng fact và dimensions được tổ chức để truy vấn dữ liệu dựa vào các thông tin tổng hợp (aggregations).
3. Tích hợp dữ liệu từ nhiều nguồn:
   • Đối với OLAP, dữ liệu thường được lấy từ nhiều nguồn (ERP, CRM, hệ thống giao dịch).
   • Dữ liệu chuyển đổi qua ETL (Extract Transform Load) để tạo các bảng chính phục vụ báo cáo.

Ví dụ:​

• Mô hình OLAP: Một hệ thống phân tích doanh số:
  • Fact Table:
    • Sales_Fact: Lưu các giá trị tổng hợp (Sale_ID, Product_ID, Revenue, Total Quantity, Sale_Date).
  • Dimension Tables:
    • Customers_Dimension: Giải thích về thông tin khách hàng.
    • Products_Dimension: Giải thích về danh mục sản phẩm.
    • Time_Dimension: Giải thích về thời gian.

Kết quả:​

• Dữ liệu tổng quan và lịch sử.
• Mô hình phi chuẩn hóa (Denormalization) giúp tối ưu cho báo cáo và phân tích.

4. Tóm tắt sự khác biệt trong Data Modeling​

5. Kết luận​

• Data Modeling giữa OLTP và OLAP hoàn toàn khác nhau. Mục đích sử dụng và loại dữ liệu được quản lý (chi tiết vs tổng quan) dẫn đến sự khác biệt lớn trong cách tổ chức dữ liệu.
• Dự án quản lý: Dữ liệu thường được chuẩn hóa để tối ưu hóa lưu trữ và giao dịch, phục vụ các thao tác nhanh chóng, đảm bảo toàn vẹn dữ liệu.
• Dự án phân tích: Dữ liệu được phi chuẩn hóa, tập trung hỗ trợ phân tích và báo cáo đa chiều, tối ưu cho tốc độ truy vấn các tập dữ liệu lớn.

Hiểu rõ sự khác biệt này sẽ giúp bạn chọn data modeling phù hợp nhất cho từng loại dự án! 😊

Buổi 1: Phần mềm là gì ?

Thời kỳ đầu: Giai đoạn khủng hoảng phần mềm → Chất lượng phần mềm kém, không tương xứng với chi phí thực hiện như chưa rất nhiều lỗi và không đúng yêu cầu

Suy ra: Cần có những phương pháp nghiên cứu chuyên sâu về phát triển phần mềm → ra đời thuật ngữ công nghệ phần mềm

Định nghĩa: Công nghệ phần mềm là một lĩnh vực khoa học về phương pháp luận, kỹ thuật và công cụ tích hợp trong phát triển và vận hành phần mềm. Nhằm tạo ra PM với chất lượng mong muốn

Software​

is a collection of instructions, data, or computer programs that are used to run machines and carry out particular activities. It is the antithesis of hardware, which refers to a computer’s external components. A device’s running programs, scripts, and applications are collectively referred to as “software” in this context.

Ví dụ về Use case​

Use Case Name: Custom Drone Order

Use Case Description: This use case describes the process of a customer ordering a custom-built drone based on their specific requirements.

Actors:

• Customer
• Drone Builder

Pre-conditions:

• The customer has identified the need for a custom drone.
• The drone builder has the necessary expertise and resources to build custom drones.

Post-conditions:

• The customer has placed an order for a custom drone.
• The drone builder has received the customer's order and is ready to start the build process.

Normal Flow:

1. The customer contacts the drone builder to express interest in a custom drone.
2. The drone builder discusses the customer's needs and requirements, gathering information about the desired features, specifications, and budget.
3. The drone builder provides a quote based on the customer's requirements.
4. The customer reviews the quote and decides whether to proceed with the order.
5. If the customer agrees to proceed, they provide the necessary payment information.
6. The drone builder confirms the order and begins the build process.

Alternative Flows:

• Customer requests modifications: If the customer requests changes to the original order, the drone builder assesses the feasibility and provides an updated quote.
• Build delays: If there are unexpected delays in the build process, the drone builder communicates with the customer and provides updates on the estimated completion time.
• Order cancellation: If the customer decides to cancel the order, the drone builder refunds any payments made and provides a reason for the cancellation.

Buổi 4: Tạo lược đồ Use - Case

Một công cụ phổ biến để biểu diễn yêu cầu của hệ thống và hiểu rõ các tác nhân, chức năng và tương tác của hệ thống là sơ đồ Use Case (Use Case Diagram). Sơ đồ Use Case cung cấp một cái nhìn tổng quan về các chức năng của hệ thống và cách các tác nhân (người dùng, hệ thống khác, v.v.) tương tác với hệ thống.

Sơ đồ Use Case bao gồm các phần tử chính như các Use Case (chức năng), các tác nhân (người dùng, hệ thống khác), và các quan hệ và tương tác giữa chúng. Use Case mô tả các hành vi của hệ thống từ góc nhìn người dùng hoặc tác nhân và giúp xác định các chức năng chính cần phát triển.

Trong quá trình phân tích thiết kế hệ thống, sơ đồ Use Case thường được kết hợp với các tài liệu khác như biểu đồ tuần tự (sequence diagram), biểu đồ lớp (class diagram) và biểu đồ hoạt động (activity diagram) để mô tả và phân tích chi tiết hơn về các tương tác và cấu trúc của hệ thống.

Nội dung bài học

1. Khái niệm về Actor và Use - Case
2. Các quan hệ trong lược đồ Use – Case: Quan hệ thổng quát hóa giữa Actor, quan hệ "<<include>>" và "<<extend>>".
3. Sơ đồ Use – Case hoàn chỉnh.
4. Đặc tả Use – Case.

Use-case diagram

Chỉ mô tả chủ yếu các thông tin liên quan đến việc thực hiện các nghiệp vụ trong thế giới thực, chưa thể hiện rõ nét việc thực hiện các nghiệp vụ trên máy tính.

Mô tả thông quá các văn bản dễ gây ra nhầm lẫn và không trực quan.

Actor

Usecase

Relationship

Quan hệ bao gồm (<<include>>)

Quan hệ mở rộng (<<extend>>)

Sơ đồ use-case đầy đủ

Đặc tả use-case

Đặc tả Use Case là một tài liệu mô tả chi tiết hành vi của hệ thống từ góc nhìn của người dùng. Nó bao gồm các trường hợp sử dụng (Use Case) chính của hệ thống, các bước thực hiện, các ràng buộc và điều kiện tiên quyết cho mỗi trường hợp sử dụng.

Cấu trúc của một đặc tả Use Case:

• Tên Use Case: Mô tả ngắn gọn chức năng của Use Case.
• Mô tả: Mô tả chi tiết hành vi của Use Case.
• Diễn viên (Actor): Mô tả các đối tượng sử dụng Use Case.
• Bước thực hiện: Mô tả các bước thực hiện Use Case.
• Ràng buộc: Mô tả các ràng buộc đối với Use Case.
• Điều kiện tiên quyết: Mô tả các điều kiện cần phải được đáp ứng trước khi thực hiện Use Case.
• Luồng nghiệp vụ (Workflow): Mô tả trình tự các bước thực hiện Use Case.

Buổi 5: Tạo lược đồ Activity (Activities diagram)

Activity Diagram là một mô hình logic dùng để mô hình hoá các hoạt động trong một quy trình nghiệp vụ. Hay có thể hiểu. Activity Diagram là sơ đồ luồng xử lý của hệ thống. Bao gồm luồng đi của dòng dữ liệu, dòng sự kiện.

Activity Diagram dùng để mô tả các hoạt động trong một chức năng của hệ thống (mô tả luồng xử lý của một Use – Case)

Các thành phần của Activity - Diagram​

Start

Activity

Nên đặt tên là động từ. Và mô tả đủ ý nghĩa tổng thể của hoạt động nhất có thể.

Transition

Từ hoạt động này tới hoạt động khác cần có Transition biểu thị đường đi. Lưu ý Transition có mũi tên biểu thị chiều của luồng xử lý.

Condition

Có thể hiểu đây là ký hiệu biểu thị nút điều kiện chuyển hướng. Tùy theo trường hợp đúng hay sai của kết quả biểu thức logic bên trong ký hiệu mà có hướng di chuyển tiếp theo tương ứng.

Synchronization bar

Có thể hiểu đơn giản. Có các trường hợp cần hội tụ đủ nhiều luông điều khiển một lúc để gộp thành một luồng xử lý thì cần dùng Join.

Và đôi khi cần phải tách một luồng điều khiển ra hai hoặc nhiều luồng khác biệt nhau thì cần Fork. Và mỗi luồng của Fork hoàn toàn không lệ thuộc nhau

End

Ánh xạ từ sơ đồ Use-case qua Activities diagrams

Bài tập buổi 5:

1. Vẽ sơ đồ activities diagram cho use-case đăng ký / đăng nhập
2. Vẽ sơ đồ activities diagram cho use-case mua hàng / thanh toán cho hệ thống thương mại điện tử
3. Vẽ sơ đồ activities diagram cho use-case tìm kiếm và lọc chuyến đi cho hệ thống đặt vé xe khách

Buổi 6: Giới thiệu về ER Diagram

ER-Diagram (Entity-Relationship Diagram) là một công cụ được sử dụng trong thiết kế cơ sở dữ liệu để biểu diễn các mối quan hệ giữa các thực thể (entities). Nó được giới thiệu bởi Peter Chen vào năm 1976 và trở thành một phương pháp phổ biến để mô hình hóa dữ liệu.

ER-Diagram sử dụng các khái niệm cơ bản như thực thể (entity), mối quan hệ (relationship) và thuộc tính (attribute) để biểu diễn cấu trúc dữ liệu. Thực thể là các đối tượng trong thế giới thực, chẳng hạn như người, đồ vật hoặc sự kiện. Mối quan hệ biểu thị các mối liên kết giữa các thực thể, trong đó có thể có mối quan hệ một một (one-to-one), một nhiều (one-to-many) hoặc nhiều nhiều (many-to-many). Thuộc tính là các đặc điểm của thực thể, ví dụ như tên, tuổi, địa chỉ.

Năm 1988, ANSI (American National Standards Institute) công nhận ER-Diagram là mô hình chuẩn trong thiết kế cơ sở dữ liệu. Việc công nhận này đã tạo ra một sự nhất quán trong việc sử dụng ER-Diagram và giúp nó trở thành một công cụ phổ biến trong lĩnh vực này.

Các thành phần của ER - Diagram​

1. Thực thể (Entity): Thực thể là một đối tượng hoặc một tập hợp các đối tượng trong thế giới thực có ý nghĩa độc lập và được lưu trữ trong cơ sở dữ liệu. Ví dụ, trong một hệ thống quản lý sinh viên, "Sinh viên" có thể là một thực thể.
2. Mối quan hệ (Relationship): Mối quan hệ biểu thị sự kết nối hoặc liên kết giữa các thực thể. Nó biểu thị cách mà các thực thể liên quan đến nhau trong cơ sở dữ liệu. Ví dụ, trong hệ thống quản lý sinh viên, một mối quan hệ có thể là "Sinh viên học trong Lớp học".

1. Thuộc tính (Attribute): Thuộc tính là các đặc điểm hoặc thông tin liên quan đến mỗi thực thể. Nó mô tả các thuộc tính của thực thể và giúp xác định các đặc điểm riêng của mỗi thực thể. Ví dụ, trong thực thể "Sinh viên", các thuộc tính có thể là "Họ và tên", "Ngày sinh", "Địa chỉ" và "Email".
2. Bảng số: Ràng buộc là các quy tắc hoặc điều kiện áp dụng cho mô hình ERD. Nó xác định các quy định về tính chất, quan hệ, và giới hạn của dữ liệu trong cơ sở dữ liệu. Ví dụ, một ràng buộc có thể là "Một sinh viên chỉ có thể tham gia một lớp học vào cùng một thời điểm".

Thực thể (Entity)​

Mối liên kết (Relationship)​

Bảng số​

Thuộc tính

Bài tập buổi 6: Xây dựng sơ đồ ERD cho hệ thống sau gồm nhân viên, phòng ban và đề án​

Yêu cầu: hoàn thành bảng bên dưới bằng cách bổ sung mối quan hệ, thuộc tính và bảng số

1. Mỗi phòng ban phụ trách không hoặc nhiều đề án - Mỗi đề án được phụ trách bởi duy nhất 1 phòng ban
2. Mỗi nhân viên được thực hiện không hoặc nhiều đề án - mỗi đề án được phân công cho 1 hoặc nhiều nhân viên

Bài tập số 1:

So sánh các mô hình phát triển phần mềm​

Bài 7: Data flow diagram

The Food Ordering System Example​

Context DFD​

A context diagram is a data flow diagram chỉ hiển thị cấp độ cao nhất, còn được gọi là Cấp độ 0. Ở cấp độ này, chỉ có một nút xử lý hiển thị đại diện cho các chức năng của một hệ thống hoàn chỉnh liên quan đến cách nó tương tác với các thực thể bên ngoài. Một số lợi ích của Biểu đồ Ngữ cảnh bao gồm:

1. Hiển thị tổng quan về ranh giới của một hệ thống
2. Không cần kiến thức kỹ thuật để hiểu với ký hiệu đơn giản
3. Dễ vẽ, sửa đổi và mở rộng vì các ký hiệu hạn chế của nó

A context Data Flow Diagram được vẽ cho một "Hệ thống đặt đồ ăn online". Thể hiện bên tham gia sẽ tương tác với hệ thống, được gọi là các thực thể bên ngoài. Trong ví dụ này, Nhà cung cấp, Nhà bếp, Quản lý và Khách hàng là các thực thể sẽ tương tác với hệ thống. Giữa quy trình và các thực thể bên ngoài, có luồng dữ liệu (các kết nối) chỉ ra sự tồn tại của việc trao đổi thông tin giữa các thực thể và hệ thống.

Context DFD là đầu vào của mô hình dữ liệu, nó chỉ thể hiện quy trình, không chưa bất kỳ dữ liệu nào

Level 1 DFD​

Data flow diagram Cấp độ 1, đó là sự phân rã (tức là phân chia) của quy trình "Hệ thống đặt đồ ăn online" được hiển thị trong Context diagram.

Lấy ví dụ "Hệ thống đặt đồ ăn online" chứa ba quy trình, bốn thực thể bên ngoài và hai kho dữ liệu.

Các quy trình

Khách hàng có thể đặt một Đơn hàng. Quy trình Đặt món nhận Đơn hàng, chuyển tiếp nó đến Nhà bếp, lưu trữ nó trong kho dữ liệu Đơn hàng, và lưu trữ thông tin cập nhật về Chi tiết hàng tồn trong kho dữ liệu Hàng tồn. Quy trình cũng gửi một Hóa đơn đến Khách hàng.

Quản lý có thể nhận Báo cáo thông qua quy trình Tạo báo cáo, quy trình này nhận Chi tiết hàng tồn và Đơn hàng như đầu vào từ kho dữ liệu Hàng tồn và Đơn hàng tương ứng.

Quản lý cũng có thể khởi tạo quy trình Đặt hàng hàng tồn bằng cách cung cấp Đơn hàng hàng tồn. Quy trình chuyển tiếp Đơn hàng hàng tồn đến Nhà cung cấp và lưu trữ thông tin cập nhật về Chi tiết hàng tồn trong kho dữ liệu Hàng tồn.

Data Flow Diagram Tips and Cautions​

1. Nhãn các quy trình (Process) nên là cụm từ động từ; các kho dữ liệu được đại diện bằng danh từ
2. Một kho dữ liệu phải được liên kết ít nhất với một quy trình
3. Một thực thể bên ngoài phải được liên kết ít nhất với một quy trình
4. Các số không nhất thiết chỉ ra trình tự, nó hữu ích trong việc xác định các quy trình khi thảo luận với người dùng
5. Kho dữ liệu (Data store) không nên được kết nối với một thực thể bên ngoài, nếu không, điều đó có nghĩa là bạn đang cho một thực thể bên ngoài truy cập trực tiếp vào các tệp dữ liệu của bạn
6. Luồng dữ liệu không nên tồn tại giữa 2 thực thể bên ngoài mà không thông qua một quy trình
7. Một quy trình có đầu vào nhưng không có đầu ra được coi là một quy trình hố đen

BÀI TẬP LỚN

Tuần 1: Phân tích yêu cầu và thiết kế hệ thống​

Phân tích chi tiết các yêu cầu chức năng và phi chức năng - dựa vào yêu cầu bài toán:

• Xác định rõ các tính năng cốt lõi và tính năng nâng cao.
• Đánh giá mức độ ưu tiên của từng tính năng.
• Xác định các ràng buộc về hiệu năng, bảo mật và khả năng mở rộng.

Lập mô hình Use Case:

• Mô tả các hành vi của người dùng khi tương tác với hệ thống.
• Xác định các actor và các use case chính.

Lập sơ đồ activities diagram

• Trình bày lược đồ hoạt động của tất cả các usecase

Thiết kế giao diện người dùng (UI):

• Tạo wireframe cho các màn hình chính của ứng dụng.
• Xác định các thành phần giao diện và bố cục.
• Chọn màu sắc, font chữ phù hợp với giao diện hiện đại và tươi sáng.

Lựa chọn công nghệ:

• Nghiên cứu và lựa chọn các công cụ, framework phù hợp để phát triển ứng dụng (ví dụ: React Native, Flutter, ...).
• Xác định cơ sở dữ liệu để lưu trữ dữ liệu người dùng (ví dụ: SQLite, Firebase).
• Nêu lí do tại sao lại sử dụng những công nghệ này ?

1. OpenAI​

Open AI là một trong những công ty nghiên cứu và triển khai trí tuệ nhân tạo hàng đầu thế giới. Công ty này tập trung vào việc phát triển các mô hình AI để giải quyết các vấn đề thực tế và mang lại giá trị cho con người. Các mô hình AI của Open AI được tập trung vào các lĩnh vực như ngôn ngữ tự nhiên, hình ảnh, âm thanh, và code lập trình.

1. Tại sao cần quản lý dự án

Nhu cầu​

1. Xuất hiện thị trường toàn cầu (Global market) ⇒ Nếu không đổi mới sẽ bị đào thải
2. Yêu cầu chất lượng sản phẩm ngày càng cao (High quality product) và thoả mãn nhu cầu khách hàng (Customer satisfaction)
3. Quy trình sản xuất phức tạp (Complex technical)
4. Vòng đời sản phẩm ngắn (Shorten product life cycles)

Quy trình quản lý Waterfall​

Đặc tính của mô hình Waterfall

1. Quy trình đi từ trên xuống dưới và không có chiều ngược lại
2. Bị xung đột giữa các bộ phận
3. Nhưng nếu một khi đã vận hành trơn tru thì lại rất hiệu quả ⇒ Vì tính chuyên môn hoá

Quy trình quản lý theo Agile​

1. Không bị ràng buộc bởi các hạn chế của Waterfall
2. Phù hợp với các dự án có tính thay đổi cao nhưng các dự án CNTT
3. Một nhóm scrum team phù hợp nhất với team size từ 6 - 10 người

Agile Manifesto​

Agile là quy trình

1. Individuals and interactions over processes and tools - Tập trung vào cá nhân và sự tương tác hơn là quy trình và công cụ
2. Working software over comprehensive documentation - Một phần mềm chạy được quan trọng hơn tài liệu dễ hiểu
3. Customer collaboration over contract negotiation - Cố gắng làm khách hàng hợp tác và cân đối để 2 bên đều có lợi thay vì tập trung vào hợp đồng
4. Responding to change over following a plan - Chấp nhận sự thay đổi thay vì tập trung vào plan

Scrum​

Scrum là khung làm việc (framework) giúp đội nhóm giải quyết các vấn đề phức tạp một các hiệu quả và tạo ra giá trị lớn nhất cho khách hàng. Scrum is lightweight and simple to understanding

Scrum 3 Pillars​

1. Transparency - Tính trong suốt: Mọi thông tin trong dự án đều là công khai và ai cũng có thể xem được cứ không bị phân tầng
2. Inspection - Tính kiểm tra: Mọi thời điểm có thể kiểm tra được tiến độ dự án, còn bao lâu nữa đến mục tiêu và phải được kiểm tra thường xuyên
3. Adaptation - Tính thích nghi: Thay đổi kế hoạch để thích nghi với sự thay đổi

Scrum 5 values​

Scrum definition​

Scrum team​

Đơn vị cơ bản của Scrum là một đội nhỏ gọi là Scrum Team. Scrum Team bao gồm một Scrum Master, một Product Owner và các Developers. Trong Scrum Team không có phân cấp hay tổ chức con. Nó là đơn vị gắn kết những chuyên gia cùng tập trung vào một mục tiêu, đó là Product Goal. Scrum Team có tính đa năng, có nghĩa là các thành viên cộng lại sẽ có tất cả kỹ năng cần thiết để tạo nên giá trị sau mỗi Sprint. Họ cũng tự quản, nghĩa là họ tự quyết định ai làm gì, khi nào và như thế nào. Scrum Team nhỏ vừa phải để giữ sự linh hoạt và lớn vừa phải để có thể hoàn tất những công việc có ý nghĩa trong một Sprint, thường là 10 người hoặc ít hơn. Nhìn chung, chúng ta thấy rằng những đội nhỏ hơn sẽ giao tiếp tốt hơn và hiệu quả hơn. Nếu Scrum Team trở nên quá lớn, họ nên nghĩ tới việc tái cấu trúc thành các Scrum Teams nhỏ hơn, cùng tập trung vào một sản phẩm. Từ đó họ có thể chia sẻ cùng một Product Goal, Product Backlog và Product Owner.

Development team​

Development team là những cá nhân trong Scrum Team cam kết tạo ra kết quả có giá trị sau mỗi Sprint.

Development team bao gồm: FE, BE, BA, Designer, Tester

Development team là một nhóm tự quản và không có người quản lý trực tiếp

Product Owner​

Product Owner là cá thể tối ưu giá trị sản phẩm của developers team. Họ có trách nhiệm quản lý Product Backlog

Scrum master​

Là người có kiến thức về scrum, tạo mô trường thực hành scrum trong scrum team. Họ có trách nghiệm tối ưu hoá tương tác các cá thể trong scrum team

Scrum Artifacts​

1. Product backlog: Là một rổ tập hợp các User stories cần phải làm để hoàn thành dự án, các công việc trong product backlog sẽ có mức độ ưu tiên khác nhau.

2. User stories: Là các câu chuyện của người dùng (Một phần mềm là tập hợp của nhiều câu chuyện người dùng)

   User stories bao gồm: tất cả các tính năng, yêu cầu, nâng cấp và sửa lỗi

3. Definition of Done - Là việc định nghĩa hoàn thành một công việc, tránh việc hiểu lầm những các thành phần trong scrum team.

Scrum Events (time-box event)​

1. Sprints - chạy nước rút: Trái tim của scrum, là các khoảng thời gian kéo dài từ 1 tuần đến 4 tuần, có độ dài như nhau xuyên suốt từ lúc bắt đầu đến kết thúc dự án

   Sprint Goal: Mục tiêu là mục tiêu chung của cả scrum team, trong quá trình thực hiện phải bám chặt lấy mục tiêu của sprint goal

2. Sprint Planning: Là sự kiện thảo luận giữa các thành viên trong scrum nhằm đưa ra được sprint goal

   1. Xác định sprint goal là gì? Và giải thích tầm quan trọng của nó để mọi người đều hiểu
   2. Làm những công việc gì trong Product Backlog để đạt được sprint goal
   3. Làm như thế nào?

3. Daily scrum: Sự kiện hàng ngày trong khoảng 15p - nhằm báo cáo công việc của ngày hôm trước và kế hoạch của ngày hôm nay.

   Từng cá nhân sẽ nói những vấn đề thuận lợi, khó khăn và kế hoạch ngày tiếp theo

   Giải quyết các vấn đề mất cân đối thông tin giữa PO, SM và Development team

How to create API service​

const Header = {
  token: LocalStorage.getItem("token"),
};

const PATH_BASE = "";

class DynamicAPI {
  constructor() {
    this.header = Header;
    this.pathBase = PATH_BASE
  }

  request = ({path, method, body}) => {
    return fetch(this.pathBase + path, {
      method: method,
      headers: this.header,
      body: body
    }).then((response) => {
      // if response success => return response
      // else if 401 => logout
      // else if 404 => redirect Not Found
      // else if 409 => throw Error
      // ....
    })
  };

  get = ({path}) => {
    return this.request({path, method: "GET", body: null})
  };

  post = ({path, body}) => {

  }
  /*same for post, delete and put*/
}

export default new DynamicAPI();

const AuthService = {
  login: async (email, password) => {
    const res = await DynamicAPI.post({path: "/login", body: {email, password}})
    // LocalStorage.setItem("token", token)
    // LocalStorage.setItem("user", user)
  },

  logout: () => {

  }
};

const APIService = {
  getListStaff: () => {
    return DynamicAPI.get({path: '/staff'})
  }
};

Ý tưởng chính của component​

• Component nên được tạo nên từ các thành phần nhỏ nhất là các component nhỏ hơn nữa được custom từ DOM của HTML, tuy nhiên được custom theo từng UI Ví dụ dưới đây là component được custom từ input: Ở đây sự dụng component custom như là một Node của HTML tuy nhiên có thể style theo từ dự án

import React from "react";

const Input = (props) => {
  return (
    <>
      <input placeholder="Custom input" {...props}/>
    </>
  )
}

export default Input;

Các cách để tạo ra một basis​

1. Sử dựng Style component​

• Có thể dựng component, truyền props để xây dựng UI

import styled from 'style-component'

const Button = styled.button`
  /* Adapt the colors based on primary prop */
  background: ${props => props.primary ? "palevioletred" : "white"};
  color: ${props => props.primary ? "white" : "palevioletred"};

  font-size: 1em;
  margin: 1em;
  padding: 0.25em 1em;
  border: 2px solid palevioletred;
  border-radius: 3px;
`;

render(
  <div>
    <Button>Normal</Button>
    <Button primary>Primary</Button>
  </div>
);

2. Sử dụng REF => Can thiệp sâu hơn vào API của DOM​

• Như là ở một article nào đó tôi đã nói kĩ về refs, và các cách để ứng dụng refs vào một component. Ứng dụng của refs là rất thực tiễn cho các component nhỏ, cần can thiệp sâu vào các API của element DOM ví dụ như: focus(), blur(), click(), select(), setSelectionRange(), setRangeText() setCustomValidity(), checkValidity(), reportValidity()

Create component

export default class InputClass extends React.Component {
  state = {
    test: "test"
  }
  showLog = () => {
    console.log("show log");
  };
  render() {
    return (
      <>
        <div>Class input component</div>
        <div>Test: {this.state.test}</div>
        <input placeholder="class input" />
      </>
    );
  }
}

const InputRef = React.forwardRef((props, ref) => (

<>
  <div>Custom input component using forward re</div>
  <input placeholder="custom ref input" ref={ref} {...props}/>
</>

))

>Using
```javascript
function App() {
  let customRefInput = React.createRef();
  let classInput = React.createRef();
  const [inputValue, setInputValue] = useState("");
  return (
    <div className="App">
      <h1>Hello React 17</h1>
      <h2>Start learing REF react</h2>
      <Input
        value={inputValue}
        onChange={e => setInputValue(e.target.value)}
        ref={node => console.log("input 1", node)}
      />
      <InputRef ref={node => (customRefInput = node)} />
      <InputClass ref={node => (classInput = node)} />
      <div>
        <button onClick={() => customRefInput.focus()}>Focus</button>
        <button onClick={() => customRefInput.blur()}>Blur</button>
        <button onClick={() => classInput.setState({ test: "test" })}>
          Reset state
        </button>
        <button onClick={() => classInput.setState({ test: "Change test" })}>
          Set state
        </button>
      </div>
    </div>
  );
}

Refs là gì:​

• Theo react official: React supports a special attribute that you can attach to any component (DOM node and component). The ref attribute can be an object created by React.createRef() function or a callback function, or a string (in legacy API). When the ref attribute is a callback function, the function receives the underlying DOM element or class instance (depending on the type of element) as its argument. This allows you to have direct access to the DOM element or component instance. Use refs sparingly. If you find yourself often using refs to “make things happen” in your app, consider getting more familiar with top-down data flow.
• Refs là một thuộc tính đặc biệt có thể attach vào bất kể một component nào (DOM node and component), thuộc tính ref có thể được tạo ra bằng React.createRef(), hoặc dùng function (node) => refName = node, hoặc đơn giản là string

  1. String refs: Là cách cũ nhất để tạo ra một refs và sẽ bị loại bỏ trong tương lai​

  // String
  export default class index extends React.Component {
    constructor() {
      super();
      this.state = {sayings: "" };
    }
    update(e) {
      this.setState({sayings: this.refs.input.value});
    }
  
    render() {
      return (
        <div>
          Bob says <input type="text" ref="btalks" onChange={this.update.bind(this)} />
          {this.state.sayings}
        </div>
      );
    }
  }
  

  If you’re currently using this.refs.textInput to access refs, we recommend using either the callback pattern or the createRef API instead.

  2. Callback refs​

  class MyComponent extends React.Component {
    constructor(props) {
      super(props);
      this.state = { uppercase: false };
    }
    
    toggleInputCase = () => {
      const isUpper = this.state.uppercase;
      // Accessing the ref using this.inputField
      const value = this.inputField.value;
      this.inputField.value =
        isUpper
          ? value.toLowerCase()
          : value.toUpperCase();
      this.setState({ uppercase: !isUpper });
    }
    render() {
      return (
        <div>
          {/* Creating a callback ref and storing it in this.inputField */}
          <input type="text" ref={elem => this.inputField = elem} />
          <button type="button" onClick={this.toggleInputCase}>
            Toggle Case
          </button>
        </div>
      );
    }
    
  }
  

  3. Using React.createRef()​

  class MyComponent extends React.Component {
   constructor(props) {
     super(props);
     this.myRef = React.createRef();
   }
   render() {
     return <div ref={this.myRef} />;
   }
  }
  

 
 
 #### 4. Some technical of Refs
 ##### a. Forward refs: 
 * Là kĩ thuật tự động truyền ref qua một component => đến một trong các component con của nó
 ```javascript
function FancyButton(props) {
  return (
    <button className="FancyButton" {...props}>
      {props.children}
    </button>
  );
}

• Xét vd trên: đây là các thông thường để tạo một custom component từ element, có thể lấy được hết các props từ cha đến thằng input nằm bên trong, tuy nhiên những API như focus(), blur(), click(), select(), setSelectionRange(), setRangeText() setCustomValidity(), checkValidity(), reportValidity() thì forward ref sẽ giải quyết đc vấn đề này:

import React from 'react'

const InputRef = React.forwardRef((props, ref) => (
    <>
      <input placeholder="custom ref input" ref={ref} {...props}/>
    </>
  ))

export default InputRef

// Using
function App() {
  let customRefInput = React.createRef();
  const [inputValue, setInputValue] = useState("");
  return (
    <div className="App">
      <h1>Hello React 17</h1>
      <h2>Start learing REF react</h2>
      <div>Custom input component</div>
      <Input value={inputValue} onChange={e => setInputValue(e.target.value)} />
      <div>Custom input component using forward ref</div>
      <InputRef ref={node => (customRefInput = node)} />
      <div>
        {/*Click button to focus ref input */}
        <button onClick={() => customRefInput.focus()}>Focus</button>
      </div>
    </div>
  );
}

b. Refs for class component​

• Mỗi class component (function component không có) cũng có thuộc tính ref, ref trỏ đến đối tượng (instance) được tạo ra từ class component Từ đây có thể access vào các method có sẵn của component được gán ref cũng như các method tự định nghĩa, ví dự trong tình huống này là method showLog

export default class InputClass extends React.Component {
  showLog = () => {
    console.log("show log");
  };
  render() {
    return (
      <>
        <input placeholder="class input" />
      </>
    );
  }
}


function App() {
  let customRefInput = React.createRef();
  let customInput = React.createRef();
  const [inputValue, setInputValue] = useState("");
  return (
    <div className="App">
      <h1>Hello React 17</h1>
      <h2>Start learing REF react</h2>
      <Input
        value={inputValue}
        onChange={e => setInputValue(e.target.value)}
        // Không được show lo
        ref={node => console.log("input 1", node)}
      />
      <InputRef ref={node => console.log("input 2", node)} />
      <InputClass ref={node => console.log("input 3", node)}/>
    </div>
  );
}

• Và đây là implememt

function App() {
  let customRefInput = React.createRef();
  let classInput = React.createRef();
  const [inputValue, setInputValue] = useState("");
  return (
    <div className="App">
      <h1>Hello React 17</h1>
      <h2>Start learing REF react</h2>
      <Input
        value={inputValue}
        onChange={e => setInputValue(e.target.value)}
        ref={node => console.log("input 1", node)}
      />
      <InputRef ref={node => (customRefInput = node)} />
      <InputClass ref={node => (classInput = node)} />
      <div>
        <button onClick={() => customRefInput.focus()}>Focus</button>
        <button onClick={() => customRefInput.blur()}>Blur</button>
        <button onClick={() => classInput.setState({ test: "test" })}>
          Reset state
        </button>
        <button onClick={() => classInput.setState({ test: "Change test" })}>
          Set state
        </button>
      </div>
    </div>
  );
}

Introduction Observation state management solution:​

• Lấy cảm hứng từ ý tưởng Observer pattern cùng việc học hỏi theo một trainer(FOZG) của mình tại FPT đã viết một công cụ có thể làm việc như là một thư viện quản lí trạng thái.
• Trong dự án tôi sử dụng 2 pattern chính là Observer Pattern và Singleton Pattern, trong một bài viết khác mình sẽ đề cấp đến một số pattern được sử dụng rất nhiều trong các dự án Javascript

Observer Pattern:​

• Như được biểu diễn trong sơ đồ UML, các đối tượng cần thiết là subject, observer và các đối tượng cụ thể. Subject có chứa tham chiếu đến các observers cụ thể để thông báo cho bất kỳ thay đổi. Đối tượng Observer là một lớp trừu tượng cho phép các observers cụ thể thực hiện phương thức thông báo

let Subject = function() {
  // Một stack các observers subscribe Subject
  this.observers = [];

  return {
    subscribeObserver: function(observer) {
      this.observers.push(observer);
    },
    unsubscribeObserver: function(observer) {
      let index = this.observers.indexOf(observer);
      if(index > -1) {
        this.observers.splice(index, 1);
      }
    },
    notifyObserver: function(observer) {
      let index = this.observers.indexOf(observer);
      if(index > -1) {
        this.observers[index].notify(index);
      }
    },
    notifyAllObservers: function() {
      for(let i = 0; i < this.observers.length; i++){
        this.observers[i].notify(i);
      };
    }
  };
};

let Observer = function() {
  return {
    notify: function(index) {
      console.log("Observer " + index + " is notified!");
    }
  }
}

let subject = new Subject();

let observer1 = new Observer();
let observer2 = new Observer();
let observer3 = new Observer();
let observer4 = new Observer();

subject.subscribeObserver(observer1);
subject.subscribeObserver(observer2);
subject.subscribeObserver(observer3);
subject.subscribeObserver(observer4);

subject.notifyObserver(observer2); // Observer 2 is notified!

subject.notifyAllObservers();
// Observer 1 is notified!
// Observer 2 is notified!
// Observer 3 is notified!
// Observer 4 is notified!

• Tư tưởng chính: ta xây dựng một nơi quản lí state tập trung của cả dự án gọi là Store, tại đây dự liệu sẽ được cập nhật => báo cho các component subscribe Store biết là đã có sự thay đổi store và hãy render lại đi (đã có dữ liệu mới rồi)

• Implement thế nào? Từ ý tưởng và khi implement là cả môt sự khác biết rất lớn:

1. Đầu tiên là vấn đề Store (Ở đây là ứng với Subject): Nơi lưu trữ dữ liệu, subscribe component và update dữ liệu Nhưng mà vấn đề ở chỗ là không thể cứ component nào cũng tạo ra một Store được vì như thế còn gì là quản lí tập trung nữa. Điều này làm ta phải nghĩ ngay đến Singleton Pattern :)))) Khó càng thêm khó => Lại thêm một pattern nữa mình băn khoăn (Xem định nghĩa ở dưới nhé) Có thể hiểu là mình cần phải tạo một object (đóng vai trò như là Singleton), tạo một lần dùng mãi mãi :)))) Tạm thời tắc tịt ở đây !!!

2. Bây là vấn đề Observer: Cái gì là đóng vai trò thông báo cho component biết khi nào cần phải render lại ???. Câu trả lời là: hàm setState của HOC chứa component => Vì khi hàm setState này được trigger thì component subscribe (HOC) sẽ được render lại => Component chính được render lại

3. Ngon rồi, đã clear hơn một chút về phần subscribe và render lại => Tuy nhiên vấn đề 1 thì còn nan giải. Vậy là cần phải tạo một instance của Store tổng để import vào HOC => Một cách để tạo ra Singleton.

Nhưng mình đang cần phải tạo ra nhiều Store để phục vụ các ứng dựng rỉêng => Giống redux nên thay vì tạo singleton là Store ta sẽ tạo singleton là các Observation chứ hàm connect HOC với component

Chi tiết code xem tại đây: https://github.com/vuanhtu1993/observation-state

Singleton Pattern​