Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Sai lầm sơ đồ ER thường gặp

Tìm hiểu sơ đồ ER (Mối quan hệ thực thể), các bộ phận của nó và những gì thường xảy ra khi tạo nó.

Bạn đã bao giờ tạo mô hình cơ sở dữ liệu quan hệ chưa? Hoặc có thể bạn đang cố gắng tạo cái đầu tiên của mình? Bạn biết đấy (hoặc bạn sẽ sớm phát hiện ra) rằng việc chuyển các vấn đề trong thế giới thực sang logic cơ sở dữ liệu đôi khi có thể khá khó khăn.

Một trong những công cụ có thể giúp bạn là sơ đồ ER. Sự khôn ngoan trong thiết kế cơ sở dữ liệu thông thường cho rằng sơ đồ ER của bạn càng tốt thì việc xây dựng mô hình cơ sở dữ liệu càng dễ dàng. Mục quan trọng này thiết lập giai điệu cho tất cả những thất vọng hoặc thành công trong tương lai. Với một sơ đồ ER tốt, việc tạo một mô hình cơ sở dữ liệu quan hệ khá đơn giản. Tất nhiên, sai lầm có thể được thực hiện trong bất kỳ giai đoạn nào của mô hình cơ sở dữ liệu. Tuy nhiên, có một sơ đồ ER tốt có thể giúp bạn tránh được một số sai lầm đó.

Vì vậy, chúng ta hãy xem sơ đồ ER là gì và làm thế nào chúng ta có thể tránh những sai lầm phổ biến của nó.

Sơ đồ ER là gì?

“Sơ đồ ER”, hay ERD, là viết tắt của Sơ đồ mối quan hệ thực thể. Nó vạch ra vấn đề cần được mô hình hóa, nhưng theo một cách có cấu trúc cho thấy mối quan hệ giữa các thực thể.

Khối xây dựng của Sơ đồ ER

Sơ đồ ER bao gồm các yếu tố sau:

  • Thực thể
  • Mối quan hệ
  • Thuộc tính thực thể hoặc mối quan hệ

Phần tử đầu tiên của sơ đồ ER là thực thể . Thực thể là một đối tượng hoặc sự kiện mà chúng ta muốn lưu trữ thông tin. Về cơ bản, đó là bất cứ thứ gì mà chúng tôi có thể thu thập dữ liệu. Ví dụ:chúng tôi có thể lưu trữ dữ liệu về nhân viên, sinh viên, giáo viên, người mua, sản phẩm, phòng ban, thanh toán, địa điểm, v.v.

Khi chúng ta có các thực thể, cần phải tạo ra các mối quan hệ . Mối quan hệ cho biết cách một thực thể được kết nối và liên kết với một hoặc nhiều thực thể khác.

Phần tử cuối cùng của sơ đồ ER là một thực thể hoặc một thuộc tính mối quan hệ . Thuộc tính là một mô tả của một thuộc tính thuộc về một thực thể hoặc mối quan hệ. Các thuộc tính có giá trị. Một số thuộc tính cho các thực thể được đề cập ở trên có thể là:

  • Nhân viên, sinh viên, giáo viên, người mua - ID, tên, họ, ngày sinh, địa chỉ, v.v.
  • Sản phẩm - ID, danh mục, mô tả, màu sắc, số sê-ri, v.v.
  • Bộ phận - ID, tên bộ phận, trưởng bộ phận, số lượng nhân viên, v.v.
  • Thanh toán - ID, ngày giờ, số tiền.
  • Vị trí - Thành phố, mã ZIP, vùng, quốc gia, lục địa.

Các loại mối quan hệ

Trước khi chúng ta mắc phải những sai lầm thông thường được tìm thấy trong sơ đồ ER, điều quan trọng là phải hiểu các loại mối quan hệ có thể có. Hầu hết các lỗi ERD về cơ bản là các mối quan hệ được xác định sai giữa các thực thể.

Có ba loại mối quan hệ giữa các thực thể:

  • Một-một (1:1)
  • Một-nhiều (1:N)
  • Nhiều-nhiều (M:N)

Mối quan hệ một đối một (1:1)

Loại mối quan hệ đầu tiên là một-một hoặc 1:1 . Trong mối quan hệ này, một cá thể của một thực thể chỉ có thể được kết nối với một cá thể của một thực thể khác (tất nhiên là ngược lại).

Giả sử rằng chúng ta có thực thể sinh viên với các thuộc tính tên họ . Chúng tôi cũng có thực thể id với thuộc tính duy nhất id . Mối quan hệ 1:1 có nghĩa là một sinh viên chỉ có thể có một số ID. Điều đó cũng có nghĩa là một số ID chỉ có thể thuộc về một học sinh.

Mối quan hệ này rất hiếm khi thấy trong cơ sở dữ liệu. Nếu chỉ có thể kết nối một ID với duy nhất một sinh viên, thì không cần phải tách chúng thành hai thực thể khác nhau.

Đây là một ví dụ về mối quan hệ này:

Mối quan hệ một-nhiều (1:N)

