Đối tượng và thuộc tính trong phân tích và thiết kế CSDL – thinking … it

Đối tượng là gì?

Trong mô hình quan hệ, với thành phần bảng (tables) chúng ta có thể dùng nhiều từ ngữ để diễn đạt nội dung của nó như: quan hệ, bảng, thực thể,…Để tổng quát và phù hợp hơn với thực tế cuộc sống, chúng ta sẽ gọi đó là các đối tượng. Như chúng ta đều biết CSDL quan hệ là một hệ thống xâu chuỗi các đối tượng có quan hệ với nhau với mục đích mô tả, sắp xếp lại những thông tin hiện hữu hoặc phát sinh qua các hoạt động thực tế trong một lĩnh vực nào đó. Nếu xét toàn bộ thế giới thực thì có vô số các đối tượng và dường như là điều không tưởng nếu chúng ta có ý muốn mô tả vô số đối tượng đó trong cùng một lược đồ quan hệ. Xét trên từng lĩnh vực riêng, phạm vi có giới hạn thì số đối tượng mà chúng ta quan tâm sẽ ít hơn và có thể mô tả được trong một lược đồ quan hệ nào đó. Ví dụ với lĩnh vực quản lý nhân sự trong một tổ chức, doanh nghiệp, chúng ta hoàn toàn có thể xây dựng một mô hình quan hệ với một số đối tượng hữu hạn như: Cá nhân, phòng ban, chức vụ, công việc, hợp đồng,…Dĩ nhiên, lúc này đây, chúng ta sẽ khó khăn và có thể không xác định được đầy đủ các đối tượng này.

Xác định các đối tượng sẽ có mặt trong một mô hình quan hệ là một quá trình phức tạp đòi hỏi nhiều suy nghĩ, cân nhắc và những bước phân tích thông tin hợp lý. Điều này có thể tương đối dễ dàng hơn khi chúng ta đã có nhiều kinh nghiệm thiết kế hệ thống cũng như có một quá trình tiếp xúc lâu dài với các công việc thực tế. Ví dụ thế này, với yêu cầu liệt kê những đối tượng cần để quản lý các đơn hàng, một sinh viên mới nghiên cứu về CSDL quan hệ ắt sẽ gặp nhiều vướng mắc hơn một chuyên gia thiết kế CSDL đã có mười năm kinh nghiệm.

Đối tượng chính yếu và bổ sung

Khi chúng ta tìm hiểu và liệt kê các đối tượng có thể xuất hiện trong một mô hình quan hệ nào đó, chúng ta thường quan tâm đến những đối tượng trực quan trước, còn những đối tượng khá trừu tượng hoặc mang tính chất bổ sung thông tin thường được xét đến sau cùng. Ví dụ: khi có yêu cầu liệt kê các đối tượng có thể có trong mô hình dữ liệu mô tả quan hệ giữa thành viên và dự án, có lẽ 2 đối tượng đầu tiên chúng ta quan tâm là: “Thành viên” (các cá nhân) và “Dự án” (danh sách các dự án), rồi sau đó những đối tượng khác mới lần lượt xuất hiện: chức danh, loại dự án, công việc,…

Việc xác định được các đối tượng chính trong một mô hình quan hệ là rất quan trọng, bởi khi xác định được chính xác, đầy đủ những đối tượng này thì mục đích thiết kế mà mô hình hướng đến sẽ trở nên rõ ràng hơn và từ đó, chúng ta có thể định hướng đúng đắn con đường tiếp theo của mình. Có một số kỹ thuật khả dĩ giúp chúng ta nhận biết được những đối tượng chính trong một mô hình quan hệ. Tuy nhiên chúng ta sẽ xét kỹ vấn đề này ở phần phân tích thiết kế. Ở đây, chỉ nếu lên một kỹ thuật nhận biết khá đơn giản để chúng ta có thể hình dung rõ hơn về các đối tượng chính yếu.

