ERD – Entity Relationship Diagram, cái tên không ít thì rất nhiều cũng rất quen với đồng đội chứ hả 🙂

Bạn Đang Xem: ERD là gì?

Bài note hôm nay mình sẽ nói về ERD, một trong những dụng cụ không thể thiếu của người làm Business Analyst.

Sẽ là tất tần tật về ERD, một cách “thực tiễn” nhất có thể, gồm có: ERD là gì, các thành phần của ERD, hay vai trò của ERD khi đối chiếu với BA. Và quan trọng nhất là 15 phút thực hiện ERD để nắm rõ: thực sự ERD giúp ích được gì cho công việc của BA nhé 😎

ERD phun nem là “Entity” “Relationship” Diagram.

• “Entity” tức thị các thực thể
• “Relationship” là các quan hệ, (giữa các thực thể đó).

==> Vậy tóm gọn: ERD là một sơ đồ, thể hiện các thực thể có trong database, và quan hệ giữa chúng với nhau.

Còn một khái niệm khác đồng đội có thể nghe tới, đó là Class Diagram.

Mặc dù cách vẽ và hình dáng của 2 loại diagram này khá giống nhau. Nhưng Class Diagram và ERD là hai khái niệm hoàn toàn khác nhau.

Class Diagram là “con” của nhà UML (Unified Modeling Languaget). Còn ERD là khái niệm tới từ concept của ERM (Entity-Relationship Modeling). Một kỹ thuật dùng làm mô hình hóa cơ sở tài liệu.

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

• Class là nhóm các Object có cùng các tính chất.
• Còn Entity thể hiện các Object ngoài đời thực.

Ví dụ mạng lưới hệ thống built ra để quản lý đối tượng người dùng khách hàng, đơn hàng, sản phẩm… Thì chính những khách hàng, đơn hàng, sản phẩm… đó là những đối tượng người dùng Entity.

Ngoài ra Entity thường được dùng làm mapping với khái niệm table trong relational database, và nó có những business logic nhất định.

Nên, ERD – Entity Relationship Diagram sẽ giúp đồng đội hình dung tổng quan được những “real business object” mà mạng lưới hệ thống đang quản lý. Và đặc biệt quan trọng nó thể hiện quan hệ giữa các “real business object” này với nhau.

Diagram này sẽ giúp đồng đội mần những chuyện sau:

Giúp mường tượng tổng quan mạng lưới hệ thống có gì

Tiếp cận theo phía top-down, ERD sẽ giúp đồng đội liệt kê các đối tượng người dùng có trong mạng lưới hệ thống.

Từ đó, đồng đội dễ dàng scope được những chức năng của mạng lưới hệ thống. Không sợ out of scope, không quá lo ngại phân tích thiếu đối tượng người dùng, cũng như đảm bảo cung cấp đủ một lượng thông tin để setup database cho thời đoạn triển khai sau này.

Ví dụ: mạng lưới hệ thống giúp quản lý hợp đồng, mà trong ERD không có đối tượng người dùng hợp đồng là tèo.

Góc nhìn top down bao giờ cũng quan trọng, nó giúp đồng đội xác định rõ ngay ngay lập tức những thành phần có trong mạng lưới hệ thống, và quan hệ giữa chúng với nhau.

Giúp phân tích mạng lưới hệ thống

Trong những dự án maintenance, việc đọc hiểu ERD của mạng lưới hệ thống ngày nay là một cách hiệu quả để đồng đội nắm được tổng quan các đối tượng người dùng và chức năng giữa chúng với nhau.

Ví dụ đồng đội thấy cục A quan hệ với cục B, cục B quan hệ với cục C.

Thì tức là, sẽ sở hữu một chức năng nào đó liên quan giữa cục A & cục B. Và một chức năng nào đó liên quan giữa cục B & cục C.

Khi nghiên cứu sâu hơn tài liệu Requirements, đôi lúc nó cũng sẽ hỗ trợ đồng đội phát hiện được những “behind the scenes” cực kỳ quan trọng nhưng lại không được thể hiện trong tài liệu.

Giúp nắm rõ hơn tầng database

Trong những system phức tạp, cấu trúc ngùng ngoằng, hoặc chứa cả trăm table, việc visualize các table ra hình ảnh sẽ giúp đồng đội dễ dàng phát hiện ra những điểm chưa phù hợp logic, những quan hệ “mờ ám”, “dư thừa” giữa các table với nhau.

