Thiết kế Database và việc tối ưu hóa Database cho phần mềm kế toán

  • Thread starter thandong_it
  • Ngày gửi
T

thandong_it

Sơ cấp
5/7/05
5
3
1
38
DNA
#1
Chào cả nhà

Rất vui lại gặp cả nhà trong một chủ đề khác. Hồi ấy cũng lâu tớ không nhớ. Trên WKT có bàn về viết phần mềm cho wkt , cũng có nhiều vấn đề trong đấy. Hôm nay tôi có một chủi đề mong mọi người trao đổi hết mình để cùng học hỏi nhé

Hiện nay trong tất cả các phần mềm kế toán hiện nay, mỗi cái nó cách tổ chức Database khac nhau không ai giống ai. Tôi muốn các bạn trao đổi cái này trong một cách nhình chung nhất của một phần mềm kế toán hiện nay. Làm thế nào để Database của chúng ta gọn, nhẹ, đầy đủ, đáp ứng được toàn bộ các nghiệp vụ kế toán hiện hành hiện nay ( Cụ thể là thông tư số 23 của Bộ tài chính).Bài toán của chúng ta sẽ đặt ra là

1. Phân hệ kế toán Tiền (111,112)
2. Hàng tồn kho (15x)
3. TSCĐ (21x)
4. Công nợ (13x)
5. Tiền lương (33x)
6. Kế toán Tổng hợp
7. Báo cáo Tài chính
8. Báo cáo quản trị "Dự định về sau" ( Hiện tại khoan bàn đã sẽ tiếp sau)
9. Phần hệ thống

Nào bắt đầu chúng ta sẽ đi từ việc tổ chức DataBase trước đi ......

Xin mời các bạn....:0frown:
 
hai2hai

hai2hai

VNUNI Makes a difference
29/4/04
2,012
125
63
45
Hà nội
vnuni.net
#3
VoiCoi nói:
chắc là phải có architecture và high-level design trước đã chứ nhỉ :)
VoiCoi ơi, extreem programming thôi.

Nhưng mà chỉ có dân IT mới biết là thiết kế database chỉ là 1 view trong high-level design. Thôi, làm kiểu top-down analysis vậy, mà thôi, nhảy luôn vào Database Design (ngầm định là quân ta đã hiểu hết chức năng của kế toán rồi). Nếu bàn đến architecture và high-level design thì sợ ít người tham gia lắm.

Go ahead....
 
T

thandong_it

Sơ cấp
5/7/05
5
3
1
38
DNA
#4
Trước tiên đơn giản chúng ta chia hệ thống DB phần mềm ra thành các loại sau

1. DB nhật ký (record lại toàn bộ các giao dịch kế toán )
2. DB danh mục (Hệ thống các danh mục TK, vật tư, công nợ, TSCĐ chi tiết cho phân hệ tương ứng..)
3. DBTrung gian ( Các DB được tạo ra trong quá trình xử lý và Ra report)
4. DB Hệ thống ( DB lưu lại các thao tác với hệ thống, Menu, User.. các giao dịch vào và ra syste.....)

Như vậy một phần mềm kế toán cách tổng quan nhất sẽ có 4 loại DB như thế, các bạn có ý kiến gì không ? Trao đổi nhé sau đấy chúng ta sẽ đi vào từng chú DB một và phân tích kỹ cho từng chú để các bạn có cách nhìn tổng quan hơn nữa nhé. !!!:0frown: :0frown:

Trân trọng !!
 
K

katie

Sơ cấp
6/11/05
4
0
0
HCMC
#5
thandong_it nói:
3. DBTrung gian ( Các DB được tạo ra trong quá trình xử lý và Ra report)
Theo ý tớ thì đôi lúc cũng không cần cái chú DB này :)
 
H

hangiang