Loại mối quan hệ cơ sở dữ liệu phổ biến nhất là một-nhiều hoặc 1:N . Mối quan hệ Một-nhiều có nghĩa là mỗi phiên bản của một thực thể có thể được kết nối với nhiều phiên bản của một thực thể khác. Điều đó cũng có nghĩa là mọi thể hiện của thực thể thứ hai chỉ có thể được liên kết với một thể hiện của thực thể đầu tiên.

Ví dụ:có một thực thể người mua với các thuộc tính id , tên họ . Chúng tôi muốn thiết lập mối quan hệ với pháp nhân thanh toán có các thuộc tính id , ngày giá trị . Đây là mối quan hệ 1:N vì một người mua có thể thực hiện một hoặc nhiều khoản thanh toán. Tuy nhiên, một số người mua không thể thực hiện một khoản thanh toán; nó chỉ có thể được thực hiện bởi một người mua.

Đây là ví dụ:

Mối quan hệ này cũng có thể được nhìn nhận theo cách khác. Trong tình huống này, nó được gọi là nhiều-một hoặc N:1 . Tất nhiên, đây không phải là một kiểu quan hệ mới. Nó giống như 1:N, nhưng nó được nhìn từ hướng ngược lại.

Ví dụ:giả sử chúng ta có thực thể nhân viên với các thuộc tính id , tên họ . Chúng tôi muốn thành lập nhân viên Mối quan hệ của tổ chức bộ phận có các thuộc tính id tên . Mối quan hệ giữa hai thực thể này là N:1. Điều này có nghĩa là mỗi nhân viên chỉ có thể làm việc trong một bộ phận, nhưng nhiều nhân viên có thể làm việc trong cùng một bộ phận.

Mối quan hệ nhiều-nhiều (M:N)

Đ Nhiều đến nhiều hoặc M:N mối quan hệ có nghĩa là mọi phiên bản của thực thể đầu tiên có thể được liên kết với nhiều hơn một phiên bản của thực thể thứ hai. Điều đó cũng có nghĩa là mọi thể hiện của thực thể thứ hai có thể được liên kết với nhiều thể hiện của thực thể đầu tiên.

Hãy xem điều này hoạt động như thế nào giữa các thực thể sinh viên bài giảng . Hãy nói rằng học sinh có thuộc tính id , tên họ . Thực thể bài giảng có thuộc tính id tên . Mối quan hệ nhiều-nhiều có thể được hiểu theo cách sau:một sinh viên có thể tham dự một hoặc nhiều bài giảng, trong khi một bài giảng có thể được tham gia bởi một hoặc nhiều sinh viên.

Đây là sơ đồ cho ví dụ này:

Trong mô hình cơ sở dữ liệu, các mối quan hệ như vậy thường được chia thành hai hoặc nhiều mối quan hệ 1:N hoặc N:1 bằng cách giới thiệu các thực thể mới.

Những sai lầm điển hình mắc phải khi tạo sơ đồ ER

Nhiều lỗi sơ đồ ER phù hợp với một trong bốn loại sau:

  • Mối quan hệ không chính xác giữa các thực thể
  • Sử dụng một cá thể thực thể thay vì một thực thể
  • Nhầm lẫn một thuộc tính với một thực thể
  • Thuộc tính phức tạp

Hãy xem xét từng cái riêng lẻ.

Mối quan hệ không chính xác giữa các thực thể

Những sai lầm phổ biến nhất xảy ra khi xác định mối quan hệ giữa các thực thể . Thường không có sai lầm trong mối quan hệ 1:1. Tuy nhiên, rất dễ nhầm lẫn giữa mối quan hệ 1:N với mối quan hệ M:N. Điều này thường bắt nguồn từ việc không hiểu các yêu cầu do người dùng cuối cung cấp. Điều quan trọng là phải có các yêu cầu được xác định rất rõ ràng và hiểu biết sâu sắc về lý do tại sao cơ sở dữ liệu là cần thiết và nó sẽ được sử dụng như thế nào. Nếu chúng tôi tạo một sơ đồ ER với không đủ dữ liệu và sự hiểu biết không đầy đủ, rất có thể sẽ dẫn đến việc xác định sai mối quan hệ giữa các thực thể.

Hãy xem một ví dụ. Nếu bạn đang tạo cơ sở dữ liệu cho một ngân hàng, hầu hết bạn có thể sẽ tạo một sơ đồ ER với thực thể khách hàng có các thuộc tính id , tên họ . Bạn cũng sẽ có một thực thể được gọi là tài khoản với các thuộc tính id loại . Nếu bạn thiếu kinh nghiệm trong ngành ngân hàng, có thể bạn sẽ nghĩ rằng luôn có mối quan hệ 1:N giữa khách hàng tài khoản các thực thể, như được hiển thị bên dưới.

Một khách hàng có thể có nhiều tài khoản trong một ngân hàng. Tuy nhiên, một tài khoản chỉ có thể được sở hữu bởi một khách hàng. Điều này có thực sự đúng? Có thể có, có thể không. Khá nhiều ngân hàng cung cấp tài khoản chung có thể được sử dụng bởi một số khách hàng. Bạn có đang tạo sơ đồ ER cho một ngân hàng cung cấp dịch vụ như vậy không? Nếu ngân hàng không cung cấp tài khoản chung, thì bạn đã đúng:mối quan hệ giữa khách hàng tài khoản là 1:N. Tuy nhiên, nếu ngân hàng cung cấp tài khoản chung, thì mối quan hệ là M:N.