Khi bắt tay vào quá trình phân tích thiết kế một mô hình quan hệ nào đó, dĩ nhiên là một mô hình mô tả về thế giới thực tế xung quanh mình, chúng ta thường gọi tên, đặt tên cho mô hình, đây là một điều hết sức bình thường, và trở thành một thói quen không bắt buộc nhưng luôn luôn xuất hiện. Việc đặt tên lại thường hướng đến những nghiệp vụ quản lý mà mô hình quan hệ hướng đến. Ví dụ: mô hình quan hệ quản lý nhân sự, mô hình quan hệ quản lý bán hàng, mô hình quan hệ quản lý tài sản thiết bị,… Ít ai và dường như không có ai lại đặt tên cho mô hình quan hệ quản lý nhân sự bằng tên gọi: mô hình quan hệ quản lý hệ thống bán vé máy bay. Kỹ thuật nhỏ ở đây đó là dựa vào tên gọi và các hình ảnh trực quan xuất hiện từ những tên gọi đó. Với tên gọi, quản lý nhân sự, đầu tiên sẽ khởi lên trong chúng ta một số đối tượng chính như: Con người (Cá nhân), Công việc (sự) và một hình ảnh trực quan khác sẽ xuất hiện: tổ chức (Con người làm việc trong tổ chức),…

Các đối tượng bổ sung thường được quan tâm như là một thành phần vây quanh đối tượng chính yếu với mục đích là làm sáng rõ hơn đối tượng chính yếu và chi tiết hơn các yêu cầu quản lý mà mô hình quan hệ hướng đến. Ví dụ như hình vẽ trên, với đối tượng chính là “Thành viên” thì có thể xuất hiện hàng loạt các đối tượng bổ sung như: chuyên môn – nghiệp vụ, trình độ học vấn, tôn giáo, nơi sinh của từng thành viên. Đối tượng bổ sung thường rất nhiều, nhưng để sự phù hợp với phạm vi mà mô hình quan hệ quan tâm thì số lượng đối tượng bổ sung cũng sẽ nằm trong một giới hạn nhất định.

Đối tượng danh từ và động từ

Danh từ và động từ là hai khái niệm của ngôn ngữ học. Trước khi tìm hiểu thế nào là đối tượng danh từ, đối tượng động từ chúng ta thử xét qua đặc điểm của danh từ động từ và mối quan hệ danh từ – động từ (cụm động từ) – danh từ. Ta thử lấy ví dụ về quan hệ này theo câu văn: “Cái nồi vo gạo”. Ở đây, Cái nồi là và Gạo là hai danh từ, “vo” là một động từ. Trong thực tế, có rất nhiều cấu trúc tương tự, những cấu trúc này thường dùng để liên kết, mô tả những quan hệ nảy sinh trong một hoàn cảnh nào đó giữa các danh từ thông qua một số động từ hoặc cụm động từ.

Chúng ta tìm hiểu về CSDL, về mô hình quan hệ cũng là tìm hiểu về các đối tượng trong thực tế. Như ví dụ ở trên, “Cái nồi”, “Gạo” là danh từ, “vo” là động từ và đó là những mô tả thực tế của thế giới thực. Trong mô hình quan hệ, chúng ta quan tâm đến một khái niệm khá trừu tượng: các đối tượng, các thực thể. Thế thì, giả sử có yêu cầu thiết kế mô hình quan hệ mô tả quá trình nấu cơm, lúc này, nếu ta gọi “Cái nồi” là một danh từ thì vẫn được, nhưng sẽ không phù hợp lắm với lĩnh vực tìm hiểu của chúng ta. Từ đó, một cụm từ xuất hiện có thể diễn đạt được hoàn cảnh thực tế nhưng đồng thời cũng rất phù hợp với lĩnh vực thiết kế CSDL là: “Đối tượng danh từ”, và tương tự như thế, ta có “đối tượng động từ”.

Chúng ta phân tích như trên để hướng đến một vấn đề rất quan trọng trong quá trình thiết kế CSDL đó là việc xác định các đối tượng danh từ, đối tượng động từ có thể có trong một mô hình quan hệ. Trong thực tế, nếu chúng ta tìm hiểu kỹ các mô hình quan hệ thì tất cả các đối tượng trong mô hình có thể nhóm thành 2 loại đối tượng: đối tượng danh từ và đối tượng động từ. Đối tượng động từ thường là kết quả của việc suy diễn, phân tích yêu cầu quản lý của các đối tượng danh từ.

Để minh họa cụ thể cho vấn đề này, chúng ta thử xét ví dụ về các đối tượng động từ xuất hiện giữa 2 đối tượng danh từ là Thiết bị và Cá nhân. Với phạm vi phân tích của mô hình được xác định theo các nghiệp vụ quản lý tài sản thiết bị trong một doanh nghiệp:

Ta có thể diễn giải sơ đồ trên bằng các nghiệp vụ quản lý thực tế như sau:

• Người nào có trách nhiệm mua thiết bị về
• Ai là người sử dụng thiết bị
• Người nào được phân công theo dõi quá trình hoạt động của thiết bị

