Professional Documents
Culture Documents
ERD – Entity Relationship Diagram, cái tên không ít thì nhiều cũng khá quen với anh
em chứ hả
Bài note hôm nay mình sẽ nói về ERD, một trong những cô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ể, bao gồm: ERD là gì, các
thành phần của ERD, hay vai trò của ERD đối với BA. Và quan trọng nhất là 15 phút
thực hành ERD để hiểu rõ: thực sự ERD giúp ích được gì cho công việc của BA
nhé
Nội dung [Hide]
1. ERD là gì?
2. ERD để làm gì?
3. Ai vẽ – ai dùng ERD?
4. Ba thành phần của một ERD
o 4.1. Entity
o 4.2. Attribute
o 4.3. Relationship
5. Thực hư 1-1, 1-nhiều, và nhiều-nhiều?!?
o 5.1. Relational Database
o 5.2. Giải nghĩa các mối quan hệ
1. ERD là gì?
ERD phun nem là “Entity” “Relationship” Diagram.
“Entity” nghĩa là các thực thể
“Relationship” là các mối 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à mối quan hệ giữa chúng với nhau.
Còn một khái niệm khác anh em 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 đến từ concept của ERM (Entity-Relationship Modeling). Một kỹ thuật
dùng để mô hình hóa cơ sở dữ 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 thuộc tính.
Còn Entity thể hiện các Object ngoài đời thực.
Ví dụ hệ thống built ra để quản lý đối tượ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 Entity.
Ngoài ra Entity thường được dùng để 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 anh em hình dung tổng quan được
các “real business object” mà hệ thống đang quản lý. Và đặc biệt nó thể hiện mối
quan hệ giữa các “real business object” này với nhau.
Từ đó, anh em dễ dàng scope được các chức năng của hệ thống. Không lo out of
scope, không lo phân tích thiếu đối tượng, cũng như đảm bảo cung cấp đủ một lượng
thông tin để setup database cho giai đoạn triển khai sau này.
Ví dụ: hệ thống giúp quản lý hợp đồng, mà trong ERD không có đối tượng hợp đồng
là tèo.
Góc nhìn top down bao giờ cũng quan trọng, nó giúp anh em xác định rõ ngay lập tức
những thành phần có trong hệ thống, và mối quan hệ giữa chúng với nhau.
Ví dụ anh em 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ẽ có 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ẽ giúp anh em phát
hiện được những “behind the scenes” cực kỳ quan trọng nhưng lại chưa được thể
hiện trong tài liệu.
3. Ai vẽ – ai dùng ERD?
Vì BA là người facing trực tiếp với khách hàng và moi móc yêu cầu từ họ. Nên rõ
ràng, BA là người hiểu 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 có trong hệ
thống, thuộc tính và mối quan hệ giữa chúng ra sao.
Vậy thì vẽ ERD xong, ai là người dùng?
Ô kê nãy giờ anh em đã nắm sơ bộ ERD rồi, giờ mình sẽ đi vào chi tiết, để xem hình
thù của một ERD nó trông thế nào nhé.
4.1. Entity
Entity là những đối tượng như: người, vật, sự việc, hoặc địa điểm… nào đó, mà anh
em muốn lưu trữ thông tin trên hệ thống.
Thường thì Entity rất dễ hình dung trong hệ thống.
Nhưng cũng có một vài entity không tồn tại ở business thực tế bên ngoài. Nó là những
entity trung gian, nằm giữa 2 entity khác, và thể hiện mối quan hệ nhiều-nhiều giữa 2
entity này với nhau.
Entity được thể hiện bằng hình chữ nhật đứng, tên nằm ngay chính giữa.
4.2. Attribute
Attribute nghĩa là thuộc tính. Thuộc tính của chính những entity này.
Nói thuộc tính nghe có vẻ “IT” quá. Anh em có thể hiểu nó là các đặc tính của một
đối tượng bất kỳ. Là những thông tin riêng biệt của đối tượng đó mà mình sẽ lưu trữ.
Ví dụ Đơn hàng sẽ có 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
Điều khoản thanh toán.
Hoặc Khách hàng sẽ có 7 thông tin riêng biệt sau mà mấy thằng khác không có, 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 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.
4.3. Relationship
Mình sẽ thực tế hơn cho anh em bằng sê ri: Mối quan hệ giữa Y TÁ vs. BỆNH
NHÂN trong một hệ thống quản lý bệnh viện như sau.
(Slideshow có nút Pause ở giữa nhé anh em)
Hi vọng seri trên giúp anh em hiểu được chi tiết 6 mối quan hệ của ERD. Và quan
trọng nhất, là cách đọc các mối quan hệ này.
Hiểu để làm gì?
Để khi khách hàng mô tả bằng ngôn ngữ thường ngày của họ, thì anh em có thể lấy
cái đó >> chuyển hóa nó thành ngôn ngữ ERD >> và phác thảo các mối quan hệ ra
như vầy.
Mấu chốt là anh em cần nhìn được: Quan hệ giữa 2 thực thể đó là gì?
Khi đó, ghép vào bối cảnh cụ thể, anh em sẽ hiểu được mối quan hệ giữa hai thực thể
này là gì, và qua lăng kính business thực tế là như thế nào?
Chú thích này giúp anh em đọc ERD dễ hơn, nhưng cũng dễ gây rối hình.
Mối 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 mối quan hệ theo chiều ngược lại, anh em chỉ cần 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, anh em có thể thấy:
em
Thì ở phần dưới đây, mình sẽ giải đáp thắc mắc này cho anh em.
Table này gồm 6 thuộc tính (Full Name, First Name, Last Name, Email,
Company Name và Business Phone)
Table này hiện đang lưu trữ 23 records (vì có 23 dòng dữ 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.
Bản 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 ở chỗ:
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 không, không quan trọng.
Còn nói theo ngôn ngữ 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ở dữ 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 để 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.
Bằng cách, mang anh em đến với phần mềm thực tế
Ô kê, đầu tiên mình có 4 entity với các attribute như sau.
Nhà có 4 anh em: A, B, C và D.
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.
4 anh em quan hệ dây mơ rễ má zới nhau.
Nhưng khoan,
Ô kê tới đây anh em đã có: các thực thể và đã liên kết chúng với nhau.
…
Nhưng trước khi đi tiếp mình có 1 câu hỏi: Bản chất quan hệ 1-nhiều nghĩa là sao?
Ví dụ A quan hệ 1-nhiều với B.
Nghĩa là, 1 record A bao gồm 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, anh em 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, nghĩa là trên A có một cái LƯỚI hoặc một cái
BẢNG chứa các dòng dữ liệu B. Chỉ đơn giản zậy thôi!
Dưới đây sẽ là: đối chiếu giữa ERD và thực tế phần mềm để anh em hình dung rõ
điều mình vừa nói ở trên nhé.
(Slide Show có nút Pause chính giữa nhé anh em).
Để ví dụ trên dễ hình dung, mình sẽ thay các entity giả định này bằng các entity thực
tế như sau.
Có một mẹo chỗ này: Làm sao để xác định FK cho nhanh?
Nếu 2 table quan hệ 1-nhiều với nhau, anh em chỉ cần lấy PK của table ở đầu quan hệ
1, bỏ vào FK của table ở đầu quan hệ nhiều, là xong