Thiết kế database quản lý thực thể như thế nào

#1

Sau topic này Cách thiết kế database cho thực thể có nhiều trường hợp, nhiều loại,... với số lượng thuộc tính khác nhau thì em còn 1 vấn đề chưa thông ạ.

Ví dụ: Em có 1 cửa hàng bán xe máy: cả cửa hàng chỉ có 2 loại xe là honda wave alpha và honda airblade. Tổng cộng 10 chiếc xe thì em phải thiết kế database như thế nào?

Em có 2 cách lưu thực thể xe máy như sau:

:green_circle: Cách 1: lưu mẫu xe, một bảng, bảng xe có 2 dòng

KHÔNG phân biệt những chiếc xe với nhau nên các đơn hàng của khách có thể cùng chung mã xe, bảng xe và bảng đơn hàng có quan hệ 1 nhiều (đơn hàng 1, mã xe nhiều)

+-------------+------------------+----------+
| Mã xe       | Tên xe           | Số lượng |
+-------------+------------------+----------+
| HD_WAVE     | Honda wave alpha | 3        |
+-------------+------------------+----------+
| HD_AIRBLADE | Honda airblade   | 7        |
+-------------+------------------+----------+

:green_circle: Cách 2: CÓ phân biệt những chiếc xe với nhau .Lưu tất cả 10 chiếc xe trong cửa hàng nên các đơn hàng của khách có thể cùng chung mã xe, bảng xe và bảng đơn hàng có quan hệ 1:1 (một chiếc xe chỉ xuất hiện trong 1 đơn hàng)

+----------------+----------+--------+
| Mã xe          | Số khung | Số máy |
+----------------+----------+--------+
| HD_WAVE_01     | 123      | 321    |
+----------------+----------+--------+
| HD_WAVE_02     | 111      | 333    |
+----------------+----------+--------+
| HD_WAVE_03     | 666      | 777    |
+----------------+----------+--------+
| HD_AIRBLADE_01 | 456      | 789    |
+----------------+----------+--------+
| HD_AIRBLADE_N  | N...     | N...   |
+----------------+----------+--------+
| HD_AIRBLADE_10 | 655      | 999    |
+----------------+----------+--------+

Hay là phải tách ra thành 3 bảng :
  • Bảng 1 là bảng info xe, specification xe
    ==> dành cho nhân viên nhập liệu viết content cho xe, SEO xe.
  • Bảng 2 chủ yếu quan tâm đến số lượng của mỗi MẪU XE
    ==> dành cho nhân viên kế toán
  • Bảng 3 quản lý từng chiếc xe, VD: chiếc 1 xước trái, chiếc x bị thủng lỗ, chiếc abc bị nổ lốp,…
    ==> dành cho nhân viên kho, bảo vệ

Quan trong là nếu làm 3 bảng như vậy thì bảng nào biểu diễn cho thực thể xe? những bảng còn lại gọi là gì? bảng tạm, bảng phụ hay bảng bổ sung? hay cả 3 bảng đều gọi là thực thể xe? mỗi lần giám đốc muốn query xe thì join cả 3 bảng lại?

Mong được giải thích! Em cảm ơn

cuahangmuabanxemaycu
Ảnh mạng minh họa không quảng cáo

#2

Nếu chỉ có 10 chiếc xe mà không có sự phát triển lên hàng ngàn chiếc xe, và đây không phải là bài tập nộp trên trường về môn cơ sở dữ liệu: nhét tất cả vào 1 bảng.

2 Likes
#3

Dạ 1 cửa hàng, 2 mẫu xe, 10 chiếc là em ví dụ, có thể có N mẫu xe, N chiếc xe. Đây là bài tập trong trường luôn a (à mà đây là ví dụ em tự đặt ra thôi, vì có nhiều dạng tương tự như này)

#4

