ERD là gì?

ERD – Entity Relationship Diagram, cái tên này chắc chắn đã quen thuộc với các chuyên gia trong lĩnh vực phân tích kinh doanh.

Trong bài viết hôm nay, chúng ta sẽ tìm hiểu về ERD, một trong những công cụ quan trọng nhất cho người làm Business Analyst.

Bài viết sẽ tập trung vào việc trình bày ERD một cách thực tế nhất, bao gồm: định nghĩa và thành phần của ERD, vai trò của ERD trong công việc của Business Analyst. Đặc biệt, chúng ta cũng sẽ thực hành ERD trong 15 phút để hiểu rõ hơn về lợi ích của ERD trong công việc của BA.

ERD viết tắt của “Entity” “Relationship” Diagram.

• “Entity” đề cập đến các thực thể.
• “Relationship” đề cập đến mối quan hệ giữa các thực thể đó.

Vì vậy, ERD được định nghĩa là một sơ đồ biểu diễn các thực thể có trong cơ sở dữ liệu và mối quan hệ giữa chúng.

Một khái niệm khác mà bạn có thể đã nghe đến là Class Diagram.

Class Diagram và ERD là hai khái niệm hoàn toàn khác nhau, mặc dù cách vẽ và hình dạng của chúng có vẻ giống nhau. Class Diagram là một phần của ngôn ngữ UML (Unified Modeling Language), trong khi ERD là một kỹ thuật từ khái niệm ERM (Entity-Relationship Modeling), được sử dụng để mô hình hóa cơ sở dữ liệu.

Một bên là Class, một bên là Entity.

• Class là một nhóm các đối tượng có cùng các thuộc tính.
• Entity đại diện cho các đối tượng trong thực tế.

Ví dụ về một hệ thống quản lý khách hàng, đơn hàng, sản phẩm… Những khách hàng, đơn hàng, sản phẩm đó có thể được xem như những đối tượng Entity.

Thường thì Entity được ánh xạ với khái niệm bảng trong cơ sở dữ liệu quan hệ và nó có một số logic kinh doanh cụ thể.

ERD – Entity Relationship Diagram sẽ giúp chúng ta có cái nhìn tổng quan về các “đối tượng kinh doanh thực tế” mà hệ thống đang quản lý và đặc biệt là mối quan hệ giữa các “đối tượng kinh doanh thực tế” này.

ERD giúp chúng ta:

Hình dung tổng quan về hệ thống

ERD giúp chúng ta tiếp cận theo hướng top-down, liệt kê các đối tượng có trong hệ thống. Từ đó, chúng ta dễ dàng xác định phạm vi các chức năng của hệ thống. Điều này giúp chúng ta không lo bỏ sót các đối tượng, đồng thời đảm bảo cung cấp đủ thông tin để thiết lập cơ sở dữ liệu cho giai đoạn triển khai sau này.

Ví dụ: nếu hệ thống quản lý hợp đồng mà trong ERD không có đối tượng hợp đồng, thì chúng ta đã bỏ sót một phần quan trọng của hệ thống.

Chúng ta luôn cần nhìn từ trên xuống, để xác định rõ ngay từ đầu các thành phần có trong hệ thống và mối quan hệ giữa chúng.

Phân tích hệ thống

Trong các dự án bảo trì, việc đọc và hiểu ERD của hệ thống hiện tại là một cách hiệu quả để hiểu tổng quan về các đối tượng và chức năng của chúng. Ví dụ, nếu chúng ta nhìn thấy mối quan hệ giữa A và B, sau đó quan hệ giữa B và C, có nghĩa là có một chức năng nào đó liên quan giữa A & B và B & C. Điều này đôi khi sẽ giúp chúng ta phát hiện những yếu tố “behind the scenes” quan trọng mà chưa được thể hiện trong tài liệu yêu cầu.

Hiểu rõ hơn về cấu trúc cơ sở dữ liệu

