Thinhnotes|ERD (Entity Relationship Diagram)

 



Copy bài viết từ trang này (Bài này copy từ A Thịnh, vì bài được anh viết xúc tích quá rồi nên mình không cần lọc nhiều, đây chỉ là trang để mình take note lại những kiến thức thoai à)

Góc nhìn top down

1. ERD là gì?

ERD là một sơ đồ (Diagram) thể hiện các thực thể (Entiry) có trong database, và mối quan hệ (Relationship) giữa chúng với nhau. 

- 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ó là những business logic nhất định.

=> ERD sẽ giúp ta hình dung tổng quan 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.

2. ERD để làm gì?

Giúp mường tượng tổng quan hệ thống có gì: Tiếp cận theo hướng top-down, ERD giúp liệt kê các đối tượng có trong hệ thống. Từ đó, 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. Đảm bảo cung cấp đue một lượng thông tin để setup database cho giai đoạn phát triển sau này.

Giúp phân tích hệ thống: Trong những dự án maintenance, việc đọc hiểu ERD của hệ thống hhiệntaij là một cách hiệu quả để mn có thể nắm được tổng quan các đối tượng và chức năng giữa chúng với nhau.

Ví dụ: Cục A có quan hệ với cục B, cục B quan hệ với cục C.

Tức là, sẽ có một chức năng nào đó liên quan giữa cục A và cục B. Và một chức năng nào đó liên quan giữa cục B và cục C.

Nghiên cứu sâu hơn tài liệu requirements, đôi lúc sẽ giúp mn 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 ra trong tài liệu.

Giúp nắm rõ tầng database: Trong những hệ thống 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 mn 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.

Giúp thiết kê report: Nhìn vào database ta hình dung được mối quan hệ giữa chúng, từ đó viết các câu query để tính toán dễ dàng hơn. Đôi lúc có những mối quan hệ nhiều nhiều, mn không thể xử lý expression trực tiếp được, mà phải thông qua table trung gian nào đó. ERD sẽ giúp mn biết được: đó là những table nào. Từ đó moi móc data 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 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?

BA vẽ ERD để capture lại các components có trong hệ thống. BA cũng cũng ERD để làm tài liệu thiết kế luôn. Ngoài ra, BA cung cấp ERD để cho ...Database Designer thiết kế database trong giai đoạn triển khai. Và dĩ nhiên, Developer cũng cần đọc bản thiết kế này. 

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

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

Gồm 3 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 mà hệ thống quản lý 
  • Relationship: 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 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 trên 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 gứac 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 phải luôn là DANH TỪ.

4.2. Attribute 

Attribute nghĩa là thuộc tính. Thuộc tính của những entity. Cũng có thể hiểu là đặ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ực thể 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à các thực thể khác không có, như: Họ và tên, emial, ngày sinh, số điện thoại, Sở thích

4.3. Relationship

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

  • One to one: Quan hệ 1-1 
  • One to many: Quan hệ 1 -nhiều
  • Many to many: Quan hệ nhiều-nhiều

Từ 3 loại mày, anh em sẽ thể hiện chi tiết hơn bằng 6 mối quan hệ như sau:


Ví dụ mối quan hệ bệnh nhân với y tá

1/ Đơn thuần là một 



2/ Quan hệ (một) - (một và chỉ một)


3/ Quan hệ (một) - (không hoặc một)

4/ Quan hệ (một) - nhiều



5/ Quan hệ (một) - (một hoặc nhiều)


6/ Quan hệ (một) - (không hoặc nhiều)


7/ Quan hệ nhiều - nhiều

Tại sao cần hiểu các mối quan hệ của ERD. Để khi khách hàng mô tả bằng ngôn ngữ thường ngày của họ thì mn có thể lấy csc đó để chuyển hóa nó thành ngôn ngữ ERD. Và phát thảo ra các mối quan hệ 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? 



Tóm gọn:
  • 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 chueyenr nó thành THỂ BỊ ĐỘNG là xong.
  • Thực thể ám chỉ DANH TỪ
  • Thuộc tính ám chỉ TÍNH TỪ, ví dụ khách hàng thì cao 1m75, nặnng 65kg)
  • Còn mối quan hệ thì ám chỉ là ĐỘNG TỪ 

 5. Thực hư 1-1, 1-nhiều, nhiều-nhiều?

5.1. 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 từ khóa. 
  • 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ữ.


  • Table đơn thuần là có các cột và dòng. 
    • Cột chính là các thuộc tính (attribute) của đối tượng customer
    • Các dòng là các bản ghi (record), là số lượng dữ liệu mà table đó lưu trữ trong database. (23 record vf có 23 dòng)
  • Primary Key (Khóa chính): Bản chất khóa chính cũng là một cột, trong hằng hà các cột mà table lưu trữ. Nhưng nó khác ở chỗ khóa chính là thứ tồn tại độc lập duy nhất (không được giống nhau), tất cả những cột khác giống hay không, không quan trọng.
  • Foreign Key (Khóa ngoại): Khóa chính ở 1 table, nhưng lại là khóa ngoại ở một table khác mà table đó liên kết đến.

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

Chỗ này đọc trên trang của ổng đi, lười rồi :v
Có một mẹo làm sao để xác định FK cho nhanh 
Nếu 2 table quan hệ 1-nhiều với nhau, ae 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 bà xong. (Hey ghê) 

Ba bước vẽ ERD thần thánh 

  • Xác định entity
  • Xác định relationship
  • Thêm mắm dặm muối :v (Cái gì dậy trời ơi)

Cụ thể hơn là: 

  • Bắt đầu dự án, anh em sẽ làm tùm lum tùm la A,B,C,... để có được specific requirements từ khách hàng.
  • Dựa vào các requirements đó, điều đầu tiên là: Vẽ ra các ĐỐI TƯỢNG cần lưu trữ. (không cần attribute, cần entity là được)
  • Sau đó, tìm kiếm mối quan hệ giữa các đối tượng. Sau đó vẽ ra LIÊN KẾT GIỮA CÁC ĐỐI TƯỢNG là gì (Lưu ý: Ngay lúc này âe nên xác định luôn các entity nó quan hệ cụ thể như thế nào trong 6 cái cardinality. Nếu chưa xác định được thì đơn thuần ae chỉ cần vẽ một đường thẳng nối 2 entity để đánh dấu là 2 tụi nó có quan hệ, lát nữa quay lại bổ sung sau, khỏi quên)
  • Bước cuối là: Bổ sung các attribute, relationship nếu còn thiếu là done (Bước thêm mắm dặm muối của ổng nè trời :v)

0 Comments:

Đăng nhận xét