Thành viên thân thiết
16/10/04
105
0
16
Da Nang
#6
katie nói:
Theo ý tớ thì đôi lúc cũng không cần cái chú DB này :)
Theo tôi thì lại cần đấy, tuy nhiên không fải mọi cái DB tạm đều được tạo ra từ đầu mà :
+ sẽ có 1 số DB được tạo sẳn bộ khung (cấu trúc) chỉ để làm nhiệm vụ xử lý trung gian (không có record nào cả), sau khi hoàn thành nhiệm vụ của nó, ta có thể xoá tất cả record trong đó
+ sẽ có 1 số được tạo ra trong quá trình xử lý data, những DB này sẽ được "hô biến" sau khi xong nhiệm vụ
 
K

katie

Sơ cấp
6/11/05
4
0
0
HCMC
#7
Đối với vài ngôn ngữ sau này chi cần thiết lập các khuôn định dạng dữ liệu (schema) để query data vào thôi .. nhưng gọi la những DB thì cũng ổn muh.
 
hai2hai

hai2hai

VNUNI Makes a difference
29/4/04
2,012
125
63
45
Hà nội
vnuni.net
#8
katie nói:
Theo ý tớ thì đôi lúc cũng không cần cái chú DB này :)
Hơi ...technical 1 tý mà tớ lại ko muốn đề cập nhưng vẫn phải nói qua.

Trong việc thiết kế CSDL, thường có 2 việc: Chuẩn hóa dữ liệu (nhằm tối ưu hóa DL) và Phi chuẩn hóa dữ liệu (nhằm tăng tốc ở 1 số công việc nào đó).

Tuy nhiên, mọi người thường bàn tới việc "thiết kế" phần mềm thì nhảy bụp ngay vào phần "thiết kế database". Như vậy là bỏ qua rất nhiều khâu...cực kỳ cần thiết. Có thể các bạn đã thinking hết mọi thứ trong đầu rồi nên mới bụp 1 cái là DB ngay. OK, thế cũng hay. Vì khi các bạn vẽ ra phần DB, mọi người có thể hình dung ...ngược lại được vấn đề :)

Để cho dễ hình dung chúng ta đang ở đâu, tớ "vẽ" lại cách làm PM theo kiểu Analysis cổ điển (top-down):

Giả sử ta có bài toán A với mục tiêu là G
Để đạt được mục tiêu G, PM cần phải có ...3 chức năng: F1, F2, F3
Ở chức năng F1, ra có mô tả chức năng này làm gì, có vị trí gì trong bài toán A,....
Nhưng cái mà ta bàn đến ở đây là để thực hiện F1 thì có bao nhiêu thực thể tham gia vào (Gọi thực thể là Table chẳng hạn). Ví dụ: F1 có đụng chạm đến 3 thực thể là T1, T2, T3. (xác định luôn các quan hệ của 3 thực thể này như thế nào để đạt được chức năng F1 này)
Tương tự như vậy, F2 đụng đến 3 thực thể là T4, T5, T3 (và các quan hệ của 3 thực thể này...), F3 có 4 thực thể là T6, T7, T8, T3.

Sau khi ta đã xác định được A có những chức năng nào (F1, F2, F3), Mỗi chức năng lại có những thực thể nào và quan hệ của chúng ra sao (T1,...T8). Từ đó, ta mới xác định tiếp là Chức năng nào dùng thực thể nào...
Rồi còn 1 số công việc khác nữa.....

Tóm lại, hiện chúng ta đang ở giai đoạn làm ngay các thực thể (T1...T8) mà bỏ qua các công việc khác.

Như vậy, chúng ta đã hình dung được vấn đề như vậy rồi. Bây giờ, chúng ta lại tiếp tục bàn tiếp vấn đề database trong PM kế toán nhé.

Mời
 
T

Tung_beo

Sơ cấp
7/11/05
10
0
0
Hanoi
#9
thandong_it nói:
Chào cả nhà

Rất vui lại gặp cả nhà trong một chủ đề khác. Hồi ấy cũng lâu tớ không nhớ. Trên WKT có bàn về viết phần mềm cho wkt , cũng có nhiều vấn đề trong đấy. Hôm nay tôi có một chủi đề mong mọi người trao đổi hết mình để cùng học hỏi nhé