Trong các hệ thống phức tạp hoặc chứa rất nhiều bảng, việc biểu diễn các bảng dưới dạng hình ảnh sẽ giúp chúng ta dễ dàng phát hiện những vấn đề logic không đúng, những quan hệ không rõ ràng hoặc quan hệ dư thừa giữa các bảng.

Ngoài ra, có một số công cụ hỗ trợ chuyển đổi ERD thành các câu lệnh SQL chạy trên các hệ quản trị cơ sở dữ liệu, như Visual-Paradigm, ModelRight hoặc Datanamic. Giúp chúng ta tiết kiệm thời gian viết câu lệnh truy vấn.

Thiết kế báo cáo

ERD giúp chúng ta hiểu cấu trúc các bảng và liên kết chúng như thế nào. Từ đó, chúng ta có thể viết các biểu thức một cách chính xác nhất có thể (tức viết các câu truy vấn để trích xuất, tính toán, đo lường hoặc so sánh dữ liệu để có được kết quả mong muốn). Đôi khi, khi có các mối quan hệ nhiều-nhiều, chúng ta không thể xử lý truy vấn trực tiếp mà phải thông qua một số bảng trung gian. ERD giúp chúng ta biết đó là những bảng nào và giúp trích xuất dữ liệu một cách chính xác nhất.

Vì Business Analyst đứng trước mặt khách hàng và thu thập các yêu cầu từ họ, rõ ràng, Business Analyst hiểu rõ nhất về những gì khách hàng muốn.

Business Analyst chính là người trình bày ERD: mô tả những đối tượng có trong hệ thống, thuộc tính và mối quan hệ giữa chúng.

Vậy ERD đã được vẽ xong, ai là người sử dụng nó?

Dĩ nhiên là Business Analyst chứ, đúng không nào?

Business Analyst vẽ ERD để tạo ra một tài liệu đặc tả các thành phần của hệ thống. Họ cũng sử dụng ERD để thiết kế cơ sở dữ liệu. Tuy nhiên, không chỉ tự mình sử dụng, Business Analyst cũng đóng vai trò:

– Cung cấp ERD cho các Database Designer để họ thiết kế cơ sở dữ liệu trong giai đoạn triển khai.

– Đôi khi các Developers cũng cần đọc các thiết kế này để hiểu rõ phạm vi và chức năng của hệ thống.

– ERD cũng có thể được sử dụng cho việc phân tích dữ liệu và phát triển ứng dụng.

Vì vậy, ERD không chỉ là một vẽ sơ đồ, nó là tài liệu phục vụ nhiều mục đích và có ảnh hưởng lớn đến công việc của Business Analyst.

Ổn, giờ chúng ta đã hiểu về tổng quan về ERD rồi. Giờ chúng ta sẽ đi vào chi tiết và xem nhìn ERD trông như thế nào.

ERD bao gồm 3 thành phần chính:

• Entity: đại diện cho các đối tượng (hoặc thực thể) mà hệ thống quản lý.
• Attribute: chỉ những thuộc tính của các đối tượng đó.
• Và Relationship: đại diện cho mối quan hệ giữa các đối tượng.

4.1. Entity

Entity là những đối tượng như người, vật, sự việc, địa điểm… mà chúng ta muốn lưu trữ thông tin trong hệ thống.

Thông thường, Entity được dễ dàng hình dung trong hệ thống.

Tuy nhiên, cũng có một số Entity không tồn tại trong thực tế. Đó là các Entity trung gian, nằm giữa hai Entity khác và thể hiện mối quan hệ nhiều-nhiều giữa hai Entity này.

Entity luôn là danh từ.

4.2. Attribute

Đối với ERD, Attribute có nghĩa là các thuộc tính của đối tượng.

Attribute có thể hiểu là các đặc tính của một đối tượng bất kỳ. Đó là thông tin riêng biệt của đối tượng mà chúng ta muốn lưu trữ.

