Vấn đề tối ưu SQL và sử dụng Transaction

1. Giới thiệu

Trong quá trình làm việc với các Cơ sở dữ liệu (CSDL), Khi chúng ta thực hiện một tác vụ nào đó, ngoài việc, CSDL có thể đáp ứng được những yêu cầu chức năng thì một vấn đề cũng không kém phần quan trọng khác để đảm bảo rằng CSDL đó có chất lượng là tốc độ xử lý của CSDL phải nhanh và chính xác. Dĩ nhiên, bước đầu tiên, CSDL phải được thiết kế tốt, nghĩa là cấu trúc các bảng, các mối quan hệ, các kiểu dữ liệu, các chỉ mục,… phải hết sức hợp lý. Kế đến là việc thiết kế các View, Stored Procedure, Trigger,… phải đúng và thích hợp. Cuối cùng là khả năng xử lý của các câu lệnh truy vấn dữ liệu (SQL) và phần tương tác giữa CSDL đó với các môi trường phát triển phần mềm.

Từ bước đầu, các câu lệnh SQL có thể chưa được hình thành một cách rõ ràng, nhưng đó là bước quan trọng đầu tiên để trong các bước tiếp theo chúng ta có thể tạo lập nên những câu SQL có chất lượng. SQL và Transaction được sử dụng và quan tâm nhiều nhất ở bước thứ 2 và bước thứ 3.

Một CSDL đáp ứng được yêu cầu xử lý nhanh, chính xác, phụ thuộc rất nhiều vào 2 vấn đề mà chúng ta vừa nêu trên, đó là tối ưu SQL và sử dụng Transaction một cách hợp lý.

2. Tối ưu SQL và sử dụng Transaction

2.1 Tạo lập và tối ưu SQL

Ở đây, chúng ta sẽ thảo luận việc tối ưu SQL dựa trên một CSDL đã có sẵn, nghĩa là các cấu trúc của các bảng, các mối quan hệ ràng buộc,… đã được định nghĩa và trong giả định là các cấu trúc đó khó thay đổi một cách tương đối, dĩ nhiên là chúng ta sẽ phải thay đổi chúng, nếu như xuất hiện một sự hiển nhiên phải thay đổi ở trong đó.

2.1.1 Tạo lập các câu lệnh truy vấn dữ liệu (SQL)

  • Cần phải có sơ đồ mô tả CSDL

Đó chính là các sơ đồ mô tả CSDL được xây dựng dưới dạng CDM (Conceptual Data Modelling), PDM (Physical Data Modelling). Thời gian hoàn thành một câu lệnh truy vấn, cũng như tốc độ mà câu lệnh đó thực hiện sẽ bị ảnh hưởng rất nhiều bởi yếu tố này. Trước khi viết một câu lệnh SQL, nhìn vào các CDM, PDM là một việc làm cần thiết.

  • Xem cấu trúc bảng trước khi viết câu lệnh SQL.

Trước khi viết một câu lệnh SQL mà nội dung của câu lệnh đó có liên quan đến bảng dữ liệu nào thì cần phải biết rõ các trường dữ liệu nằm trong bảng đó. Đừng bao giờ sử dụng “ Select * from ABC…”, bởi điều này sẽ làm chậm đi quá trình xử lý dữ liệu và có thể sẽ làm chúng ta khó khăn trong quá trình viết mã nguồn (có thể phát sinh ra các lỗi về CSDL).

  • Cast” có nên sử dụng hay không?

Cast” là một hàm được định nghĩa sẵn trong InterBase để “ép” kiểu dữ liệu. Nếu đã “ép” (chuyển đổi từ kiểu dữ liệu này sang kiểu dữ liệu khác) thì nên hạn chế dùng, dĩ nhiên trong nhiều trường hợp phải sử dụng đến yêu cầu này.

  • Sử dụng các câu lệnh SQL lồng nhau.