Có vẻ là bạn không đọc qua các nguyên tắc, cảm thấy dài hay sao nhỉ? Phải kiên nhẫn đọc các nguyên tắc và áp dụng. Ví dụ, mình nhìn vào thấy số lượng xe máy 3, 7 ở đó là thấy có vẻ gì đó không ổn rồi, vì đó là cái có thể tính toán được khi bạn đếm dòng các xe máy được nhập vào ở một bảng khác.

Số máy, số khung không trùng nhau thì cũng có thể dùng nó làm mã xe, không nhất thiết phải đẻ ra bảng mã xe làm gì bởi vì khi tra số khung hoặc/ và số máy đã xác định được chính xác chiếc xe nào mà không lẫn lộn.

Cho nên, cần phải đọc thêm tài liệu, và phân biệt cái nào là category (dễ hình dung hơn: tương đương với thư mục trên ổ đĩa máy tính => loại xe/ nhóm xe máy), cái nào là item (tương đương với file => cái xe máy).

Để mình gợi ý và bạn đọc thêm lý thuyết để tinh chỉnh cho tốt hơn:

table Loai_xe_may
ma_loai
ten_loai
thu_tu_hien_thi

table Xe_may
ma_xe (dung so khung hoac so may)
so_khung (hoac so_may tuy theo ma xe da dung cai nao)
ma_loai (khoá ngoại của table Loai_xe_may)
ten_goi
mau_sac
nam_san_xuat (doi xe)

table Dac_diem_rieng
ma_dac_diem
ma_xe (khoá ngoại của ma_xe ở table Xe_may)
ten_goi_bong_bay (Wave RS, Wave Alpha 100cc, Wave Alphe 110cc, Wave Raider,…)
kieu_banh (nan hoa/ banh mam)
kieu_phanh_banh_truoc (dum / dia)
kieu_phanh_banh_sau (dum / dia)
nhan_hieu_lop (Inoue/ Kanda/ Casumina,…)
cong_tac_den (co / khong ; default: co)
ghi_chu (xe bi tray/ be den/ queo co,…; default; null)

table Don_hang
ma_don_hang
ma_khach_hang
ma_san_pham (khoa ngoai cua ma_xe may)
trang_thai_don_hang (da thanh toan/ dang xu ly/ moi dat hang/ blah blah)

Cứ thiết kế ra cho nhiều đi, đừng có sợ sai, rồi sau đó tinh chỉnh. Còn cứ hỏi chứng tỏ là đang không tự tin làm, việc đó gây cản trở cho việc học. Học đơn giản là một quá trình thử - sai, càng sai nhiều càng tốt chứ không phải là điều đáng ngại. Còn nếu không thể/ chưa thể làm các table ngay từ đầu nghĩa là phải xác định nguyên nhân/ thành thật với bản thân: chưa đọc kỹ đủ nhiều để hiểu lý thuyết (đọc ở đây phải hiểu là đọc và suy ngẫm, ghi chép, chỗ nào chưa rõ thì tìm thêm tài liệu khác hoặc hỏi người khác để bổ sung).

Khi thiết kế tạm xong, gõ câu lệnh SQL chạy thử các query theo các “kịch bản” mà bạn muốn lấy thông tin, trong quá trình này cũng sẽ phát hiện ra một số thứ bất hợp lý, rồi ta lại chỉnh lại lần nữa. Cũng nên biết qua các chuẩn như: First Normal Form (1NF): dạng chuẩn 1NF. Second Normal Form (2NF): dạng chuẩn 2NF. Third Nomal Form (3NF): dạng chuẩn 3NF. Boyce-Codd Normal Form (BCNF): dạng chuẩn Boyce-Codd để áp dụng.

Túm lại, mình là dân tự học và thế hệ cũ, sau thời gian loay hoay mình rút ra kết luận là học 1 giờ trên trường thì bỏ ra 3 giờ đọc sách cho cái môn đó + thực hành theo gợi ý trong sách là bỗng làm được. Ví dụ như hồi đó mình học môn chung là Tâm lý học đại cương, lúc chưa vào học chuyên ngành thì mình là thằng duy nhất trong giảng đường đọc 3 cuốn sách về tâm lý (2 sách tiếng Việt + 1 sách tiếng Anh), cảm thấy chỉ mới có lý thuyết nên đạp xe đạp đến trại cai nghiện Bình Triệu phỏng vấn tâm lý con nghiện, đến khi thi, cô giáo nói một câu mát lòng: tôi nghĩ anh đã chọn nhầm chuyên ngành, giờ vẫn còn kịp nếu muốn theo học tâm lý học, làm đơn đi tôi giúp chuyển ngành.