Hiện nay trong tất cả các phần mềm kế toán hiện nay, mỗi cái nó cách tổ chức Database khac nhau không ai giống ai. Tôi muốn các bạn trao đổi cái này trong một cách nhình chung nhất của một phần mềm kế toán hiện nay. Làm thế nào để Database của chúng ta gọn, nhẹ, đầy đủ, đáp ứng được toàn bộ các nghiệp vụ kế toán hiện hành hiện nay ( Cụ thể là thông tư số 23 của Bộ tài chính).Bài toán của chúng ta sẽ đặt ra là

1. Phân hệ kế toán Tiền (111,112)
2. Hàng tồn kho (15x)
3. TSCĐ (21x)
4. Công nợ (13x)
5. Tiền lương (33x)
6. Kế toán Tổng hợp
7. Báo cáo Tài chính
8. Báo cáo quản trị "Dự định về sau" ( Hiện tại khoan bàn đã sẽ tiếp sau)
9. Phần hệ thống

Nào bắt đầu chúng ta sẽ đi từ việc tổ chức DataBase trước đi ......

Xin mời các bạn....:0frown:

Hi all

Theo kinh nghiệm của mình Phần mềm kế toán (các Table Nghiệp vụ) chỉ cần dùng các table sau la đủ

Phieu_NX
dong_NX
Phieu_TC
dong_tc


Chỉ cần 4 table này là đủ thể hiện các nghiệp vụ kế toán của VN

Các bạn nghĩ sao ???
 
hai2hai

hai2hai

VNUNI Makes a difference
29/4/04
2,012
125
63
45
Hà nội
vnuni.net
#10
Tung_beo nói:
Hi all

Theo kinh nghiệm của mình Phần mềm kế toán (các Table Nghiệp vụ) chỉ cần dùng các table sau la đủ

Phieu_NX
dong_NX
Phieu_TC
dong_tc


Chỉ cần 4 table này là đủ thể hiện các nghiệp vụ kế toán của VN

Các bạn nghĩ sao ???
Bạn phân tích kỹ hơn tý nữa đi. Có vẻ hơi giống cách mà tớ hay làm. :)
Mình thì nghĩ trên quan điểm giao dịch, SAP hay gọi nó là documents. Dựa trên Document Type có thể có được nhiều kiểu giao dịch với các định khoản khác nhau.

Theo mình nghĩ. 1 Transaction thì có 3 parts:
- Trans_Header
- Trans_LineItem (Transaction Detail)
- Định khoản (Nên tách thành 1 phần riêng, link với transaction header) - Làm như thế này, có thể tách rất tốt giữa các modules ở các quy trình khác (sales, purchasing, inventory,...) với phần finance.

Mọi người nghĩ sao?

Nhân tiện, tớ thấy có nhiều người nói rằng tính giá vốn theo phương pháp BQGQ theo mỗi lần nhập là phức tạp và rất chậm (mỗi khi phải tính lại chẳng hạn). Nhất là các trường hợp phải tính giá vốn cho trường hợp chuyển kho, lắp ráp từ nhiều Items ở các kho khác nhau thành 1 sản phẩm ở 1 kho khác (như vậy phải tính giá của nhiều items tại mỗi thời điểm thực hiện giao dịch ở các kho khác nhau và tính giá của item đã được lắp ráp ở kho mới). Việc phải tính giá tại nhiều nơi, đối với nhiều items ở nhiều kho khác nhau nên được thiết kế sao cho tăng tốc độ? (Nhất là trường hợp ở PM của ta lại cho phép sửa trực tiếp các giao dịch mà ko sinh ra 1 giao dịch nào khác - trái với nguyên tắc KT - nên phải tính lại khá mất công).

Mọi người có cao kiến gì trong vụ này ko?

Mời!
 
H

hangiang

Thành viên thân thiết
16/10/04
105
0
16
Da Nang
#11
Tung_beo nói:
Hi all
dong_NX

dong_tc
Bạn có thể cho biết 2 file trên làm nhiệm vụ gì vậy?

Theo cách của Tôi thì nhốt hết vào 1 file, có mã để phân biệt giữa các modul khác nhau
 
