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.
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ề phí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.
- Đã 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.
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.
- 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.
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).
- 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…
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.
- 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.
*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 |
|
|
|
|
…
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!!!
08/10/2019 at 4:05 chiều
Chào anh, cho em hỏi ở bài “ERD là gì” anh có nói khi 2 đối tượng có mối quan hệ nhiều – nhiều thì cần có 1 entity trung gian. Nhưng ở sơ đồ trên em vẫn thấy có mấy đối tượng là quan hệ nhiều nhiều là sao ạ.
12/10/2019 at 2:07 chiều
Chào Hằng, 2 đối tượng quan hệ nhiều – nhiều có thể CẦN hoặc KHÔNG CẦN thể hiện đối tượng trung gian giữa 2 đối tượng đó nhé em.
Anh ví dụ nhé: A với B là 2 bảng quan hệ nhiều nhiều.
1. Nếu chỉ đơn thuần 1 record của A có thể link tới nhiều record của B => thì trên 1 record A sẽ có 1 lưới, gồm rất nhiều record B nằm trong lưới đó đúng không => nếu Requirement ở đây là: các record B trong lưới này không thay đổi thuộc tính (các fields) so với thuộc tính của bảng B ban đầu, nghĩa là B có bao nhiêu fields => thì xuất hiện bấy nhiêu fields
==> Thì với Requirement này, em không cần thể hiện bảng trung gian ở đây. VÀ ngược lại từ B qua A em nhé (quan hệ nhiều – nhiều luôn là symmetric!)
==> Em cần thể hiện bảng trung gian để thể hiện rõ các thuộc tính thay đổi này 😀
Ví dụ MỘT Product có thể thuộc NHIỀU Orders, và 1 Order sẽ có NHIỀU Products
==> Trên 1 Order, khi link các Products vào Order này, có phải em cần thể hiện thêm Giá sản phẩm, Tỉ lệ chiết khấu… không? Rõ ràng 2 fields này mình đâu thể hiện trên bảng Product ban đầu được (sản phẩm luôn theo thời giá và tùy điều kiện sẽ có mức chiết khấu sẽ khác nhau)
==> Cần thể hiện 1 bảng trung gian (Order Detail) để thể hiện thêm 2 fields: Giá sản phẩm và Tỉ lệ chiết khấu này.
Hoặc 1 lý do đơn giản khác của việc không thể hiện bảng trung gian là để ERD Diagram của mình nhìn gọn hơn 🙂 Tham khảo thêm nhé em!
14/10/2019 at 4:44 chiều
Dạ em hiểu rồi ạ. Cảm ơn anh nhiều nhiều 😊😊😊
12/10/2019 at 5:51 chiều
Slider speed nhanh quá, chả kịp đọc Thịnh ơi, hic 🙁
12/10/2019 at 9:54 chiều
Em mới chèn nút pause ở giữa á anh
27/10/2019 at 2:21 sáng
Thuộc tính luôn là TÍNH TỪ (ví dụ khách hàng cao 175cm, nặng 65kg, giới tính Nam, địa chỉ nhà, email…) -> nghe không ổn lắm nhỉ: Chiều cao, Cân nặng, Giới tính, Địa chỉ… đều là danh từ chứ?
29/10/2019 at 8:53 chiều
Hi a Trung, mặc dù thuộc tính là từ loại Danh từ, nhưng ý ở đây là: các thuộc tính nó thể hiện đc tính chất của đối tượng đó là gì đó.
Nên hình dung entity, relationship và attribute theo từ loại phần nào sẽ dễ hình dung hơn. Này là ý kiến cá nhân nên cũng hên xui nha a :)))
07/11/2019 at 10:21 sáng
Chờ giải thích từng chút từng chút ERD anh vẽ ạ :<
08/11/2019 at 6:51 sáng
Sr em mấy nay a lu bu quá. Đúng là để không vậy ae cũng khó hình dung. Để anh viết thêm đoạn giải thích sau nhé.
08/11/2019 at 11:02 chiều
E cảm ơn anh nhiều ạ
12/11/2019 at 8:48 sáng
Cùng ý kiến :3..
Nếu có thể a chia sẻ nhẹ về sơ đồ tư duy của mình hình thành khi có các etity ạ.
Thông quá đó để có cái nhìn tổng quát định hình và xử lý khi gặp những yêu cầu phức tạp hơn.
13/11/2019 at 5:50 chiều
mình cũng có cùng thắc mắc. Khi mới nhìn vào ERD của Thịnh, thực sực k biết bắt đầu đọc từ đâu. Có tips nào cho newbie không Thịnh?
17/11/2019 at 9:23 chiều
em nghĩ là sao entity thì vẽ mấy cái mối quan hệ ra. sau đó xếp lại ngay ngắn mấy cái entity. rồi bắt đầu xét quan hệ 1-1 hay 1-n … rồi mới tới thuộc tính.
22/11/2019 at 11:09 sáng
ah ơi, cho em hỏi, thuộc tính on-hand với count on-hand là gì ạ, em cảm ơn
25/11/2019 at 9:40 sáng
Hi Dũng, a có giải thích bên trên với lấy ví dụ trong bảng đó em. 1 cái là số liệu user tự nhập, 1 cái là số liệu hệ thống tự tính dựa trên số lượng tồn kho đầu kỳ mà user nhập trừ cho số lượng sản phẩm bán được ngày hôm đó từ sales order line đó em. Hai cái này để so sánh đối chiếu với nhau.
27/12/2019 at 11:25 sáng
Bạn ơi, mình chưa từng vẽ cái này vì nghĩ đó là việc của Dev sau khi đọc SRS. BA như mình amateur quá nhỉ 😀
27/12/2019 at 12:46 chiều
Cũng tuỳ cty, tùy dự án mà BA có làm ERD không nhé My. Chứ không phải nhất thiết lúc nào BA cũng phải vẽ FS. Nhưng nắm được ERD, BA mình sẽ nắm chắc hơn về việc: system được cấu thành từ data như thế nào!!!
01/01/2020 at 8:43 chiều
em chào anh, em thấy có nhiều quan hệ giữa thực thể Project với các thực thể khác mà không đề cập đến, anh có thể giải thích đoạn này giúp em với ạ, em cảm ơn
14/09/2020 at 9:10 chiều
Anh ơi em chưa hình dung được khi mình vẽ thì trong đầu mình sẽ đi theo thứ tự thế nào, đây là cách em nghĩ khi bập bẹ cầm bút lên vẽ:
– Đọc qua yêu cầu ở trên của anh, list ra entity; ví dụ: Project, Location (địa điểm làm vc), Time (tgian làm việc), Shift (ca làm vc), Promoter Score, Product, Inventory; các entity để chứa thông tin của Admin, Promoter, Supervisor. Em biết là còn thêm râu ria nữa nhưng mà chắc em để sau.
– Em bày hết mớ entity đó ra xong em ngồi nhìn khong biết bắt đầu từ đâu…Anh giúp em “tư duy” lúc mình vẽ với ạ :< Cảm ơn anh
14/09/2020 at 12:49 chiều
Làm zậy còn gì hót nữa em, ae đọc vào cũng nhanh quên thôi. Ai chịu thực hành thì sẽ nhớ lâu hơn. Hiệu quả hơn thì em tự vẽ xong quay lại đây trao đổi với anh nhé.
14/11/2021 at 1:32 chiều
anh ơi có thể xem giùm e cái hình ERD này đúng hay sai ko ạ. Nếu a rep lại thì để e nhắn đề bài với hình e đã vẽ qua face. Cảm ơn a ạ
18/05/2022 at 9:46 sáng
Anh Thịnh ơi, anh có thêm các bài tập khác để luyện tập vẽ ERD này không ạ?
Em muốn luyện tập thêm phần vẽ ERD này nhưng không biết lấy đề bài ở đâu, vì vẽ xong cũng chẳng biết đúng sai 🙁
07/03/2022 at 10:15 chiều
Anh thịnh cho em hỏi là cái attribute là mình tự suy ra từ case hả anh ?
19/03/2022 at 12:13 chiều
Đúng rồi em, dựa vào thông tin của đối tượng mình muốn mô tả, em tách nhỏ nó ra thành các thuộc tính có thể đo lường được & có ý nghĩa với sản phẩm của mình
(Ví dụ đối tượng là anh công nhân, trong hệ thống quản lý hiệu suất & chấm công, thì attribute thuận chân trái hay chân phải có vẻ không ý nghĩa lắm với bài toán đang giải, nhưng attribute thuận tay trái hay tay phải thì có vẻ hợp lý để tách nó thành 1 attribute để lưu trữ)
07/04/2022 at 3:34 chiều
Anh Thịnh cho em hỏi tẹo: Từ ví dụ trên, theo em hiểu thì bản chất các thuộc tính là giống nhau thì mình sẽ luôn gom vào 1 Entity đúng k ạ? Có trường hợp nào ngoại lệ không ạ?
Em đang có 1 case điểm danh các bạn học viên trong lớp học. Có 3 loại học viên: học viên chính thức, học viên học thử và học viên học bù. Thì em cũng nên xem 3 loại này vào 1 Entity ạ?
19/04/2022 at 9:21 chiều
Hi Linh, tùy vào 3 loại học viên này có các thuộc tính (các field) khác biệt nhau quá không em nhé. Ngoài ra mối quan hệ giữa 3 loại học viên này là gì, có liên quan gì đến quy trình nào khác nữa hay không. Trả lời được những câu này thì em sẽ biết nên dùng chung 1 entity hay tách riêng nhé.
23/05/2022 at 2:31 chiều
Dạ em chào anh. A cho em hỏi chỗ ví dụ về chênh lệch chai xịt muỗi ấy a. Theo như ví dụ anh đưa ra thì cái record order line tg phải diễn ra vào trước thời gian promoter kiểm lại vào cuối ngày đúng ko ạ? Lúc ấy đến cuối ngày thì hệ thống mới phát hiện chênh lệch.
Cám ơn anh!
28/05/2022 at 2:43 chiều
đúng rồi em nhé, có bán hàng thì là bán trong ca làm >> phát sinh order line trong ca làm, trước khi record inventory adjustment (type: closing) được phát sinh. Record inventory adjustment này phát sinh khi PG đã kết thúc ca làm việc.
18/05/2023 at 5:01 chiều
A ơi cho e hỏi, e có nghe 1 số bài giảng hướng dẫn ER của các trường dạy CNTT thì các thầy cô hướng dẫn vẽ theo các hình chữ nhật, hình tròn, hình thoi khá khác so với cách a vẽ. ko biết có sự mâu thuẫn nào ở đây k ạ?
19/06/2023 at 10:37 sáng
Hi em, vẽ quan hệ giữa các bảng có rất nhiều phương pháp & công cụ để làm. Chưa kể mỗi món nó có một số ký hiệu/ quy tắc được update nữa. Nên em cứ dùng thử xem cách nào phù hợp với bản thân/ dự án của mình đang làm thì dùng nhé.
Sẽ không có đúng hay sai, mà chỉ có tool đó nó có giúp mình truyền đạt được ý tưởng và save time hơn hay không thôi. Cứ thoải mái trải nghiệm em nhé.
21/05/2023 at 11:49 chiều
Em chào anh.
Anh có thể giải thích giúp em về mối quan hệ 1-1 giữa Time Entry – Order, Time Entry – Booking, Time Entry -Shift được không ạ?
Tại vì khi đọc đề bài thì em chưa thấy có hint chỗ nào đề cập đến mối quan hệ giữa Time Entry với 3 đối tượng là Order, Booking và Shift ạ mà chỉ define được mối quan hệ giữa Time Entry với User và Project thôi ạ.
Thêm vào đó, em cũng thắc mắc về mối quan hệ 1-1 của Time Entry – Order: 1 order phải có duy nhất 1 time entry, nhưng 1 time entry đâu nhất thiết phải có 1 order đâu ạ, vì chưa chắc trong thời gian làm việc đó họ bán được hàng ạ?
Cảm ơn anh ạ.