(Select …from ABC where (Select … from ABC)…) Đây là một thực tế mà chúng ta, trong quá trình viết các câu lệnh SQL rất hay gặp. Tuy nhiên, nếu có thể sử dụng các lệnh như HAVING, GROUP BY, WHERE,… để thay thế cho việc sử dụng SQL lồng nhau – sẽ tốt hơn. Khi lượng dữ liệu nhiều, điều này được thể hiện rất rõ ràng.

  • Sử dụng các liên kết (join) giữa các bảng.

Đây là một kỹ thuật được sử dụng rất thường xuyên khi viết các câu lệnh SQL. Có nhiều trường hợp thay vì dùng điều kiện WHERE, chúng ta có thể sử dụng các kỹ thuật JOIN (INNER JOIN, LEFT JOIN,…) để thay thế, tốc độ thực hiện có thể sẽ tốt hơn (điều này có liên quan đến việc tạo lập và sử dụng Indices).

  • Sử dụng kiểu liên kết (join) nào thì thích hợp

Có một số hình thức liên kết được sử dụng trong quá trình viết các câu lệnh SQL như: INNER JOIN, LEFT JOIN, RIGHT JOIN, CROSS JOIN, FULL OUTER JOIN.

SQL and Transaction_html_23627385

Trước khi quyết định sử dụng hình thức JOIN nào chúng ta cần phải biết kiểu quan hệ giữa các bảng mà chúng ta cần JOIN với nhau. Ví dụ, Hình trên thể hiện 3 quan hệ thường gặp nhất: R1: Quan hệ tùy chọn, R2: Quan hệ bắt buộc, R3: Quan hệ phụ thuộc. Chúng ta không thảo luận đến vấn đề sử dụng các quan hệ này như thế nào mà sẽ bàn đến việc sử dụng hình thức JOIN nào tương ứng với các quan hệ đó.

  • Đối với quan hệ R1 (Quan hệ tùy chọn). Chúng ta sẽ sử dụng hình thức LEFT JOIN, hoặc RIGHT JOIN, để có thể thực hiện được yêu cầu truy vấn một cách đầy đủ nhất. Chúng ta củng có thể sử dụng FULL JOIN để lấy toàn bộ dữ liệu của cả 2 bảng TABLE A1 và TABLE B1. Có trường hợp chúng ta sử dụng INNER JOIN (tốc độ xử lý sẽ nhanh hơn), tuy nhiên yêu cầu về tính liệt kê đầy đủ dữ liệu sẽ không được đáp ứng.

  • Đối với quan hệ R2 (Quan hệ bắt buộc), thì trường dữ liệu là khóa chính của bảng TABLE A2 sẽ trở thành khóa ngoại và là một trường dữ liệu bắt buộc (NOT NULL) trong bảng TABLE B2. Hình thức INNER JOIN sẽ là cách lựa chọn tốt nhất để thực hiện liên kết 2 bảng có quan hệ này.

  • Đối với quan hệ R3 (Quan hệ phụ thuộc), trong cấu trúc thực tế của CSDL thì khóa chính của bảng TABLE A3 vừa là khóa ngoại, vừa là một thành phần tạo nên khóa chính của bảng TABLE B3. Khi viết câu lệnh SQL chúng ta sẽ sử dụng hình thức : INNER JOIN.

Chú ý: Kết quả của câu lệnh truy vấn sẽ khác nhau, nếu chúng ta sử dụng những hình thức JOIN khác nhau.

  • Thứ tự của JOIN … và ON …

  • Trường hợp 1: Select A.A_NO, B.B_NAME from A inner join B on (B.B_No = A.B_No).

  • Trường hợp 2: Select A.A_NO, B.B_NAME from A inner join B on (A.B_No = B.B_No).

Hai trường hợp trên, dữ liệu được kết xuất ra đều giống nhau nhưng trường hợp 1 sẽ tốt hơn trường hợp 2.

  • Sử dụng IN và BETWEEN

Sử dụng hai lệnh này trong các câu lệnh SQL nếu có thể, sẽ tốt hơn nếu chúng ta sử dụng chúng khi thay thế cho điều kiện WHERE, khi có thể thay thế được.

  • ORDER BY khi nào?