Như vậy giữa 2 đối tượng Thiết bị và Cá nhân (là những đối tượng danh từ), đã xuất hiện ba đối tượng động từ nhằm thể hiện những yêu cầu quản lý thực tế: Mua, Sử dụng, Theo dõi. Tất nhiên số lượng đối tượng động từ có thể còn nhiều hơn, tùy theo từng hoàn cảnh. Ta có thể liệt kê thêm rất nhiều: Sửa chữa (những ai tham gia sửa chữa thiết bị), thanh lý (thanh lý thiết bị cho ai),…

Các đối tượng tương tự nhau

Thuộc tính

Khi chúng ta tìm hiểu một mô hình quan hệ, cụ thể hơn khi xét đến một đối tượng, chúng ta thường nghĩ ngay đến những mô tả, đặc điểm, tính chất của đối tượng. Ví dụ: với đối tượng Cá nhân, chúng ta ngay lập tức sẽ nghĩ đến họ tên, ngày sinh, giới tính,…Trong thực tế, bất cứ một đối tượng nào cũng có những đặc điểm giúp chúng ta có thể hiểu rõ hơn về chúng, trong mô hình quan hệ cũng thế, các đối tượng luôn luôn tồn tại ít nhất là một đặc điểm. Thuật ngữ thuộc tính dùng để chỉ những mô tả, đặc điểm và tính chất của đối tượng.

Tập hợp các thuộc tính của một đối tượng không cố định đối với mỗi mô hình quan hệ. Chúng phụ thuộc vào mục đích và phạm vi quản lý thực tế mà mô hình quan hệ xét đến. Ví dụ, trong mô hình quản lý nhân sự, có thể cần mô tả thuộc tính “Tôn giáo” của đối tượng “Cá nhân”, nhưng trong mô hình quản lý bán hàng đối tượng “Cá nhân” (người bán hàng), có thể không quan tâm đến thuộc tính “Tôn giáo” này. Với một đối tượng thực tế, chúng ta có thể liệt kê rất nhiều thuộc tính của nó, nhưng nếu không có sự giới hạn về mục đích và phạm vi quản lý đối tượng, thì lượng thông tin để mô tả các thuộc tính của đối tượng sẽ rất lớn, “kích thước” về mặt vật lý lẫn dữ liệu của mô hình cũng sẽ bùng nổ theo. Đó là một điều cần chú ý trong quá trình phân tích và thiết kế các mô hình dữ liệu quan hệ.

Chúng ta thử quan sát màn hình làm việc thực tế của một nhân viên quản lý sản phẩm, trong một doanh nghiệp nào đó. Các ô dữ liệu là những ký tự, hình ảnh mô tả cho thông tin của sản phẩm, trong mô hình quan hệ mà chúng ta đang tìm hiểu thì những ô dữ liệu đó là sự trình bày một cách trực quan các thuộc tính của đối tượng sản phẩm. Có lẽ màn hình này đã hơi làm rối mắt chúng ta và sẽ rối hơn khi có thêm mười thuộc tính nữa được mô tả ở trong này. Trong khi bất kỳ một sản phẩm thuộc chủng loại nào, nếu không có sự giới hạn có thể có đến hàng chục, hàng trăm thậm chí hàng ngàn thuộc tính. Chúng ta thử nghĩ xem chuyện gì sẽ xảy ra!

Bản thân mỗi thuộc tính cũng có những yêu cầu quản lý khác nhau trong từng mô hình quan hệ. Sự khác nhau đó có thể do chủ quan của người thiết kế, cũng có thể do yêu cầu khách hàng của mô hình hoặc của người sử dụng CSDL. Ví dụ chúng ta xét thuộc tính “địa chỉ liên lạc” của đối tượng “thành viên”. Trong một số mô hình, thuộc tính “địa chỉ liên lạc” chỉ đơn giản là một chuỗi ký tự mô tả số nhà, đường phố, quận huyện,…của một người nào đó, ví như: “số 112, đường Nguyễn Đình Chiểu, phường 4, quận 3, thành phố Hồ Chí Minh”. Tuy nhiên, trong một số mô hình, với yêu cầu quản lý thông tin “địa chỉ” một cách chi tiết hơn, có thể, thuộc tính địa chỉ sẽ là sự kết hợp của những thuộc tính con của nó. Khi đó, trong đối tượng “Thành viên” sẽ có các thuộc tính: {Số nhà, Đường phố, Phường (Xã), Quận (Huyện), Tỉnh (Thành phố)} thay cho thuộc tính “địa chỉ liên lạc”.

