CHƯƠNG 2 MÔ HÌNH THỰC THỂ KẾT HỢP

BÀI GHI MÔN HỌC CƠ SỞ DỮ LIỆU NÂNG CAO ADVANCED DATABASE Trường: Đại học Khoa học Tự nhiên Đại học Quốc gia TP Hồ Chí Minh Lớp: 20HTTT2 Khóa: 2020 Năm học: 20222023 Giảng viên: TS. Nguyễn Trần Minh Thư

󾠯 Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL Overview Relational Database Model - Mơ hình sở liệu quan hệ Thường dùng giai đoạn Conceptial Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL Entity Relationship Model - Mơ hình thực thể kết hợp Thường dùng giai đoạn thiết kế logic Đối với mơ hình ER có loại mơ hình: Basic (nền tảng, bản) Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL Enhanced (mở rộng) → đưa thêm số khái niệm (kế thừa liệu, …) Data Modeling & Data Models Model: Là tập hợp ký hiệu dùng để biểu diễn liệu Data Modeling (Mơ hình hóa liệu): Q trình triển khai ý tưởng lên mơ hình Design: Thiết kế xong phải kiểm tra lại coi có hay không Phần 1: Entity Relationship Model (ERM) Business Rule ℹ Là quy tắc nghiệp vụ hệ thống, sau thu thập tất yêu cầu từ người dùng tài liệu hóa tất u cầu kỹ thuật business rule, từ người thiết kế liệu có nhìn rõ ràng yêu cầu, mối quan hệ thực thể với giúp cho việc thiết kế liệu dễ dàng xác Những yêu cầu viết business rule Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL Những nguồn tìm kiếm business rule Ưu điểm business rule Giúp cho hiểu chất cách nhìn, cách chuẩn hóa cơng ty Là cơng cụ giao tiếp người thiết kế liệu với người dùng cuối Cho phép người thiết kế hiểu rõ phạm vi liệu, quy trình nghiệp vụ hệ thống → tạo mơ hình liệu xác Các ví dụ business rule Chuyển đổi Business Rule thành thành phần mơ hình liệu Các danh từ chuyển đổi thành thực thể Các động từ chuyển thành mối quan hệ thực thể với Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL Các mối quan hệ chiều (bidirectional) Xác định loại mối quan hệ (1-1; 1-n; n-n) Khi mà chuyển đổi từ business rule sang data model cẩn phải xác định yếu tố là: - Entity - Relationship - Constraint (Ràng buộc) → Một business rule tốt cho mô hình liệu tốt Qui ước tên Tên thực thể, tên thuộc tính phải đặt xác để dễ dàng cho việc phân tích liệu, làm việc thành viên nhóm Entity Relationship Model (Basic) Các thành phần database bao gồm: Thực thể: tập đối tượng có chung tính chất Entity Instance - Thể thực thể: thường liên quan đến thông tin người, nơi chốn, vật, kiện,… cụ thể (giống với hàng bảng liệu) Entity Type(set): nhóm thực thể (giống bảng liệu) Thuộc tính: đặc trưng đối tượng liệu muốn quản lý 💡 Thuộc tính đặc trưng cho thực thể mối kết hợp có thuộc tính mơ tả cho thực thể có thuộc tính mơ tả cho kết hợp liên quan thực thể với Mối quan hệ: thể mối quan hệ ngữ nghĩa (nếu có) tập thực thể với Với điều kiện tập thực thể phải có mối quan hệ cần phải quản lý Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL Ví dụ sơ đồ ký hiệu Crow’s Foot cho hệ thống bán hàng Các ký hiệu (Basic ER notation) Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 💡 Ký hiệu thực thể: - Strong: định danh thuộc tính - Weak: thân khơng định danh mà phải dựa vào thực thể mạnh khác - Associative (Kết hợp) Ký hiệu thuộc tính: - Identifier (định danh): thuộc tính khóa - Partial identifier (định danh riêng phần): xuất có kết hợp thực thể yếu thực thể mạnh - Optional: liệu thay đổi tùy ý - Derived (suy diễn): giá trị suy từ giá trị thuộc tính khác (tính tuổi thơng qua ngày sinh nhập vào) - Multivalue (Đa trị): có nhiều thơng tin thuộc tính (1 sinh viên có nhiều kỹ năng) - Composite (Kết hợp): gồm nhiều thuộc tính bên tạo ngữ nghĩa (Địa bao gồm đường, số nhà, quận, huyện) → Khi chuyển đổi thành mơ hình liệu quan hệ, thuộc tính có cách chuyển đổi khác Với thuộc tính Suy diễn trở thành thuộc tính table, với thuộc tính Đa trị, Composite khơng thể trở thành thuộc tính bảng mà cần có cách chuyển đổi khác Ký hiệu loại mối kết hợp (Degree of Relationships): - Unary (Phản thân) - Binary (Nhị phân) - Tenary (Đa phân) Thể lực lượng mối quan hệ (Relationship Cardinality): - Mandatory (bắt buộc phải nhập số) - Optional Date Completed xem thuộc tính mối kết hợp Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL Một ví dụ cho kiểu thực thể Associative (Kết hợp) Diễn dịch ký hiệu thành lời Entity (Thực thể) Định nghĩa Thực thể đối tượng ngồi giới thực, cụ thể trừu tượng Tập thực thể (Entity set/Entity type): tập thực thể có chung tính chất, đặc trưng Ví dụ ký hiệu thực thể Student Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 💡 Người ta đặt thuộc tính lên mối kết hợp mà thuộc tính mơ tả cho đối tượng có quan hệ kết nối với Thực thể mạnh, thực thể yếu mối quan hệ Thực thể mạnh (Strong entity): Tồn độc lập với thực thể khác Có định danh riêng → Định danh gạch với nét đơn Thực thể yếu (Weak entity): Phụ thuộc thực thể mạnh để xác định tồn tại, khơng tự xác định Khơng có định danh riêng (chỉ có định danh riêng phần) Hình bao cho thực thể định danh dùng đường nét kép Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL Xác định mối quan hệ (identifying relationship): Tạo đường kết nối thực thể mạnh yếu Thực thể liên kết - Associative Entities Là kiểu thực thể liên kết thể (Instance) nhiều kiểu thực thể chứa thuộc tính cụ thể cho mối kết hợp thể Thực thể dạng có điều đặc biệt vừa thực thể có thuộc tính vừa mối kết hợp liên kết thực thể lại với Mục đích Associative Entity nhấn mạnh đối tượng dùng giới thực thông qua mối quan hệ many-to-many VD: Một hóa đơn mua nhiều sản phẩm, loại sản phẩm có nhiều hóa đơn Vậy nhu cầu đề quản lý chi Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 10 tiết số hóa đơn đối tượng thực tế lúc dùng Associative entity VD: Xét biểu đồ sau cho biết khác biệt? Về mặt ngữ nghĩa, biểu đồ khơng có khác Tuy nhiên Trong cấp độ người ta muốn biết nhân viên học khóa học hồn thành vào ngày nào, không cần biết thêm chi tiết khác Cịn mơ hình người ta cần quản lý thêm thông tin chi tiết khóa học người nhân viên thơng qua Chứng mà người nhân viên có bao gồm Ngày hồn thành, Mã số chứng chỉ,… 💡 Khơng nên lạm dụng việc phân cấp mơ hình mơ hình phân cấp nhiều ảnh hưởng đến tốc độ việc truy suất liệu ❓ Khi nên dùng mối quan hệ với thuộc tính thay thực thể liên kết? - Tất mối quan hệ cho thực thể liên kết nên Nhiều - Thực thể liên kết nên có nghĩa độc lập với thực thể khác Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 11 - Thực thể liên kết có định danh có thuộc tính khác - Thực thể liên kết tham gia mối quan hệ khác thực thể mối quan hệ liên kết - Mối quan hệ đa phân (Ternary) nên chuyển thực thể liên kết Chú ý Một thực thể Nên Entity phải có nhiều đối tượng, entity type phải có nhiều object Được hình thành mơ tả nhiều thuộc tính Là đối tượng mà cố mơ hình hóa Khơng nên Là output đầu hệ thống VD: bảng điểm cá nhân trích xuất từ liệu cá nhân trường Là người dùng hệ thống 💡 Nếu có thực thể yếu thực thể yếu phải có liên kết đến thực thể mạnh đứng Attribute (Thuộc tính) Định nghĩa Thuộc tính dùng để biểu diễn đặc trưng của: Thực thể Mối kết hợp Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 12 Các ví dụ ký hiệu thuộc tính STU_LNAME, STU_FNAME, STU_INITIAL,… Thuộc tính yêu cầu - Required attribute: phải có giá trị, khơng để NULL Thuộc tính tùy chọn - Optional attribute: khơng u cầu có giá trị, phép NULL Miền giá trị - Domain: tập giá trị phép thuộc tính Định danh - Identifiers: Một hay nhiều thuộc tính mà xác định tính thể thực thể 💡 Định danh kết hợp - Composite Identifier: Khóa bao gồm nhiều thuộc tính Thuộc tính kết hợp - Composite Attribute: Thuộc tính chia nhỏ để tạo thuộc tính bổ sung Thuộc tính đơn - Simple Attribute: Thuộc tính khơng thể chia nhỏ Thuộc tính đơn trị - Single-valued Attribute: Thuộc tính có giá trị đơn Thuộc tính đa trị - Multivalued Attribute: thuộc tính có nhiều giá trị yêu cầu tạo: - Một vài thuộc tính mới, thuộc tính thành phần thuộc tính gốc - Một thực thể mới, bao gồm thành phần thuộc tính đa trị nguyên ban đầu Thuộc tính suy diễn - Derived Attribute: thuộc tính có giá trị tính tốn từ giá trị thuộc tính khác (Suy diễn ~ sử dụng phương pháp, thuật tốn tính tốn) Định danh - Identifiers (Keys) Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 13 Identifier (Key): thuộc tính (hoặc kết hợp nhiều thuộc tính) để xác định tính thể thực thể Định danh đơn giản định danh kết hợp (Simple versus Composite Identifier) Candidate Identifier - Định danh ứng viên: thuộc tính khóa, thỏa yêu cầu định danh Tiêu chuẩn cho thuộc tính định danh (Identifier) Chọn định danh mà: Những giá trị không thay đổi tương lai VD: MSSV Không phép bỏ trống + (unique) Tránh việc làm cho khóa trở nên thông minh mà thay đổi nội dung, ngữ nghĩa VD: Sinh viên học ngành Vật lý có MSSV 20VL001 chuyển sang ngành CNTT với mã 20CNTT001 Thuộc tính định danh Simple Composite (Simple and Composite identifier attributes) Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 14 Flight ID thuộc tính định danh kết hợp (Composite Identifier Attribute) định danh Flight Number Date Đặt tên cho thuộc tính Tên nên đặt cách thống chuẩn hóa tồn hệ thống để dễ dàng quản lý Xác định thuộc tính Để xác định thuộc tính cần phải trả lời câu hỏi sau: Thuộc tính gì? Tại quan trọng? Làm rõ khơng phép bảng gí trị thuộc tính Bao gồm bí danh tài liệu Chỉ nguồn giá trị Chỉ định thuộc tính bắt buộc tùy chọn Số lần xuất tối thiểu, tối đa cho phép Chỉ mối quan hệ với thuộc tính khác Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 15 Relationship (Mối kết hợp) Khái niệm Biễu diễn kết hợp hệ ngữ nghĩa hay nhiều thực thể Sự kiện nối kết Mối quan hệ vật lý Mơ hình hóa mối kết hợp Relationship Types: loại mối kết hợp Relationship Instances: thể mối kết hợp Mối kết hợp có thuộc tính Multiple Relationships: Hai thực thể có nhiều loại mối kết hợp chúng Associative Entity - Thực thể kết hợp: Kết nối mối kết hợp thực thể Các loại mối kết hợp - Degree of Relationships Có loại mối kết hợp thường gặp là: - Unary - Binary - Ternary Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 16 Degree of Relations in DBMS - GeeksforGeeks We are living in a world where every entity has relationships with one other whether a living or non-living being For example, you are a single entity but you share different relations with your https://www.geeksforgeeks.org/degree-of-relations-in-dbms/ Bản số - Cardinality of Relationship ℹ Mô tả liên kết thực thể Có loại mối quan hệ sau: - One-to-many (1:M): Một thực thể bên mối quan hệ có nhiều thực thể liên quan, thực thể bên cịn lại có tối đa thực thể liên quan - Many-to-many (M:N M:M): Mỗi thực thể bên mối quan hệ có nhiều thực thể liên quan tới bên cịn lại - One-to-one (1:1): Mỗi thực thể mối quan hệ có xác thực thể liên quan Ràng buộc số - Cardinality Constraints ℹ Số lượng thể thực thể có thể/phải kết hợp với thể thực thể khác Nhãn thời gian - Time Stamp Một giá trị thời gian có liên kết với giá trị liệu, thường biểu thị ảnh hưởng thời gian lên giá trị liệu Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 17 Nhãn thời gian áp dụng thuộc tính có hiệu lực khoảng thời gian xác định VD: Giá sản phẩm, lương nhân viên, … Một ví dụ Time Stamp, giá sản phẩm áp dụng khoảng thời gian xác định nên thuộc tính Price History cần phải lưu thêm Effective Date để biết ngày mà giá bắt đầu có hiệu lực Thơng tin thêm 💡 Trong mơ hình liệu quan hệ KHƠNG có mối quan hệ Many-to-many mà biểu diễn thông quan mối quan hệ One-to-many 💡 Với hệ thống yêu cầu tính quán cao (hệ thống ATM, …) 💡 Đối với đối tượng có ngữ nghĩa, mối quan hệ (1:1) với KHƠNG thể sử dụng noSQL phương diện Physical xem xét gộp lại Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 18 💡 Một mơ hình ER nằm mức: Conceptial → khơng ép khóa ngoại Implementation → ép khóa ngoại vào → kiểm chứng tính đắn Bài tập lớp Cho sơ đồ Crow’s Foot sau trả lời câu hỏi: ❓ Can a customer have an unlimited number of plans? Có theo biểu đồ khách hàng thuộc nhiều không kế hoạch → Số lượng kế hoạch khách hàng không giới hạn Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 19 ❓ Can a customer exist without a plan? Có khách hàng thuộc nhiều kế hoạch không kế hoạch → Nên khách hàng tồn không thuộc kế hoạch ❓ Is it possible to create a plan without knowing who the customer is? Không kế hoạch phải thuộc người nên thêm kế hoạch mà thuộc ❓ Dose the operator want to limit the types of handsets that can be linked to the specific plan type? Có, thân Handset type có nhiều handset handset có tối đa kế hoạch kế hoạch có plan type ❓ Is it possible to maintain data regarding a handsets without connecting it to a plan? Có thể handset không cần phải bao gồm plan ❓ Can a handset be associated with multiple plans? Khơng handset không bao gồm plan bao gồm plan Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 20 ❓ Assume a handset type exists that can utilize multiple operating systems Could this situation be accommondated within the model included in Figure? Khơng loại handset dùng cho hệ điều hành ❓ Is the company able to track a manufacturer without maintaining information about its handsets? Có manufacturer khơng thiết phải sản xuất handset ❓ Can the same operating system be used on multiple handset types? Có Hệ điều hành sử dụng nhiều handset type không ❓ There are two relationships between Customer and Plan Explain how they differ Mỗi Khách hàng sở hữu chịu trách nhiệm nhiều kế hoạch không sở hữu chịu trách nhiệm kế hoạch Ngược lại kế hoạch chịu trách nhiệm cho đối tượng khách hàng loại kế hoạch liên quan đến nhiều khách hàng khác ❓ Characterize the degree and the cardinalities of the relationship the connects Customer to itself Explain its meaning Chương 2: MÔ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 21 Khách hàng có nhiều khơng có người thân Ngược lại người thân danh sách thuộc khách hàng ❓ Is it possible to link a handset to a specific customer in a plan with multiple customers? Không, kế hoạch liên quan đến nhiều khách hàng nên định khách hàng cụ thể ❓ Can the company track a handset without identifying its operating system? Khơng, nhập thông tin handset phải biết thông tin handset type, mà muốn biết xác handset type nao phải biết thơng tin hệ điều hành mà sử dụng Chương 2: MƠ HÌNH THỰC THỂ KẾT HỢP - ENTITY RELATIONSHIP MODEL 22