hai2hai

hai2hai

VNUNI Makes a difference
29/4/04
2,012
125
63
45
Hà nội
vnuni.net
#12
hangiang nói:
Bạn có thể cho biết 2 file trên làm nhiệm vụ gì vậy?

Theo cách của Tôi thì nhốt hết vào 1 file, có mã để phân biệt giữa các modul khác nhau
Transaction thì phải có ít nhất là 2 files (à quên, 2 tables mới đúng): Header & Detail rồi.

Phần Header của transaction bao giờ cũng có 1 phần chung rất giống nhau (thường có các thuộc tính sau: TransID, TransNo, TransDate, TransTypeID, TransRefNo, TotalAmount,..., TransDescription, UserID, TimeStamp) nên ta có thể Tạo 1 Generic_Transaction_Header. Từ cái Generic_Header đó, ta có thể tạo các Concrete_Transaction_Header (Có bao nhiêu TransTypes thì có bấy nhiêu cái Concrete này. Những Concrete_Transaction_Header này có quan hệ 1-1 với Generic_Transaction_Header). Đó là phần Header của transaction. Thiết kế kiểu này các bạn sẽ thấy:

Ưu điểm:
- Tính giá vốn theo BQGQ mỗi lần nhập rất dễ dàng (vì khi làm việc với các chứng từ thì đầu mối nó là Generic_Transaction_Header, các thứ tự của transactions là phân theo TransID (tăng dần) mà ko cần phải dựa vào TransDate + Time.
- Generic_Transaction_Header không bị thừa thông tin (nếu thuộc tính của tất cả các transactions mà tập hợp vào 1 table thôi thì sẽ thừa thông tin, chạy rất chậm, ko tối ưu dữ liệu)
- Với cách thiết kế này, có thể viết theo hướng OOP rất tiện
Nhược điểm:
- Hơi khó khăn trong khi viết code nếu mọi người ko quen thinking kiểu OOP

Phần Detail của transaction - Là các Line_Item tables có quan hệ 1-n với Generic_Transaction_Header
....
 
Sửa lần cuối:
T

Tung_beo

Sơ cấp
7/11/05
10
0
0
Hanoi
#13
hangiang nói:
Bạn có thể cho biết 2 file trên làm nhiệm vụ gì vậy?

Theo cách của Tôi thì nhốt hết vào 1 file, có mã để phân biệt giữa các modul khác nhau

Hehehehehehe

Nếu làm như vậy cung OK thôi, nhưng vấn đề là các báo cáo quản trị , kỹ thuật Drill down sẽ rất khó làm nếu áp vào 01 file

mặt khác cần phân biệt các thao tác khác nhau trên các dòng dữ liệu khác nhau
VD: Nhập, Xuất sẽ lưu lại các vết về hàng hóa đồng thời sẽ ghi các nghiệp vụ về kế toán lên dong_tc.....


các pac có cao kiến gì không ????
 
H

hieppm

Thành viên thân thiết
5/7/05
72
1
0
40
Tp.HCM
#14
Database!!!

Thiết kế database phải dựa trên nghiệp vụ, công nghệ, kỹ thuật lập trình thì mới toàn vẹn được! nói trống trơn như vậy thì ... đâu khác gì đọc sách? lý thuyết trơn!!!!!!! không làm nên điều gì cả và cũng không học được kinh nghiệm gì cả

Mỗi database đều có ưu và nhược điểm của nó. Fox khác, SQL Server khác, Access khác, MySQL khác, SAPDB khác, Firebird khác,Oracle khác,...

Khi thiết kế, kiến trúc sư hệ thống sẽ dựa vào quy mô của từng phần mềm mà thiết kế khác nhau, có thể vài chục table cũng có thể lên đến vài trăm table cho một hệ thống. :biggrin:
 
hai2hai

hai2hai

VNUNI Makes a difference
29/4/04
2,012
125
63
45
Hà nội
vnuni.net
#15
Thiết kế database phải dựa trên nghiệp vụ, công nghệ, kỹ thuật lập trình thì mới toàn vẹn được!
Hic, Ở đây đang nói về thiết kế DB cho PMKT mà :), và mình cũng giả sử ở đây toàn là người non-it (như mình thôi :)) nên chỉ nói theo phương diện rất cụ thể là cách thiết kế các transactions trong PMKT sao cho gọn (chắc ý thandong_it cũng là như thế - thandong_it 1 phần là bận, 1 phần là chán wkt nên chạy ...mất dép rồi, tớ yêu wkt nên mới bàn tiếp chuyện của người khác thôi). Tớ hiểu tính cách, sự "hiểu biết" của các cô các bác programmers lắm :)

