Mô hình dữ liệu mối quan hệ thực thể (Entity-Relationship Data Model)

Mô hình dữ liệu mối quan hệ thực thể (Entity-Relationship Data Model)

Ví dụ: Thiết kế mô hình quan hệ thực thể (ER) cho cơ sở dữ liệu của trường đại học

Cơ sở dữ liệu của trường đại học

Lưu trữ thông tin chi tiết về sinh viên đại học (STUDENT), các khóa học (PROGRAM), học kỳ (COURSE) mà sinh viên đã tham gia một khóa học cụ thể (và điểm của sinh viên nếu sinh viên đã hoàn thành nó) và bằng cấp cho mỗi sinh viên đã đăng ký học. Cơ sở dữ liệu mang tính chất minh họa các mối quan hệ để dễ hình dung.

Entities:

• STUDENT.
• PROGRAM.
• COURSE.

Attributes:

• Sinh viên có một hoặc nhiều tên riêng, họ, mã định danh sinh viên, ngày tháng năm sinh & năm họ ghi danh lần đầu. 
• Một chương trình có tên, mã định danh chương trình, tổng điểm tín chỉ cần thiết để tốt nghiệp và năm bắt đầu.
• Một khóa học có tên, mã định danh khóa học, giá trị điểm tín chỉ, một năm (ví dụ: năm 1) và một học kỳ (ví dụ: học kỳ 1).

Relationships:

• Trường đại học cung cấp một hoặc nhiều chương trình.
• Một chương trình được tạo thành từ một hoặc nhiều khóa học.
• Một sinh viên phải ghi danh vào một chương trình.
• Một sinh viên tham gia các khóa học nằm trong chương trình của mình.
• Khi một sinh viên tham gia một khóa học, năm học & học kỳ sinh viên đó đã học sẽ được ghi lại. Khi sinh viên kết thúc khóa học, kết quả (điểm số) sẽ được ghi lại.

ER diagram

Giải thích:

• STUDENT là một thực thể mạnh, với mã số định danh: Student_Id, được tạo ra để làm khóa chính dùng để phân biệt giữa các học sinh (chúng ta có thể có sinh viên cùng tên).
• PROGRAM là một thực thể mạnh, với mã số định danh: Program_Id, là khóa chính được sử dụng để phân biệt giữa các PROGRAM.
• Mỗi sinh viên phải đăng ký vào một chương trình, vì vậy thực thể STUDENT tham gia hoàn toàn vào mối quan hệ ENROLLS_IN nhiều-một với PROGRAM. Một chương trình có thể tồn tại mà không cần có bất kỳ sinh viên đăng ký nào, vì vậy nó tham gia một phần vào mối quan hệ này.
• COURSE có ý nghĩa khi tồn tại PROGRAM, vì vậy nó là một thực thể yếu, với Course_Id như một khóa yếu. Có nghĩa là một thực thể COURSE được xác định duy nhất bằng cách sử dụng thêm mã định danh của PROGRAM: Course_Id và Program_Id. Là một thực thể yếu, COURSE hoàn toàn tham gia vào mối quan hệ xác định nhiều-một với PROGRAM của chính nó.
• STUDENT và COURSE có liên quan thông qua mối quan hệ nhiều-nhiều: ATTEMPTS; một COURSE có thể tồn tại mà không có sinh viên và một STUDENT có thể được ghi danh mà không cần học bất kỳ khóa học nào.
• Khi một sinh viên tiếp cận một khóa học, có những thuộc tính cần thiết để ghi nhận như: Year, Semester, Mark, Grade.

Kiến trúc Three-Schema

Ba cấp độ của trừu tượng hóa dữ liệu (Data abstraction).

Mục tiêu của kiến trúc này là tách những ứng dụng người dùng ra khỏi mô hình dữ liệu vật lý.

Kiến trúc three-schemas

Trong kiến trúc này, các lược đồ có thể xác định ở ba cấp độ sau:

