15 phút thực hành với sơ đồ ERD
15 phút thực hành với sơ đồ ERD
Hế lôôôô anh em 
Ở tập trước chúng ta đã hiểu về ERD, ERD là gì, dùng để làm gì, cũng như các thành phần của một ERD.
Giờ tạm gác mớ lý thuyết đó qua 1 bên. Phần này anh em mình sẽ cùng đi vào thực tế, bằng cách phác họa ngay và luôn: một ERD bằng xương bằng thịt dựa trên một case study hoàn toàn thực tế.
Âu kây lét s gâuuuuu!
Ba bước vẽ ERD thần thánh
(Lưu ý: Phần này không hướng dẫn anh em thiết kế database. Thiết kế database là một phạm trù lớn, đòi hỏi nhiều chi tiết, nỗ lực và việc tối ưu ngay trong từng các attribute cụ thể).
Notes dưới đây mình hướng dẫn anh em vẽ: Sơ đồ Quan hệ thực thể – ERD, một cách đơn giản, chính xác, và hiệu quả nhất có thể.
Và nó dùng để capture yêu cầu của khách hàng theo góc nhìn database. Từ đó, anh em Database Designer dựa vào ERD để thiết kế database sao cho tối ưu và hiệu quả nhất 
…
Vẽ ERD thì có 3 bước cơ bản mà ai cũng thấy cái một đó là:
Xác định entity >> xác định relationship >> thêm mắm dặm muối.
Bắt đầu dự án, anh em sẽ làm tùm lum tùm la, A, B, C, X, Y, Z để có được specific requirements từ khách hàng.
Dựa vào các requirements đó, anh em dòm vào, đừng làm gì nhiều, việc cần làm đầu tiên là: Vẽ ra các ĐỐI TƯỢNG cần lưu trữ cái đã.
Đoạn này anh em chưa cần care nhiều tới các attribute, chỉ cần sơ khởi một vài attribute nổi bật của entity đó là được.
Ô kê, giờ có được các đối tượng rồi, anh em sẽ đọc tiếp.
Mục đích đọc lần này là tìm kiếm mối quan hệ giữa các đối tượng. Sau đó vẽ ra: LIÊN KẾT GIỮA CÁC ĐỐI TƯỢNG là gì?
*Lưu ý ngay lúc này anh em nên xác định luôn: các entity nó quan hệ cụ thể như thế nào trong 6 cái cardinality ở bài trước. Nếu chưa xác định được thì đơn thuần anh em chỉ cần vẽ một đường thẳng nối 2 entity để đánh dấu là 2 tụi nó có quan hệ, lát nữa quay lại bổ sung sau, khỏi quên.
Lúc này ERD đã ổn 80% rồi.
Bước cuối cùng là: dặm mắm dặm muối vào sơ đồ ERD của mình. Nghĩa là bổ sung thêm các attribute, hoặc relationship còn thiếu ở bước trên là xongggg!!!
Trên là lý thuyết, giờ là thực tế nhé anh em.
Mình có một case study sau, anh em thử áp dụng 3 bước trên để vẽ ERD của nó nhé.
(phải thực hành thì mới nhớ lâu được)
TN là một đơn vị kinh doanh chuyên cung cấp dịch vụ Promoter quảng cáo.
Ví dụ một quầy trưng bày của các Promoter (Nguồn ảnh: Nestle)
Cụ thể là TN sỡ hữu rất nhiều Promotion Girl (PG) và Promotion Boy (PB). Nếu một đơn vị có nhu cầu:
- Trưng bày hoặc bán sản phẩm tại quầy (roadshow & sampling)
- Tổ chức event.
Thì đơn vị đó có thể liên hệ TN.
TN sẽ giúp khách hàng của họ: trưng bày sản phẩm, bán hàng tại quầy với các KPIs cụ thể mà khách hàng có thể đưa ra.
Hiện tại TN có độ phủ rộng khắp 54 tỉnh thành, với hơn 80,000 promoters khắp cả nước. Vì nhu cầu phát sinh càng lớn, nên họ cần:
- Quản lý các chiến dịch
- Quản lý PG, PB, và Supervisor cho các chiến dịch
- Quản lý luôn doanh số bán hàng cụ thể theo từng ngày, và tại mỗi quầy
- Quản lý giờ công, lịch làm việc cho PG, PB, Supervisor
- Quản lý lộ trình làm việc của Supervisor
- Quản lý số lượng sản phẩm tồn kho tại mỗi địa điểm đặt quầy.
Với một đống nhu cầu quản lý trên, họ cần tự động hóa các quy trình này, và quản lý chúng trực tiếp ngay trên mobile device. Cụ thể, họ cần có:
- 1 mobile apps cho Promoter (PG & PB) quản lý công việc.
- 1 mobile apps cho Supervisor quản lý các Promoter này.
- 1 web apps để Admin quản lý back-end
- Và một nền tảng báo cáo cho BOD chạy trên các mobile device.
Nói về các dự án và khách hàng của TN
TN sẽ quản lý các dự án đã ký với khách hàng, với các thông tin đặc thù như: thời gian, sản phẩm mẫu, số lượng, KPIs, chi phí dự trù, chi phí thực tế, vâng vâng.
Khách hàng của TN đa phần là các nhãn hàng FMCG. Mỗi nhãn hàng gồm từ 1 đến 2 người liên hệ cụ thể để làm việc cho nhãn hàng đó.
Nói về Sup và Promoter
Promoter được các Supervisor quản lý.
Trước mỗi 2 tuần, Sup sẽ lên kế hoạch làm việc cho Promoter, bao gồm những thứ như: địa điểm làm việc, sản phẩm, số lượng sản phẩm, hoặc KPIs cần đạt.
Sau khi nhận lịch làm việc, Promoter có thể yêu cầu đổi ca làm việc, địa điểm làm việc, hoặc chỉnh sửa các nội dung cần thiết khác, trước khi xác nhận kế hoạch làm việc với Sup.
Ngoài Promoter ra, Sup cũng cần được lên kế hoạch làm việc.
Admin sẽ lên kế hoạch những địa điểm cần kiểm tra trong ngày hôm đó. Tạo thành một lộ trình gồm các địa điểm mà Sup phải ghé và kiểm tra chất lượng trong ngày hôm đó.
Nói về địa điểm làm việc
Trong một dự án, Promoter có thể trực ở nhiều quầy khác nhau. Mỗi quầy thuộc một địa điểm nào đó. Ví dụ về địa điểm làm việc và quầy:
- Quầy có thể là: quầy trước cửa chính vào siêu thị, quầy khu vực cashier, quầy khu vực hotzone, hoặc quầy khu vực gửi xe.
- Địa điểm làm việc có thể là: siêu thị, cửa hàng, đại lý, ngã tư, hoặc bất kỳ địa điểm nào.
Nói về công việc của Promoter và Sup sẽ làm trong ngày
Trước mỗi ca làm, Promoter sẽ check in bắt đầu làm việc, bao gồm: chụp một tấm hình với kệ trưng bày, ghi nhận thời gian vào làm và nhập số lượng sản phẩm nhận được lúc đầu ca vào mobile apps.
Lúc kết ca cũng tương tự, Promoter sẽ phải check out như sau: chụp một tấm hình với kệ trưng bày, ghi nhận thời gian ra về, và nhập số lượng còn lại sau ngày hôm đó vào mobile apps.
Nhiệm vụ chính của Promoter là giới thiệu sản phẩm đến càng nhiều người càng tốt. Ngoài ra, họ sẽ bán các sản phẩm này và được thưởng huê hồng cho mỗi lượng sales nhất định.
Với mỗi sản phẩm bán được, Promoter sẽ ghi nhận đơn hàng trên mobile apps để tính KPIs cho họ.
Còn Sup, họ có nhiệm vụ hỗ trợ và kiểm tra chất lượng làm việc của Promoter.
Mỗi ngày, họ sẽ đi đến các quầy để kiểm tra tác phong, quần áo, thái độ, tình hình bán hàng, hoặc mật độ người qua lại tại khu vực đó. Để chấm điểm Promoter ngay trên mobile apps dành cho Supervisor.
Mỗi promoter sẽ có số điểm cụ thể cho mỗi ngày làm việc. Điểm này sẽ được tổng hợp, và tạo thành báo cáo đánh giá Promoter cuối mỗi tháng.
Về khía khách hàng của TN
Các nhãn hàng này mong muốn được TN báo cáo chính xác số lượng sản phẩm bán được, sản phẩm tồn kho, và sản phẩm thất thoát cuối mỗi kỳ.
.
.
.
XONGGGG! Hi vọng anh em đọc hết, và đọc cẩn thận case study này.
Nhiệm vụ tiếp theo: anh em lên trang draw.io >> thực hành ngay và luôn ERD cho nóng.
.
.
.
15 phút trôi qua
.
.
.
30 phút trôi qua…
.
.
.
Ô kieeeee, hi vọng anh em đã vẽ xong. Dưới đây là ERD của mình để anh em đối chiếu.
Giờ mình sẽ giải thích cách làm của mình. Note những điểm mình tô màu dưới đây:
- Màu đỏ: Entity
- Màu hồng: Attribute
- Màu xanh dương đậm: Relationship
Nói về các dự án và khách hàng của TN
TN sẽ quản lý các dự án đã ký với khách hàng, với các thông tin đặc thù như: thời gian, sản phẩm mẫu, số lượng, KPIs, chi phí dự trù, chi phí thực tế, vâng vâng.
Khách hàng của TN đa phần là các nhãn hàng FMCG. Mỗi nhãn hàng gồm từ 1 đến 2 người liên hệ cụ thể để làm việc cho nhãn hàng đó.
ĐOẠN NÀY CHO CHÚNG TA:
- Entity:
- Dự án: Project
- Khách hàng: Account
- Người liên hệ: Contact
- Relationship:
- Đã ký: tức một dự án phải làm cho một khách hàng nào đó. Và một khách hàng có thể làm nhiều dự án với TN.
==> Account và Project quan hệ 1-nhiều. - Làm việc cho nhãn hàng: tức một nhãn hàng có nhiều người/ nhiều cá nhân làm việc cho nhãn hàng đó. Và có thể mỗi người chỉ được làm cho một nhãn hàng duy nhất.
==> Account và Contact quan hệ 1-nhiều.
Nói về Sup và Promoter
Promoter được các Supervisor quản lý.
Trước mỗi 2 tuần, Sup sẽ lên kế hoạch làm việc cho Promoter, bao gồm những thứ như: địa điểm làm việc, sản phẩm, số lượng sản phẩm, hoặc KPIs cần đạt.
Sau khi nhận lịch làm việc, Promoter có thể yêu cầu đổi ca làm việc, địa điểm làm việc, hoặc chỉnh sửa các nội dung cần thiết khác, trước khi xác nhận kế hoạch làm việc với Sup.
Ngoài Promoter ra, Sup cũng cần được lên kế hoạch làm việc.
Admin sẽ lên kế hoạch những địa điểm cần kiểm tra trong ngày hôm đó. Tạo thành một lộ trình gồm các địa điểm mà Sup phải ghé thăm và kiểm tra chất lượng trong ngày hôm đó.
ĐOẠN NÀY CHO CHÚNG TA:
- Entity:
- Supervisor/ Promoter/ Admin: mình gom chung thành 1 entity là User, vì bản chất thuộc tính của các đối tượng này là như nhau.
- Kế hoạch làm việc: Booking (thời gian bắt đầu – kết thúc làm việc theo kế hoạch dành cho các user, mô tả, trạng thái, thời lượng làm việc…)
- Địa điểm làm việc: Outlet (thuộc nhóm master data, lưu trữ địa chỉ, mô tả, kinh độ, vĩ độ…)
- Sản phẩm: Product (thuộc nhóm master data, lưu trữ tên sản phẩm, mã sản phẩm, mô tả…)
- KPIs cần đạt/ chất lượng: Promoter Score (là các transaction data, ghi nhận điểm của Promoter mỗi ngày)
- Ca làm việc: Shift (thuộc nhóm master data, lưu trữ thời gian ra vào của từng ca)
- Lộ trình: Route (transaction data, dùng để show các điểm trên bản đồ mà Sup phải đi kiểm tra chất lượng trong ngày)
- Relationship:
- Yêu cầu đổi/ chỉnh sửa nội dung cần thiết/ xác nhận kế hoạch làm việc: tức Promoter sẽ tương tác (điều chỉnh, thêm bớt) kế hoạch làm việc sao cho hợp ý mình. Một record kế hoạch làm việc đi theo một ngày. Và đương nhiên 1 Promoter sẽ có rất nhiều kế hoạch làm việc.
==> User và Booking quan hệ 1-nhiều.
==> Project và Booking quan hệ 1-nhiều (tự suy). - Vì kế hoạch làm việc bao gồm luôn ca làm việc, nên.
==> Shift và Booking quan hệ 1-nhiều. - Cần kiểm tra: mỗi Promoter sẽ có KPIs hàng kỳ, và được chấm điểm chất lượng mỗi ngày, để ra được báo cáo chính xác nhất về chất lượng làm việc của Promoter đó trong dự án.
==> User và Promoter Score quan hệ 1-nhiều. - Và vì một Promoter Score là một bảng chấm điểm của một Promoter trong 1 ngày cụ thể. Nên nó sẽ có nhiều tiêu chí (nhiều dòng) trong đó. Mỗi dòng là các KPIs với số điểm cụ thể cho từng lần kiểm tra, mình gọi là Promoter Score Line quan hệ cha con với Promoter Score.
==> Promoter Score và Promoter Score Line quan hệ 1-nhiều.
Nói về địa điểm làm việc
Trong một dự án, Promoter có thể trực ở nhiều quầy khác nhau. Mỗi quầy thuộc một địa điểm nào đó. Ví dụ về địa điểm làm việc và quầy:
- Quầy có thể là: quầy trước cửa chính vào siêu thị, quầy khu vực cashier, quầy khu vực hotzone, hoặc quầy khu vực gửi xe.
- Địa điểm làm việc có thể là: siêu thị, cửa hàng, đại lý, ngã tư, hoặc bất kỳ địa điểm nào.
ĐOẠN NÀY CHO CHÚNG TA:
- Entity:
-
- Quầy: Location (mình tạo 1 entity riêng và cho nó làm Master Data, vì mục đích thống kê, có thể kế thừa sử dụng nhiều lần hoặc có thể thay đổi lượng lớn dữ liệu sau này).
- Địa điểm làm việc: Outlet (như đã nói bên trên).
- Relationship:
- Mỗi quầy thuộc một địa điểm: Ví dụ địa điểm cửa hàng Big C (Outlet) có thể đặt được nhiều quầy (Location): quầy cửa trước, cửa sau, khu vực hotzone…
==> Outlet và Location quan hệ 1-nhiều. - Vì kế hoạch làm việc bao gồm luôn làm việc tại quầy nào, nên.
==> Location và Booking quan hệ 1-nhiều.
(Tức một Booking sẽ đi với 1 Location, và sẽ được link tới nhiều Booking).
Nói về công việc của Promoter và Sup sẽ làm trong ngày
Trước mỗi ca làm, Promoter sẽ check in bắt đầu làm việc, bao gồm: chụp một tấm hình với kệ trưng bày, ghi nhận thời gian vào làm và nhập số lượng sản phẩm nhận được lúc đầu ca vào mobile apps.
Lúc kết ca cũng tương tự, Promoter sẽ phải check out như sau: chụp một tấm hình với kệ trưng bày, ghi nhận thời gian ra về, và nhập số lượng còn lại sau ngày hôm đó vào mobile apps.
Nhiệm vụ chính của Promoter là giới thiệu sản phẩm đến càng nhiều người càng tốt. Ngoài ra, họ sẽ bán các sản phẩm này và được thưởng huê hồng cho mỗi lượng sales nhất định.
Với mỗi sản phẩm bán được, Promoter sẽ ghi nhận đơn hàng trên mobile apps để tính KPIs cho họ.
Còn Sup, họ có nhiệm vụ hỗ trợ và kiểm tra chất lượng làm việc của Promoter.
Mỗi ngày, họ sẽ đi đến các quầy để kiểm tra tác phong, quần áo, thái độ, tình hình bán hàng, hoặc mật độ người qua lại tại khu vực đó. Để chấm điểm Promoter ngay trên mobile apps dành cho Supervisor.
Mỗi promoter sẽ có số điểm cụ thể cho mỗi ngày làm việc. Điểm này sẽ được tổng hợp, và tạo thành báo cáo đánh giá Promoter cuối mỗi tháng.
ĐOẠN NÀY CHO CHÚNG TA:
- Entity:
- Thời gian vào làm/ Thời gian ra về: Time Entry
- Số lượng sp nhận được đầu ca/ Số lượng sp còn lại sau ngày hôm đó: Inventory Adjustment.
- Đơn hàng: Order
- Mỗi sản phẩm bán được: Order Line
(Hoặc theo kinh nghiệm thì anh em có thể suy ra được: Order thì phải có Order Line, vì Đơn hàng thì cần phải ghi nhận bán được sản phẩm gì, mỗi sản phẩm bán được bao nhiêu cái…).
- Relationship:
- Check-in/ Check-out: Rõ ràng User phải tương tác đến các dữ liệu Time Entry và Inventory On-hand để cập nhật số liệu về thời gian và số lượng sản phẩm trong mỗi ca làm việc.
==> User và Time Entry quan hệ 1-nhiều.
==> User và Inventory On-hand quan hệ 1-nhiều. - Bán các sản phẩm: Promoter bán các sản phẩm, đơn hàng ghi nhận doanh số cho Promoter đó.
==> User và Order quan hệ 1-nhiều.
*Bonus
Entity Inventory Adjustment là để Promoter nhập số lượng tồn đầu ngày và cuối ngày của 1 sản phẩm bất kỳ. Đây là dữ liệu user tự nhập thủ công (tức đầu ngày đếm bao nhiêu chai >> nhập vô apps, cuối ngày đếm bao nhiêu chai >> nhập vô apps).
Còn Inventory On-hand là để hệ thống lấy con số Opening Balance trên entity Inventory Adjustment, trừ đi Số lượng sản phẩm bán được trong ngày từ entity Order Line. Để từ đó đối chiếu với con số tồn cuối ngày mà user nhập thủ công.
Vì có thể Promoter chào sản phẩm cho KH >> KH đồng ý mua và bỏ sản phẩm vào giỏ đi chợ >> Promoter cập nhật bán thêm được 1 sản phẩm vào Order Line (trên apps).
Nhưng khi đến quầy tính tiền, KH đổi ý >> bỏ sản phẩm ra không tính >> dẫn tới chênh lệch giữa số lượng tồn thực tế và số lượng tồn mà Promoter nhập thủ công vào.
Ví dụ:
| Record: Inventory Adjustment | Record: Inventory Adjustment | Record: Order Line | Record: Inventory On-hand |
- ID: 02194210412
- Type: Opening
- Project: ABCH
- Outlet: Big C 3 tháng 2.
- Location: Quầy cổng A.
- Date time: 8:30 AM 24/09/2019.
- Product: Thuốc xịt muỗi 500ml
- Opening Balance: 770 (chai)
- Closing Balance: _____
| - ID: 02194210413
- Type: Opening/ Closing
- Project: ABCH
- Outlet: Big C 3 tháng 2.
- Location: Quầy cổng A.
- Date time: 4:00 PM 24/09/2019.
- Product: Thuốc xịt muỗi 500ml
- Opening Balance: _____
- Closing Balance: 761 (chai)
| - ID: 02194210413
- Order: ORD-2012042
- Submitted at: 4:05 PM 24/09/2019.
- Product: Thuốc xịt muỗi 500ml
- Quantity: 10 (chai)
- Đơn giá: 10,000 (đ)
- Tổng tiền: 90,000 (đ)
| - ID: 18394071416
- Date time: 00:00 AM 25/09/2019
- Outlet: Big C 3 tháng 2
- Location: Quầy cổng A
- On-hand: 760 (chai) [770 – 10 = 760]
- Count On-hand: 761 (chai)
|
…
Mặc dù không thể cover được hết mọi ngóc ngách trong ERD mình vẽ. Nhưng hi vọng phần giải thích trên đủ để anh em hình dung được: cách chúng ta vẽ ERD dựa trên nguồn thông tin có được như thế nào.
Nếu ERD của anh em khác biệt quá thì còm men xuống dưới cùng trao đổi nhé.
Bài note cũng đã dài rồi nên mình sẽ kết thúc tại đây Bái bai và hẹn gặp anh em ở những bài sauuuuu!!!
Nguồn: thinhnotes.com