Sử dụng một thực thể thay vì một thực thể

Một sai lầm phổ biến khác là sử dụng một cá thể thực thể thay vì một thực thể. Một cá thể thực thể là một sự xuất hiện đơn lẻ của một thực thể nhất định - tức là một thực thể thực sự có thể là một thuộc tính của một danh mục lớn hơn.

Giả sử chúng tôi làm việc trong một công ty phân phối điện thoại di động và máy tính xách tay cho một số nhân viên nhất định. Vì vậy, trong cơ sở dữ liệu của chúng tôi, chúng tôi sẽ có một thực thể được gọi là máy tính xách tay với các thuộc tính id mô hình và một thực thể có tên là nhân viên với các thuộc tính id , tên họ , đúng?

Có một vấn đề ở đây:máy tính xách tay thực sự không phải là một thực thể - cũng có điện thoại di động để giải thích. Giải pháp là thay thế thực thể máy tính xách tay với một thực thể chung chung hơn, chẳng hạn như thiết bị . Thực thể này có thể có các thuộc tính ID , loại mô hình , như hình dưới đây. Loại có thể bao gồm các giá trị chẳng hạn như điện thoại , PC , máy tính bảng máy tính xách tay . Bằng cách này, không cần tạo một thực thể riêng biệt cho mọi loại thiết bị.

Bạn có thể tìm thấy ví dụ ở đây:

Nhầm lẫn một thuộc tính với một thực thể

Sai lầm phổ biến tiếp theo là nhầm lẫn một thuộc tính với một thực thể. Giả sử chúng tôi đã quyết định tạo một thực thể có tên là nhân viên sẽ bao gồm các thuộc tính id , tên , họ , date_birth , id_department , tên_căn_bộ head_department . Thực thể này sẽ khiến chúng tôi gặp rắc rối khi tạo mô hình cơ sở dữ liệu vì nó bao gồm quá nhiều thuộc tính không xác định duy nhất thực thể cụ thể này .

Hãy nhớ rằng, chúng tôi đã định nghĩa các thực thể là bất kỳ thứ gì mà chúng tôi có thể thu thập dữ liệu. Với suy nghĩ đó, chúng ta có thể thấy rằng nhân viên hiện tại thực thể có thể được chia thành hai thực thể: nhân viên bộ phận , như hình dưới đây.

Thuộc tính phức tạp

Sai lầm phổ biến cuối cùng mà chúng ta sẽ nói đến là bao gồm một thuộc tính phức tạp trong một thực thể. Nói cách khác, chúng ta có một thuộc tính thực sự phải là thực thể của chính nó .

Giả sử chúng ta có một thực thể có tên là sinh viên được xác định bởi các thuộc tính sau: id , tên , họ , date_birth , địa chỉ exam_passed . Đây, exam_passed là một thuộc tính phức tạp bao gồm nhiều thông tin, tức là ID, ngày thi và điểm của học sinh. Để nó theo cách đó sẽ là một sai lầm. Thay vào đó, chúng ta nên tạo một thực thể mới ra khỏi thuộc tính phức tạp này . Thực thể mới có thể được đặt tên là kỳ thi và bao gồm các thuộc tính sau: id , ngày , student_id điểm số .

Bạn có thể tìm thấy ví dụ ở đây:

Bạn có Nhận được Lời khuyên Sơ đồ ER Hữu ích nào không?

Bốn loại sai lầm này là những lỗi phổ biến nhất trong quá trình tạo sơ đồ ER. Tất nhiên, không có danh sách đầy đủ các sai lầm điển hình hoặc các loại sai lầm. Trong cuộc sống thực, rất nhiều loại sai lầm có thể xảy ra. Việc thiếu kế hoạch, không đủ hỗ trợ kỹ thuật và quá trình thiết kế cơ sở dữ liệu gấp rút đều góp phần gây ra các vấn đề riêng. Nếu bạn đã từng tạo cơ sở dữ liệu hoặc tham gia vào nó từ phía doanh nghiệp, bạn có thể đã trải qua một số cơ sở dữ liệu đó! Tất cả những trường hợp đó đều dẫn đến những sai lầm khác nhau, một số trong số đó khá độc đáo.

Bạn có ví dụ của riêng mình về một sơ đồ ER không tốt không? Hoặc có thể có một số sai lầm khác mà bạn thấy thường xuyên? Vui lòng cho tôi biết trong phần bình luận.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Trực quan hóa dữ liệu

  2. Biểu thức bảng thông thường:Khi nào và làm thế nào để sử dụng chúng

  3. Nhóm dữ liệu bằng cách sử dụng hàm OVER và PARTITION BY

  4. Kết nối SQuirreL SQL với Microsoft Excel

  5. Thiết lập con cơ sở dữ liệu - Cách sử dụng IRI Voracity