ERD – Entity Relationship Diagram (hay sơ đồ mối quan hệ thực thể)
Nghe tên là thấy sặc mùi kỹ thuật rồi. BA xuất thân business giờ nhiều lắm (chẳng hạn như mình), nên cái gì nặng kỹ thuật thì ngán lắm.
Nhưng mà cái này nên biết, hoặc có thể nói là phải học vì nó giúp ích rất nhiều.
ERD giúp gì?
ERD giúp bạn hình dung mọi thứ dưới góc nhìn của developer, tư duy hướng đối tượng.
Nắm được mô hình này, bạn sẽ hình dung các đối tượng quan hệ với nhau ra sau và dữ liệu được lưu vào Database như thế nào. Sẽ bắt đầu hình dung được Scope của hệ thống này rộng tới đâu.
Từ đó tránh được việc lấy thiếu yêu cầu về tính năng, về các đối tượng của hệ thống, dẫn đến đánh giá sai phạm vi dự án (Scope), chi phí, thời gian…
Ví dụ cho dễ hiểu:
Một khách hàng đặt hàng hàng trên website mua 1 hoặc nhiều sản phẩm cho cùng 1 đơn hàng.
Hệ thống cần lưu thông tin khách hàng gồm (tên, số điện thoại, địa chỉ) và đơn hàng (ngày đặt, sản phẩm, giá từng sản phẩm, tổng giá đơn hàng, nhân viên xác nhận).
Nhân viên bán hàng cần xác nhận thông tin đơn hàng.
Mỗi đơn hàng chỉ được đặt bởi 1 khách hàng và xác nhận bởi 1 nhân viên.
Đấy, 1 tấm hình hơn ngàn câu nói. Nếu biết cách đọc ERD, bạn sẽ nắm bắt tổng quát nhanh chóng mà không gặp rắc rối với mớ từ ngữ lẫn lộn.
Vậy nó có khó không? Mình thấy khá dễ. Bạn chỉ cần nắm những gì tổng quát là đủ để sử dụng.
Những điều quan trọng của ERD
Vì đây là lược đồ mối quan hệ giữa các đối tượng, nên 2 thứ quan trọng nhất đó chính là Đối tượng và Mối quan hệ
Đối tượng (Entity)
Khi đọc requirement về 1 quy trình hoặc 1 tính năng, hãy xác định các danh từ, trạng từ chỉ đối tượng, người, vật, hệ thống… mà cần phải lưu lại thông tin vào hệ thống để thực hiện các nghiệp vụ sau này.
Ở ví dụ trên:
- Khách hàng đặt hàng thì hệ thống phải lưu thông tin khách đúng không, vậy khách hàng là 1 đối tượng cần đưa vào ERD
- Website, cũng là 1 danh từ, là nơi mà khách hàng mua hàng. Nhưng đọc requirement thì không thấy đề cập việc lưu lại thông tin này, vậy nên không cần đưa đối tượng này vào ERD. Giả sử shop này bán hàng trên nhiều website và thông tin đơn hàng cần lưu lại khách mua từ web nào thì lúc đó Website hoặc Nguồn bán sẽ được cân nhắc thể hiện vào ERD.
- Đơn hàng, sản phẩm, nhân viên cũng là những đối tượng được yêu cầu lưu lại thông tin trong suốt quá trình mua hàng này.
Khi xác định được đối tượng, bạn sẽ quan tâm đến
- Tạo bảng: 1 bảng đại diện cho 1 đối tượng. Hãy tạo các bảng tương ứng với những đối tượng đã xác định
- Khóa chính (primary key): là thuộc tính định danh của đối tượng. Định danh có nghĩa là không được trùng lặp và không được để trống. Giả sử đối tượng Đơn hàng có khóa chính mà Mã đơn hàng. Có nghĩa là dù shop này có 100 hay 1000 đơn hàng đi nữa, thì mỗi đơn hàng phải có 1 mã đơn khác nhau, không được trùng. Hay nói ngược lại, cho 1 mã thì chỉ tìm ra được 1 và chỉ 1 đơn có mã đó thôi. Tìm ra 2 đơn là tào lao liền. Mỗi bảng bắt buộc phải có 1 khóa chính (\*).
- Thuộc tính: là những thông tin liên quan của một đối tượng. Đóng vai trò mô tả, làm rõ đối tượng, lưu trữ thông tin về đối tượng. Ví dụ đối tượng Khách hàng cần thuộc tính Tên, số điện thoại, địa chỉ… để mô tả về 1 khách hàng. Những thứ phức tạp hơn như Kiểu dữ liệu, Not Null, Unique thì chắc tạm thời mình không đề cập ở bài tổng quan này.
-
Đặt tên: mình không tìm hiểu một quy tắc chuẩn nào hết. Mình tự đặt theo quán tính thôi, nguyên tắc đặt tên của mình là
- Bảng: Dùng dạng số nhiều, viết hoa ký tự đầu của mỗi từ, dùng dấu cách
- Thuộc tính: viết lower-case, thay các dấu cách bằng dấu gạch dưới ( \_ )
- Khóa chính: Tên đối tượng cộng với “id” (dạng số ít, viết theo cú pháp thuộc tính)
(*) Trường hợp những bảng không dùng khóa chính mà dùng các cặp thuộc tính để định danh mình sẽ đề cập ở bài khác
Mối quan hệ (Relationship)
Xác định các mối quan hệ trực tiếp giữa các đối tượng trong quy trình hoặc tính năng.
Cú pháp để xác định các mối quan hệ là:
Một <đối tượng A> có thể sinh ra/thuộc về mấy <đối tượng B>
và ngược lại Một <đối tượng B> có thể sinh ra/thuộc về mấy <đối tượng A>
Đi vào ví dụ luôn nha:
-
Khách hàng và đơn hàng:
- 1 khách có thể đặt nhiều đơn (cùng 1 khách, hôm nay mua 1 đơn, ngày mai có thể quay lại mua tiếp và tạo thành 1 đơn khác)
- 1 đơn chỉ thuộc 1 khách (1 đơn hàng là do 1 ông khách tạo thôi, không có chuyện 2 – 3 ông cùng đặt 1 đơn hay là không có khách nào đặt mà đơn tự sinh ra được)
- → Quan hệ 1 – nhiều
-
Đơn hàng và nhân viên
- 1 nhân viên có thể xác nhận nhiều đơn hàng
- 1 đơn hàng được xác nhận bởi chỉ 1 nhân viên
- → Quan hệ 1 – nhiều
-
Đơn hàng và sản phẩm
- 1 đơn hàng có thể gồm nhiều sản phẩm
- 1 sản phẩm có thể nằm trong nhiều đơn hàng
- → Quan hệ nhiều – nhiều
Ta thấy ví dụ trên có 3 cặp quan hệ chính cần thể hiện lên ERD
Mục tiêu bây giờ là xác định loại kết nối giữa các cặp đó.
Để kết nối 2 bảng với nhau để tạo mối quan hệ thì ta đặt khóa chính của bảng này vào làm thuộc tính của bảng kia với vai trò là khóa ngoại.
Ví dụ luôn. Giả sử để tạo mối quan hệ Khách hàng – Đơn hàng (1 – n) ta đặt khóa ngoại customer_id vào bảng Orders. Dễ dàng thấy ngay customer_id chính là khóa chính của bảng customer đúng không. Điều này mang ý nghĩa là, nhìn vào 1 order, ta biết được order này được đặt bởi ông customer có mã định danh là customer_id.
Các kiểu quan hệ
Về cơ bản thì mối quan hệ được biểu diễn ở dạng một đường thẳng nối giữa hai bảng và có ký hiệu “vết chân chim” ở hai đầu đường thẳng.
Bạn sẽ cần hiểu các ký hiệu này để đọc và vẽ được ERD.
Dạng nâng cao hơn là sự kết hợp giữa các ký hiệu này để thể hiện giá trị min-max. Khuyến khích dùng dạng này khi vẽ cho rõ nghĩa.
Cách đọc ERD
Xét mô hình tổng quát quan hệ giữa 1 cặp đối tượng như sau:
Ta sẽ thấy có 2 chiều đọc theo hành động từ đối tượng A → B và ngược lại. Công thức đọc (phát biểu) tổng quát là:
- Chiều A → B:
1 + \[Đối tượng A\] + \[hành động 1\] + tối thiểu + \[số lượng min 1\] + và tối đa + \[số lượng max 1\] + \[Đối tượng B\]
- Chiều B → A:
1 + \[Đối tượng B\] + \[hành động 2\] + tối thiểu + \[số lượng min 2\] + và tối đa + \[số lượng max 2\] + \[Đối tượng A\]
Ráp thử với ví dụ Customers – Orders nhé:
Hành động 1 mình gọi là đặt: vì theo ngôn ngữ kinh doanh là khách hàng đặt đơn hàng
Hành động 2 là thuộc về: 1 đơn hàng sẽ thuộc về (hoặc dùng được tạo ra bởi cũng được, nhưng mà nó dài)
- Phát biểu 1:
1 khách hàng đặt tối thiểu 0 và tối đa không giới hạn đơn hàng.
- Phát biểu 2:
1 đơn hàng thuộc về tối thiểu 1 và tối đa 1 khách hàng
Đó là cấu trúc chuẩn, giờ bạn có thể diễn đạt lại với từ ngữ mượt mà uyển chuyển hơn
1 khách hàng không bắt buộc phải đặt đơn hàng nào và được phép tạo nhiều đơn hàng khác nhau. (Việc tạo 1 khách hàng thì không quan tâm khách có đơn hàng hay chưa, 1 khách hàng tạo được nhiều đơn)
1 đơn hàng bắt buộc phải thuộc ít nhất 1 và chỉ 1 khách hàng duy nhất. (tạo đơn hàng thì bắt buộc phải biết khách hàng sở hữu đơn đó là ai, và chỉ gắn với 1 khách thôi, không có khách thứ 2)
Đó là chúng ta đang đọc từ 1 ERD có sẵn thành ngôn ngữ kinh doanh. Ngược lại, khi bạn xác định được yêu cầu của khách hàng rồi, bạn có thể dựa vào cú pháp này để vẽ ra được 1 ERD hoàn chỉnh.
1 số ví dụ về việc đọc ERD
Okay, tạm dừng bài viết dài dằng dặc này ở đây. Hy vọng bạn đã nắm được khái quát những gì ERD có thể làm và cách để tạo ra nó.
ERD giúp tư duy hướng đối tượng, hiểu quan hệ và dữ liệu trong Database. Nó bao gồm Đối tượng và Mối quan hệ.
ERD, hay Entity Relationship Diagram, là công cụ giúp mô phỏng mối quan hệ và dữ liệu trong cơ sở dữ liệu thông qua việc xác định các Đối tượng và Mối quan hệ giữa chúng. Việc đọc và vẽ ERD giúp người dùng phát triển kỹ năng tư duy hướng đối tượng, giúp họ dễ dàng hình dung các đối tượng quan hệ và dữ liệu được lưu trữ trong cơ sở dữ liệu như thế nào.