Sử dụng ORDER BY cho các trường dữ liệu đã được tạo lập chỉ mục (INDEX) sẽ tốt hơn những trường dữ liệu khác, đối với các trường dữ liệu không được tạo INDEX, chúng ta sẽ thực hiện ORDER BY chỉ khi nào cần thiết mà thôi.

  • Thực hiện ghép nối (cộng) các trường dữ liệu với nhau

Đôi khi chúng ta vẫn thường sử dụng các câu lệnh SQL có dạng: Select A.FIELD1 || A.FIELD2, A.FIELD1 from A …, điều này chỉ nên thực hiện khi nào cần thiết mà thôi, tốc độ xử lý sẽ bị chậm đi rất nhiều khi chúng ta thực hiện nó. (Chúng ta sẽ thảo luận thêm ở phần Tương tác giữa SQL và môi trường phát triển phần mềm – (đang soạn)).

  • Sử dụng các ALIAS

Khi sử dụng các ALIAS, bạn có thể sẽ làm cho câu lệnh SQL trở nên gọn gàng hơn, đặc biệt khi bạn phải chọn nhiều trường dữ liệu, thực hiện nhiều động tác JOIN. Tuy nhiên, nhiều khi sử dụng các ALIAS không rõ ràng, chúng ta có thể sẽ gặp chút khó khăn.

Khi chúng ta đã tạo lập xong các câu lệnh SQL, một việc làm tiếp theo mà chúng ta thường lãng quên là kiểm tra độ chính xác và tối ưu tốc độ của nó. Khi dữ liệu được kết xuất, chúng ta có thể biết được độ chính xác của nó bằng trực diện. Còn tốc độ xử lý của câu lệnh truy vấn, chúng ta khó có thể nhìn thấy được, (Nếu lượng dữ liệu lớn có thể chúng ta sẽ dễ dàng thấy hơn bằng trực quan). Vậy chúng ta sẽ tối ưu các câu lệnh SQL như thế nào?

2.1.2 Tối ưu các câu lệnh truy vấn dữ liệu (SQL)

Đôi khi chỉ cần một thay đổi nhỏ trong câu lệnh SQL mà chúng ta lại thu được rất nhiều lợi ích về thời gian. Chúng ta phân quá trình tối ưu câu lệnh SQL thành 3 phần: trước khi tối ưu, thực hiện tối ưu và kiểm tra sự tối ưu.

2.1.2.1 Trước khi tối ưu

  • Cần phải có dữ liệu trong các bảng

Một câu lệnh SQL sẽ dường như làm cho chúng ta mịt mờ hơn khi nó làm việc với các bảng không hề có dòng dữ liệu nào. Vì vậy, trước khi thực hiện động tác tối ưu các câu lệnh SQL, chúng ta nhất thiết phải có đầy đủ dữ liệu trong các bảng. Nếu có càng nhiều dữ liệu, thì đó là một điều nên vui.

  • Để trạng thái của các INDEX về trạng thái tĩnh

Động tác này sẽ giúp cho câu lệnh SQL của chúng ta không bị ảnh hưởng bởi những INDEX không liên quan tới, giúp ta kiểm tra được thời gian thực hiện câu lệnh truy vấn được rõ ràng hơn.

  • Làm mới (Refresh) bộ phân tích câu lệnh SQL

Trong các công cụ quản trị hệ CSDL nghiêm chỉnh, đều có phần phân tích và thống kê tốc độ xử lý của các câu lệnh SQL. Trước khi thực hiện câu lệnh SQL chúng ta cần phải làm mới bộ phân tích này, để có một sự so sánh chính xác và rõ ràng hơn.

2.1.2.2 Thực hiện tối ưu

  • Tạo lập và kiểm tra các chỉ mục INDEX

  • INDEX là một phần rất quan trọng, ảnh hưởng đến tốc độ xử lý dữ liệu. Vì vậy việc tạo lập và quản lý các INDEX là một việc làm cần thiết. Thường thì trong các hệ quản trị CSDL, luôn có một công cụ để tạo lập các INDEX dựa trên cấu trúc của Khóa chính và khóa ngoại trong các bảng. Tuy nhiên, chúng ta cũng có thể bỏ đi một chỉ mục nào đó trong số các chỉ mục được tạo theo kiểu này (không khuyến khích).

  • Ngoài ra, chúng ta cũng có thể tạo lập thêm một số chi mục cho các bảng ngoài những chỉ mục như hình thức trên, tùy theo yêu cầu tìm kiếm, truy xuất dữ liệu. Việc tạo lập các chỉ mục này cũng cần thiết, nhưng không phải lúc nào cũng có giá trị.

  • Tạo lập và hủy bỏ các INDEX

