erd là gì

ERD – Entity Relationship Diagram, cái brand name quá nhiều thì nhiều vô kể cũng tương đối quen thuộc với bằng hữu chứ hả 🙂

Bài note thời điểm ngày hôm nay bản thân tiếp tục nói đến ERD, một trong mỗi khí cụ không thể không có của những người thực hiện Business Analyst.

Bạn đang xem: erd là gì

Sẽ là vớ tần tật về ERD, một cơ hội “thực tiễn” nhất hoàn toàn có thể, gồm những: ERD là gì, những bộ phận của ERD, hoặc tầm quan trọng của ERD so với BA. Và cần thiết nhất là 15 phút thực hành thực tế ERD nhằm hiểu rõ: thực sự ERD mang lại lợi ích được gì mang lại việc làm của BA nhé 😎

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

• “Entity” tức là những thực thể
• “Relationship” là những mối quan lại hệ, (giữa những thực thể đó).

==> Vậy tóm gọn: ERD là một trong sơ đồ, thể hiện tại các thực thể đem vô database, và mối mối quan hệ thân thiết chúng cùng nhau.

Còn một định nghĩa không giống bằng hữu hoàn toàn có thể nghe cho tới, tê liệt là Class Diagram.

Mặc cho dù phương pháp vẽ và dáng vẻ của 2 loại diagram này khá giống như nhau. Nhưng Class Diagram và ERD là nhị định nghĩa hoàn toàn không giống nhau.

Class Diagram là “con” ở trong phòng UML (Unified Modeling Languaget). Còn ERD là định nghĩa tới từ concept của ERM (Entity-Relationship Modeling). Một chuyên môn dùng để làm mô hình hóa hạ tầng dữ liệu.

Một mặt mày là Class, còn một phía là Entity.

• Class là group những Object đem với những tính chất.
• Còn Entity thể hiện tại những Object ngoài đời thực.

Ví dụ khối hệ thống built đi ra nhằm quản lý và vận hành đối tượng người sử dụng khách hàng, đơn hàng, sản phẩm… Thì chủ yếu những khách hàng, đơn hàng, sản phẩm… này đó là những đối tượng người sử dụng Entity.

Ngoài đi ra Entity thông thường được dùng để làm mapping với khái niệm table vô relational database, và nó đem những business logic chắc chắn.

Nên, ERD – Entity Relationship Diagram sẽ hỗ trợ bằng hữu tưởng tượng tổng quan lại được các “real business object” nhưng mà khối hệ thống đang được quản lý và vận hành. Và đặc trưng nó thể hiện tại quan hệ Một trong những “real business object” này cùng nhau.

2. ERD nhằm thực hiện gì?

Diagram này sẽ hỗ trợ bằng hữu mần những chuyện sau:

Giúp tưởng tượng tổng quan lại khối hệ thống đem gì

Tiếp cận theo phía top-down, ERD sẽ hỗ trợ bằng hữu liệt kê những đối tượng người sử dụng đem vô khối hệ thống.

Từ tê liệt, bằng hữu dễ dàng và đơn giản scope được những công dụng của khối hệ thống. Không lo ngại out of scope, không phải lo ngại phân tách thiếu hụt đối tượng người sử dụng, na ná đáp ứng hỗ trợ đầy đủ một lượng vấn đề nhằm setup database mang lại quy trình tiến độ tổ chức thực hiện sau đây.

Ví dụ: hệ thống gom quản lý và vận hành hợp ý đồng, nhưng mà vô ERD không tồn tại đối tượng người sử dụng hợp ý đồng là tèo.

Góc nhìn top down lúc nào cũng cần thiết, nó gom bằng hữu xác lập rõ rệt tức thì tức thì những bộ phận đem vô khối hệ thống, và quan hệ thân thiết bọn chúng cùng nhau.

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