5 Likes
#5

Em cảm ơn. Cho em hỏi thêm là “Loai_xe_may” và “Dac_diem_rieng” có được gọi là thực thể không?

#6

bạn hiểu như nào là thực thể, đặc trưng của thực thể là gì?

1 Like
#7

Kinh nghiệm của mình khi “thiết kế database” không thông qua đào tạo bài bản, nó là như vầy:
#1. Ngồi suy nghĩ coi mình muốn quản lý cái gì, user có thể nhập liệu cái gì, chỉnh sửa cái gì, làm ra làm sao, lỡ sau này cần quản lý thêm cái xyz thì phải làm sao, list ra hết
#2. Vẽ sơ đồ cho cái #1 (người ta kêu là Database design hay Diagram gì gì đó), đại khái là từ những cái gạch đầu dòng, mình chuyển thành những cái tables trên sơ đồ
#3. Làm bước #1 và #2 nhiều lần, cho tới khi thấy ok
#4. Code. Khi code sẻ nảy sinh thêm những nhữgn thông tin “trung gian” khác cần quản lý/xử lý trong quá trình code. Quy lại bước #1.
Xong.

Note thêm, là khi viết 1 phần mềm hay web quản lý cái gì đó, thì thiết kế cái database nó chiếm phần lớn thời gian và mang tính quyết định (cả về tính hiệu qủa cũng như rút ngắn thời gian code).

4 Likes
#8

Thực thể entity là một tập hợp instance: Xe cộ, nhà cửa, cây xanh, sản phẩm, môn học, nhân viên, phòng ban, …

#9

đây là khi bạn trả lời 1 câu hỏi nhưng lại để lại 1 câu hỏi khác, vậy instance là gì?

4 Likes
#10

Instance là một thể hiện cụ thể của entity. Entity xe máy thì có các instance: xe A biển số 123, xe B biển số 456, …

#11

Chết thật, giờ mình mới phát hiện ra là bạn chủ topic đang lăn tăn đến cái mô hình Entity-Relationship Model còn mình thì chỉ quan tâm đến Relational Model. Do đó, mình toàn liệt kê ra những thứ Relational Model. Điều này có thể khíến chủ topic càng thêm hoang mang.

Vậy 2 mô hình trên thì khác nhau chỗ nào? Mô hình E-R đứng ở góc độ người lập trình, mà cụ thể là lập trình hướng đối tượng; còn mô hình Relational Model lại thiên về người quản trị cơ sở dữ liệu.

Chủ topic giờ làm mô hình E-R đi đã, đưa cái diagram lên đây, có mô hình rồi mọi người nhìn vào đó mới có gợi ý nên phân rã ra để chuyển nó về Relational Model (nếu dùng Relational Model DBMS để lưu thông tin).

Không có E-R thì rõ ràng người khác không đoán được chủ topic muốn quản lý những cái gì, người chỉ biết Relational Model như mình (chỉ biết lập trình function nên mấy cái thực thể gì đó là ngoài tầm) hoàn toàn bó tay. Thỉnh thoảng đụng chút ít OOP trên một số framework đã có lệnh để sinh dữ liệu chuyển từ E-R sang Relational Model giúp. Trong quá trình viết code theo cách nhìn vào dòng, cột của các table trong CSDL viết câu query hoặc cứ thảy tham số vào method để nhận kết quả. Từ đó, lý thuyết về quan hệ giữa E-R với Relational Model là khá mơ hồ, thực sự phải thừa nhận như vậy, chỉ những ai đang đi dạy hoặc thực hiện huấn luyện nội bộ mới rõ, còn lại đa số làm quen tay thôi.

