III. Quy trình phân tích hệ thống thông tin quản lý
4. Mô hình hóa và chuẩn hóa dữ liệu
4.3. Nâng cao chất lượng của mô hình dữ liệu
Để có được một mô hình dữ liệu hoàn hảo thì phải tốn thời gian. Khách hàng phải giải thích vấn đề một cách đầy đủ sao cho người thiết kế có thể hiểu rõ mọi yêu cầu của khách hàng nhằm thiết kế được một mô hình đáp ứng yêu cầu đó. Mô hình hóa dữ liệu giống như một quá trình thử nghiệm và cải biến dần: cán bộ thiết kế dần dần tạo ra một mô hình của CSDL nhờ sự tiếp xúc và trao đổi thường xuyên với khách hàng. Đôi khi mô hình dữ liệu bộc lộ những thiếu sót nghiêm trọng khiến nhà thiết kế phải thay đổi hàng loạt. Sau đây là một số gợi ý để nâng cao chất lượng của mô hình dữ liệu và giảm bớt những sự sửa đổi không đáng phải tiến hành.
a. Mở rộng hay thu hẹp mô hình dữ liệu
Mô hình dữ liệu có thể mở rộng và có thể thu hẹp được. Mô hình dữ liệu sẽ được mở rộng khi ta tăng phạm vi ứng dụng, bổ sung thực thể, thuộc tính và các mối quan hệ để bao trùm cả các trường hợp ngoại lệ. Nói chung, các mô hình dữ liệu thường lớn dần lên, có khi gấp hai ba lần quy mô ban đầu, bởi vì nó cần phản ánh độ phức tạp của thực tế mà người thiết kế không dễ gì nhận thức được đầy đủ ngay từ đầu. Đừng cố ý hạn chế sự tăng trưởng của mô hình dữ liệu mà hãy để cho nó lớn lên đến mức cần thiết. Một mô hình dữ liệu có thể thu hẹp lại khi ta tổng quát hóa các thực thể của nó. Mô hình cũng được thu hẹp khi ta có những cải tiến để biểu diễn các quan hệ một cách đáng tin cậy đúng đắn và ít vụng về hơn. Sau đây là một vài ví dụ về sự cải biến mô hình dữ liệu: Ví dụ 1: Xét trường hợp một công ty có những phòng ban và những tổ đội. Một phòng ban có nhiều tổ đội nhưng mỗi tổ đội chỉ thuộc về một phòng ban. Thoạt đầu, giả sử công ty chỉ cho phép mỗi cán bộ công nhân viên (CBCNV) làm
việc trong một tổ đội duy nhất. Mô hình dữ liệu phản ánh cơ cấu tổ chức theo công việc của công ty được thể hiện như ở hình sau:
Mô hình cơ cấu tổ chức theo công việc
Trong suốt thời kì làm việc cho công ty, một CBCNV có thể thuyên chuyển từ bộ phận này sang bộ phận khác. Thậm chí, công ty có thể thay đổi chủ trương, cho phép một người đồng thời kiêm nhiệm ở nhiều bộ phận. Muốn ghi nhận cả lịch sử, tức là việc làm trong quá khứ, và thể hiện được chủ trương mới của công ty thì cần mở rộng mô hình. Vì một tổ có nhiều CBCNV và một CBCNV có thể làm việc cho nhiều tổ nên ta có quan hệ m:m giữa tổ và CBCNV . Cần có một thực thể giao để biểu diễn mối quan hệ này, ta gọi nó là một thực thể Chuc_vu. Mỗi hiện diện của thực thể, tức là mỗi chức vụ mà CBCNV nào đó đảm nhiệm được xác định duy nhất bởi ngày bắt đầu, kết hợp với mã tổ và mã CBCNV như hình sau:
Mô hình cơ cấu tổ chức theo công việc- Phiên bản 2
Bây giờ ta lại muốn theo dõi các khoản tiền công đã trả cho CBCNV. Một người có nhiều phiếu trả lương (Pay Slip) nhưng mỗi phiếu chỉ thuộc vể một người. Mỗi phiếu trả lương có nhiều dòng ghi tổng lương và các khoản khấu trừ như bảo hiểm y tế, bảo hiểm xã hội… Các dòng của phiếu trả lương tương tự như những dòng của một hóa đơn; mỗi dòng chỉ thuộc về một phiếu. Một lần nữa, mô hình lại được mở rộng như hình sau:
Mô hình cơ cấu tổ chức theo công việc (phiên bản 3)
b. Yếu tố phân biệt – Thực thể độc lập và thực thể phụ thuộc
Nếu không có một yếu tố phân biệt rõ ràng và đơn giản nào thì hãy sáng tạo ra một yếu tố hay nhờ hệ QTCSDL tạo ra. Đơn giản nhất là dùng một mã ngắn gọn làm yếu tố phân biệt. Nếu ta tự tạo ra một yếu tố phân biệt thì cần đảm bảo cho nó có giá trị trùng lặp đối với các cá thể khác nhau.
Đừng chất đầy thông tin vào một yếu tố phân biệt làm cho nó quá tải. Có công ty chất dẻo đã từng đặt ra mã sản phẩm một cách duy nhất mà không còn chỉ ra màu sắc, loại nguyên liệu tạo nên sản phẩm…Màu sắc và loại nguyên liệu đều là những thuộc tính. Nếu mã quá dài thì dễ mắc phải lỗi khi nạp dữ liệu và ít người có thể nhớ cách giải mã để biết được ý nghĩa đầy đủ của nó.
Một yếu tố phân biệt chỉ có một nhiệm vụ là xác định duy nhất từng cá thể. Việc chất thêm gánh nặng cho nó sẽ làm nảy sinh những công việc đáng lẽ không cần làm.
Thực thể độc lập hay phụ thuộc: Một thực thể khác phải dựa vào một thực thể khác để tồn tại hay để được xác định một cách duy nhất thì được gọi là thực thể phụ thuộc. Chẳng hạn, giả sử trong một nhà máy có
nhiều phân xưởng, mỗi phân xưởng có những tổ sản xuất. Các phân xưởng có những tên khác nhau nhưng các tổ trong một phân xưởng thì chỉ được đánh số là 1, 2, 3… Khi đó phải dựa vào tên phân xưởng thì mới phân biệt được các tổ ở những phân xưởng khác nhau, bởi thế tổ trở thành thực thể phụ thuộc vào Phan xưởng còn Phân xưởng là thực thể độc lập.
Khái niệm độc lập hay phụ thuộc chỉ là tương đối bởi vì: Nếu đặt cho mỗi tổ một tên sao cho không có hai tổ nào trong nhà máy trùng nhau đồng thời cho phép một số tổ trực thuộc ban giám đốc chứ không trực thuộc về phân xưởng nào thì tổ sẽ trở thành thực thể độc lập.
c. Vị trí và trật tự
Trong mô hình dữ liệu không có quy định gì về vị trí và thứ tự xuất hiện của các thực thể. Tuy nhiên, thực thể nào có nhiều quan hệ với nhiều thực thể khác thì nên đứng giữa để dễ vẽ và khiến cho mô hình gọn đẹp hơn .
Các thuộc tính của một thực thể cũng có thể được liệt kê theo thứ tự tùy ý. Tuy nhiên nên sắp xếp liên tiếp các thuộc tính có liên quan với nhau. Chẳng hạn, họ đệm (họ và chữ lót) nên đứng ngay trước tên.
Các cá thể tức các dòng trong bảng cũng không cần được nạp và theo thứ tự nào cả. Có nhiều phương tiện dễ dàng xử lý các dòng theo một trình tự nào đó; mệnh đề order by của SQL chính là một trong những phương tiện đó.
d. Thực thể chỉ có một cá thể
Đừng dè dặt khi tạo ra một thực thể chỉ có một cá thể. Xét mô hình dữ liệu sau để quản lý dữ liệu về các máy điện thoại.
Công ty điện thoại độc quyền
Vì Việt Nam chỉ có một công ty điện thoại độc quyền là “Công ty Bưu chính Viễn thông” nên thực thể Cong_ty chỉ có một cá thể. Việc đưa thực thể
này vào mô hình khiến cho sự kiện về công ty được ghi nhận. Hơn nữa nếu sau này nhà nước huỷ bỏ chế độ độc quyền thì sẽ xuất hiện thêm nhiều công ty điện thoại khác nữa, lúc đó không cần phải sửa đổi mô hình dữ liệu.
e. Chú ý tới các trường ngoại lệ
Luôn thăm dò và phát hiện các trường hợp ngoại lệ để thiết kế lại mô hình nhằm xử lý được cả những trường hợp đó. Mô hình càng bao trùm được nhiều trường hợp ngoại lệ thì càng có độ trung thực cao. Để phát hiện được những trường hợp ngoại lệ thì hãy luôn luôn hỏi khách hàng những câu hỏi tương tự như sau:
- Có phải lúc nào cũng như vật không ?
- Liệu có tình huống nào khiến cho mối quan hệ này trở thành nhiều – nhiều hay không ?
- Trong tương lai có giữ ngyên quy định đó không ? - Đã có trường hợp nào bất thường xảy ra hay chưa?
f. Tham khảo các mô hình dữ liệu đã từng được sử dụng
Một mô hình đã từng được sử dụng chắc chắn sẽ có một độ trung thực khá cao vì nó đã trải qua nhiều lần sàng lọc và sửa đổi. Việc thừa kế có chọn lọc những di sản của một mô hình dữ liệu cũ sẽ tốt hơn so với việc thiết kế một mô hình mới hoàn toàn.