Trong những dự án công trình maintenance, việc gọi hiểu ERD của khối hệ thống lúc này là một trong cơ hội hiệu suất cao nhằm bằng hữu tóm được tổng quan lại những đối tượng người sử dụng và công dụng thân thiết bọn chúng cùng nhau.

Ví dụ bằng hữu thấy viên A mối quan hệ với viên B, viên B mối quan hệ với viên C.

Thì tức là, sẽ có được một công dụng nào là đó tương quan thân thiết viên A & viên B. Và một công dụng nào là tê liệt tương quan thân thiết viên B & viên C.

Khi phân tích thâm thúy rộng lớn tư liệu Requirements, song khi nó cũng sẽ hỗ trợ bằng hữu phân phát hiện tại được những “behind the scenes” khôn xiết cần thiết tuy nhiên lại không được thể hiện tại vô tư liệu.

Giúp nắm vững rộng lớn tầng database

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

Ngoài đi ra, đem một số trong những tool tương hỗ việc convert ERD trở nên dòng sản phẩm mệnh lệnh SQL điều khiển xe trên những DBMS, như: Visual-Paradigm, ModelRight, hoặc Datanamic. Từ tê liệt gom bằng hữu tiết kiệm chi phí thời hạn viết lách query.

Giúp design report

ERD sẽ hỗ trợ bằng hữu hiểu được: cấu trúc những table links với nhau thế nào.

Từ tê liệt hoàn toàn có thể viết lách những expression một cơ hội đúng chuẩn nhất đem thể (tức viết lách những câu query nhằm xói móc, đo lường, đo lường và thống kê, hoặc đối chiếu những tài liệu cùng nhau nhằm đi ra được thành phẩm hòng muốn).

Vì song khi, đem những mối quan hệ nhiều – nhiều bằng hữu ko thể xử lý expression thẳng được, nhưng mà nên trải qua một số trong những table trung gian ngoan nào là tê liệt. ERD sẽ hỗ trợ bằng hữu biết được: này đó là những table nào là. Từ tê liệt, móc data đi ra thế nào là đúng chuẩn nhất.

3. Ai vẽ – ai sử dụng ERD?

Vì BA là kẻ facing thẳng với người tiêu dùng và xói móc đòi hỏi kể từ chúng ta. Nên rõ rệt, BA là kẻ làm rõ người tiêu dùng ham muốn gì nhất.

BA đó là người phác hoạ họa đi ra ERD: mô miêu tả những đối tượng đem vô khối hệ thống, thuộc tính và mối quan lại hệ thân thiết bọn chúng đi ra sao.

Vậy thì vẽ ERD xong xuôi, ai là kẻ dùng?

Cũng chủ yếu BA luôn luôn, à há.

BA vẽ ERD nhằm capture lại những components đem vô khối hệ thống. Và BA cũng sử dụng ERD nhằm thực hiện tư liệu kiến thiết luôn luôn. Tuy nhiên, ngoài các việc tự động sướng, tự túc tự động cung cấp đi ra, thì BA còn vẽ ERD để…

Cung cung cấp cho những Database Designer, nhằm chúng ta kiến thiết database vô quy trình tiến độ tổ chức thực hiện. Và tất nhiên, bằng hữu Developer cũng tương đối cần thiết gọi phiên bản kiến thiết này.

Để hiểu rằng phạm vi những đối tượng người sử dụng cần thiết quản lý và vận hành, hiểu rằng kích cỡ của system. cũng có thể phần nào là hiểu rõ công dụng phí a đằng sau những đối tượng người sử dụng này, và dò la cơ hội tối ưu database sao mang lại tiết kiệm chi phí khoáng sản nhất hoàn toàn có thể.

…

Ô kê nãy giờ bằng hữu vẫn tóm sơ cỗ ERD rồi, giờ bản thân tiếp tục lên đường vô cụ thể, nhằm coi hình thù oán của một ERD nó nhìn thế nào là nhé. 

4. Ba bộ phận của một ERD

Như bằng hữu vẫn biết, không biết, hoặc biết rồi nhưng mà thực hiện cỗ không biết, thì ERD bao gồm 3 bộ phận chính:

