🎯 Mục tiêu: Hiểu Encapsulation và "de-magic" các decorators của NestJS. Tiếp tục phát triển UserService từ Phần 1.

🎯 Mục tiêu: Phân biệt rõ ràng Interface và Abstract Class, áp dụng vào UserService với Repository Pattern.

🎯 Mục tiêu: Hiểu bản chất DI, IoC Container, và hoàn thiện inject IUserRepository vào UserService.

🎯 Mục tiêu: Hiểu 5 nguyên tắc SOLID và áp dụng vào code NestJS thực tế.

🎯 Mục tiêu: Tổng hợp các Design Patterns trong NestJS và hoàn thiện kiến thức OOP.

GitHub Actions là nền tảng CI/CD (Continuous Integration/Continuous Delivery) được tích hợp trực tiếp vào GitHub, cho phép bạn tự động hóa toàn bộ quy trình phát triển phần mềm từ build, test đến deploy. Bài viết này sẽ giúp bạn hiểu rõ về GitHub Actions từ khái niệm cơ bản đến các best practices.

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 ?