Bởi vì các bảng sẽ cập nhật lại các chỉ mục sau khi một tác vụ: xóa, cập nhật, thêm mới dữ liệu được thực hiện trên bảng đó, vì vậy nếu có càng nhiều chỉ mục (có những chỉ mục không liên quan đến việc cập nhật, xóa,.. dữ liệu) thì thời gian làm việc sẽ lâu hơn. Do đó, trong quá trình truy vấn, chúng ta có thể tạo lập một INDEX và sau đó thì xóa bỏ INDEX đó đi.

  • Một số lưu ý khi tạo lập các chỉ mục INDEX

  • Đừng tạo chỉ mục cho các trường dữ liệu có lượng dữ liệu lớn, chỉ tạo khi cần thiết, rồi xóa bỏ nó đi sau khi thực hiện câu lệnh SQL (Select…). (Điều này có liên quan đến vấn đề chuẩn hóa dữ liệu (Dạng chuẩn 1, Hãy chia nhỏ các trường dữ liệu nếu còn có thể!))

  • Hạn chế tạo chỉ mục cho các trường có định dạng dữ liệu là Numeric.

  • Việc tạo chỉ mục sẽ ảnh hưởng rất nhiều đến việc thực hiện các yêu cầu WHERE, ORDER BY trong câu lệnh truy vấn.

  • Kiểm tra các nối kết dữ liệu (JOIN)

Các hình thức JOIN khác nhau sẽ kết xuất dữ liệu ra khác nhau, cũng như tốc độ xử lý của CSDL cũng vì thế mà khác nhau. Có trường hợp nếu chúng ta sử dụng INNER JOIN thì tốc độ xử lý của CSDL sẽ nhanh gấp 10 lần so với khi ta sử dụng LEFT JOIN. Độ chênh lệch này sẽ tăng nhiều hơn khi lượng dữ liệu càng lớn.

  • Tối ưu trong các câu lệnh SQL lồng nhau

Khi sử dụng các câu lệnh truy vấn lồng nhau (Sub query) nên theo cách: Câu lệnh SQL con sẽ là dạng thức của một câu lệnh tổng hợp, tập hợp (Max, Sum, Min,…). Ví dụ: Select A.A_No from A where A.A_DATE = (selectMax(A.A_DATE) from A).

  • Sử dụng VIEW và STORED PROCEDURE

VIEW và STORED PROCEDURE là 2 công cụ rất hữu ích trong việc phát triển các tính năng của CSDL. Tuy nhiên, nếu có thể thực hiện được yêu cầu truy vấn dữ liệu bằng VIEW thì hãy luôn sẵn sàng thực hiện, bằng không, nếu như dùng VIEW không thể đáp ứng được yêu cầu thì mới dùng đến STORED PROCEDURE. Bởi vì, một QUERY hay một VIEW là những công cụ chuẩn của SQL, do đó tốc độ xử lý của VIEW sẽ nhanh hơn tốc độ xử lý của STORED PROCEDURE.

  • Trong khi sử dụng câu lệnh có điều kiện WHERE

Trường hợp 1: Select A.A_No from A where A.VAL1 – A.VAL2 = 8
Trường hợp 2: Select A.A_No from A where A.VAL1 = A.VAL2 + 8

(Giả định VAL1, VAL2 là 2 trường có kiểu dữ liệu INTTEGER, hay NUMERIC,…).Trường hợp 2 sẽ tối ưu hơn trường hợp 1!

  • Vấn đề Trigger