nói trống trơn như vậy thì ... đâu khác gì đọc sách? lý thuyết trơn!!!!!!! không làm nên điều gì cả và cũng không học được kinh nghiệm gì cả
Người ta có nói Lý thuyết đi đôi với Thực hành. Chứ có nói là Thực hành thôi đâu. Ở đây mọi người cũng đang viết rất cụ thể đấy chứ. ERP hay bất kỳ cái gì cũng vậy, ko có lý thuyết đi trước thì cũng chẳng có thực hành đâu.

Mỗi database đều có ưu và nhược điểm của nó. Fox khác, SQL Server khác, Access khác, MySQL khác, SAPDB khác, Firebird khác,Oracle khác,...
Tớ design DB = công cụ nên ko care đến CSDL lắm, vẫn cái model đó tớ thích generate là loại DB nào cũng được. Rồi tùy loại DB nào xem có cần viết trigger, sp, v.v.. hay ko mà gen nốt ra (rồi viết thêm vào)

Khi thiết kế, kiến trúc sư hệ thống sẽ dựa vào quy mô của từng phần mềm mà thiết kế khác nhau, có thể vài chục table cũng có thể lên đến vài trăm table cho một hệ thống.
Quy mô của từng phần mềm: Vẫn là đang nói về PMKT chung chung thôi, đâu có xa xôi gì. Dĩ nhiên, PMKT có dăm bảy loại nhưng ở đây khó nói hết ra được nên mọi người mới mổ xẻ từng phần. Đang bàn về thiết kế transactions, documents của PMKT.

Nói thật, tớ cũng ko nghĩ là phát triển tiếp cái topic này đâu. Vì thế mọi người nếu ko đóng góp cho chủ đề thì đừng viết tiếp vào đây nữa nhé vì nếu viết tiếp là tớ lại ... phản biện tiếp đấy. (vì nó ăn vào máu thịt rồi, bao năm vẫn chẳng quên được)
 
haizapo

haizapo

Sơ cấp
18/4/06
67
1
8
HCMC
#16
Em nghĩ là chúng ta nên nói chuyện nhiều hơn vào từng vấn đề cụ thể rồi mới khái quát lại hay tổng hợp lại. Chứ đọc bài phân tích của các bác nói thật, chung chung và hơi khó hiểu ( vì bản thân em cũng hơi chậm hi hiiiii).
Vậy, tại sao chúng ta không tập trung giải quyết những vấn đề cụ thể hơn.
Nhân đây, em cũng muốn đưa ra vấn đề tồn đọng của chính công ty em làm Kế toán trưởng.
Thứ nhất, sử dụng đến 2 loại tiền tệ(VND và USD) trong giao dịch và thu chi cũng làm bảng bao gồm 2 loại tiền tệ. Tất nhiên bảng báo cáo này là của nội bộ thôi.
Thứ 2, dữ liệu chưa chuẩn hóa. Bảng báo cáo bán thì tên khách hàng khác, mà thu chi lại tên khách hàng khác(mặc dù là cùng khách hàng). Em đang cố gắng điều chình để cập nhật chung trong 1 bảng báo cáo tổng hợp chi tiết và từ đấy lấy lên Bảng cân đối số phát sinh. Mong các bác hướng dẫn, nhưng đừng bảo em quy đổi USD sang VND nhé. Board ò Manager không chịu...hu huuuuu
 

Thành viên trực tuyến

  • mypham0711
  • daongocnam0603
  • bebapkute




Xem nhiều