Database: ERD, EER và chuẩn hóa – khái niệm trắc nghiệm cần nhớ

Cardinality vs Degree of a relationship

Cardinality: số instance của một entity có thể tham gia quan hệ với MỘT instance của entity kia. Degree: số loại entity (entity types) tham gia quan hệ.

1 / 29

Tạo bởi

Long Nguyễn Trường

Thuật ngữ trong học phần này (29)

Cardinality vs Degree of a relationship

Cardinality: số instance của một entity có thể tham gia quan hệ với MỘT instance của entity kia. Degree: số loại entity (entity types) tham gia quan hệ.

Wellmeadows Hospital – 3NF relations (diagnostic tests)

PATIENT(PatientNo PK, FullName, DOB) CONSULTANT(ConsultantNo PK, ConsultantName) CONSULTANT_ASSIGNMENT(AssignmentID PK, PatientNo FK, ConsultantNo FK, StartDate, EndDate) TEST_CATEGORY(CategoryName PK) LABORATORY(LaboratoryNo PK, LaboratoryName) DIAGNOSTIC_TEST(TestNumber PK, TestName, CategoryName FK, LaboratoryNo FK) TEST_RECORD(TestRecordID PK, AssignmentID FK, TestNumber FK, TestDate, ResultDate, ResultStatus) Ý: tên/loại test cố định ở DIAGNOSTIC_TEST; ngày và kết quả thuộc từng lần làm test.

Projects Inc – 3NF relations (employee, job, department, marriage)

DEPARTMENT(DepartmentName PK, PhoneNumber, Location) EMPLOYEE(EmployeeNo PK, Name, DOB, Gender, HireDate, DepartmentName FK) JOB(JobTitle PK, BaseSalary, BonusRate) JOB_ASSIGNMENT(EmployeeNo PK/FK, StartDate PK, JobTitle FK, EndDate) MARRIAGE(EmployeeNo1 PK/FK, EmployeeNo2 UNIQUE/FK, MarriageDate) Ý: lịch sử công việc cần bảng riêng; EndDate của việc hiện tại là NULL.

In a ticket table, what is the 'Owner' column that references Student?

Foreign key tham chiếu tới bảng student. Đường nối Ticket–Student biểu thị foreign key Ticket.SID tham chiếu Student.SID.

Generalization vs Specialization

Generalization: từ nhiều entity (CAR, TRUCK) có thuộc tính chung (VIN, Manufacturer) tạo supertype mới (VEHICLE) – đi từ dưới lên. Specialization: từ một entity chia thành các subtype có thuộc tính riêng – đi từ trên xuống.

Attribute inheritance

Tính chất subtype có tất cả giá trị thuộc tính của supertype.

When to use subtypes

Khi có thuộc tính chỉ áp dụng cho một số (không phải tất cả) instance của entity type, hoặc subtype có quan hệ riêng.

Disjointness constraint

Disjoint: một instance chỉ thuộc tối đa một subtype. Overlapping: một instance có thể thuộc nhiều subtype cùng lúc.

Completeness constraint

Xác định một instance của supertype có bắt buộc thuộc ít nhất một subtype hay không. Total specialization: bắt buộc thuộc subtype. Partial specialization: instance được phép KHÔNG thuộc subtype nào.

Multivalued attribute when transforming ER to relations

Trở thành một relation riêng, chứa foreign key lấy từ entity cha (superior entity). Ví dụ: Speciality của một entity được vẽ là multi-valued attribute.

Derived attribute

Thuộc tính mà giá trị phụ thuộc/được tính từ thuộc tính khác (ví dụ tuổi từ ngày sinh).

Attribute of a relationship (e.g. Semester of TEACHES between PROFESSOR and COURSE) is modeled as...

Attribute của chính relationship TEACHES (không đặt vào PROFESSOR hay COURSE).

Entity should NOT be...

Không nên là: output của hệ thống CSDL; user của CSDL. Entity nên là: đối tượng cần mô hình hóa, có nhiều instance, có nhiều attribute.

ER diagram symbols

Rectangles = entities; lines giữa các entity = relationships.

Student attends 5 classes, each with a different professor; each professor has 30 students. Relationship type?

Many-to-many.

SDLC phase that defines every data attribute, category of data and business relationship between entities?

Analysis phase (giai đoạn phân tích). Mẹo: Analysis = xác định dữ liệu và quan hệ; Design = thiết kế cách cài đặt.

Business rule

Một business rule xác định hoặc ràng buộc một khía cạnh của nghiệp vụ. Trong E-R diagram, mỗi relationship có TWO business rules (một cho mỗi chiều đọc).

Data integrity (relational model component)

Thành phần của mô hình quan hệ dùng để chỉ định business rules nhằm duy trì tính toàn vẹn khi dữ liệu bị thao tác. Data structure là thành phần khác.

Entity integrity rule

Không thuộc tính nào của primary key được phép NULL.

Referential integrity rule

Giá trị foreign key phải trùng một giá trị primary key trong quan hệ ở phía 'one' (hoặc là null). Ràng buộc đảm bảo: FOREIGN KEY (không phải Check, Unique, Primary key).

Composite key

Khóa gồm nhiều hơn một thuộc tính.

{Shipment_id, Item_no} → Quantity vs Item_no → Quantity: which FD is valid?

{Shipment_id, Item_no} → Quantity: Quantity phụ thuộc vào cả khóa kép (composite key) của chi tiết lô hàng, không chỉ một phần.

1NF, 2NF, 3NF – điều kiện của mỗi dạng

1NF: không có thuộc tính đa trị / nhóm lặp. 2NF: 1NF + thuộc tính không khóa phụ thuộc đầy đủ vào khóa chính (không phụ thuộc bộ phận). 3NF: 2NF + không có phụ thuộc bắc cầu. Ví dụ đề: quan hệ không đa trị, phụ thuộc đủ vào khóa chính nhưng còn transitive dependency → đang ở Second normal form.

Transitive dependency: EmployeeID → DepartmentID, DepartmentID → DepartmentName, so EmployeeID → DepartmentName is...

Transitive dependency (phụ thuộc bắc cầu): thuộc tính không khóa xác định thuộc tính không khóa khác. F = {A→B, B→C}: bảng ở 2NF nhưng không đạt 3NF (vi phạm 3NF do phụ thuộc bắc cầu) – cả hai phương án B và C đều đúng.

Functional dependency (FD)

Ràng buộc giữa hai thuộc tính (tập thuộc tính): A → B nghĩa là giá trị A xác định duy nhất giá trị B. Đáp án trắc nghiệm: 'functional dependency' (không phải attribute dependency).

Domain definition components (EXCEPT which one?)

Domain gồm: domain name, data type, size (độ dài), và có thể cả giá trị cho phép/ý nghĩa. KHÔNG gồm: integrity constraints.

One table stores both customer and order data, causing redundancy and update anomalies. Best fix?

Normalize: tách thành các thực thể riêng (Customer, Order). Không dùng denormalize, composite attribute hay surrogate key để sửa.

When is denormalization needed instead of more normalization?

Khi cần tăng hiệu năng đọc (read performance) bằng cách tránh các phép join phức tạp. Ngược lại, giảm dư thừa / đạt 3NF / giảm null là mục tiêu của normalization.

Purpose / main goals of normalization

Giảm dư thừa dữ liệu (reduce redundancy), tăng toàn vẹn dữ liệu, dễ bảo trì, đơn giản hóa việc thực thi referential integrity. KHÔNG phải: tăng dư thừa, 'maximize storage space', 'đảm bảo mỗi bảng có foreign key', 'chuyển ERD sang relational model'.