Trigger được dùng trong 3 trường hợp: Thêm mới, cập nhật và xóa dữ liệu trong các bảng. Ngoài những trigger hệ thống, và những trigger mang tính chất định nghĩa sẵn (các trigger được chuyển hóa từ các quan hệ ràng buộc giữa các bảng). Chúng ta phải thực hiện việc tạo lập một số Trigger theo những yêu cầu khác. Tuy nhiên cần:

  • Chú ý việc sử dụng các Trigger trên những bảng có số lượng dữ liệu lớn.

  • Hạn chế việc viết những Trigger quá đơn giản, ví dụ: những trigger chỉ có nhiệm vụ tăng các trường dữ liệu lên 1 đơn vị trong một hệ thống AutoNumber nào đó!

  • Giới hạn vùng dữ liệu sẽ chịu những tác động của Trigger.

  • Hạn chế sử dụng nhiều STORED PROCEDURE lồng nhau

Nghĩa là trong STORED PROCEDURE A, chúng ta thực hiện lệnh gọi STORED PROCEDURE B thi hành, trong STORED PROCEDURE B chúng ta lại gọi STORED PROCEDURE C thi hành, … Điều này, sẽ hạn chế tốc độ xử lý của CSDL, vì trước khi một STORED PROCEDURE thi hành, nó phải chuẩn bị thời gian để khởi tạo biến, cung cấp giá trị tham số,…

2.1.2.3 Kiểm tra sự tối ưu

  • Kiểm tra kết quả được truy xuất khi thực hiện câu lệnh:

  • Đáp ứng được đầy đủ yêu cầu cần truy vấn…

  • Kiểm tra tốc độ thực hiện câu lệnh

Việc đánh giá tốc độ thực hiện câu lệnh SQL dựa trên 3 nhóm yếu tố:

  • Thời gian truy vấn (Query Time): Thời gian chuẩn bị (Prepare Time), thời gian thực hiện (Execute), và thời gian tìm và lấy toàn bộ dữ liệu (Fetch Time)

  • Mức sử dụng bộ nhớ (Memory Using).

  • Các tác vụ trên bảng (Operations).

Các tiêu chuẩn kiểm tra này đều được các công cụ quản trị và phát triển CSDL cung cấp.

2.2 Sử dụng Transaction

2.2.1 Transaction và công việc bên trong của nó

2.2.1.1 Transaction

Transaction là một khái niệm cũng như là một thành phần rất cơ bản và quan trọng trong quá trình CSDL làm việc. Transaction được thể hiện qua các yếu tố, viết tắt là ACID:

  • Atomicity:

Điều này muốn nói rằng, mọi hoạt động bên trong của một Transaction sẽ được thực hiện một cách trọn vẹn, khi Transaction thực hiện chức năng của nó.

  • Consistency:

Điều này đảm bảo rằng CSDL sẽ thực hiện những trạng thái đã được dự tính mà không quan tâm đến cách thức Transaction hoàn thành tác vụ của mình: <COMMIT> hoặc <ROLLBACK>

  • Isolation:

Khả năng tác chiến riêng biệt  cung cấp những tác vụ có tính độc lập khi thực hiện các giao dịch (transact) mang tính cạnh tranh. Nghĩa là giao dịch này không bị ảnh hưởng bởi những giao dịch khác trong khi cùng thực hiện.

  • Durability:

Liên tục, liên tục…nhấn mạnh đến khả năng duy trì và bảo vệ quyền làm chủ đối với CSDL mà không cần quan tâm đến các lỗi phần cứng hay phần mềm.

Transaction sẽ bắt đầu thực hiện nhiệm vụ (START TRANSACTION) của nó khi CSDL bắt đầu làm việc. Tuy nhiên, chúng ta có thể cho nó làm việc bất cứ lúc nào! Và kết thúc công việc của nó khi CSDL thực hiện động tác <COMMIT WORK> hoặc <ROLLBACK WORK>

2.2.1.2 Các trạng thái làm việc của Transaction

Transaction có 4 cách thức làm việc khác nhau theo tiêu chuẩn của ANSI (American Nataional Standards Institute) đặt ra:

  • Read Uncommitted