1. External Schema

Lược đồ bên ngoài: Là phần cơ sở dữ liệu mà người dùng cụ thể quan tâm. Nó ẩn các chi tiết không liên quan đến người dùng như việc truy xuất hoặc lưu trữ dữ liệu.

Ví dụ: một người dùng phòng kinh doanh sẽ chỉ thấy dữ liệu liên quan đến bán hàng.

2. Conceptual Schema

Lược đồ khái niệm: Mô tả cấu trúc cơ sở dữ liệu của toàn bộ cơ sở dữ liệu cho cộng đồng người dùng. Lược đồ này ẩn thông tin về cấu trúc lưu trữ vật lý và tập trung vào việc mô tả kiểu dữ liệu, thực thể, mối quan hệ,...

3. Internal Schema 

Mô tả cách cơ sở dữ liệu được lưu trữ trên các thiết bị vật lý như ổ cứng. Lược đồ nội bộ sử dụng mô hình dữ liệu vật lý và mô tả chi tiết đầy đủ về đường dẫn truy cập và lưu trữ dữ liệu cho cơ sở dữ liệu.

Ví dụ về kiến trúc three-schemas

Để rõ ràng hơn, hãy xem xét ví dụ về việc truy cập một trang web thông qua máy tính cá nhân.

Trình duyệt web trên máy tính của bạn là cấp bên ngoài (1) vì bạn chỉ nhận được trang web được hiển thị trên màn hình của mình mà không cần biết những gì đang diễn ra bên trong. Máy chủ lưu trữ trang web là cấp độ khái niệm (2) khi nó nhận yêu cầu của bạn, truy xuất dữ liệu bạn muốn từ cơ sở dữ liệu và sau đó gửi dữ liệu đó trở lại máy tính của bạn. Cơ sở dữ liệu (được lưu trữ trên một số phương tiện vật lý) đại diện cho mức vật lý. Nó chứa dữ liệu bạn quan tâm.

Tại sao phải sử dụng three-schemas

• Nhiều người dùng sẽ truy cập vào cùng một dữ liệu, nhưng có thể xem các tùy chỉnh dữ liệu khác nhau.
• Người dùng không cần tác động trực tiếp lên cơ sở dữ liệu vật lý.
• Người quản trị cơ sở dữ liệu có thể thay đổi cấu trúc lưu trữ cơ sở dữ liệu mà không làm ảnh hưởng đến chế độ xem của người dùng.
• Khi có các thay đổi được thực hiện đối với các khía cạnh vật lý của lưu trữ thì cấu trúc bên trong của cơ sở dữ liệu sẽ không bị ảnh hưởng.

Mô hình dữ liệu (Data models)

Giới thiệu về mô hình dữ liệu

Mô hình dữ liệu là một tập hợp các khái niệm hoặc ký hiệu để mô tả dữ liệu, mối quan hệ dữ liệu (data relationships), ngữ nghĩa dữ liệu (data semantics) & các ràng buộc dữ liệu (constraints data).

Để lưu trữ dữ liệu trên hệ thống cơ sở dữ liệu, chúng ta cần một số cấu trúc dữ liệu. Nhưng hệ thống cơ sở dữ liệu thường bao gồm một số cấu trúc dữ liệu phức tạp mà người dùng không sử dụng. Để hiệu quả về mặt truy xuất dữ liệu và giảm độ phức tạp cho người dùng, các nhà phát triển đã trừu tượng hóa dữ liệu (data abstraction), tức là ẩn các chi tiết không liên quan khỏi người dùng.

Các loại mô hình dữ liệu:

1 - Mô hình dữ liệu High-level conceptual

Mô hình dữ liệu High-level conceptual cung cấp cách trình bày dữ liệu tương tự như cách mọi người nhìn nhận dữ liệu. Một ví dụ điển hình là mô hình mối quan hệ thực thể, sử dụng các khái niệm như thực thể, thuộc tính và mối quan hệ.