• Entity: thực thể (hoặc đối tượng) nhưng mà khối hệ thống quản ngại lý
• Attribute: thuộc tính của những đối tượng người sử dụng.
• Và Relationship: quan hệ Một trong những đối tượng người sử dụng.

4.1. Entity

Entity là những đối tượng người sử dụng như: người, vật, vấn đề, hoặc địa điểm… nào là tê liệt, nhưng mà bằng hữu ham muốn tàng trữ vấn đề bên trên khối hệ thống.

Thường thì Entity rất dễ dàng hình dung vô khối hệ thống.

Nhưng cũng có thể có một vài ba entity ko tồn bên trên ở business thực tiễn phía bên ngoài. Nó là những entity trung gian ngoan, nằm trong lòng 2 entity không giống, và thể hiện tại quan hệ nhiều-nhiều thân thiết 2 entity này cùng nhau.

Entity PHẢI LUÔN là danh kể từ nhé bằng hữu.

4.2. Attribute

Attribute tức là thuộc tính. Thuộc tính của chủ yếu những entity này.

Nói tính chất nghe có vẻ như “IT” vượt lên trước. Anh em hoàn toàn có thể hiểu nó là những đặc tính của một đối tượng người sử dụng ngẫu nhiên. Là những vấn đề riêng biệt của đối tượng người sử dụng này mà bản thân tiếp tục tàng trữ.

Ví dụ Đơn hàng sẽ có được 5 vấn đề riêng không liên quan gì đến nhau sau, nhưng mà chỉ mất lô hàng mới mẻ đem, bao nhiêu thằng không giống không tồn tại, như:

• Ngày bịa đặt hàng
• Tổng chi phí ko giảm
• Tiền khuyến mãi
• Thành tiền
• Điều khoản thanh toán giao dịch.

Hoặc Khách hàng sẽ có được 7 vấn đề riêng không liên quan gì đến nhau sau nhưng mà bao nhiêu thằng không giống không tồn tại, như:

• Họ và tên
• Email
• Ngày sinh nhật
• Số năng lượng điện thoại
• Sở thích

Có thể đối tượng người sử dụng Đơn hàng và Khách hàng sẽ vẫn thật nhiều vấn đề không giống, tuy nhiên bản thân chỉ quan hoài cho tới nhiêu trên đây thông tin, nên bản thân chỉ tàng trữ nhiêu trên đây attribute thôi.

Chỗ PK (Primary Key) và FK (Foreign Key) nhằm lát trình bày sau nhé bằng hữu.

4.3. Relationship

Về cơ phiên bản thì relationship của ERD đem 3 loại:

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

Từ 3 loại này, bằng hữu tiếp tục thể hiện tại cụ thể rộng lớn vì thế 6 quan hệ như sau:

Mình tiếp tục thực tiễn rộng lớn mang lại bằng hữu vì thế sê ri: Mối mối quan hệ thân thiết Y TÁ vs. BỆNH NHÂN vô một khối hệ thống quản lý và vận hành cơ sở y tế như sau.

(Slideshow đem nút Pause ở thân thiết nhé anh em)

This slideshow requires JavaScript.

Hi vọng seri bên trên gom bằng hữu hiểu rõ chi tiết 6 quan hệ của ERD. Và cần thiết nhất, là cách đọc những quan hệ này.

Xem thêm: sư phạm là gì

Hiểu nhằm thực hiện gì?

Để khi người tiêu dùng tế bào miêu tả vì thế ngôn ngữ thông thường ngày của mình, thì bằng hữu hoàn toàn có thể lấy cái tê liệt >> gửi hóa nó trở nên ngôn ngữ ERD >> và phác thảo những nguyệt lão quan lại hệ đi ra như vọc.

Mấu chốt là bằng hữu cần thiết nhìn được: Quan hệ thân thiết 2 thực thể này đó là gì?