Ngoài ra, có một số tool tương trợ việc convert ERD thành dòng lệnh SQL chạy trên các DBMS, như: Visual-Paradigm, ModelRight, hay Datanamic. Từ đó giúp đồng đội tiết kiệm chi phí thời kì viết query.

Giúp design report

ERD sẽ giúp đồng đội hiểu được: cấu trúc các table link với nhau thế nào.

Từ đó có thể viết các expression một cách chuẩn xác nhất có thể (tức viết các câu query để soi mói, tính toán, thống kê giám sát, hoặc so sánh các tài liệu với nhau để ra được kết quả mong muốn).

Vì đôi lúc, có những quan hệ nhiều – nhiều đồng đội không thể xử lý expression trực tiếp được, mà phải thông qua một số table trung gian nào đó. ERD sẽ giúp đồng đội biết được: đó là những table nào. Từ đó, móc data ra thế nào là chuẩn xác nhất.

Vì BA là người facing trực tiếp với khách hàng và soi mói yêu cầu từ họ. Nên rõ ràng, BA là người nắm rõ khách hàng muốn gì nhất.

BA đó chính là người phác họa ra ERD: mô tả những đối tượng người dùng có trong mạng lưới hệ thống, tính chất và quan hệ giữa chúng ra sao.

Vậy thì vẽ ERD xong, ai là người dùng?

Cũng chính BA luôn, à há.

BA vẽ ERD để capture lại các components có trong mạng lưới hệ thống. Và BA cũng dùng ERD để làm tài liệu thiết kế luôn. Tuy nhiên, ngoài việc tự sướng, tự cung tự cấp ra, thì BA còn vẽ ERD để…

Xem Thêm :

Cung cấp cho những Database Designer, để họ thiết kế database trong thời đoạn triển khai. Và dĩ nhiên, đồng đội Developer cũng rất cần đọc bản thiết kế này.

Để biết được phạm vi các đối tượng người dùng cần quản lý, biết được độ lớn của system. Có thể phần nào hiểu được chức năng đằng sau các đối tượng người dùng này, và tìm cách tối ưu database sao cho tiết kiệm chi phí tài nguyên nhất có thể.

…

Ô kê nãy giờ đồng đội đã nắm sơ bộ ERD rồi, giờ mình sẽ đi vào cụ thể chi tiết, để xem hình thù của một ERD nó trông thế nào nhé.

Như đồng đội đã biết, không biết, hoặc biết rồi mà làm bộ không biết, thì ERD gồm 3 thành phần chính:

• Entity: thực thể (hoặc đối tượng người dùng) mà mạng lưới hệ thống quản lý
• Attribute: tính chất của không ít đối tượng người dùng.
• Và Relationship: quan hệ giữa các đối tượng người dùng.

4.1. Entity

Entity là những đối tượng người dùng như: người, vật, sự việc, hoặc địa điểm… nào đó, mà đồng đội muốn lưu trữ thông tin trên mạng lưới hệ thống.

Thường thì Entity rất dễ hình dung trong mạng lưới hệ thống.

Nhưng cũng đều có một vài entity không tồn tại ở business thực tế phía ngoài. Nó là những entity trung gian, nằm trong lòng 2 entity khác, và thể hiện quan hệ nhiều-nhiều giữa 2 entity này với nhau.

Entity PHẢI LUÔN là danh từ nhé đồng đội.

4.2. Attribute

Attribute tức thị tính chất. Tính chất của chính những entity này.

Nói tính chất nghe có vẻ “IT” quá. Bạn bè có thể hiểu nó là các đặc tính của một đối tượng người dùng bất kỳ. Là những thông tin riêng biệt của đối tượng người dùng này mà mình sẽ lưu trữ.

Ví dụ Đơn hàng sẽ sở hữu 5 thông tin riêng biệt sau, mà chỉ có đơn hàng mới có, mấy thằng khác không có, như:

• Ngày đặt hàng
• Tổng tiền chưa giảm
• Tiền khuyến mãi
• Thành tiền
• Pháp lý tính sổ.

Hoặc Khách hàng sẽ sở hữu 7 thông tin riêng biệt sau mà mấy thằng khác không có, như:

• Họ và tên
• Thư điện tử
• Ngày sinh nhật
• Số điện thoại cảm ứng
• Thị hiếu

Có thể đối tượng người dùng Đơn hàng và Khách hàng sẽ còn rất nhiều thông tin khác, nhưng mình chỉ quan tâm đến nhiêu đây thông tin, nên mình chỉ lưu trữ nhiêu đây attribute thôi.