Mô hình mối quan hệ thực thể

Một thực thể đại diện cho một đối tượng trong thế giới thực, chẳng hạn như một nhân viên hoặc một dự án. Thực thể có các thuộc tính đại diện như tên, địa chỉ và ngày sinh của nhân viên. Mối quan hệ thể hiện sự liên kết giữa các thực thể; ví dụ, một nhân viên làm việc trong nhiều dự án. Một mối quan hệ tồn tại giữa nhân viên và mỗi dự án.

2 - Mô hình dữ liệu Record-based logical

Các mô hình dữ liệu logic dựa trên bản ghi cung cấp các khái niệm mà người dùng có thể hiểu nhưng vẫn tương tự như cách dữ liệu được lưu trữ trên máy tính. 3 mô hình dữ liệu nổi tiếng thuộc loại này là:

• Hierarchical: Cấu trúc này bắt buộc mỗi bản ghi CON chỉ có một CHA, trong khi mỗi bản ghi CHA có thể có một hoặc nhiều bản ghi con

Car có hai con là Engine và Body,...

• Network: Sau này được thay thế bởi mô hình quan hệ.
• Relational: Mô hình quan hệ biểu diễn dữ liệu dưới dạng quan hệ hoặc bảng. Ví dụ, hệ thống cơ sở dữ liệu trường đại học chứa nhiều bảng (quan hệ) mà lần lượt có một số thuộc tính (cột) và bộ dữ liệu (hàng).

3 - Mô hình dữ liệu Physical.

Biểu thị cách dữ liệu được lưu trữ trong bộ nhớ máy tính, cách nó được phân tán và sắp xếp trong bộ nhớ, và cách nó sẽ được truy xuất từ ​​bộ nhớ. Về cơ bản, mô hình dữ liệu vật lý đại diện cho mỗi bảng, cột và thông số kỹ thuật của nó, v.v. Nó cũng nêu bật cách các bảng được xây dựng và liên quan với nhau trong cơ sở dữ liệu.

Bảng STUDENT có liên quan đến bảng DEPARTMENT thông qua thuộc tính Dep_Id.

Chúng ta có thể thấy bảng STUDENT bao gồm các thuộc tính như Std_Id, Std_Name, Age với các kiểu dữ liệu của chúng, tương tự đối với bảng DEPARTMENT. Mũi tên cho thấy hai bảng này được kết nối như thế nào trong mô hình này.

SQL và NoSQL

Nói về cơ sở dữ liệu (CSDL), có hai loại giải pháp chính: SQL và NoSQL (CSDL quan hệ và CSDL phi quan hệ). Cả hai đều khác nhau về cách chúng được xây dựng, loại thông tin lưu trữ và phương pháp lưu trữ mà chúng sử dụng.

CSDL quan hệ được cấu trúc và có các lược đồ được xác định trước như danh bạ lưu trữ số điện thoại và địa chỉ. CSDL phi quan hệ thì không có cấu trúc, được phân phối và có một lược đồ động như các thư mục, tập tin chứa mọi thứ từ địa chỉ, số điện thoại của một người đến các sở thích mua sắm trực tuyến và những lượt 'like' trên Facebook của họ.

#SQL

CSQL quan hệ lưu trữ dữ liệu theo hàng và cột. Mỗi hàng chứa tất cả thông tin về một thực thể và mỗi cột chứa tất cả các điểm dữ liệu riêng biệt. Một số CSDL quan hệ phổ biến nhất là MySQL, Oracle, MS SQL Server, SQLite, Postgres và MariaDB.

#NoSQL

Sau đây là các loại NoSQL phổ biến nhất:

Key-Value Stores: Dữ liệu được lưu trữ trong một mảng các cặp key-value. 'Key' là tên thuộc tính được liên kết với 'Value'. Các hệ quản trị Key-Values phổ biến như: Redis, Voldemort và Dynamo.