Để phân biệt đối tượng này với đối tượng khác, chúng ta phải nắm rõ thuộc tính của đối tượng. Thường thì mỗi đối tượng sẽ có một hoặc một nhóm thuộc tính nào đó mang tính đặt trưng có thể giúp ta nhận biết được đối tượng.

Thuộc tính tự nhiên

Trong thực tế, các đối tượng thường có một số thuộc tính mà tự bản thân nó được chúng ta nhận biết một cách tự nhiên. Tự nhiên ở đây có nghĩa là không phải qua nhiều bước phân tích phức tạp, mà biết được một cách đơn giản, như tự nó là thế. Ví dụ, với đối tượng: “Cây”, một số thuộc tính của nó như: rễ, thân, lá,…là những thuộc tính mang tính tự nhiên.

Các thuộc tính tự nhiên có vai trò rất quan trọng trong việc mô tả đối tượng, bởi khi sử dụng các thuộc tính này, chúng ta sẽ hạn chế được những nhận định không chính xác về các thuộc tính được định nghĩa theo chủ quan và yêu cầu quản lý của mô hình quan hệ.

Thuộc tính khóa

Như chúng ta đã biết, trong một đối tượng có thể có một hoặc nhiều thuộc tính. Khái niệm này được cụ thể hơn trong mô hình dữ quan hệ: một bảng có thể có một hoặc nhiều cột. Thuộc tính khóa là thuộc tính chỉ rõ tính duy nhất của mỗi dòng (bộ) dữ liệu trong cùng một bảng. Nghĩa là, trong một bảng, không tồn tại bất cứ hai dòng dữ liệu nào giống hệt nhau. Có thể thông tin của các thuộc tính khác tương tự nhau, nhưng thông tin chứa đựng trong thuộc tính khóa phải khác nhau. Ví dụ, bảng dữ liệu sau (với thuộc tính EmployeeID làm khóa) là không tồn tại trong mô hình dữ liệu quan hệ nào:

Trong một bảng, có thể có một hoặc tập hợp một số thuộc tính tạo thành khóa. Chúng ta hay dùng cụm từ “Khóa ứng viên” (candicate key) để mô tả chúng. Trường hợp khóa chỉ có một thuộc tính thì gọi là khóa đơn (simple key), trường hợp khóa ứng viên có nhiều thuộc tính gọi là khóa phức hợp (composite key). Trong thực tế, có bảng chỉ có một khóa ứng viên, nhưng cũng có bảng có nhiều khóa ứng viên và bất cứ khóa ứng viên nào cũng phải xác định được tính duy nhất của từng bộ dữ liệu. Tuy nhiên, cần phải có thêm một yêu cầu nữa đối với khái niệm khóa ứng viên đó là phải loại bỏ những thuộc tính không cần thiết có thể xuất hiện trong một tập thuộc tính có thể làm khóa ứng viên. Chúng ta xét ví dụ sau:

Xét bảng dữ liệu Khách hàng (Customers) với các thuộc tính: CustomerID (Mã khách hàng), CustomerName (Tên khách hàng), Address (Địa chỉ), City (Thành phố).

Ở đây, CustomerID là một khóa ứng viên. Trong khi đó tập thuộc tính {CustomerID, CustomerName}, hoặc kể cả tập thuộc tính {CustomerID, CustomerName, Address}, mặc dù cũng xác định được tính duy nhất của các bộ dữ liệu, nhưng chúng không phải là các khóa ứng viên, bởi lẽ thuộc tính CustomerName, Address là không cần thiết.

Thuộc tính quan trọng và bổ sung

Cũng tương tự như các đối tượng trong một mô hình quan hệ, các thuộc tính của một đối tượng cũng có thể được gom vào hai nhóm: nhóm các thuộc tính quan trọng và nhóm các thuộc tính mang tính chất bổ sung. Thường thì đã là thuộc tính của một đối tượng, thì mỗi thuộc tính đều có vai trò và nội dung riêng, trong một hoàn cảnh và yêu cầu nào đó, tầm quan trọng của nó sẽ được xác định cụ thể. Ví dụ, với đối tượng đơn hàng, các thuộc tính OrderID (Mã đơn hàng), OrderDate (Ngày đặt hàng), ExpiredDate (Ngày hết hạn),…thường được xem là những thuộc tính quan trọng, bên cạnh đó có một số thuộc tính như: CreateEmployee (Người lập đơn hàng), OrderDesc (thông tin diễn giải thêm) được xem là các thông tin bổ sung.