Ví dụ, một đơn hàng có thể có các thông tin riêng biệt như: ngày đặt hàng, tổng tiền chưa giảm, tiền khuyến mãi, thành tiền và điều khoản thanh toán.

Hoặc, một khách hàng có thể có các thông tin riêng biệt như: họ và tên, email, ngày sinh nhật, số điện thoại, sở thích…

Có thể đối tượng Đơn hàng và Khách hàng sẽ còn nhiều thuộc tính khác, nhưng chúng ta chỉ quan tâm đến những thông tin quan trọng như vậy và chúng ta chỉ lưu trữ những thuộc tính cần thiết.

4.3. Relationship

ERD có ba loại mối quan hệ cơ bản: một-một, một-nhiều và nhiều-nhiều.

Có thể tạo ra sự khác biệt giữa các loại quan hệ này thông qua cách chúng ta trình bày ví dụ.

Bằng việc áp dụng những khái niệm ERD vào các phần mềm thực tế, chúng ta có thể giải thích sự khác biệt giữa các quan hệ như sau:

• Mối quan hệ một-một: mỗi đối tượng trong A (entity A) chỉ tương ứng với duy nhất một đối tượng trong B (entity B), và ngược lại.
• Mối quan hệ một-nhiều: mỗi đối tượng trong A (entity A) tương ứng với một số đối tượng trong B (entity B). Tuy nhiên, mỗi đối tượng trong B chỉ tương ứng với duy nhất một đối tượng trong A.
• Mối quan hệ nhiều-nhiều: mỗi đối tượng trong A (entity A) có thể tương ứng với nhiều đối tượng trong B (entity B), và ngược lại. Mối quan hệ nhiều-nhiều thường được biểu diễn thông qua một đối tượng trung gian (entity E) giữa A và B, thành một mối quan hệ một-nhiều giữa A và E, và một mối quan hệ một-nhiều giữa E và B.

Bằng cách này, chúng ta có thể tạo ra một hình ảnh rõ ràng về mối quan hệ giữa các đối tượng và hiểu được cách đọc mối quan hệ này.

Như vậy, chúng ta đã hiểu được khái niệm cơ bản về ERD và cách trình bày các mối quan hệ trong ERD. Hiểu rõ những điều này giúp chúng ta dễ dàng chuyển đổi ngôn ngữ hàng ngày của khách hàng thành ERD và phác thảo mối quan hệ một cách chính xác hơn.

*Lưu ý quan trọng: Quan hệ nhiều-nhiều thực chất là quan hệ một-nhiều. Chi tiết xem phần tiếp theo 😎

Bây giờ, chúng ta đã có cái nhìn tổng quan về ERD. Liệu chúng ta có thể thực hiện những gì đã tạo ra trên hệ thống được không?

5.1. Cơ sở dữ liệu quan hệ

Đầu tiên, hãy tưởng tượng một chút về cơ sở dữ liệu quan hệ.

Nguyên tắc cơ bản của cơ sở dữ liệu quan hệ là các bảng quan hệ với nhau thông qua các khóa.

Một bảng trong cơ sở dữ liệu quan hệ đại diện cho một entity.

Bảng chỉ đơn giản là một tập hợp các cột và hàng. Ví dụ:

• Cột là các thuộc tính của entity, chẳng hạn như: Tên, Tuổi, Email, Địa chỉ…
• Hàng là các “bản ghi”, hoặc còn gọi là các bản ghi dữ liệu có trong bảng.

Ví dụ trên, chúng ta có thể kết luận như sau về bảng Khách hàng:

• Bảng này bao gồm 6 thuộc tính (Tên đầy đủ, Tên, Họ, Email, Tên công ty và Số điện thoại).
• Bảng này hiện đang lưu trữ 23 bản ghi (vì có 23 hàng dữ liệu).

