Cho mình hỏi về viêc lưu trữ 2 loại data, ví dụ lấy bài toán nhập dữ liệu về đơn hàng và đơn hơn hàng chi tiết cho dễ hình dung:
Việc lưu  trữ  danh mục các loại mặt hàng (tênhàng, đơn giá...) từng loại mặt hàng sẽ vào trong 1(hoặc nhiều) bảng T1, bảng này sẽ được cập nhật nhưng nói chung tất cả các tên hàng và đơn giá sẽ vào cùng 1 khu là khu "cố định" chỗ này.
Danh mục đơn hàng chi tiết cho 1 lần mua hàng (Đơn1) dành cho khách hàng A, thì mình đang hình dung là được tạo ra từ 1 hoặc nhiều bảng, query... để ra đc 1 query cuối (gọi là Q1) gồm đầy đủ thông tin các mặt hàng và xuất ra Report R1 để in và đưa cho khách.
Tuy nhiên khi cần lưu Q1 đó, để sau này tra lại, và tạo ra (đơn2) cho khách B, thì Q2 sẽ được tạo ntn? (bởi vì có nhiều trường hợp việc tạo ra Q1 như ở trên là gồm rất nhiều bước kết hợp bảng, Query rồi mới ra được). Sau đó Q2 lại lưu trữ ntn, để sau này lại xem lại. Và tiếp tục tạo ra Q3 ntn? (Q2 với Q1 cùng là đơn hàng chi tiết nhưng số lượng các bản ghi (hàng hóa) khác nhau... nói chung là để tạo ra được  1Q đó thì cần rất nhiều bước nhập liệu và liên kết...) Có phải nôm na là tren menu giao diện mình tạo 1 nút "tạo đơn hàng mới" và action là "copy Q1" rồi đặt tên mới và bắt đầu nhập liệu lại cho Q mới này?
Các Q nó cứ tăng dần lên theo số lượng lần ra đơn hàng, thì như vậy có đúng với cách làm mà các phần mềm bán hàng vẫn làm ko? hay phải thiết kế ntn?
Ý mình là phân biệt giữa data cho từng lần nhập liệu và data lưu trữ danh mục kho hàng, có gì khác nhau ko?
Cảm ơn các bạn.

Các file demo ứng dụng Access trên mạng có rất nhiều, bạn chỉ cần chịu khó tìm kiếm là ra cả đống và download về tham khảo cách làm là nhanh nhất.

Link đính kèm là 4 cái ứng dụng Access liên quan bán hàng, 2 cái Việt, 2 cái Tây. Trong nó cái Northwind database là cái mẫu có sẵn của Access, bạn đọc hiểu hết cách làm của nó là viết được cái ứng dụng tương đối rồi đó.

Link: https://www.mediafire.com/file/1e7qw4tp7...ng.7z/file

Tôi thấy bạn có vẻ mơ hồ trong các câu hỏi của mình nên sẽ trả lời cụ thể từng phần một:
1/ Cho mình hỏi về viêc lưu trữ 2 loại data
Data là dữ liệu lưu trữ, đây là dữ liệu gốc chưa được xử lý, việc chia nó ra là bao nhiêu loại là tùy thuộc vào từng người cụ thể và không có ý nghĩa gì về mặt thiết kế hay xử lý của 1 phần mềm access.
2/ Việc lưu  trữ  danh mục các loại mặt hàng (tênhàng, đơn giá...) từng loại mặt hàng sẽ vào trong 1(hoặc nhiều) ...
Tất cả các dữ liệu lưu trữ (data) chứa trong table (cho dù bạn xử dụng 1 hệ ứng dụng CSDL nào access, foxpro, dBASE, Oracle ...) Excel không được tính vì excel không phải là ứng dụng CSDL. Table là đối tượng dùng chứa toàn bộ thông tin hoặc dữ liệu chính xác cần lưu trữ. Các table có thể có hoặc không quan hệ với nhau, nhưng không được xung đột dữ liệu với nhau.
3/Danh mục đơn hàng chi tiết cho 1 lần mua hàng (Đơn1)...
Từ đoạn này trở đi. Bạn phải làm được hết việc này rồi mởi tính tiếp:
a/ Tạo các table với đầy đủ các field cần thiết: Khách hàng(đơn vị, họ tên, địa chỉ, điện thoại...), mặt hàng(Mã/Tên mặt hàng...), tên hàng(mã/Tên hàng, mặt hàng, đvt...), Phát sinh đơn hàng(mã phát sinh, NCC/Người mua, ngày phát sinh, số chứng từ), Chi tiết đơn hàng(mã phát sinh, tên hàng, số lượng, đơn giá mua/bán, thành tiền...)
b/ Tạo các quan hệ (relationship) đầy đủ, hợp lý, chính xác.
c/Nếu bạn có nhiều kho hàng. bạn cần có table kho hàng, và trên table Chi tiết đơn hàng phải có field kho hàng để xác định số lượng nhập xuất cho từng kho và tạo quan hệ cho 2 table kho hàng và Chi tiết đơn hàng để xử lý sau này, tất nhiên nếu bạn quan tâm với nhân viên giữ kho bạn cũng sẽ phải tạo table nhân viên và tạo quan hệ 2 table nhân viên và kho...
Để tạo 1 phần mềm tốt, điều quan trọng là phân tích và tạo được hệ thống table đầy đủ, chính xác và hợp lý. Còn việc nhập mỗi lần 1 record hay nhiều record đơn giản hơn nhiều. Khi bạn có 1 hệ thống table tồi thì chỉ cần nhập 1/2 record cũng đủ làm bạn điên tiết 

