ERD – Entity Relationship Diagram, cái tên không ít thì nhiều cũng khá quen với đồng đội chứ hả 🙂
Bài note ngày hôm nay mình sẽ nói về ERD, một trong những công cụ không hề 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é 😎

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 bạn bè hoàn toàn 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ụ mạng lưới hệ thống built ra để quản trị đối tượng người dùng người mua, đơn hàng, mẫu sản phẩm … Thì chính những người mua, đơn hàng, mẫu sản phẩm … đó là những đối tượng người dù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 đồng đội tưởng tượng tổng quan được những “ real business object ” mà mạng lưới hệ thống đang quản trị. Và đặc biệt quan trọng nó bộc lộ mối quan hệ giữa những “ real business object ” này với nhau .

Ví dụ ERD của một mạng lưới hệ thống quản trị những hợp đồng dịch vụ và những hãng hàng không người mua.

2. ERD để làm gì ?

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

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

Tiếp cận theo hướng top-down, ERD sẽ giúp bạn bè liệt kê những đối tượng người tiêu dùng có trong mạng lưới hệ thống .
Từ đó, bạn bè thuận tiện scope được những công dụng của mạng lưới hệ thống. Không lo out of scope, không lo nghiên cứu và phân tích thiếu đối tượng người dùng, cũng như bảo vệ cung ứng đủ một lượng thông tin để setup database cho quy trình tiến độ tiến hành sau này .
Ví dụ : mạng lưới hệ thống giúp quản trị hợp đồng, mà trong ERD không có đối tượng người tiêu dùng hợp đồng là tèo .
Góc nhìn top down khi nào cũng quan trọng, nó giúp bạn bè xác lập rõ ngay lập tức những thành phần có trong mạng lưới hệ thống, và mối quan hệ giữa chúng với nhau .

Giúp phân tích hệ thống

Trong những dự án Bất Động Sản maintenance, việc đọc hiểu ERD của mạng lưới hệ thống hiện tại là một cách hiệu suất cao để đồng đội nắm được tổng quan những đối tượng người tiêu dùng và tính 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ẽ có một tính năng nào đó tương quan giữa cục A và cục B. Và một tính năng nào đó tương quan giữa cục B và cục C.
Khi nghiên cứu và điều tra sâu hơn tài liệu Requirements, đôi lúc nó cũng sẽ giúp đồng đội phát hiện được những “ behind the scenes ” cực kỳ quan trọng nhưng lại chưa được bộc lộ 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 loằng ngoằng, hoặc chứa cả trăm table, việc visualize các table ra hình ảnh sẽ giúp anh em dễ dàng phát hiện ra những điểm chưa hợp logic, những mối quan hệ “mờ ám”, “dư thừa” giữa các table với nhau.

Ngoài ra, ERD hoàn toàn có thể giúp đồng đội : sẵn tiện … tạo database luôn .
Có một số ít tool tương hỗ việc convert ERD thành dòng lệnh SQL chạy trên những DBMS, như : Visual-Paradigm, ModelRight, hay Datanamic. Từ đó giúp đồng đội tiết kiệm chi phí thời hạn ngồi viết từng dòng lệnh một .

Giúp design report

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

Từ đó hoàn toàn có thể viết những expression một cách đúng mực nhất hoàn toàn có thể ( tức viết những câu query để moi móc, thống kê giám sát, giám sát, hoặc so sánh những tài liệu với nhau để ra được tác dụng mong ước ) .

Vì đôi lúc, có những quan hệ nhiều – nhiều anh em 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 anh em biết được: đó là những table nào. Từ đó, móc data ra như thế nào là chính xác nhất.

3. Ai vẽ – ai dùng ERD ?

Vì BA là người facing trực tiếp với người mua và moi móc nhu yếu từ họ. Nên rõ ràng, BA là người hiểu rõ người mua 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 ?

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

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

Cung cấp cho các Database Designer, để họ thiết kế database trong giai đoạn triển khai. Và dĩ nhiên, anh em Developer cũng rất cần đọc bản thiết kế này.