Để đơn giản chúng ta sẽ hình dung rằng: Có 2 người dùng cùng đang làm việc trên một bảng dữ liệu, ví dụ: ABC. Người dùng thứ 1 đang bắt đầu một transaction T1 để chỉnh sửa dữ liệu trên bảng ABC, người dùng thứ 2 cũng bắt đầu một transaction T2 để đọc dữ liệu từ bảng ABC. Khi đó Người dùng 2 có thể thấy được mọi sự thay đổi được thực hiện bởi transaction T1. Như vậy, người dùng 2 vẫn có thể lấy được dữ liệu – mà thực tế là không tồn tại – trong CSDL nếu người dùng 1 thực hiện tác vụ ROLLBACK đối với T1.

  • Read Commited

Cũng với 2 người dùng và bảng dữ liệu ABC, người dùng thứ 1 bắt đầu thực hiện một transaction T1 để chỉnh sửa dữ liệu trên bảng ABC và người dùng thứ 2 cũng đã bắt đầu một transaction T2 để đọc dữ liệu từ bảng này. Kết quả là, người dùng thứ 2 sẽ không thấy được những thay đổi được thực hiện bởi T1 cho đến khi, người dùng thứ nhất xác nhận những thay đổi của T1. Nghĩa là người dùng 2 sẽ lấy được hai tập hợp dữ liệu khác nhau trước và sau khi người dùng 1 xác nhận transaction T1.

  • Repeatable Read

Đối với trạng thái Transaction này, nếu người dùng thứ 1 thay đổi dữ liệu trong bảng ABC thì người dùng thứ 2 vẫn sẽ không thấy được những sự thay đổi đó với transaction T2 mặc dù người dùng thứ nhật thực hiện tác vụ COMMIT đối với T1.

  • Ở đây xuất hiện một tính huống rất thú vị, sẽ thảo luận thêm!

  • Serializable

Kết quả của việc thực hiện song song các transaction T1 và T2 sẽ giống nhau, nếu T1 và T2 thực hiện một cách liên tục tác vụ của mình.

2.2.2 Sử dụng Transaction trong các ứng dụng

Có 3 cách thức sử dụng Transaction trong các ứng dụng (viết trên nền Delphi, Jbuilder,…). Chúng ta tạm gọi như sau: sử dụng Transaction theo vùng CSDL, sử dụng Transaction theo chức năng xử lý phần mềm và sử dụng Transaction theo lớp, dựa trên cấu trúc của phần mềm. Mỗi cách thức sử dụng đều hợp lý theo từng trường hợp, tuy nhiên không có phương án nào là tốt nhất và có tác dụng tổng hợp nhất. Vì vậy chúng ta sẽ kết hợp các cách thức sử dụng Transaction dựa trên thực tế ứng dụng mà mình đang thực hiện.

2.2.2.1 Sử dụng Transaction theo vùng CSDL

SQL and Transaction_html_7b4c750c

Trong thực tế, một CSDL thường có những bộ phận tương đối tách biệt nhau, ví dụ: CSDL Bán hàng thì thông tin khách hàng sẽ tương đối độc lập với thông tin người bán hàng, CSDL Kế toán thì thông tin các cá nhân sẽ khá tách biệt với thông tin của các phiếu thu chi,…Nghĩa là trong rất nhiều CSDL, chúng ta có thể khoanh vùng, phân chia vùng CSDL theo một số tiêu chuẩn nào đó. Sơ đồ trên mô tả sự phân vùng CSDL. Xuất phát, từ thực tế này, trong quá trình sử dụng các Transaction, chúng ta sẽ quan tâm đến việc sử dụng các Transaction dựa trên sự phân vùng CSDL đó. Trong ví dụ trên, chúng ta có thể sử dụng Transaction T1 cho vùng CSDL A1, Transaction T2 cho vùng A2, Transaction T3 cho A3,…

Ý nghĩa của việc sử dụng Transaction theo hình thức này là làm tăng thêm tính năng hoạt động độc lập của các Transaction, giảm bớt sự kiêm nhiệm trong vấn đề xử lý các giao dịch trong CSDL.

2.2.2.2 Sử dụng Transaction theo chức năng xử lý phần mềm