Khi tê liệt, ghép vô toàn cảnh ví dụ, bằng hữu tiếp tục hiểu rõ quan hệ thân thiết nhị thực thể này là gì, và qua quýt lăng kính business thực tế là như vậy nào?

❓ ❓ ❓ Ví dụ dò la quan hệ Một trong những thực thể sau:

• Khách sản phẩm – Đơn hàng
  • Khách sản phẩm có Đơn hàng
  • Đơn sản phẩm thuộc về Khách sản phẩm.
• Người sử dụng – Đặt điểm (Booking)
  • Người sử dụng tiến hành đặt Booking
  • Booking được đặt vì thế Người sử dụng.
• Dịch vụ – Hợp đồng
  • Dịch vụ nằm trong Hợp đồng
  • Hợp đồng bao gồm Thương Mại & Dịch Vụ.
• Nhân viên CSKH – Khách hàng
  • NV chăm sóc Khách hàng
  • Khách sản phẩm được siêng sóc vì thế NV.
• Sinh Viên – Sách
  • Sinh viên mượn Sách
  • Sách được mượn vì thế Sinh viên.
• Khách sản phẩm – Hoạt động tương tác
  • Khách sản phẩm thực hiện Hoạt động tương tác
  • Hoạt động tương tác được thực hiện vì thế Khách sản phẩm.

Ngoài đi ra, bằng hữu hoàn toàn có thể chú quí rõ rệt nguyệt lão quan lại hệ này vì thế một hình con cái thoi nhỏ.

Tóm gọn gàng váy phen một:

• Mối mối quan hệ Một trong những thực thể đều là: ĐỘNG TỪ (có, nằm trong, bịa đặt, che chở, mượn, thực hiện…)
• Khi gọi quan hệ theo hướng ngược lại, bằng hữu chỉ việc gửi nó trở nên THỂ BỊ ĐỘNG là xong xuôi 🙂 (được mượn, được che chở, được thực hiện…).

Tóm gọn gàng váy phen nhị, bằng hữu 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 tính hóa học – quánh điểm của thực thể (ví dụ người tiêu dùng thì cao 175cm, nặng nề 65kg, nam nữ Nam, vị trí căn nhà, email…)
• Còn quan hệ thì ám chỉ ĐỘNG TỪ.

Nhận diện được những đối tượng người sử dụng này, bằng hữu tiếp tục dễ dàng và đơn giản bóc tách ngữ điệu thông thường ngày của người tiêu dùng trở nên những đối tượng người sử dụng vô ERD ==> phác hoạ họa nhanh gọn & đúng chuẩn rộng lớn.

*NOTE KHÔNG HỀ NHỎ: Thực hỏng mối quan hệ NHIỀU-NHIỀU xoay lên đường quẩn lại cũng đó là mối quan hệ 1-NHIỀU. Chi tiết như nào là coi tiếp phần bên dưới nhé bằng hữu 😎 

5. Thực hỏng đối chọi, 1-nhiều, và nhiều-nhiều?!?

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

Phần bên trên bằng hữu vẫn hiểu được: entity, attribute và relationship trong ERD. Nhưng nếu như bằng hữu vẫn còn đấy thắc mắc:

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

1-nhiều, rồi nhiều-nhiều THỰC TẾ không giống nhau như vậy nào?

Thì ở trong phần tiếp sau đây, bản thân tiếp tục trả lời vướng mắc này mang lại bằng hữu.

5.1. Relational Database

Đầu tiên bằng hữu cần thiết tưởng tượng lại đôi lúc về Relational Database.

Relational Database nôm mãng cầu là những database được tổ chức trở nên nhiều bảng, và Một trong những bảng quan hệ cùng nhau vì thế các khóa.

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

Mapping với định nghĩa ERD, 1 table đó là 1 entity (một đối tượng người sử dụng, hoặc một thực thể) nhưng mà database tàng trữ.

Table thì giản đơn đem những cột và dòng. Như ví dụ trên:

• Cột đó là tính chất (attribute) của đối tượng người sử dụng Customer, bao hàm cột: Last Name, First Name, Thư điện tử, bla, bla… những loại.
• Còn dòng là những “bản ghi”, mình hoặc gọi là những record, là con số tài liệu nhưng mà table tê liệt tàng trữ vô database.

Từ ví dụ bên trên, bằng hữu hoàn toàn có thể Kết luận như sau về table Customer:

• Table này bao 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 giờ đang tàng trữ 23 records (vì đem 23 dòng sản phẩm dữ liệu).

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

Bản hóa học thì khóa chủ yếu cũng chỉ là một trong cột, vô hằng hà những cột nhưng mà table tàng trữ. Nhưng nó khác lạ ở chỗ:

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

Khóa đó là loại tồn bên trên song lập có một không hai (và ko được giống như nhau).
Tất cả những cột không giống, giống như nhau hay là không, ko cần thiết.

Còn trình bày theo gót ngữ điệu lập trình sẵn thì: khóa đó là loại nhằm định danh duy nhất từng phiên bản ghi vô table của hạ tầng tài liệu. 

Tiếp theo gót là khóa nước ngoài (Foreign Key).

Vì những table link cùng nhau. Nhưng nhằm link cùng nhau thì nó cần đem điểm chung nào là tê liệt. Foreign Key đó là điểm cộng đồng tê liệt. Nó là key dùng để làm link 2 tables lại cùng nhau.

Foreign Key được xem là Primary Key ở một table, tuy nhiên lại là Foreign Key ở một table khác nhưng mà table tê liệt link cho tới.

5.2. Giải nghĩa những nguyệt lão quan lại hệ

Phần này phân tích và lý giải mang lại thắc mắc nhức nhói nhất nãy giờ: Đâu là việc khác lạ trên khối hệ thống thực tế, Một trong những quan lại hệ:

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

Bằng cơ hội, đem bằng hữu cho tới với ứng dụng thực tiễn 😎

.

.

.

Ô kê, thứ nhất bản thân đem 4 entity với những attribute như sau.

Mình tiếp tục mang lại 4 entity này mối quan hệ cùng nhau như sau:

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

Nhưng khoan,

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

Thế là Entity E Ra đời. Hình ảnh chen vô giữa anh B và anh C như sau.

Ô kê sắp tới đây bằng hữu vẫn có: các thực thể và đã liên kết bọn chúng cùng nhau.

…

Nhưng trước lúc lên đường tiếp bản thân có một câu hỏi: Bản hóa học mối quan hệ 1-nhiều tức là sao?

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

Nghĩa là, 1 record A bao hàm thật nhiều record B. Hoặc, nhiều record B nằm trong link cho tới 1 record A.

Do tê liệt, nhằm tưởng tượng mối quan hệ 1-nhiều dễ dàng và đơn giản, bằng hữu cứ tưởng tượng cho tới cái LƯỚI hoặc BẢNG là được. Vì lưới hoặc bảng đem rất nhiều DÒNG vô tê liệt.

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

Dưới trên đây tiếp tục là: so sánh thân thiết ERD và thực tế phần mềm nhằm bằng hữu tưởng tượng rõ rệt điều tôi vừa trình bày phía trên nhé.

(Slide Show đem nút Pause ở trung tâm nhé anh em).

This slideshow requires JavaScript.

Để ví dụ bên trên dễ dàng tưởng tượng, bản thân tiếp tục thay cho những entity giả thiết này vì thế những entity thực tế như sau.

ERD map với thực tiễn

Có một mẹo điểm này: Làm sao nhằm xác lập FK mang lại nhanh?

Xem thêm: biểu tượng là gì

Nếu 2 table mối quan hệ 1-nhiều cùng nhau, bằng hữu chỉ việc lấy PK của table ở đầu mối quan hệ 1, bỏ vô FK của table ở đầu mối quan hệ nhiều, là xong xuôi 🙂

…

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