Để biết được khoanh vùng phạm vi những đối tượng người dùng cần quản trị, biết được độ lớn của system. Có thể phần nào hiểu được tính năng đằng sau những đối tượng người tiêu 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 hoàn toàn có thể .
…
Ô kê nãy giờ đồng đội đã nắm sơ bộ ERD rồi, giờ mình sẽ đi vào cụ thể, để xem hình thù của một ERD nó trông thế nào nhé .

4. Ba thành phần của một ERD

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

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

4.1. Entity

Entity là những đối tượng người tiêu dùng như : người, vật, vấn đề, hoặc khu vực … nào đó, mà bạn bè muốn tàng trữ thông tin trên mạng lưới 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 sống sót ở business trong thực tiễn bên ngoài. Nó là những entity trung gian, nằm giữa 2 entity khác, và biểu lộ mối quan hệ nhiều-nhiều giữa 2 entity này với nhau .
Entity PHẢI LUÔN là danh từ nhé bạn bè .

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.

Chỗ PK ( Primary Key ) và FK ( Foreign Key ) để lát nói sau nhé bạn bè .

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, bạn bè sẽ bộc lộ cụ thể hơn bằng 6 mối quan hệ như sau :

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é đồng đội )
This slideshow requires JavaScript .

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 toàn cảnh đơn cử, bạn bè 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 trong thực tiễn là thế nào ?

❓ ❓ ❓ 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àngcó

    Xem thêm: Hãy giải thích sơ đồ :ADN (gen) – m ARN – protein – tính trạng .Qua sô đồ, em có kết luận gì về mối quan hệ giữa gen và tính trạng? nam 2022 | https://dvn.com.vn

    Đơn hàng

  • Đơn hàng thuộc về Khách hàng.
• Người dùng – Đặt chỗ (Booking)
  • Người dùngtiế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 đồngbao gồm

    Dịch vụ.

• Nhân viên CSKH – Khách hàng
  • NVchăm sóc

    Khách hàng

  • Khách hàng được chăm nom bởi NV.
• Sinh Viên – Sách
  • Sinh viênmượ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 triển khai 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, anh em có thể chú thích rõ mối quan hệ này bằng một hình con thoi nhỏ.

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

• 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, bạn bè hoàn toàn có thể thấy :

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

Nhận diện được những đối tượng này, anh em sẽ dễ dàng bóc tách ngôn ngữ thường ngày của khách hàng thành các đối tượng trong ERD ==> phác họa nhanh chóng & chính 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. Chi tiết như nào xem tiếp phần dưới nhé anh em 😎 

5. Thực hư 1-1, 1 – nhiều, và nhiều-nhiều ? ! ?

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

Phần trên anh em đã hiểu được: entity, attribute và relationship trong ERD. Nhưng nếu anh em 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 thế nào .

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

Thì ở phần dưới đây, mình sẽ giải đáp vướng mắc này cho đồng đội .

5.1. Relational Database

Đầu tiên bạn bè 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, hoặc một thực thể) mà database lưu trữ.

Ví dụ về table Customer ( Nguồn ảnh : Microsoft )

Table thì đơn thuần có các cột và dòng. Như ví dụ trên:

• Cột chính là thuộc tính (attribute) của đối tượng Customer, bao gồm cột: Last Name, First Name, Email, 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 dữ liệu mà table đó lưu trữ trong database.

Từ ví dụ trên, đồng đội hoàn toàn có thể Tóm lại như sau về table Customer :

• 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 từ 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 để 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 những mối quan hệ

Phần này giải thích cho câu hỏi nhức nhối nhất nãy giờ: Đâu là sự khác biệt trên hệ thống thực tế, giữa các quan hệ:

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

Bằng cách, mang bạn bè đến với ứng dụng thực tiễn 😎
.
.
.
Ô kê, tiên phong 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 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ó : những thực thể và đã link 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 gồm có rất nhiều record B. Hoặc, nhiều record B cùng link đế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à : so sánh giữa ERD và trong thực tiễn ứng dụng để bạn bè tưởng tượng rõ điều mình vừa nói ở trên nhé .
( Slide Show có nút Pause chính giữa nhé bạn bè ) .
This slideshow requires JavaScript .

Để 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.

ERD map với trong thực tiễn

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 🙂

…

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

Like this:

Like

Loading…

Bài viết liên quan

Source: https://dvn.com.vn
Category: Bản Tin DVN