Document Databases: Trong các CSDL này, dữ liệu được lưu trữ trong Document (thay vì các hàng và cột trong bảng) và các Document này được nhóm lại với nhau trong các bộ sưu tập. Mỗi Document có thể có cấu trúc hoàn toàn khác nhau. Document Databases phổ biến như CouchDB và MongoDB.

Wide-Column Databases: Thay vì là 'tables', CSDL cột có tập các cột là nơi chứa cho các hàng. Không giống như SQL, chúng ta không cần biết tất cả các cột ở phía trước và mỗi hàng không nhất thiết phải có cùng số cột. Cơ sở dữ liệu cột phù hợp nhất để phân tích các tập dữ liệu lớn. Những tên tuổi lớn: Cassandra và HBase.

Graph Databases: Khi mà các mối quan hệ của dữ liệu được biểu diễn tốt nhất trong một biểu đồ thì hãy suy nghĩ đến Graph Database. Dữ liệu được lưu trong cấu trúc đồ thị với các nodes (thực thể), properties (thông tin về các thực thể) và lines (kết nối giữa các thực thể). Ví dụ: Neo4J và InfiniteGraph.

#Những sự khác biệt nhất giữa SQL và NoSQL

Storage: SQL lưu trữ dữ liệu trong các bảng trong đó mỗi hàng đại diện cho một thực thể và mỗi cột đại diện cho một điểm dữ liệu về thực thể đó; ví dụ: Nếu ta lưu trữ một thực thể xe hơi trong một bảng, các cột khác nhau có thể là 'Màu', 'Kiểu dáng', 'Loại xe', v.v.

Cơ sở dữ liệu NoSQL có các mô hình lưu trữ dữ liệu khác nhau. Những thứ chính là Key-Values, Document, Graph và Column. 

Schema: Trong SQL, mỗi record (bản ghi) tuân theo một lược đồ cố định, nghĩa là các cột phải được quyết định và chọn trước khi nhập dữ liệu và mỗi hàng phải có dữ liệu cho mỗi cột. Lược đồ có thể được thay đổi sau đó, nhưng nó liên quan đến việc sửa đổi toàn bộ CSDL.

Trong NoSQL, các lược đồ là động. Các cột có thể được thêm nhanh chóng và mỗi 'hàng' (hoặc tương đương) không cần phải chứa dữ liệu cho mỗi 'cột.'

Querying: Hệ quản trị CSDL SQL sử dụng ngôn ngữ SQL (structured query language: ngôn ngữ truy vấn có cấu trúc) để xác định và thao tác dữ liệu, đây là điểm mạnh. Trong hệ quản trị NoSQL, các truy vấn tập trung vào một tập hợp các tài liệu. Đôi khi nó còn được gọi là UnQL (Ngôn ngữ truy vấn không có cấu trúc). Các hệ CSDL khác nhau có các cú pháp sử dụng UnQL khác nhau.

Scalability: Trong hầu hết các tình huống phổ biến, Hệ quản trị CSDL SQL có thể mở rộng theo chiều dọc, tức là nâng cấp phần cứng (RAM, CPU, v.v.), điều này có thể gây tốn kém, chúng ta cũng có thể mở rộng bằng cách thêm nhiều máy chủ nhưng sẽ có nhiều thử thách và mất thời gian.

Trong khi đó, hệ quản trị CSDL NoSQL có khả năng mở rộng theo chiều ngang, có nghĩa là chúng ta có thể dễ dàng thêm nhiều máy chủ hơn trong cơ sở hạ tầng NoSQL để xử lý nhiều lưu lượng truy cập. Bất kỳ phần cứng thông dụng hay cloud cũng có thể lưu trữ CSDL NoSQL, do đó nó tiết kiệm chi phí hơn rất nhiều so với mở rộng theo chiều dọc. Rất nhiều công nghệ NoSQL tự động phân phối dữ liệu trên các máy chủ.