Chúng ta thường quan tâm đến việc phân chia cấu trúc của một phần mềm thành 3 lớp: Lớp nhập dữ liệu, lớp tính toán và xử lý dữ liệu, lớp phân tích dữ liệu:

Phân tích dữ liệu

Tính toán dữ liệu

Nhập dữ liệu

Theo cấu trúc trên, một điều chúng ta dễ nhận thấy là công việc ở mỗi lớp sẽ khác nhau. Công việc nhập dữ liệu sẽ khác với công việc phân tích dữ liệu. Nhưng giao dịch dữ liệu trong quá trình xử lý của các lớp sẽ thực sự khác nhau. Trong khi, ở lớp nhập dữ liệu, chúng ta muốn dữ liệu được nhập vào phải nhanh, gọn, không bị mất mát, hư hỏng,… Ở lớp phân tích, chúng ta lại muốn so sánh, thống kê, đôi khi sự thay đổi dữ liệu một cách liên tục sẽ gây khó khăn cho ta trong quá trình phân tích,…

Để đáp ứng được yêu cầu trên một cách đầy đủ và chính xác nhất, chúng ta sẽ quan tâm đến việc sử dụng các giao dịch dữ liệu trong CSDL tương ứng với đặc tính của các lớp phần mềm trên. Nghĩa là, sẽ có 1 (hoặc nhiều hơn) Transaction phục vụ cho lớp Phân tích, 1 (hoặc nhiều hơn) Transaction phục vụ cho lớp Nhập dữ liệu,…

2.2.2.3 Sử dụng Transaction theo lớp

Trong các CSDL, chúng ta thường hay gặp những cấu trúc theo hình thức được mô tả ở sơ đồ dưới đây:

SQL and Transaction_html_6ef78762

Chúng ta đều biết rằng, khoá chính của B sẽ bao gồm khóa chính của A, khóa chính của C sẽ bao gồm cả khóa chính của B. Khi đó, để có dữ liệu ở C, chúng ta phải có dữ liệu ở B, và để có dữ liệu ở B, trước hết chúng ta phải có dữ liệu ở A. Chúng ta, thử mô tả một cách xử lý phần mềm đặc trưng trong các ứng dụng cho trường hợp trên:

SQL and Transaction_html_m2a500d76

Giả sử, trong ứng dụng chúng ta sử dụng một Transaction phục vụ cho 2 quá trình xử lý: xử lý TABLE_A và xử lý TABLE_B (thực ra là xuất hiện 2 giao dịch). Sẽ có những trường hợp chúng ta nhìn thấy một cách ngộ nghĩnh và khó hiểu, tùy theo ta đặt các trạng thái của Transaction (Read Commited, SnapShot,…). Ví dụ, có trường hợp ta thực hiện thêm và lưu dữ liệu ở TABLE_B, một thông báo về sự tồn tại hay không tồn tại Khóa chính ở Xử lý TABLE_A bất thình lình xuất hiện,…và còn nhiều biến trạng khác…

Trường hợp chúng ta sử dụng thuộc tính AutoCommit mà Transaction cung cấp, chúng ta có thể tránh được những biến trạng đó, tuy nhiên đây là một việc làm không hợp lý cho lắm, bởi vì, AutoCommit, nghĩa là cái gì cũng chấp nhận hết, mà thực tế, có nhiều cái chúng ta nhìn, chúng ta lấy mà không hề chấp nhận!

Do đó việc sử dụng các Transaction theo từng lớp sẽ thể hiện những tính năng rất tốt của nó trong trường hợp này. Nghĩa là ở lớp Xử lý TABLE_A chúng ta có Transaction T1, ở lớp xử lý TABLE_B chúng ta có T2, lớp xử lý TABLE_C chúng ta có T3.

3 Tài liệu tham khảo

  • InterBase Document Set – Borland Express – 2000

  • Designing Relational Database System (Rebecca Riordan).

  • InterBase 6.0 Documentation (Borland press).

  • Database Systems handbook (Paul J.Fortier).

  • http://www.dbmsmag.com

  • http://searchdatabase.techtarget.com

  • Tài liệu học tập từ giáo sư Usop.

12/2004

Mai Thế Hùng

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s