Tuy nhiên, vì bảng lưu trữ quá nhiều bản ghi, chúng ta cần phân biệt các bản ghi với nhau và do đó cần một khóa chính.

Khóa chính cũng chỉ là một cột, nhưng khác biệt ở chỗ:

Khóa chính là một cột tồn tại độc lập duy nhất và không được giống nhau. Các cột khác có hoặc không giống nhau không quan trọng.

Khóa ngoại là một khóa được sử dụng để liên kết hai bảng với nhau.

5.2. Giải thích các quan hệ

Phần này giải đáp câu hỏi “Sự khác biệt giữa các quan hệ 1-nhiều trong thực tế như thế nào?”, bằng cách lấy ví dụ từ phần mềm thực tế.

.

.

.

Ồ, dường như chúng ta đã có đủ điều kiện để đi sâu vào ví dụ thực tế rồi.

Đầu tiên, tôi có 4 entity với các thuộc tính như sau.

Tôi sẽ tạo quan hệ giữa các entity như sau:

• D có mối quan hệ 1-1 với A
• A có mối quan hệ 1-nhiều với B
• B có mối quan hệ nhiều-nhiều với C.

Nhưng đợi một chút,

B và C không thể có mối quan hệ nhiều-nhiều trực tiếp như vậy trong thực tế. Thực tế là chúng cần thông qua một entity trung gian.

Vậy Entity E được tạo ra. Chúng tôi chèn Entity E vào giữa B và C như sau.

Ồ, tại đây chúng ta đã có: các entity và các liên kết giữa chúng.

…

Nhưng trước khi đi xa hơn, tôi có một câu hỏi: “Mối quan hệ 1-nhiều đồng nghĩa với điều gì?”

Giả sử A có mối quan hệ 1-nhiều với B.

Điều đó có nghĩa là, mỗi đối tượng trong A tương ứng với nhiều đối tượng trong B. Hoặc nhiều đối tượng trong B liên kết đến duy nhất một đối tượng trong A.

Vì vậy, để hình dung quan hệ 1-nhiều dễ dàng, hãy tưởng tượng đến một lưới hoặc bảng. Vì lưới hoặc bảng có nhiều dòng.

Nếu A có quan hệ 1-nhiều với B, có nghĩa là trên A có một lưới hoặc bảng chứa các dòng dữ liệu B. Chỉ đơn giản như vậy!

Như vậy, chúng tôi đã trình bày ví dụ cho mỗi mối quan hệ trong ERD dễ dàng hình dung. Chúng ta hiểu sâu sắc về mối quan hệ giữa hai thực thể này là gì và qua lăng kính kinh doanh thực tế là gì.

❓ ❓ ❓ Ví dụ tìm mối quan hệ giữa các thực thể sau:

• Khách hàng – Đơn hàng
  • Khách hàng có đơn hàng
  • Đơn hàng thuộc về Khách hàng.
• Người dùng – Đặt chỗ (Booking)
  • Người dùng tiến hành đặt Booking
  • Booking được đặt bởi Người dùng.
• Dịch vụ – Hợp đồng
  • Dịch vụ nằm trong Hợp đồng
  • Hợp đồng bao gồm Dịch vụ.
• Nhân viên CSKH – Khách hàng
  • Nhân viên chăm sóc Khách hàng
  • Khách hàng được chăm sóc bởi Nhân viên.
• Sinh Viên – Sách
  • Sinh viên mượn Sách
  • Sách được mượn bởi Sinh viên.
• Khách hàng – Hoạt động tương tác
  • Khách hàng thực hiện Hoạt động tương tác
  • Hoạt động tương tác được thực hiện bởi Khách hàng.

Ngoài ra, chúng ta có thể chú thích mối quan hệ này bằng một hình con thoi nhỏ.

Tóm lại lần thứ nhất:

• Mối quan hệ giữa các thực thể luôn là một động từ (có, thuộc về, đặt, chăm sóc, mượn, thực hiện…)
• Khi đọc từ quan hệ theo chiều ngược lại, chúng ta chỉ cần chuyển nó sang dạng bị động là xong 🙂 (được mượn, được chăm sóc, được thực hiện…).

Tóm lại lần thứ hai, chúng ta có thể thấy:

• Thực thể chỉ một DANH TỪ.
• Thuộc tính chỉ một TÍNH TỪ, chỉ các đặc điểm của thực thể (ví dụ: khách hàng có chiều cao 175cm, cân nặng 65kg, giới tính là Nam, địa chỉ nhà, email…)
• Mối quan hệ là một ĐỘNG TỪ.

Đã nhận biết được những đối tượng này, chúng ta có thể dễ dàng tách ngôn ngữ hàng ngày của khách hàng thành những đối tượng trong ERD, phác thảo nhanh chóng và chính xác hơn.

*Lưu ý quan trọng: Mối quan hệ nhiều-nhiều thực chất là mối quan hệ một-nhiều. Chi tiết xem phần dưới.

Ổn, đến đây chúng ta đã hiểu về khái niệm chung của ERD và cách trình bày các mối quan hệ trong ERD. Nhưng giờ chúng ta sẽ đi vào chi tiết hơn và xem cách ERD trông như thế nào trong thực tế.

Như chúng ta đã biết, chúng ta sẽ đi sâu vào thông tin chi tiết về ERD và cách nó trông như thế nào. Tuy nhiên, bạn có thắc mắc:

ERD vẽ như thế rồi, vậy nó hoạt động như thế nào trên hệ thống? Mối quan hệ 1-nhiều, nhiều-nhiều khác nhau như thế nào trong thực tế?

Ở phần tiếp theo, chúng ta sẽ giải đáp các thắc mắc này.

5.1. Cơ sở dữ liệu quan hệ

Đầu tiên, hãy cùng nhìn lại một chút về Cơ sở dữ liệu quan hệ.

Cơ sở dữ liệu quan hệ là một hệ thống cơ sở dữ liệu được tổ chức thành nhiều bảng, và các bảng này có các mối quan hệ với nhau thông qua các khóa.

Bảng trong cơ sở dữ liệu quan hệ tương ứng với một entity.

Bảng gồm các cột và hàng. Ví dụ:

• Cột đại diện cho thuộc tính của entity, chẳng hạn như: Họ và tên, Tuổi, Email, Giới tính, Địa chỉ…
• Hàng đại diện cho bản ghi dữ liệu, hay còn gọi là record, là các dòng dữ liệu mà bảng đó lưu trữ.

Ví dụ trên, chúng ta có thể kết luận như sau về bảng Khách hàng:

• Bảng này gồm 6 thuộc tính (Họ và tên đầy đủ, Tên, Họ, Email, Tên công ty, Số điện thoại).
• Bảng này hiện đang lưu trữ 23 bản ghi (vì có 23 hàng dữ liệu).

Tuy nhiên, vì bảng lưu trữ quá nhiều bản ghi nên chúng ta cần phải phân biệt giữa các bản ghi. Đó là lý do vì sao chúng ta cần có khóa chính.

Khóa chính cũng chỉ là một cột, nhưng khác biệt ở chỗ:

Khóa chính là một cột tồn tại độc lập duy nhất và không được giống nhau. Các cột khác, giống hay không, không quan trọng.

Khóa ngoại là một khóa được sử dụng để liên kết hai bảng. Khóa ngoại là khóa chính của một bảng, và đồng thời cũng là khóa ngoại của một bảng khác mà bảng đã liên kết tới.

5.2. Giải thích các mối quan hệ

Ở phần này, chúng ta sẽ giải thích sự khác biệt giữa các quan hệ 1-nhiều trong thực tế. Chúng ta sẽ xem ví dụ thực tế để hiểu rõ hơn.