Cảm ơn bác tranthanhan1962, phần chỉ dẫn của bác chuẩn y như các tài liệu em đọc được về CSDL
Thứ tự làm như ở phần 3 bác hướng dẫn là đi từ trên xuống, chỉ có điều là với người mới thực hành giải quyết bài toán thì e thấy hay đi ngược từ dưới lên, tức là đi từ 1 cái output cụ thể (và cần thiết nhất) theo nhu cầu cuối, đi ngược trở lên (theo e biết đây cũng là 1 cách làm) rồi cứ thế loang dần ra thêm các tham số khác ít cần thiết hơn, cuối cùng rồi mới suy ra về các bảng. Cách này về mặt tưởng tượng hình ảnh sẽ dễ hình dung ra hơn nhưng sẽ bị hơi rối về mặt hệ thông như chính thắc mắc em hỏi.
Ví dụ quá trình suy nghĩ của e như sau:
Muốn có danh sách đơn hàng chi tiét > phải có Report đơn hàng chi tiết > phải có Query "danh mục đơn hàng chi tiết" > phải đc kết hợp từ bảng danh mục đơn hàng... ok 
Nhưng bị cái trên cái report đơn hàng chi tiết lại có mục số hóa đơn, vậy số đó lại phải nằm ở đâu đó, mà chỉ hiển thị 1 giá trị trên mỗi cái report đơn hàng chi tiết này thôi > vậy những cái report đơn hàng khác thì đã lưu ở đâu? > ... kiểu như vậy nên mới có câu hỏi là 2 loại data

Như bác giải thích thì em hiểu là nên tư duy kiểu kết quả kết xuất cuối chỉ là sự kết hợp giữa các thành phần theo 1 điều kiện mình muốn gọi ra thôi. 1 bảng Report cuối có thể được hiển thị cho bất kỳ trang danh sách đơn hàng nào (số hóa đơn do mình nhập vào). còn thực tế mình ko lưu trữ 1 đống report nào như 1 quyển sổ vật lý gồm tất cả những tờ hóa đơn hàng chi tiết 1, 2, 3...n để mà mình bật từng report lên xem đúng ko bác.

(11-08-21, 03:50 PM)minhvu410 Đã viết: thực hành giải quyết bài toán thì đi ngược từ dưới lên, tức là đi từ 1 cái output cụ thể (và cần thiết nhất) theo nhu cầu cuối, đi ngược trở lên

Đây là nguyên tắt cho tất cả mọi người chứ không là người mới người cũ gì cả. Giống như hành trình phá án của công an, yêu cầu là tìm thủ phạm. bạn phải đi ngược từ các bằng chứng hiện trường đi ngược lên. Đây gọi là phân tích ngược.
Tôi không biết các yêu cầu của phần mềm của bạn nhưng đây là 1 ví dụ:

Tất nhiên phần mềm trên không chỉ có Biên lai - phiếu, và trong Biên lai - phiếu tôi chỉ lấy 1 thứ là phiếu nhập. Tất nhiên xong phiếu nhập sẽ tới phiếu khác, xong các phiếu sẽ tới các báo cáo khác... bla, bla...

Các khung màu nâu chỉ dữ liệu đơn vị sử dụng phần mềm cũng có thể dùng label để xử lý, nhưng nếu tạo hẳn 1 table sẽ dễ dàng hơn khi thay đổi địa chỉ, điện thoại chẳng hạn.
Các khung màu xanh dương rõ ràng là form chính có resource là table chính - table phát sinh vì dữ liệu của nó có ngày/số chứng từ, ngày/số phiếu nhập, đơn vị bán hàng (đây cũng là các field của table này) 
Khung màu tím chính là subform có số liệu chi tiết của hàng hoá, kho...
Khung màu đỏ là các số liệu hạch toán tài khoản là 1 subform khác. Tất nhiên, nếu không cần thì bỏ qua nó.
Giống như vậy, hàng chữ ký cuối cùng có thể đưa vào các field tên họ của các người ký để in cho đẹp còn nếu sử dụng mộc tên thì không cần.
Ngoài ra cùng phải có 1 cái mã ID nào đó để liên kết table chính và các subtable. Rồi phải có 1 function để biên dịch số tiền ra bằng chữ.
Subtable số liệu của hàng hoá có tên hàng hóa -> cần phải có table Danh sách hàng hóa, sub table tài khoản có têntài khoản -> cần phải có table danh sách tài khoản.
Nếu có nhiều kho thì trên chi tiết hàng hóa phải có field tên kho cho từng record -> phải có table danh sách kho quản lý tên kho.
Có nhập thì có xuất, 2 phát sinh này hoàn toàn giống nhau trừ nghiệp vụ -> thêm field nhập/xuất để quản lý record.
có nhập/xuất ở table phát sinh chỉ cần xử lý thêm field tồn cho sub table chi tiết hàng hóa: nhập -> tồn = + số lượng, xuất -> tồn = - số lượng. Sau này tạo query chỉ cần sum 1 phát̀ ra tồn số lượng.
Xong trường hợp nhập/xuất xử lý đến trường hợp khác - ví dụ thu/chi, Xong biên lai-phiếu chuyển sang các báo cáo khác. số liệu các field nào đã có nằm trong table nào. Cần thiết tạo 1 table mới để chứa field dữ liệu hay nhét field đó vào table nào thì hợp lý hơn
Để phân tích OK cần phải mở 1 file word hay lấy quyển tập ra gạch từng đầu dòng 1, xem xét xử lý từng cái cho hợp lý. chứ không nên mở ngay field access tạo tùm lum mà không table nào ra table nào. Chúc bạn thành công