Mình không rõ trong thực tế có cơ sở dữ liệu nào đang hỗ trợ trực tiếp mô hình E-R hay không nên không dám bàn gì thêm.

4 Likes
#12

Cả 2 cách cậu đề cập đều không phù hợp với business của cậu thì phải.
Cách 1 của cậu không hỗ trợ được việc mô tả các đặc điểm riêng của từng xe (số khung, số máy…). Việc này rất quan trọng khi bán xe, vì hóa đơn của cậu xuất ra cần có các thông tin đó.
Cách 2 của cậu không thể hiện hãng/loại xe. Khi tìm kiếm, cậu gần như không thể thực hiện được yêu cầu “tìm tất cả xe wave”.

Phần tách thành 3 bảng của cậu hợp lý về mặt logic, nhưng tớ chưa thấy sự hoàn thiện ở đây. Mặt khác, việc thiết kế dữ liệu phục vụ cho toàn business, chứ không nên phục vụ cho từng đối tượng sử dụng (nếu cậu có thể tách bạch đối tượng sử dụng ra, cậu nên tạo ra các hệ thống khác nhau cho từng đối tượng đó, cùng với DB riêng. Hẳn nhiên là nó không thể trong TH này).
Với 3 bảng kể trên, cậu cần phải join dữ liệu từ các bảng 1 và 3 (tớ không để bảng 2, vì thông tin này là thông tin kho hàng, không phải thông tin đại diện cho chiếc xe) để form thành thực thể xe. Việc này hoàn toàn bình thường, vì CSDL của cậu cần được chuẩn hóa để tối ưu về dung lượng lưu trữ & query, nên dữ liệu của 1 thực thể có thể được chia nhỏ ra các bảng khác nhau.

Hope it helps!

3 Likes
#13

Kiểm tra xong rồi em mới dám up tiếp ạ. Bài kiểm tra có câu:

Mô tả hệ thống quản lý tiêm chủng:

  • Khách hàng gồm các thông tin: mã khách hàng, họ tên , ngày sinh, địa chỉ. Khách hàng có 2 loại: khách hàng là người lớn và khách hàng là trẻ em. Khách hàng người lớn có thêm SĐT. Khách hàng trẻ em có thêm thông tin người thân gồm họ tên người thân, SĐT, quan hệ với bé.

  • Vaccine có mã vaccine, tên, mã lô , liều dùng, đường truyền, ngày sản xuất, ngày hết hạn, số liều đạt hiệu quả, thời gian nhắc lại, độ tuổi tiêm chủng, mã loại, tên loại , mã nhà sản xuất, tên nhà sản xuất.

  • Bác sĩ bao gồm mã BS, họ tên BS, bằng cấp, SĐT, địa chỉ.

  • Một khách hàng sẽ có nhiều lịch tiêm chủng gồm mã lịch tiêm , mã khách hàng, mã bác sĩ chỉ định, mã vaccine, số thứ tự mũi tiêm, ngày tiêm, ngày nhắc lại, ghi chú.

Em phân tích như này thế quái nào lại sai :sob:

Đây là các mối quan hệ (M là many):

  • KHÁCH HÀNG 1:M LỊCH TIÊM CHỦNG
  • BÁC SĨ 1:M LỊCH TIÊM CHỦNG
  • LỊCH TIÊM CHỦNG M:M VACCINE.
    • LỊCH TIÊM CHỦNG 1:M CHITIETTIEM
    • CHITIETTIEM M:1 VACCINE

Sơ đồ ERD

x
x646×564 20.5 KB

Sơ đồ vật lý (chưa chuẩn hóa, phần chuẩn hóa câu khác)

y
y858×687 5.58 KB

Chỗ khách hàng có 2 loại không khác gì bài toán quản lý xe có 2 loại như trên luôn.

#14

nếu ai nói bạn sai, hãy hỏi lại họ, bạn sai chỗ nào

83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?