Persistence cho đối tượng và quan hệ
a. Khái niệm persistence.
Trong khoa học máy tính, persistence nói đến đặc tính của dữ liệu sống lâu hơn sự thực thi của chương trình tạo ra chúng. Không có khả năng này, dữ liệu chỉ tồn tại trong bộ nhớ trong, và sẽ bị mất khi bộ nhớ không hoạt động nữa.
Trong chương trình máy tính, persistence nói đến một cách đặc biệt tới khả năng để lấy về một cấu trúc dữ liệu nào đó trong khi chương trình thực thi.
Điều này đạt được trong hoạt động của hệ thống file, cơ sở dữ liệu quan hệ, cơ sở dữ liệu đối tượng dựa trên bộ nhớ lưu trữ. Các phương pháp thiết kế giải quyết vấn đề persistence được dựa trên container based persistence, component based persistence và mô hình DAO.
b. Persistence trong ứng dụng hướng đối tượng.
Theo khái niệm persistence, trong một ứng dụng hướng đối tượng có hỗ trợ tính chất này của dữ liệu, các đối tượng sẽ sống lâu hơn chương trình tạo ra nó. Trạng thái của đối tượng có thể được lưu trữ vào đĩa và một đối tượng với cùng trạng thái sẽ được tái tạo ở lúc nào đó trong tương lai.
Cơ sở dữ liệu quan hệ hiện đại cung cấp các cách biểu diễn cho persistent data, có thể sắp xếp, tìm kiếm và kết hợp dữ liệu với nhau. Hệ quản trị cơ sở dữ liệu có trách
nhiệm quản lý đồng thời và toàn vẹn dữ liệu; chúng cũng có trách nhiệm trong việc chia sẻ dữ liệu giữa nhiều người dùng và nhiều ứng dụng. Một hệ quản trị cơ sở cũng cung cấp bảo mật ở các mức khác nhau trong việc thao tác cơ sở dữ liệu.
Tóm lại, trong bài viết này, khi nói đến persistence chúng ta suy nghĩ đến các vấn đề như sau:
Lưu trữ, tổ chức và lấy dữ liệu có cấu trúc Xử lí đồng thời và toàn vẹn dữ liệu
Chia sẻ dữ liệu
c. Persistence trong kiến trúc phân lớp & các lựa chọn cho mục đích persistence.
Trong một ứng dụng cỡ vừa hoặc cỡ lớn, công việc tổ chức các lớp theo các thành phần có liên quan đến nhau là cần thiết. Chúng ta có thể kể ra các thành phần phổ biến như, Persistence trình diễn, luồng công việc và xử lí logic (presentation, workflow & business logic). Cũng có những thành phần “cross-cutting” có thể được cài đặt chung bởi framework như ghi, cấp phép, phân định ranh giới giao dịch ... Sau đây chúng ta sẽ giới thiệu kiến trúc phân lớp và vai trò của từng lớp là như thế nào. Sau đó chúng ta sẽ tập trung vào lớp chúng ta quan tâm nhất persistence layer và các cách thức có thể để thực hiện công việc này.
• Kiến trúc phân lớp (Layered Architecture)
Một kiến trúc phân lớp định nghĩa các giao tiếp giữa các mã cài đặt giữa các tầng liên quan, cho phép thay đổi cách cài đặt của những bộ phận này mà không là thay đổi mã của những bộ phận khác. Chúng ta phân lớp dựa theo các quy luật sau:
Các lớp giao tiếp từ trên xuống. Một layer phụ thuộc vào các lớp trực tiếp làm việc với nó
Mỗi lớp không nhận thấy bất kỳ lớp nào khác trừ lớp ở bên dưới nó.
Các ứng dụng khác nhau phân lớp khác nhau do chúng nhóm các thành phần khác nhau. Một kiểu phân lớp ứng dụng đặc trưng cho kiến trúc ứng dụng mức cao là kiến trúc 3 lớp bao gồm Presentation, Business Logic và Persistence như minh họa trong hình 4.4:
Presentation Layer: (Lớp trình diễn)
Lớp này chứa các giao tiếp người dùng, định nghĩa và điều khiển các trang và màn hình
Business Layer (Lớp xử lí chức năng, nghiệp vụ)
Lớp này có trách nhiệm giải quyết mọi vấn đề về các luật business và các yêu cầu hệ thống được xây dựng bởi người dùng trong miền bài toán cần giải quyết.
Persistence Layer
Database
Dữ liệu tồn tại bên ngoài ứng dụng. Nó thực sự là sự biểu diễn persistent của trạng thái ứng dụng. Nếu một SQL database được dùng, tầng DB bao gồm lược đồ quan hệ và có thể cả các thủ tục (StoredProcedure) nữa.
Các lớp Helper/Utility
Mọi ứng dụng có một tập các lớp kiểu helper hoặc utility được dùng trong mọi lớp của ứng dụng (ví dụ Exception Class trong xử lí ngoại lệ). Những lớp này không tạo nên một lớp vì chúng không theo quy luật nào cả trong các luật của kiến trúc phân lớp.
Hình 4-21 Vị trí của lớp Persistence trong kiến trúc phân lớp
• Các cách thức thực hiện công việc persistence
Tất cả mọi vấn đề của ứng dụng, tập trung lại, cái quan trọng nhất vẫn là đảm bảo việc xử lí dữ liệu chính xác và tốt nhất. Cách tiếp cận phổ biến trước đây với người lập trình Java cho persistence là sử dụng hệ quản trị cơ sở dữ liệu quan hệ với JDBC, các thực thể EJB, những nhà lập trình .Net thì sử dụng ADO.Net cho mục đích tương tự. Họ cũng sử dụng mẫu thiết kế DAO để ẩn đi các thành phần phức tạp trong business logic. Tuy nhiên, nếu sử dụng những công nghệ trên, công việc của người lập trình là phải viết mã cho tất cả các thực thể, lớp trong mô hình thiết kế. Nếu không muốn sử dụng hệ quản trị cơ sở dữ liệu quan hệ theo cách trên, chúng ta có thể sử dụng một hệ quản trị cơ sở dữ liệu hướng đối tượng (OODBMS).Dường như nghe qua rất hợp lí khi nói đến sự kết hợp hoàn hảo của nó với một ngôn ngữ lâp trình hướng đối tượng. Tuy nhiên, vào thời điểm hiện tại và tương lai gần, mặc dù được nghiên cứu rất nhiều nhưng OODBMS không đảm đáp ứng đầy đủ các yêu cầu trong xây dựng ứng dụng so với RDBMS. Như vậy, khó khăn của chúng ta là ở chỗ cả kỹ thuật lập trình hướng đối tượng và RDBMS đều đã khằng định được vai trò của nó trong việc đáp ứng yêu cầu thực tế của ngành công nghiệp phần mềm nhưng khi đặt hai mô hình đối tượng và mô hình quan hệ cạnh nhau trong cùng một ứng dụng lại nảy sinh hàng loạt vấn đề mà chúng ta sẽ nói đến ở phần tiếp theo trong đồ án tốt nghiệp. (adsbygoogle = window.adsbygoogle || []).push({});
Các vấn đề trong ánh xạ quan hệ đối tượng-Object Relation Mapping
Vấn đề ánh xạ quan hệ, đối tượng là các vấn đề chúng ta gặp khi sử dụng một ngôn ngữ lập trình hướng đối tượng hoặc viết theo phong cách hướng đối tượng để thao tác cơ sở dữ liệu được thiết kế theo mô hình quan hệ.
Truy cập tới một đối tựơng trong một chương trình hướng đối tượng thường được thực hiện tốt nhất theo các giao diện (interface) mà cùng nhau cung cấp sự truy cập duy nhất tới các thành phần bên trong của đối tượng. Một cách tương tự, các khái niệm OOP cơ bản cho các lớp đối tượng, thừa kế và đa hình, không được hỗ trợ trong hệ quản trị cơ sở dữ liệu
Các vấn đề không tương thích trong việc thực hiện ánh xạ đối tượng, quan hệ.
a. Ánh xạ kết hợp
Như chúng ta đã nói cơ bản ở phần kết hợp trong mô hình quan hệ, một kết hợp có thể là hai chiều, một chiều, có thể là một nhiều, nhiều một, một một, ... . Ánh xạ kết hợp và quản lý kết hợp các thực thể là trung tâm của các giải pháp object persitence.
Ngôn ngữ hướng đối tượng biểu diễn kết hợp sử dụng tham chiếu đối tượng (object reference) và các tập hợp các object reference. Trong thế giới quan hệ, một kết hợp được biểu diễn dưới dạng một khóa ngoại, sao chép các giá trị khóa vào các bảng. Có các điểm khác nhau căn bản trong hai cách biểu diễn này.
Trong mô hình hướng đối tượng, Object Reference có hướng tự nhiên; sự kết hợp là từ một đối tượng tới đối tượng khác. Nghĩa là sự kết hợp có thể đi theo cả hai hướng, khi đó phải khai báo kết hợp tới hai lần, mỗi lần trong mỗi lớp được kết hợp. Xét biểu đồ lớp đơn giản sau:
Hình 4-22 Một biểu đồ lớp đơn giản
Khi đó khai báo lớp trong mô hình đối tượng sẽ như sau:
Hướng trong mô hình quan hệ lúc này chỉ là một chiều.
Điều này không thể có trong cơ sở dữ liệu quan hệ, chúng ta phải tạo một bảng liên kết để phá vỡ các liên kết nhiều nhiều thành các liên kết một nhiều nhưng khi đó mô hình đối tượng sẽ không nhận ra bảng này.
Bây giờ giả sử thông tin người dùng phải có địa chỉ, ta có biểu đồ sau:
Hình 4-23 Biểu đồ lớp được làm phức tạp hơn
Theo mô hình trên, có hai cách lựa chọn để ánh xạ trong trường hợp này. Thứ nhất, lưu thông tin về địa chỉ thành các trường khác nhau trong bảng người dùng. Thứ hai, chúng ta tạo một kiểu địa chỉ mới và chỉ tạo một trường trong bảng người dùng. Lúc này, xảy ra vấn đề khai báo một kiểu mới trong cơ sở dữ liệu. Cách làm này rõ ràng không được hỗ trợ nhiều bởi hệ quản trị cơ sở dữ liệu quan hệ. Mặt khác, nếu chúng ta sử dụng phương pháp thứ nhất thì chắc chắn dư thừa dữ liệu là điều không thể tránh khỏi.
Tóm lại, khá nhiều vấn đề không tương thích giữa hai mô hình khi thực hiện ánh xạ sự kết hợp giữa hai mô hình.
b. Ánh xạ thừa kế
Ta lại làm cho vấn phức tạp hơn khi hệ thống của chúng ta chấp nhận thanh toán ở nhiều hình thức hơn, bằng CreditCard và BankAccount. Khi đó biểu đồ lớp có thể vẽ lại như sau:
Hình 4-24 Biểu đồ lớp có thừa kế
Vấn đề đặt ra là ánh xạ một cây thừa kế như trên vào cơ sở dữ liệu như thế nào, khi mà vấn đề kế thừa không được cài đặt trong hệ quản trị cơ sở dữ liệu quan hệ chúng ta đang dùng. Có nhiều cách để giải quyết vấn đề này như ánh xạ kiểu “table per concrete class”, “table per class hierarchy”, “table per subclass”. Với những ứng dụng khác nhau, việc lựa chọn các chiến lược cụ thể khác nhau sẽ dẫn đến hiệu năng khác nhau cho thực hiện ứng dụng. Chúng sẽ quay lại vấn đề này ở phần II của bài viết và tìm hiểu cách giải quyết cụ thể.
c. Vấn đề duyệt đồ thị đối tượng
Cách thức chúng ta duyệt các đối tượng trong một ngôn ngữ lập trình hướng đối tượng và trong cơ sở dữ liệu quan hệ là khác nhau. Trong việc truy cập dữ liệu hướng đối tượng, chúng ta đi từ đối tượng tới thuộc tính của đối tượng đó hay đi từ đối tượng này tới đối tượng khác để đạt được dữ liệu mà chúng ta mong muốn. Thế nhưng, cách làm này không thực hiện được trong việc truy cập cơ sở dữ liệu quan hệ. Cách mà chúng ta thường làm là thực hiện phép kết nối các bảng. Số lượng các phép kết nối giữa các bảng mà chúng ta quan tâm sẽ quyết định số đối tượng trong biểu đồ lớp mà chúng ta phải duyệt qua, do đó nó quyết định số lần chúng ta yêu cầu tới cơ sở dữ liệu. Mặt khác, khi thực hiện ánh xạ đối tượng/quan hệ, số lần chúng ta truy cập tới một bảng là số lần chúng ta thực hiện phép chọn tới đối tượng đó. Vì vậy, nó đưa ra một vấn đề mà người ta gọi là n + 1 phép chọn. Vấn đề này ảnh hưởng tới hiệu năng của hệ thống.
d. Vấn dề Entity/Identity
Giả sử chúng ta xem xét đồng thời hai đối tượng, ví dụ, hai Users và kiểm tra xem chúng có đồng nhất hay không. Có ba cách để thực hiện vấn đề này, hai
cách trong ứng dụng của chúng ta và một cách trong cơ sở dữ liệu. Có hai cách để hiểu thế nào là hai đối tượng giống nhau bằng: Object Identity (Được xác định bằng toán tử ==)
Object Equality. (Được xách dịnh bằng phương thức equals() ).
Mặt khác, tính đơn nhất của một hàng trong cơ sở dữ liệu được đảm bảo bằng khóa chính.
Người phát triển hiểu sự khác nhau giữa object identity và object equality. Khi so sánh Object identity, ==, được định nghĩa bởi máy ảo Java, hai đối tượng cùng tham chiếu đến một địa chỉ bộ nhớ thì chúng như nhau.
Mặt khác Object equality được định nghĩa bởi các lớp cài đặt phương thức equals(), tỉnh thoảng được hiểu như là tương đương. Tương đương nghĩa là các đối tượng
object/relation persistencem, một đối tượng trong bộ nhớ biểu diễn một hàng đặc biệt của cơ sở dữ liệu. Vì thế, theo Java Identity và object equality, chúng ta lấy về database identity (adsbygoogle = window.adsbygoogle || []).push({});
e. Tóm tắt
Trên đây, chúng ta đã liệt kê ra các vấn đề cơ bản không tương thích khi nhìn dữ liệu hệ thống dưới hai mô hình khác nhau là mô hình hướng đối tượng và mô hình quan hệ. Công việc mà chúng ta quan tâm nhất là thực hiện persistence cho các đối tượng từ mô hình đối tượng vào mô hình quan hệ như thế nào. Ở phần 4.2.2 của bài viết này tôi sẽ giới thiệu một công cụ cho phép tự động thực hiện công việc này, đó là công cụ Hibernate.