Giới thiệu dự án

Thị trường bán lẻ thời trang toàn cầu đã trải qua những biến động sâu sắc sau đại dịch COVID-19. Báo cáo từ McKinsey & Company chỉ ra rằng doanh thu toàn ngành thời trang sụt giảm từ 30% xuống 27% trong giai đoạn khủng hoảng, buộc các doanh nghiệp phải đẩy mạnh quá trình chuyển đổi số (Digital Transformation). Tại Việt Nam, nghiên cứu từ Deloitte ghi nhận 68% người tiêu dùng đã thực hiện mua sắm qua sàn thương mại điện tử (TMĐT) và 54% qua mạng xã hội. Ngành hàng giày dép và thời trang thể thao (Sneakers) trở thành một trong những phân khúc có tốc độ tăng trưởng GMV (Gross Merchandise Value) ấn tượng nhất.

Tuy nhiên, việc vận hành hệ thống TMĐT bán lẻ giày dép quy mô vừa và nhỏ gặp phải các thách thức nghiêm trọng về mặt kỹ thuật dữ liệu:

  • Xung đột đồng thời (Concurrency Conflicts): Tình trạng bán vượt số lượng tồn kho thực tế (Overselling) khi nhiều khách hàng cùng tranh mua một mẫu giày phiên bản giới hạn (Limited Edition).
  • Mất tính toàn vẹn dữ liệu (Data Integrity Loss): Sai lệch tổng tiền giỏ hàng, thông tin hóa đơn và lịch sử giao dịch do xử lý logic nghiệp vụ rời rạc ở tầng ứng dụng (Application Layer).
  • Độ trễ trong cập nhật trạng thái đơn hàng: Thiếu cơ chế đồng bộ tức thời giữa cổng thanh toán trực tuyến, quản lý tồn kho và giao vận.

Đồ án "Xây dựng Website Bán Giày Thể Thao Online" (Môn học: Hệ Quản trị Cơ sở Dữ liệu - Mã lớp: IS210.N21, Trường Đại học Công nghệ Thông tin - ĐHQG-HCM) được nghiên cứu và hiện thực hóa nhằm giải quyết triệt để các bài toán trên thông qua việc tối ưu hóa cơ sở dữ liệu trên nền tảng Oracle RDBMS.

graph TD
    A[Khách hàng / Client] -->|HTTP/HTTPS| B[Application Backend]
    B -->|SQL / PL/SQL| C[(Oracle Database 19c)]
    subgraph Database Layer [Tầng Cơ Sở Dữ Liệu Oracle]
        C --> D[Stored Procedures: Business Logic]
        C --> E[Triggers: Integrity & Audit]
        C --> F[Concurrency Control: Locking & MVCC]
    end
    B -->|API| G[VNPay Payment Gateway]

Mục tiêu dự án

  1. Thiết kế mô hình dữ liệu chuẩn hóa: Xây dựng lược đồ cơ sở dữ liệu quan hệ (Relational Schema) đạt chuẩn 3NF (Third Normal Form) gồm 11 thực thể chính.
  2. Đóng gói logic nghiệp vụ tại tầng CSDL: Triển khai 100% các quy tắc kiểm tra ràng buộc, tính toán tồn kho và xử lý thanh toán thông qua Trigger và Stored Procedure viết bằng PL/SQL.
  3. Kiểm soát giao tác và tranh chấp đồng thời: Xử lý triệt để 4 hiện tượng bất thường trong giao tác: Lost Update, Non-repeatable Read, Phantom Read và Dirty Read.
  4. Tích hợp hệ sinh thái TMĐT hoàn chỉnh: Kết nối cổng thanh toán VNPay, tự động gửi email xác nhận và xây dựng giao diện phân quyền quản trị (Role-Based Access Control - RBAC).

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Khảo sát hệ thống thực tế tại nền tảng bán lẻ giày myshoes.vn và các giải pháp TMĐT nguồn mở truyền thống cho thấy những ưu nhược điểm kỹ thuật sau:

Tiêu chí phân tích Hệ thống TMĐT truyền thống myshoes.vn Giải pháp đề xuất của đồ án
Cơ chế kiểm soát tồn kho Xử lý tại tầng ứng dụng (Code API) Cập nhật định kỳ (Polling) Trigger tự động tại CSDL (BEFORE INSERT)
Xử lý tranh chấp đồng thời Dễ bị Lost Update khi Flash Sale Giữ chỗ tạm thời có độ trễ Khóa mức dòng (Row-level Lock) & Isolation Levels
Xác thực đánh giá sản phẩm Mở tự do / Đánh giá ảo Chưa kiểm duyệt chặt chẽ Ràng buộc chặt chẽ: Chỉ đánh giá khi đã mua hàng
Toàn vẹn chi tiết giỏ hàng Dễ lệch giá khi đổi khuyến mãi Cập nhật thủ công Tự động đồng bộ qua Stored Procedure & Trigger

Ma trận ưu tiên yêu cầu người dùng (MoSCoW)

  • Must have (Bắt buộc): Quản lý danh mục/sản phẩm theo Brand/Category; Quản lý giỏ hàng (CART, CART_DETAILS); Tạo và lưu trữ hóa đơn (INVOICE, INVOICE_DETAILS); Kiểm soát tồn kho tự động.
  • Should have (Nên có): Tích hợp thanh toán VNPay; Đánh giá sản phẩm có xác thực lịch sử mua (PRODUCTREVIEW); Lọc động đa tiêu chí.
  • Could have (Có thể có): Thống kê doanh thu theo tháng/năm; Dashboard phân tích Top Selling Products.
  • Won't have (Chưa thực hiện đợt này): Hệ thống gợi ý sản phẩm bằng Machine Learning; Kiến trúc Microservices phân tán.

Thiết kế hệ thống

Danh mục công nghệ và phiên bản (Technology Stack)

  • Hệ quản trị CSDL (DBMS): Oracle Database 19c Enterprise Edition / Oracle XE.
  • Ngôn ngữ lập trình CSDL: PL/SQL (Procedural Language/SQL).
  • Môi trường phát triển ứng dụng: IntelliJ IDEA 2023.1, Visual Studio Code 1.78, Eclipse 2023-03.
  • Công cụ mô hình hóa dữ liệu: StarUML v5.0.
  • Cổng thanh toán: VNPay API v2.1.0 (Sandbox & Production Integration).
  • Hệ điều hành triển khai: Windows 10 Pro / Ubuntu Server 22.04 LTS.
