Vẽ các mối quan hệ
Cũng có bằng 28 ngôn ngữ khác
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Mô-đun 2 trong 6 của chương Mô hình hóa dữ liệu vì ý nghĩa, chương 2 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Lắng nghe các danh từ · Tiếp theo: Xây dựng mô hình logic
Câu hỏi mô-đun này trả lời: Làm sao biến các thực thể ứng viên thành một mô hình dữ liệu khái niệm?
Chúng ta đã có các danh từ trên bảng. Giờ tôi muốn biết về những đường nối giữa các hộp, vì một tập hợp thực thể thì chưa thực sự là một mô hình dữ liệu. Phần lớn ý nghĩa nằm ở các quan hệ. Một Đối tác bán lẻ vận hành các trung tâm phân phối. Một bảng kê hàng liệt kê các lần giao. Một lần giao đi đến một Người nhận. Một tổ giao hàng chạy một xe tải. Mỗi câu đó cho tôi biết một điều về việc kinh doanh, và mỗi câu cho tôi thêm một câu hỏi để hỏi.
Bắt đầu bằng ngôn ngữ nghiệp vụ
Phần tiêu đề “Bắt đầu bằng ngôn ngữ nghiệp vụ ”Tôi vẫn chưa muốn nói về Salesforce. Tôi không hỏi đây nên là quan hệ tra cứu hay chính-chi tiết, không nghĩ đến đối tượng nối của Salesforce (Salesforce Junction Object), cũng không quyết định điều gì xảy ra khi một bản ghi cha bị xóa. Tôi đang cố hiểu quan hệ nghiệp vụ.
Hãy lấy câu “một Đối tác bán lẻ vận hành các trung tâm phân phối”. Nghe đơn giản. Nhưng một Đối tác bán lẻ có thể có một DC hay nhiều DC? Ở Steve Trucking, mỗi Đối tác bán lẻ vận hành một trung tâm phân phối khu vực ở mỗi vùng Steve Trucking phục vụ, vậy là nhiều. Một DC có thể thuộc về nhiều hơn một Đối tác bán lẻ không? Một DC có quan trọng tự thân, với nhân sự và lịch sử riêng, hay chỉ là một địa chỉ? Nếu một Đối tác bán lẻ rời đi, chúng ta có còn quan tâm đến các DC của họ không?
Đó không phải là câu hỏi về Salesforce. Đó là câu hỏi nghiệp vụ, và câu trả lời có thể thay đổi hoàn toàn mô hình.
Đọc các đường nối
Phần tiêu đề “Đọc các đường nối ”Trước khi đi sâu hơn, tôi muốn đưa cho bạn ngôn ngữ chúng ta sẽ dùng trên mọi sơ đồ từ đây trở đi. Nó rất nhỏ. Một đường nối giữa hai hộp nói rằng hai thứ có liên quan, và các ký hiệu ở hai đầu nói bao nhiêu.
Hãy bắt đầu với một đường đơn giản, không có ký hiệu nào. Đó là chỗ tôi bắt đầu trên bảng trắng: tôi biết hai danh từ này có liên quan, chỉ là chưa hỏi liên quan thế nào. Rồi các đầu được thêm ký hiệu. Một vạch ngang cắt qua đường nghĩa là một. Chân quạ, đầu tách thành ba như chân chim, nghĩa là nhiều. Ở phần sau của mô-đun này bạn sẽ thấy một ký hiệu thứ hai xuất hiện cạnh ký hiệu đầu, một vạch hoặc một vòng tròn, và nó trả lời một câu hỏi khác: có thể không có cái nào không?
Quy tắc duy nhất cần nhớ: bạn đọc mỗi ký hiệu ở cái hộp mà nó chạm vào. Ký hiệu gần hộp nhất là số lượng tối đa; ký hiệu tiếp theo là số lượng tối thiểu.
Ngồi, Đứng yên, Mô hình hóa
Phần tiêu đề “Ngồi, Đứng yên, Mô hình hóa ”Trước Steve Trucking, hãy quay lại những chú chó ở mô-đun 1. Chúng ta có năm hộp: Chủ nuôi, Người nhân giống, Chó, Giống và Trò. Giờ tôi hỏi về những đường nối giữa chúng.
Một hay nhiều? Một chủ nuôi có thể có nhiều hơn một con chó; Ana có hai con. Một con chó có một chủ nuôi, ít nhất là trong mô hình của chúng ta. Đó là quan hệ một-nhiều: một vạch ở phía Chủ nuôi, một chân chim ở phía Chó. Người nhân giống cũng có hình dạng như vậy: một người nhân giống nhân giống nhiều con chó.
Có thể không có không? Max được nhận về từ trại chó hoang, nên nó hoàn toàn không có người nhân giống. Đầu Người nhân giống có một vòng tròn: một con chó có không hoặc một người nhân giống. Tuy vậy, con chó nào cũng có chủ nuôi, nên đầu đó có thêm một vạch thứ hai: đúng một.
Nhiều-nhiều? Một con chó biết nhiều trò, và một trò, chẳng hạn Ngồi, được nhiều con chó biết. Đó là quan hệ nhiều-nhiều, và đó chính là chỗ tôi đi tìm một khái niệm ẩn. Có điều gì về việc con chó này biết trò này không? Cô ấy làm trò đó giỏi đến đâu, và học được khi nào. Quan hệ có những sự thật của riêng nó, nên nó trở thành một thứ riêng: Trò của chó (Dog Trick), với tên của con chó đứng trước, vì chính con chó dẫn dắt nó.
Mỗi đường nối có nghĩa gì? Một chủ nuôi nuôi một con chó. Một người nhân giống nhân giống nó. Một con chó biết các trò của nó. Hãy đặt tên cho các đường nối, và ai cũng có thể đọc lại mô hình cho bạn nghe.
Hiện tại, hay theo thời gian? Có ai quan tâm hôm nay Bella làm trò Ngồi giỏi đến đâu, hay cô ấy đã đạt đến đó như thế nào? Nếu một người huấn luyện kiểm tra cô ấy vài tháng một lần, mỗi lần kiểm tra là một bản ghi riêng: một Đánh giá trò (Trick Assessment), với ngày, mức kỹ năng và người kiểm tra, nằm dưới Trò của chó mà nó thuộc về. Ngay cả một quan hệ đã trở thành một thứ cũng có thể có lịch sử của riêng nó.
Giống thì tôi tạm để chưa nối. Đó vẫn là câu hỏi từ mô-đun 1, một hộp riêng hay một chữ trên con chó, và mô-đun 4 sẽ giải quyết nó.
Mỗi câu hỏi đó vận hành y như vậy trên một doanh nghiệp thật. Giờ hãy đặt chúng cho Steve Trucking.
Hãy hỏi “Một hay nhiều?”
Phần tiêu đề “Hãy hỏi “Một hay nhiều?” ”Một trong những điều đầu tiên tôi muốn hiểu về một quan hệ là lực lượng (cardinality) của nó. Đó là thuật ngữ cơ sở dữ liệu; câu hỏi thì đơn giản hơn nhiều: bao nhiêu cái này có thể liên quan đến bao nhiêu cái kia? Ở mức khái niệm có ba mẫu cơ bản.
Đây là một bước quan trọng trong quy trình: lấy hai danh từ khác nhau và hiểu quan hệ giữa chúng. Trong hầu hết trường hợp, đó là một-nhiều hoặc nhiều-một. Chỉ trong những hoàn cảnh hiếm hoi bạn mới gặp một-một.
Một-nhiều có ở khắp nơi. Một Đối tác bán lẻ có nhiều trung tâm phân phối. Một bảng kê hàng liệt kê nhiều lần giao. Một tuyến có khoảng mười điểm dừng. Khi nghe những câu như vậy, tôi bắt đầu vẽ đường nối.
Và giờ đường nối có ký hiệu. Mỗi đầu cho biết có bao nhiêu cái của hộp mà nó chạm vào: vạch cho một, chân quạ cho nhiều. Hãy đọc từ mỗi hộp: một Đối tác bán lẻ có nhiều Trung tâm phân phối.
Quan hệ một-một có tồn tại, nhưng hiếm, và khi tìm thấy một cái tôi đặt vài câu hỏi. Đây thực sự là hai danh từ khác nhau, hay chỉ là một? Nếu khác nhau, quan hệ một-một giữa chúng là gì? Và nó sẽ luôn là một-một, hay chỉ là một-một ngay lúc này? Đây là những câu hỏi then chốt khi thiết kế mô hình dữ liệu. Vào một buổi sáng bất kỳ, một tổ giao hàng và một xe tải trông như một-một: hai người, một xe tải, một tuyến. Qua một tháng thì không, và đó là nơi quan hệ thú vị nhất trong mô hình này đang ẩn mình.
Quan hệ nhiều-nhiều đặc biệt thú vị, vì chúng thường cho chúng ta biết có một khái niệm khác trong việc kinh doanh. Một tổ có thể lái nhiều xe tải theo thời gian không? Có. Một xe tải có thể được nhiều tổ lái không? Trong suốt vòng đời của nó, chắc chắn có. Vậy tổ giao hàng và xe tải có quan hệ nhiều-nhiều. Nhưng giờ tôi muốn biết thêm. Việc kinh doanh có quan tâm khi nào một tổ dùng một xe tải không? Cho tuyến nào, vào ngày nào? Ai đã phân công? Nếu bản thân quan hệ mang thông tin chúng ta quan tâm, chúng ta đã khám phá ra một khái niệm nghiệp vụ khác: Phân công tổ (Crew Assignment).
Đó là một thói quen mô hình hóa quan trọng. Đôi khi thứ thú vị nhất không phải là một trong những danh từ chúng ta nghe lúc đầu. Nó ẩn trong quan hệ giữa hai danh từ.
Quan hệ có thể trở thành một thứ
Phần tiêu đề “Quan hệ có thể trở thành một thứ ”Đây là một trong những chỗ tôi muốn các quản trị viên bắt đầu nghĩ khác đi. Trong Salesforce chúng ta quen nói về đối tượng và trường, nên dễ coi các hộp là phần quan trọng còn các đường nối chỉ là đường ống. Nhưng bản thân quan hệ có thể mang ý nghĩa nghiệp vụ.
Hãy xét một lần giao và các sản phẩm trên đó. Một lần giao có thể chở vài sản phẩm, chẳng hạn một máy giặt và một máy sấy. Một sản phẩm, cùng một mẫu tủ lạnh, xuất hiện trong hàng nghìn lần giao. Khá dễ. Nhưng nếu tôi cần biết có bao nhiêu sản phẩm đó trên lần giao này, nó có được lắp đặt không, hay máy cũ có được chở đi không? Tôi không còn chỉ quan tâm đến quan hệ giữa Giao hàng và Sản phẩm. Tôi quan tâm đến một Mặt hàng giao (Delivery Item), và khái niệm đó xứng đáng có một thực thể riêng.
Nếu bạn đến từ Salesforce, có thể bạn đã nghĩ: “Đó là một đối tượng nối.” Bạn không sai. Nhưng tôi không muốn bắt đầu từ đó. Một Mặt hàng giao là một khái niệm nghiệp vụ trước khi là một đối tượng nối của Salesforce (Salesforce Junction Object). Nghiệp vụ trước, triển khai sau.
Vài thói quen của tôi với các thực thể quan hệ này, dù cuối cùng chúng được xây ở đâu.
Hãy đặt tên cho nó. Nếu việc kinh doanh đã có từ cho nó, hãy dùng từ của họ. Nếu chưa có, hãy lấy tên của hai thực thể cha và ghép lại. Hãy nghĩ đến một đơn hàng và một sản phẩm. Thứ nằm giữa chúng là Order Item (mặt hàng trong đơn): đơn hàng, và mặt hàng trên đơn hàng. Nó là con của cả hai cha, và trong Salesforce có thể trở thành một đối tượng nối của Salesforce. Nhưng tên nào đứng trước trong tiếng Anh: Item Order, hay Order Item? Hãy xem mỗi cha là loại dữ liệu gì. Sản phẩm là dữ liệu tham chiếu; đơn hàng là dữ liệu giao dịch, và chính đơn hàng dẫn dắt nó. Vì vậy là Order Item, hay Order Product, giống như Salesforce có Opportunity Product. Ở Steve Trucking đó là Delivery Item (Mặt hàng giao). Tên dẫn dắt đứng trước, và bản ghi được sắp xếp cạnh chủ của nó trong mọi danh sách bạn sẽ xem.
Hãy cho nó khóa riêng. Rất dễ bị cám dỗ nói rằng một Mặt hàng giao được nhận diện bằng Giao hàng cộng Sản phẩm và dừng ở đó. Đó là một khóa phức hợp, và khóa phức hợp khó xử lý hơn nhiều: mọi hệ thống trỏ đến bản ghi phải mang theo cả hai nửa. Hãy cho thực thể quan hệ mã định danh riêng của nó, và giữ Giao hàng cộng Sản phẩm như một quy tắc về tính duy nhất, chứ không phải ID bản ghi.
Hãy để ý thứ không có trên đó: một số sê-ri. Số lượng và số sê-ri không thuộc về cùng một bản ghi. Số lượng đếm nhiều cái của một thứ; số sê-ri nhận diện một thứ cụ thể. Nếu việc kinh doanh cần số sê-ri, mỗi đơn vị trở thành một bản ghi riêng, và năm chiếc tủ lạnh là năm bản ghi. Tôi không thấy lý do nào cho một Mặt hàng giao có một Chi tiết mặt hàng giao bên dưới. Chỉ một trong hai: một bản ghi gộp có số lượng, hoặc mỗi đơn vị một bản ghi. Ở đây là số lượng.
Hãy coi chừng các thuộc tính cần lịch sử. Một số thực thể quan hệ ổn định ngay khi được tạo: chiếc máy giặt trên lần giao này vẫn là chiếc máy giặt trên lần giao này. Những thực thể khác cứ thay đổi. Một tổ có xe tải 117 tuần này, và tuần sau xe tải chuyển cho tổ khác. Khi quan hệ thay đổi và việc kinh doanh quan tâm nó từng là gì, thực thể quan hệ cần có ngày tháng, và Phân công tổ chính là thứ cần để mắt tới. Hãy hỏi sớm việc kinh doanh quan tâm hiện tại hay theo thời gian; chúng ta sẽ quay lại điều này ngay sau đây.
Quan hệ có ý nghĩa vượt ra ngoài lực lượng
Phần tiêu đề “Quan hệ có ý nghĩa vượt ra ngoài lực lượng ”“Một-nhiều” chưa đủ để hiểu một quan hệ. Tôi còn muốn biết quan hệ đó nghĩa là gì.
Một lần giao có một địa điểm. Địa điểm nào? Trung tâm phân phối nơi nó xuất phát? Nhà của Người nhận nơi nó đến? Hai cái đó không thay thế cho nhau được. Hai mô hình có thể có đúng cùng các hộp và cùng lực lượng, mà các đường nối lại mang những ý nghĩa hoàn toàn khác nhau. Đó là lý do một mô hình tốt không chỉ là các hộp được nối bằng đường. Các đường nối cần có tên. Nếu tôi đưa sơ đồ của mình cho một kiến trúc sư khác, họ không nên phải đoán một quan hệ nghĩa là gì, và nếu tôi trình bày nó cho phía nghiệp vụ, nó nên dùng ngôn ngữ họ nhận ra.
Tính tùy chọn cũng quan trọng
Phần tiêu đề “Tính tùy chọn cũng quan trọng ”Còn một câu hỏi khác ẩn bên trong “bao nhiêu?”: quan hệ đó có bắt buộc không? Một lần giao có thể tồn tại trước khi được xếp vào một tuyến không? Phải có: bảng kê hàng đến trước ngày giao một hai ngày, và các tuyến được chốt vào tối hôm trước. Một lần giao có thể tồn tại mà không có Đối tác bán lẻ không? Không; mọi lần giao đều đến từ bảng kê hàng của một đối tác. Đó là tính tùy chọn.
Một lần nữa, đừng nhảy thẳng đến ô Bắt buộc của Salesforce. Có khác biệt giữa nói “mọi lần giao phải có một Đối tác bán lẻ” và nói “Salesforce phải bắt buộc trường Đối tác bán lẻ khi bản ghi được tạo”. Chúng có thể dẫn đến cùng một cách triển khai, nhưng không phải cùng một phát biểu. Câu đầu là một quy tắc nghiệp vụ; câu sau là một cách thực thi nó. Là kiến trúc sư, chúng ta muốn hiểu câu đầu trước khi quyết định câu sau.
Trên sơ đồ, tính tùy chọn là ký hiệu thứ hai ở mỗi đầu. Ký hiệu gần hộp nhất là số lượng tối đa: vạch cho một, chân quạ cho nhiều. Ký hiệu tiếp theo là số lượng tối thiểu: thêm một vạch nghĩa là ít nhất một, một vòng tròn nghĩa là có thể bằng không. Vậy mỗi Giao hàng nằm trên đúng một Bảng kê hàng, và một Bảng kê hàng liệt kê một hoặc nhiều Giao hàng. Một Giao hàng nằm ở không hoặc một Điểm dừng, không có cái nào cho đến khi được xếp tuyến, và một Điểm dừng giao không hoặc nhiều Giao hàng.
Thời gian làm thay đổi quan hệ
Phần tiêu đề “Thời gian làm thay đổi quan hệ ”Đây là câu hỏi tôi hỏi rất nhiều: ý bạn là hiện tại, hay theo thời gian?
Một tổ chạy một xe tải. Ngay lúc này? Cho tuyến hôm nay? Chừng nào hai người đó còn làm việc cùng nhau? Mỗi cách cho ra một mô hình khác nhau. Nếu việc kinh doanh chỉ quan tâm hôm nay một tổ có xe tải nào, mô hình có thể đơn giản. Nếu cần mọi xe tải một tổ đã lái, khi nào và trên tuyến nào, chúng ta cần lịch sử, và Phân công tổ mà chúng ta vừa khám phá bỗng trở nên rất quan trọng.
Đây là một nguồn sai lầm mô hình hóa phổ biến. Chúng ta mô hình hóa trạng thái hiện tại vì đó là thứ chúng ta thấy trên màn hình. Rồi vài tuần sau, một Đối tác bán lẻ gửi khiếu nại hư hỏng và ai đó hỏi: “Ngày 17 tháng 3 tổ nào dùng xe tải 117?” Và chúng ta phát hiện ra mình đã ghi đè câu trả lời mỗi lần phân công thay đổi.
Một cách để giữ lịch sử đó là biến việc phân công thành một bản ghi riêng. Khi một tổ được phân công, chúng ta tạo một Phân công tổ với ngày bắt đầu. Khi phân công thay đổi, chúng ta đặt ngày kết thúc cho bản ghi cũ và tạo một bản ghi mới với ngày bắt đầu riêng. Giờ câu hỏi “sáu tháng trước ai giữ phân công đó?” trở nên dễ trả lời, thay vì phải lục lại lịch sử trường hay một nhật ký thay đổi dữ liệu. Và khi một tổ đã có nhiều phân công, sẽ có người hỏi cái nào đang hiện hành, nên tôi cũng thêm một cờ Active (Đang hoạt động).
Vì vậy khi ai đó kể với tôi về một quan hệ, tôi không chỉ hỏi các thứ liên quan với nhau thế nào. Tôi hỏi: quan hệ đó có thay đổi không, và chúng ta có quan tâm đến lịch sử của nó không?
Hãy vẽ trước khi cấu hình
Phần tiêu đề “Hãy vẽ trước khi cấu hình ”Mô hình Steve Trucking của chúng ta đang trở nên hữu ích. Chúng ta biết quan hệ nào là một-nhiều, chỗ nào một quan hệ nhiều-nhiều ẩn một khái niệm khác, quan hệ nào là tùy chọn, và quan hệ nào thay đổi theo thời gian. Và chúng ta vẫn chưa tạo một đối tượng Salesforce nào. Đó là cố ý.
Sơ đồ này nên là thứ tôi có thể đặt trước mặt phía nghiệp vụ, và họ không cần biết Salesforce mới nói được nó đúng hay không. Nếu họ không xác nhận được nó vì đầy thuật ngữ Salesforce, tôi đã chuyển sang thiết kế vật lý quá nhanh.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”Khi làm việc với các quan hệ trong một mô hình khái niệm, tôi đang quyết định:
- Các thực thể nghiệp vụ chính liên quan với nhau thế nào.
- Mỗi quan hệ là một-một, một-nhiều hay nhiều-nhiều, hiện tại và theo thời gian.
- Mỗi quan hệ là bắt buộc hay tùy chọn.
- Một quan hệ nhiều-nhiều có đang ẩn một khái niệm nghiệp vụ có ý nghĩa hay không.
- Quan hệ có thay đổi theo thời gian không, và chúng ta có cần lịch sử của nó không.
Tra cứu hay chính-chi tiết, cấu hình đối tượng nối, hành vi xóa dây chuyền và chia sẻ là những quyết định vật lý; chúng ta sẽ đến đó. Ngay bây giờ chúng ta vẫn đang trả lời câu hỏi quan trọng hơn: việc kinh doanh này thực sự vận hành thế nào? Khi đã hiểu các thực thể và quan hệ giữa chúng, chúng ta có thể bắt đầu thêm các chi tiết mô tả chúng. Đó là lúc mô hình khái niệm của chúng ta bắt đầu trở thành một mô hình dữ liệu logic.