Reliability or ACID Compliancy (Atomicity, Consistency, Isolation, Durability): Phần lớn các hệ quản trị CSQL SQL đều tuân thủ ACID. Vì thế  khi nói đến độ tin cậy của dữ liệu và đảm bảo an toàn khi thực hiện các giao dịch, cơ sở dữ liệu SQL vẫn là lựa chọn hàng đầu.

Hầu hết các giải pháp NoSQL ưu tiên cho hiệu suất và khả năng mở rộng, nên hi sinh ACID .

#SQL vs NoSQL - Sử dụng cái nào?

Khi nói đến công nghệ, không có 1 giải pháp nào phù hợp với tất cả. Đó là lý do tại sao nhiều doanh nghiệp dựa vào cả SQL và NoSQL cho những nhu cầu khác nhau. NoSQL đang trở nên phổ biến vì tốc độ và khả năng mở rộng thì SQL có thể hoạt động tốt hơn ở một số ngữ cảnh; Chúng ta cần lựa chọn công nghệ nào phù hợp với từng trường hợp sử dụng.

Dưới đây là một số lý do để chọn cơ sở dữ liệu SQL:

1. Chúng tôi cần đảm bảo ACID. Việc tuân thủ ACID làm giảm sự rủi ro và bảo vệ tính toàn vẹn của CSDL bằng cách chỉ định chính xác cách mà các giao dịch tương tác với CSDL. Nói chung, cơ sở dữ liệu NoSQL hy sinh tuân thủ ACID để có khả năng mở rộng và tốc độ xử lý, nhưng đối với nhiều ứng dụng thương mại điện tử và tài chính, CSDL tuân thủ quy tắc ACID vẫn là lựa chọn ưu tiên.
2. Dữ liệu của bạn có cấu trúc và không thay đổi. Nếu doanh nghiệp của bạn không có sự phát triển vượt bậc đòi hỏi nhiều máy chủ hơn và nếu bạn chỉ làm việc với dữ liệu có tính nhất quán, thì có thể không có lý do gì để sử dụng một hệ thống được thiết kế để hỗ trợ nhiều loại dữ liệu và lưu lượng truy cập cao.

Lý do sử dụng cơ sở dữ liệu NoSQL:

Big data (dữ liệu lớn) đang tạo nên sự thành công lớn cho NoSQL, chủ yếu là do chúng xử lý dữ liệu khác với cách xử lý của SQL. Một vài ví dụ phổ biến về cơ sở dữ liệu NoSQL là MongoDB, CouchDB, Cassandra và HBase.

1. Lưu trữ khối lượng lớn dữ liệu không có cấu trúc hoặc ít cấu trúc. NoSQL không đặt ra giới hạn về các loại dữ liệu mà chúng ta có thể lưu trữ cùng nhau và cho phép chúng ta thêm các loại dữ liệu mới khi nhu cầu thay đổi. Với Document Database, bạn có thể lưu trữ dữ liệu ở một nơi mà không cần phải xác định trước “loại” dữ liệu nào.
2. Khai thác tối đa điện toán đám mây và lưu trữ. Lưu trữ dựa trên đám mây là một giải pháp tiết kiệm chi phí tuyệt vời nhưng yêu cầu dữ liệu phải dễ dàng phân bố nhiều máy chủ để mở rộng quy mô. Sử dụng phần cứng thông thường hiện có hoặc trên đám mây giúp bạn tiết kiệm được những phần mềm bổ sung phức tạp và NoSQL như Cassandra được thiết kế để mở rộng trên nhiều trung tâm dữ liệu mà không phải đau đầu.
3. Phát triển nhanh chóng. NoSQL cực kỳ hữu ích cho việc mở rộng nhanh chóng vì nó không cần phải chuẩn bị trước. Nếu bạn đang làm việc thường xuyên cập nhật cấu trúc dữ liệu trên các hệ thống mà không cần phải ngưng hệ thống.

 Nguồn: https://www.educative.io/