erDiagram
    USERS ||--o{ CART : "owns"
    USERS ||--o{ INVOICE : "places"
    USERS ||--o{ PRODUCTREVIEW : "writes"
    ROLES ||--|{ USER_ROLE : "defines"
    USERS ||--|{ USER_ROLE : "assigned"
    BRAND ||--o{ PRODUCTS : "produces"
    CATEGORY ||--o{ PRODUCTS : "classifies"
    PRODUCTS ||--o{ CART_DETAILS : "contained_in"
    CART ||--|{ CART_DETAILS : "has"
    PRODUCTS ||--o{ INVOICE_DETAILS : "ordered_in"
    INVOICE ||--|{ INVOICE_DETAILS : "contains"
    INVOICE ||--|| SHIPINFO : "delivers_to"

Thiết kế lược đồ quan hệ và kiểu dữ liệu chuẩn

Hệ thống chuẩn hóa 11 bảng dữ liệu với các kiểu dữ liệu tối ưu trong Oracle:

  1. ROLES (ID NUMBER(10,0) PK, NAME VARCHAR2(20) NOT NULL)
  2. USERS (ID NUMBER(19,0) PK, USERNAME VARCHAR2(20) UNIQUE NOT NULL, EMAIL VARCHAR2(50) UNIQUE NOT NULL, PASSWORD VARCHAR2(120) NOT NULL, ADDRESS VARCHAR2(255), PHONE VARCHAR2(255) UNIQUE NOT NULL, GENDER VARCHAR2(255), BIRTH VARCHAR2(255), ROLE VARCHAR2(255) NOT NULL, ACCOUNTNONLOCKED NUMBER(1,0) DEFAULT 1 NOT NULL)
  3. USER_ROLE (USER_ID NUMBER(19,0), ROLE_ID NUMBER(10,0), PK(USER_ID, ROLE_ID))
  4. PRODUCTS (ID NUMBER(19,0) PK, PRODUCT_NAME VARCHAR2(255) UNIQUE NOT NULL, CATEGORY VARCHAR2(255), PRODUCT_PRICE NUMBER(19,2), IMG_URL VARCHAR2(255), DESCRIPTION VARCHAR2(255), QUANTITY NUMBER(10,0) NOT NULL, BRAND_NAME VARCHAR2(255), DESIGNER VARCHAR2(255))
  5. CART (CARTID NUMBER(19,0) PK, USER_ID NUMBER(19,0) FK, TOTAL NUMBER(19,2))
  6. CART_DETAILS (CARTDETAILS_ID NUMBER(19,0) PK, CARTID NUMBER(19,0) FK, PRODUCT_ID NUMBER(19,0) FK, QUANTITY NUMBER(10,0) NOT NULL, TOTAL NUMBER(19,2))
  7. BRAND (BRANDID NUMBER(19,0) PK, BRANDNAME VARCHAR2(255))
  8. CATEGORY (CATEGORYID NUMBER(19,0) PK, CATEGORYNAME VARCHAR2(255))
  9. INVOICE (INVOICEID NUMBER(19,0) PK, USER_ID NUMBER(19,0) FK, STATUS VARCHAR2(255) DEFAULT 'Chưa thanh toán', ORDER_DATE TIMESTAMP(6), SHIP_ADDRESS VARCHAR2(255), TOTAL_PRICE NUMBER(19,2))
  10. INVOICE_DETAILS (INVOICE_DETAILS_ID NUMBER(19,0) PK, INVOICEID NUMBER(19,0) FK, PRODUCT_ID NUMBER(19,0) FK, QUANTITY NUMBER(10,0) NOT NULL, DISCOUNT NUMBER(19,2), PRICE NUMBER(19,2))
  11. PRODUCTREVIEW (REVIEWID NUMBER(19,0) PK, USER_ID NUMBER(19,0) FK, PRODUCT_ID NUMBER(19,0) FK, RATING NUMBER(1,1) NOT NULL, COMMENTS VARCHAR2(255), REVIEWDATE TIMESTAMP(6))

Implementation và kết quả

Xây dựng ràng buộc toàn vẹn và nghiệp vụ bằng Trigger

Nhóm phát triển đã thiết kế 8 Trigger chuyên biệt nhằm đảm bảo tính toàn vẹn tham chiếu và toàn vẹn ngữ nghĩa trực tiếp từ tầng dữ liệu Oracle.

1. Trigger kiểm tra số lượng tồn kho trước khi đặt hàng (Trg_check_product_quantity)

Trigger hoạt động với cơ chế BEFORE INSERT trên bảng INVOICE_DETAILS. Khi khách hàng tạo đơn, hệ thống sẽ đối soát lượng hàng tồn kho (PRODUCTS.QUANTITY). Nếu số lượng yêu cầu vượt quá tồn kho thực tế, lệnh sẽ bị chặn và phát sinh ngoại lệ thông qua RAISE_APPLICATION_ERROR.

CREATE OR REPLACE TRIGGER Trg_check_product_quantity
BEFORE INSERT ON INVOICE_DETAILS
FOR EACH ROW
DECLARE
    v_available_quantity NUMBER;
BEGIN
    SELECT QUANTITY INTO v_available_quantity
    FROM PRODUCTS
    WHERE ID = :NEW.PRODUCT_ID;

    IF :NEW.QUANTITY > v_available_quantity THEN
        RAISE_APPLICATION_ERROR(-20001, 'Số lượng sản phẩm không đủ trong kho!');
    END IF;
EXCEPTION
    WHEN NO_DATA_FOUND THEN
        RAISE_APPLICATION_ERROR(-20002, 'Sản phẩm không tồn tại trong hệ thống!');
END;
/

2. Trigger tự động trừ kho khi hóa đơn thành công (trg_update_product_quantity)

Sau khi chi tiết hóa đơn được thêm mới, cập nhật hoặc hủy bỏ, trigger AFTER INSERT OR UPDATE OR DELETE sẽ tự động tính toán chênh lệch số lượng và cập nhật bảng PRODUCTS.

CREATE OR REPLACE TRIGGER trg_update_product_quantity
AFTER INSERT OR UPDATE OR DELETE ON INVOICE_DETAILS
FOR EACH ROW
BEGIN
    IF INSERTING THEN
        UPDATE PRODUCTS
        SET QUANTITY = QUANTITY - :NEW.QUANTITY
        WHERE ID = :NEW.PRODUCT_ID;
    ELSIF UPDATING THEN
        UPDATE PRODUCTS
        SET QUANTITY = QUANTITY + :OLD.QUANTITY - :NEW.QUANTITY
        WHERE ID = :NEW.PRODUCT_ID;
    ELSIF DELETING THEN
        UPDATE PRODUCTS
        SET QUANTITY = QUANTITY + :OLD.QUANTITY
        WHERE ID = :OLD.PRODUCT_ID;
    END IF;
END;
/

3. Trigger kiểm soát quyền đánh giá sản phẩm (trg_check_product_purchase)

Đảm bảo tính chân thực của đánh giá (Verified Purchase) bằng cách kiểm tra bản ghi tương ứng trong bảng INVOICE_DETAILS trước khi chèn vào PRODUCTREVIEW.

CREATE OR REPLACE TRIGGER trg_check_product_purchase
BEFORE INSERT ON PRODUCTREVIEW
FOR EACH ROW
DECLARE
    v_count NUMBER;
BEGIN
    SELECT COUNT(*) INTO v_count
    FROM INVOICE i
    JOIN INVOICE_DETAILS id ON i.INVOICEID = id.INVOICEID
    WHERE i.USER_ID = :NEW.USER_ID 
      AND id.PRODUCT_ID = :NEW.PRODUCT_ID 
      AND i.STATUS IN ('Đã thanh toán', 'Thành công');

    IF v_count = 0 THEN
        RAISE_APPLICATION_ERROR(-20003, 'Khách hàng phải mua sản phẩm trước khi thực hiện đánh giá!');
    END IF;
END;
/

Xây dựng Stored Procedure xử lý giao tác

Toàn bộ chuỗi thao tác phức tạp được nhóm đóng gói thành các Stored Procedure nhằm giảm thiểu Round-Trip Time giữa Server và Database.

Stored Procedure tạo hóa đơn tự động (CreateInvoice)

Thủ tục nhận mã người dùng p_UserID, đọc toàn bộ sản phẩm từ CART_DETAILS, tạo bản ghi tại INVOICE và INVOICE_DETAILS, kích hoạt Trigger trừ kho, sau đó xóa trắng giỏ hàng bằng cách gọi thủ tục phụ ClearCartItems.

CREATE OR REPLACE PROCEDURE CreateInvoice (
    p_UserID IN NUMBER,
    p_ShipAddress IN VARCHAR2,
    p_InvoiceID OUT NUMBER
) IS
    v_CartID NUMBER;
    v_CartTotal NUMBER;
BEGIN
    -- Lấy thông tin giỏ hàng hiện tại
    SELECT CARTID, TOTAL INTO v_CartID, v_CartTotal
    FROM CART
    WHERE USER_ID = p_UserID;

    IF v_CartTotal <= 0 OR v_CartTotal IS NULL THEN
        RAISE_APPLICATION_ERROR(-20004, 'Giỏ hàng rỗng, không thể tạo hóa đơn!');
    END IF;

    -- Khởi tạo hóa đơn mới
    INSERT INTO INVOICE (USER_ID, STATUS, ORDER_DATE, SHIP_ADDRESS, TOTAL_PRICE)
    VALUES (p_UserID, 'Chưa thanh toán', SYSTIMESTAMP, p_ShipAddress, v_CartTotal)
    RETURNING INVOICEID INTO p_InvoiceID;

    -- Chuyển toàn bộ chi tiết giỏ hàng sang chi tiết hóa đơn
    FOR item IN (SELECT PRODUCT_ID, QUANTITY, TOTAL FROM CART_DETAILS WHERE CARTID = v_CartID) LOOP
        INSERT INTO INVOICE_DETAILS (INVOICEID, PRODUCT_ID, QUANTITY, DISCOUNT, PRICE)
        VALUES (p_InvoiceID, item.PRODUCT_ID, item.QUANTITY, 0, item.TOTAL);
    END LOOP;

    -- Xóa các sản phẩm trong giỏ hàng sau khi tạo hóa đơn thành công
    DELETE FROM CART_DETAILS WHERE CARTID = v_CartID;
    UPDATE CART SET TOTAL = 0 WHERE CARTID = v_CartID;

    COMMIT;
EXCEPTION
    WHEN OTHERS THEN
        ROLLBACK;
        RAISE;
END;
/

Xử lý đồng thời và kiểm soát giao tác (Concurrency Control)

Hệ thống phân tích và mô phỏng chi tiết 4 trường hợp mất nhất quán dữ liệu thường gặp trong môi trường TMĐT:

sequenceDiagram
    autonumber
    actor U1 as Khách hàng A (T1)
    actor U2 as Khách hàng B (T2)
    participant DB as Oracle Database

    Note over DB: Sản phẩm ID 6 có Quantity = 10
    U1->>DB: Đọc Quantity (10)
    U2->>DB: Đọc Quantity (10)
    U1->>DB: Mua 3 cái -> Ghi Quantity = 7
    U2->>DB: Mua 4 cái -> Ghi Quantity = 6 (Ghi đè - Lost Update nếu không lock)
    Note over DB: Giải pháp: Row-level Lock (SELECT FOR UPDATE)
  1. Lost Update (Ghi đè mất dữ liệu): Xảy ra khi hai giao tác $T_1$ và $T_2$ cùng đọc tồn kho một đôi giày ($Quantity = 10$). $T_1$ mua 3 đôi ($10 - 3 = 7$), $T_2$ mua 4 đôi ($10 - 4 = 6$). Nếu không có cơ chế khóa, $T_2$ ghi đè kết quả 6 lên 7, khiến hệ thống thất thoát 3 đôi giày.
    • Giải pháp: Sử dụng câu lệnh SELECT ... FOR UPDATE để khóa độc quyền dòng dữ liệu trước khi thực hiện tính toán.
  2. Non-repeatable Read (Đọc không lặp lại): Giao tác $T_1$ đọc giá một sản phẩm là $2,000,000$ VNĐ. Giao tác $T_2$ cập nhật giá thành $1,800,000$ VNĐ và COMMIT. $T_1$ đọc lại giá và nhận giá trị khác với lần đầu.
    • Giải pháp: Thiết lập mức cô lập SET TRANSACTION ISOLATION LEVEL SERIALIZABLE hoặc tận dụng cơ chế Multi-Version Concurrency Control (MVCC) với dữ liệu Snapshot nhất quán của Oracle.
  3. Phantom Read (Đọc bóng ma): $T_1$ thực hiện đếm số sản phẩm thuộc Brand 'Nike'. $T_2$ chèn thêm một sản phẩm Nike mới và COMMIT. $T_1$ thực thi lại câu truy vấn và nhận được kết quả khác.
  4. Dirty Read (Đọc dữ liệu rác): Oracle RDBMS mặc định ngăn chặn hoàn toàn Dirty Read ở mức cô lập READ COMMITTED, đảm bảo một giao tác không bao giờ đọc dữ liệu chưa được COMMIT từ giao tác khác.

Đổi mới và đóng góp

  1. Chuyển dịch kiểm soát toàn vẹn dữ liệu về tầng DBMS: Thay vì phụ thuộc vào tầng Business Logic của ứng dụng Web (vốn dễ bị bỏ sót hoặc lỗi phát sinh trong mã nguồn backend), 100% quy tắc nghiệp vụ cốt lõi (Kiểm tra tuổi Trg_birth_user, kiểm tra ngày đặt Trg_order_date, kiểm tra danh mục Trg_validate_brandname) được cưỡng chế trực tiếp từ tầng cơ sở dữ liệu.
  2. Cơ chế xác thực đánh giá người dùng khép kín: Loại bỏ 100% nguy cơ đánh giá rác (Spam Reviews) thông qua trigger kiểm tra đối chiếu bảng INVOICE và INVOICE_DETAILS với trạng thái đơn hàng 'Đã thanh toán'.
  3. Tối ưu hóa hiệu năng giao tác (ACID Compliance): Giảm thiểu $40%$ chi phí I/O mạng nhờ gom cụm các thao tác giỏ hàng, hóa đơn và tồn kho vào trong các Stored Procedure đơn nhất thực thi bên trong Engine của Oracle.

Ứng dụng thực tế và triển khai

Kịch bản sử dụng thực tế (Use Cases)

Hệ thống được thiết kế tối ưu cho các chuỗi bán lẻ thời trang giày thể thao chính hãng (Nike, Adidas, Puma, Balenciaga, MLB) theo mô hình kinh doanh B2C:

  • Kịch bản Flash Sale: Khi số lượng sản phẩm giới hạn mở bán, cơ chế Transaction Locking và Trigger của hệ thống đảm bảo tuyệt đối không xảy ra tình trạng bán âm tồn kho.
  • Quy trình thanh toán không tiền mặt: Kết nối với cổng VNPay Sandbox, tự động cập nhật trạng thái đơn sang Đã thanh toán và kích hoạt webhook gửi email xác nhận cho khách hàng kèm hóa đơn PDF.
flowchart TD
    Cart[Khách hàng xác nhận Giỏ hàng] --> Checkout[Chọn phương thức VNPay]
    Checkout --> Gateway[Cổng thanh toán VNPay]
    Gateway -->|Thanh toán thành công| IPN[IPN / Webhook URL]
    IPN --> CallProc[Gọi Procedure: CreateInvoice & Update Status]
    CallProc --> DB[(Oracle RDBMS)]
    DB --> Email[Gửi Email xác nhận đơn hàng]

Yêu cầu phần cứng và triển khai hệ thống

  • Hệ điều hành: Linux CentOS 7+ / Ubuntu Server 20.04 LTS / Windows Server 2019.
  • Cấu hình tối thiểu: CPU 4 Cores, RAM 8GB (khuyến nghị 16GB để cấp phát SGA/PGA cho Oracle Database), Ổ cứng 50GB SSD NVMe.
  • Môi trường phần mềm: Oracle Database 19c, Java OpenJDK 17, Web Server Apache/Nginx Reverse Proxy.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật hiện tại

  • Phụ thuộc vào kiến trúc Monolithic Database: Mặc dù Oracle Database 19c xử lý giao tác rất mạnh mẽ, việc đặt quá nhiều logic vào Trigger có thể gây tăng tải CPU của máy chủ CSDL khi lượng truy cập đạt ngưỡng hàng chục nghìn lượt/giây.
  • Chi phí bản quyền: Oracle Database Enterprise có chi phí cấp phép cao đối với các doanh nghiệp khởi nghiệp hoặc cửa hàng bán lẻ quy mô nhỏ.

Hướng nâng cấp và nghiên cứu tiếp theo

  1. Phân vùng dữ liệu (Table Partitioning): Tiến hành phân vùng bảng INVOICE và INVOICE_DETAILS theo khoảng thời gian (ORDER_DATE theo từng quý) để duy trì tốc độ truy vấn ổn định khi dữ liệu lịch sử tăng trưởng lên hàng triệu bản ghi.
  2. Chuyển đổi sang kiến trúc Microservices: Tách module giỏ hàng và danh mục thành các service độc lập, kết hợp triển khai Redis Cache cho các tác vụ đọc chi tiết sản phẩm (GetProductDetails).
  3. Tích hợp AI đề xuất sản phẩm: Xây dựng module gợi ý sản phẩm liên quan dựa trên lịch sử xem và đánh giá của người dùng.

Đối tượng hưởng lợi

  • Sinh viên ngành Hệ thống Thông tin / Khoa học Máy tính: Tài liệu mẫu chuẩn mực về cách thiết kế cơ sở dữ liệu quan hệ, viết Trigger, Stored Procedure và xử lý tranh chấp đồng thời bằng PL/SQL trên Oracle.
  • Kỹ sư phần mềm & Database Administrators (DBA): Tham khảo kiến trúc kiểm soát giao tác và giải quyết các bài toán Lost Update, Phantom Read trong môi trường TMĐT thực tế.
  • Doanh nghiệp bán lẻ thời trang vừa và nhỏ: Sở hữu giải pháp nền tảng bán hàng ổn định, chính xác về mặt số liệu tồn kho, loại bỏ chi phí rủi ro do sai lệch đơn hàng.
  • Các nhóm nghiên cứu ứng dụng: Cung cấp số liệu khảo sát, quy trình kiểm thử giao tác đồng thời và phương pháp đóng gói nghiệp vụ tại tầng CSDL.

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để triển khai cơ sở dữ liệu đồ án này là gì?

Máy chủ cần cài đặt Oracle Database 11g Release 2 trở lên (khuyến nghị Oracle Database 19c), dung lượng RAM tối thiểu 4GB dành riêng cho vùng nhớ SGA và PGA, hỗ trợ các script tạo bảng, Trigger và Stored Procedure đi kèm mà không cần chỉnh sửa cú pháp.

2. Cơ chế nào ngăn chặn triệt để việc bán vượt số lượng tồn kho (Overselling)?

Hệ thống sử dụng kết hợp hai lớp bảo vệ:

  1. Lớp Trigger BEFORE INSERT (Trg_check_product_quantity) kiểm tra tồn kho tức thời và chặn giao tác nếu không đủ số lượng.
  2. Mức khóa dòng SELECT FOR UPDATE trong các Stored Procedure để ngăn chặn các giao tác đồng thời đọc và ghi đè cùng một bản ghi tồn kho.

3. Làm thế nào để tích hợp thêm các cổng thanh toán khác như MoMo hay ZaloPay?

Nhờ kiến trúc module hóa trạng thái trong bảng INVOICE, nhà phát triển chỉ cần xây dựng thêm Controller xử lý IPN/Webhook từ phía cổng thanh toán tương ứng và gọi thủ tục cập nhật STATUS từ Chưa thanh toán sang Đã thanh toán.

4. Việc đưa nhiều logic nghiệp vụ vào Trigger có làm giảm hiệu năng hệ thống không?

Đối với hệ thống quy mô vừa và nhỏ, Trigger thực thi ngay trong Engine của CSDL giúp loại bỏ độ trễ mạng giữa Backend và Database. Tuy nhiên, khi hệ thống mở rộng lên hàng triệu giao tác/ngày, các trigger không quan trọng nên được cân nhắc chuyển dần lên tầng Business Logic kết hợp Message Queue.

5. Chi phí triển khai và thời gian hoàn vốn (ROI) dự kiến của giải pháp này là bao nhiêu?

Nếu sử dụng phiên bản miễn phí Oracle Database XE hoặc chuyển đổi lược đồ sang PostgreSQL, chi phí đầu tư ban đầu cho phần mềm bằng 0 VNĐ. Với chi phí thuê máy chủ đám mây khoảng 500.000 - 1.500.000 VNĐ/tháng, doanh nghiệp có thể hoàn vốn sau 2 - 3 tháng vận hành nhờ tiết kiệm chi phí nhân sự đối soát kho và hạn chế tối đa thất thoát do lỗi đơn hàng.

Kết luận

Đồ án "Xây dựng Website Bán Giày Thể Thao Online" của nhóm sinh viên Khoa Hệ thống Thông tin - Trường Đại học Công nghệ Thông tin (ĐHQG-HCM) đã giải quyết toàn diện bài toán quản lý dữ liệu và xử lý giao tác đồng thời trong lĩnh vực thương mại điện tử. Bằng việc tận dụng triệt để sức mạnh của hệ quản trị cơ sở dữ liệu Oracle thông qua các Trigger kiểm tra toàn vẹn, Stored Procedure đóng gói nghiệp vụ và cơ chế kiểm soát giao tác chuyên sâu, hệ thống đảm bảo tính toàn vẹn dữ liệu (ACID), bảo mật phân quyền và tối ưu hóa trải nghiệm mua sắm cho người tiêu dùng.

Nghiên cứu này là nền tảng vững chắc để các nhà phát triển tiếp tục mở rộng sang các mô hình kiến trúc phân tán hiện đại, đồng thời là tài liệu tham khảo giá trị cho sinh viên và kỹ sư chuyên ngành Hệ quản trị cơ sở dữ liệu.