Chỗ PK (Primary Key) và FK (Foreign Key) để lát nói sau nhé đồng đội.

4.3. Relationship

Về cơ bản thì relationship của ERD có 3 loại:

1. One-to-One: quan hệ 1-1
2. One-to-Many: quan hệ 1-nhiều
3. Many-to-Many: quan hệ nhiều-nhiều.

Từ 3 loại này, đồng đội sẽ thể hiện cụ thể chi tiết hơn bằng 6 quan hệ như sau:

Mình sẽ thực tế hơn cho đồng đội bằng sê ri: Quan hệ giữa Y TÁ vs. BỆNH NHÂN trong một mạng lưới hệ thống quản lý bệnh viện như sau.

(Slideshow có nút Pause ở giữa nhé đồng đội)

This slideshow requires JavaScript.

Hi vọng seri trên giúp đồng đội hiểu được cụ thể chi tiết 6 quan hệ của ERD. Và quan trọng nhất, là cách đọc các quan hệ này.

Hiểu để làm gì?

Để khi khách hàng mô tả bằng tiếng nói thường ngày của họ, thì đồng đội có thể lấy cái đó >> chuyển hóa nó thành tiếng nói ERD >> và phác thảo các quan hệ ra như vầy.

Mấu chốt là đồng đội cần nhìn được: Quan hệ giữa 2 thực thể đó là gì?

Khi đó, ghép vào toàn cảnh cụ thể, đồng đội sẽ hiểu được quan hệ giữa hai thực thể này là gì, và qua lăng kính business thực tế là thế nào?

❓ ❓ ❓ Ví dụ tìm 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.
• Thương Mại & Dịch Vụ – Hợp đồng
  • Thương Mại & Dịch Vụ nằm trong Hợp đồng
  • Hợp đồng gồm có Thương Mại & Dịch Vụ.
• Viên chức CSKH – Khách hàng
  • NV chăm sóc Khách hàng
  • Khách hàng được chăm sóc bởi NV.
• 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, đồng đội có thể chú thích rõ quan hệ này bằng một hình con thoi nhỏ.

Tóm gọn váy lần một:

• Quan hệ giữa các thực thể đều là: ĐỘNG TỪ (có, thuộc, đặt, chăm sóc, mượn, thực hiện…)
• Khi đọc quan hệ theo chiều trái lại, đồng đội chỉ việc chuyển nó thành THỂ BỊ ĐỘNG là xong 🙂 (được mượn, được chăm sóc, được thực hiện…).

Tóm gọn váy lần hai, đồng đội có thể thấy:

• Thực thể ám chỉ DANH TỪ
• Tính chất ám chỉ TÍNH TỪ, chỉ những tính chất – đặc điểm của thực thể (ví dụ khách hàng thì cao 175cm, nặng 65kg, nam nữ Nam, địa chỉ nhà, email…)
• Còn quan hệ thì ám chỉ ĐỘNG TỪ.

Nhận diện được những đối tượng người dùng này, đồng đội sẽ dễ dàng bóc tách tiếng nói thường ngày của khách hàng thành các đối tượng người dùng trong ERD ==> phác họa nhanh chóng & chuẩn xác hơn.

*NOTE KHÔNG HỀ NHỎ: Thực hư quan hệ NHIỀU-NHIỀU quay đi quẩn lại cũng đó chính là quan hệ 1-NHIỀU. Rõ ràng và cụ thể như nào xem tiếp phần dưới nhé đồng đội 😎

Ô kê xam bu chêêêêê.

Phần trên đồng đội đã hiểu được: entity, attribute và relationship trong ERD. Nhưng nếu đồng đội vẫn còn thắc mắc:

Vẽ như zậy rồi trên mạng lưới hệ thống nó chạy ra sao.

1-nhiều, rồi nhiều-nhiều THỰC TẾ khác nhau thế nào?

Thì ở phần tiếp sau đây, mình sẽ trả lời thắc mắc này cho đồng đội.

5.1. Relational Database

Xem Thêm : #So Sánh Chứng Chỉ FRM Và CFA? Chứng Chỉ Nào Phù Hợp Với Bạn

Trước nhất đồng đội cần mường tượng lại đôi chút về Relational Database.

Relational Database nôm na là các database được tổ chức thành nhiều bảng, và giữa các bảng quan hệ với nhau bằng các khóa.