Xét về mặt thực tế, tầm quan trọng của thuộc tính tùy thuộc vào yêu cầu quản lý. Còn xét về mặt cấu trúc và yêu cầu của mô hình quan hệ, tầm quan trọng của thuộc tính được xác định qua các yếu tố như: thuộc tính khóa hay không khóa, dữ liệu của thuộc tính luôn luôn phải được mô tả cụ thể hay không cần, thuộc tính này có thể có cũng được, nếu không có thì không ảnh hưởng nhiều đến mô hình,…

Việc xác định hợp lý các thuộc tính quan trọng và các thuộc tính bổ sung thường sẽ giúp cho mô hình quan hệ rõ ràng, phù hợp với nhu cầu quản lý thực tế. Thuộc tính quan trọng sẽ giúp chúng ta mô tả được đối tượng một cách chính xác, thuộc tính bổ sung sẽ giúp cho thông tin của đối tượng được trình bày vừa đủ. Điều này sẽ làm cho các đối tượng không bị cồng kềnh, hay dư thừa các thông tin không cần thiết. Và xa hơn sẽ giúp cho người dùng không bị rối và choáng ngợp trước quá nhiều dữ liệu có trong thực tế nhưng xa lạ với nghiệp vụ quản lý của họ.

Ràng buộc trên thuộc tính và giữa các thuộc tính

Trong một mô hình quan hệ, bên cạnh các liên kết mô tả quan hệ giữa các đối tượng, trong mỗi đối tượng cũng có những quan hệ được xác lập giữa các thuộc tính, kèm theo đó là những ràng buộc được xác định trên từng thuộc tính và giữa các thuộc tính với nhau. Những ràng buộc này được đặt ra do yêu cầu về tính hợp lý của các bộ dữ liệu nhằm hạn chế những vấn đề không phù hợp với thực tế. Ví dụ xét 2 bảng dữ liệu: Orders (Đơn hàng) và OrderDetail (Chi tiết đơn hàng). Một điều tồn tại hiển nhiên trong thực tế đó là ngày đặt hàng (OrderDate) luôn luôn diễn ra trước ngày giao hàng (ExpiredDate), ràng buộc này cần phải mô tả vào mô hình quan hệ cụ thể là 2 thuộc tính trong bảng Orders: OrderDate phải trước ExpiredDate. Đó chỉ là một ví dụ đơn giản và thường thấy trong việc mô tả ràng buộc giữa các thuộc tính, trường hợp này là ràng buộc giữa các thuộc tính trong cùng một đối tượng. Có một số trường hợp, thuộc tính giữa hai đối tượng khác nhau cũng có khi được đặt trong một ràng buộc nào đó.

Với thông tin số lượng sản phẩm được đặt hàng (Quantity), vì thực tế số lượng đặt hàng là một giá trị nguyên và lớn hơn 0, vì thế, chúng ta phải gán ràng buộc này cho thuộc tính Quantity, cụ thể là qui định kiểu dữ liệu là Integer (Số nguyên) và có giá trị lớn hơn 0 (mặc dù 0 vẫn có nghĩa nhưng điều này dường như không xảy ra trong thực tế).

Từ đây, nảy sinh ra một số ràng buộc khác trên từng thuộc tính đó là sẽ có những thuộc tính bắt buộc phải có giá trị, và ngược lại. Khái niệm thuộc tính không lưu trữ giá trị nào (null) để mô tả.

Đối tượng và thuộc tính (Entity – Attribute (Table – Field)) là hai khái niệm quan trọng trong phân tích và thiết kế CSDL. Nắm vững thông tin của đối tượng và thuộc tính sẽ giúp cho người thiết kế có thể làm nên một CSDL tốt. Ngôn ngữ là lĩnh vực thường thường được nhiều người gắn kết với văn học hoặc các ngành khoa học xã hội, tuy nhiên, trong trường hợp xây dựng và phát triển các mô hình cơ sở dữ liệu, việc sử dụng ngôn ngữ khéo léo, hợp thời, có thể giúp cho các cơ sở dữ liệu trở nên rõ ràng, chính xác hơn rất nhiều. Đó cũng chính là cái nền tảng rất cơ bản để những lập trình viên hoặc các chuyên gia phần mềm có thêm những ý niệm để phát triển sản phẩm trong chuỗi quá trình làm ra những phần mềm ứng dụng phục vụ nhu cầu đa dạng của con người.

08/2008

Mai Thế Hùng