Mà bảng (table) là gì?

Mapping với khái niệm ERD, 1 table đó chính là 1 entity (một đối tượng người dùng, hoặc một thực thể) mà database lưu trữ.

Table thì thuần tuý có những cột và dòng. Như ví dụ trên:

• Cột đó chính là tính chất (attribute) của đối tượng người dùng Customer, gồm có cột: Last Name, First Name, Thư điện tử, bla, bla… các kiểu.
• Còn dòng là các “bản ghi”, mình hay gọi là các record, là số lượng tài liệu mà table đó lưu trữ trong database.

Từ ví dụ trên, đồng đội có thể Kết luận như sau về table Customer:

• Table này gồm 6 tính chất (Full Name, First Name, Last Name, Thư điện tử, Company Name và Business Phone)
• Table này hiện tại vẫn đang lưu trữ 23 records (vì có 23 dòng tài liệu).

Tuy nhiên, vì table lưu trữ nhiều record quá ==> nhu cầu phát sinh: cần phân biệt các record với nhau ==> khóa chính (Primary Key) ra đời.

Thực chất thì khóa chính cũng chỉ là một cột, trong hằng hà các cột mà table lưu trữ. Nhưng nó khác biệt tại vị trí:

Nói theo xì tai của anh Người Phán Xử thì:

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

Còn nói theo tiếng nói lập trình thì: khóa đó chính là thứ để định danh duy nhất mỗi bản ghi trong table của cơ sở tài liệu.

Tiếp theo là khóa ngoại (Foreign Key).

Vì các table liên kết với nhau. Nhưng để liên kết với nhau thì nó cần có điểm chung nào đó. Foreign Key đó chính là điểm chung đó. Nó là key dùng làm liên kết 2 tables lại với nhau.

Foreign Key sẽ là Primary Key ở một table, nhưng lại là Foreign Key ở một table khác mà table đó liên kết đến.

5.2. Giải nghĩa các quan hệ

Phần này giảng giải cho vướng mắc nhức nhối nhất nãy giờ: Đâu là việc khác biệt trên mạng lưới hệ thống thực tế, giữa các quan hệ:

• 1-1
• 1-nhiều
• Và nhiều-nhiều

Bằng phương pháp, mang đồng đội đến với phần mềm thực tế 😎

.

.

.

Ô kê, trước nhất mình có 4 entity với những attribute như sau.

Mình sẽ cho 4 entity này quan hệ với nhau như sau:

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

Nhưng khoan,

Anh B và anh C đang quan hệ nhiều-nhiều. Chỗ này thực tế nó sẽ không còn quan hệ nhiều-nhiều trực tiếp với nhau như vầy, mà cần thông qua một entity trung gian.

Thế là Entity E ra đời. Ảnh chen vào giữa anh B và anh C như sau.

Ô kê tới đây đồng đội đã có: các thực thể và đã liên kết chúng với nhau.

…

Nhưng trước lúc đi tiếp mình có một vướng mắc: Thực chất quan hệ 1-nhiều tức thị sao?

Ví dụ A quan hệ 1-nhiều với B.

Tức thị, 1 record A gồm có rất nhiều record B. Hoặc, nhiều record B cùng liên kết đến 1 record A.

Do đó, để hình dung quan hệ 1-nhiều dễ dàng, đồng đội cứ hình dung đến cái LƯỚI hoặc BẢNG là được. Vì lưới hoặc bảng có rất nhiều DÒNG trong đó.

Nếu A quan hệ 1-nhiều với B, tức thị trên A có một chiếc LƯỚI hoặc một chiếc BẢNG chứa các dòng tài liệu B. Chỉ đơn giản zậy thôi!

Trong tương lai sẽ là: so sánh giữa ERD và thực tế phần mềm để đồng đội hình dung rõ điều tôi vừa nói ở trên nhé.

(Slide Show có nút Pause tại chính giữa nhé đồng đội).

This slideshow requires JavaScript.

Để ví dụ trên dễ hình dung, mình sẽ thay các entity giả thiết này bằng các entity thực tế như sau.

Có một mẹo chỗ này: Làm thế nào để xác định FK cho nhanh?

Nếu 2 table quan hệ 1-nhiều với nhau, đồng đội chỉ việc lấy PK của table ở đầu quan hệ 1, bỏ vào FK của table ở đầu quan hệ nhiều, là xong 🙂

…

Đọc tiếp phần 2 tại: 15 phút thực hiện với sơ đồ ERD.