Đề tài Quản lý sinh viên nội trú trường đại học Kinh tế Quốc dân

, Merge, Add, Substract, Multily, Division, Do… Các phép toán số học và logic thường dùng. Ngôn ngữ cũng dùng các danh từ được dùng để mô tả dữ liệu trong từ điển hệ thống. Ngôn ngữ cấu trúc không dùng các trạng từ và tính từ. Ví dụ 1 : Đọc số lượng trong kho Chọn trường hợp: Trường hợp 1: Nếu số lượng trong kho lớn hơn hạn mức dự trữ Thực hiện: Không làm gì Trường hợp 2: Nếu số lượng trong kho nhỏ hơn hạn mức lưu kho Thực hiện : Tạo một đơn đặt hàng Trường hợp 3: Hết hàng trong kho Thực hiện: Đặt hàng khẩn cấp Hết trường hợp Một số quy ước quy tắc liên quan đến DFD Mỗi luồng dữ liệu phải có một tên trừ luồng xử lý và kho dữ liệu Dữ liệu chứa trên hai vật mang khác nhau nhưng luôn đi đôi cùng nhau thì có thể tạo ra một luồng duy nhất. Xử lý luôn phải được đánh mã số. Vẽ lại các kho dữ liệu để các luồng dữ liệu không cắt nhau. Tên cho xử lý phải là một động từ. Xử lý buộc phải thực hiện một biến đổi dữ liệu. Luồng vào phải khác với luồng ra từ một xử lý. Đối với việc phân rã DFD Thông thường một xử lý mà logic xử lý của nó được trình bày bằng ngôn ngữ có cấu trúc chỉ chiếm một trang giấy thì không phân rã tiếp. Cố gắng chỉ để tối đa 7 xử lý trên một trang DFD. Tất cả các xử lý trên một trang DFD phải thuộc cùng một mức phân rã. Luồng vào của một DFD mức cao phải là luồng vào của một DFD mức con nào đó. Luồng ra tới đích của một DFD phải là luồng ra của một DFD mức cao hơn nào đó. Đây gọi là nguyên tắc cân đối của DFD. Xử lý không phân ra tiếp thêm thì được gọi là xử lý nguyên thủy. Mỗi xử lý nguyên thủy phải có một phích logic trong từ điển hệ thống. Sơ đồ luồng thông tin và sơ đồ luồng dữ liệu là hai công cụ thường dùng nhất để phân tích và thiết kế HTTT. Chúng thể hiện hai mức mô hình và hai góc nhìn động và tĩnh về hệ thống. Những công cụ này được phần lớn các nhà phân tích thiết kế sử dụng bất luận là quy mô dự án lớn hay nhỏ hay kích thước hệ thống lớn hay nhỏ. Ngày nay một số công cụ được tin học hóa, vì vậy có nhiều phần mềm cho phép xây dựng sơ đồ luồng dữ liệu của một hệ thống. Một số phần mềm tinh tế hơn cho tạo ra cả sơ đồ luồng dữ liệu và từ điển hệ thống. Tuy nhiên các công cụ chỉ giúp các nhà phân tích tạo nhanh hơn các sơ đồ hoặc mối liên quan giữa sơ đồ và các yếu tố trong từ điển, chứ nó không thực hiện thay công việc của nhà phân tích và việc phát hiện lỗi trên sơ đồ vẫn thuộc trách nhiệm nhà phân tích. Đông Tĩnh Vật lý IFD ( Information Flow Diagram) – Sơ đồ luồn thông tin SD ( System Dictionary) Từ điển hệ thống Các phích vật lý. Logic DFD (Data Flow Diagram) Sơ đồ luồng dữ liệu. SD (System Dictionary) Từ điển hệ thống Các phích logic. Các công cụ phân tích và thiết kế hệ thống thông tin 4. Mô hình hóa và chuẩn hóa dữ liệu 4.1. Mô hình hóa dữ liêu là gì ? Mô hình hóa dữ liệu là quá trình xác định các chi tiết dữ liệu và những mối quan hệ cần được lưu trữ trong một DSDL. Đó cũng là quá trình trao đổi về cách thiết kế CSDL giữa người này với người khác. Mục đích là tạo ra một mô hình dữ liệu trong thế giới thực tại. Những yếu tố cơ bản hợp thành một mô hình dữ liệu là : các thực thể, các thuộc tính của mỗi thực thể, các yếu tố phân biệt của mỗi thực thể và những mối quan hệ giữa các thực thể. Việc xây dựng mô hình dữ liệu đòi hỏi một sự phối hợp chặt chẽ giữa khách hàng, tức là đại diện của những người dùng, với các nhà thiết kế. Phác họa mô hình dữ liệu là một thử nghiệm, thường phải sửa đi sửa lại nhiều lần. Một mô hình dữ liệu sẽ thay đổi khi người thiết kế hiểu biết nhiều hơn về nhu cầu và lĩnh vực hoạt động của khách hàng. Sản phẩm cuối cùng rất có thể sẽ khác xa với những phiên bản ban đầu của nhà thiết kế. Tốt nhất là dùng một phần mềm máy tính để vẽ và sửa mô hình dữ liệu được dễ dàng hơn. 4.2. Chất lượng của mô hình dữ liệu Khi đánh giá chất lượng của một mô hình dữ liệu trước hết ta phải tìm hiểu cặn kẽ bối cảnh của môi trường mà trong đó mô hình được sử dụng, sau đó dựa vào các tính chất của một mô hình dữ liệu hoàn hảo và coi đó là những tiêu chuẩn để đánh giá. Một mô hình dữ liệu hoàn hảo có các tính chất sau đây: Tuân thủ mọi quy tắc và quy định về xây dựng mô hình dữ liệu đã được khách hàng chấp nhận. Không nhập nhằng dẫn tới hiểu theo nhiều nghĩa khác nhau. (Chẳng hạn, nên dùng cụm từ số hiệu hóa đơn thay cho số hóa đơn để tránh hiểu lầm thành số lượng hóa đơn). Các tên thực thể trong một mô hình và các tên thuộc tính của một thực thể không trùng nhau. Các tên đều có nghĩa và gần sát với những tên mà khách hàng thường dùng hàng ngày. Mỗi thực thể có ít nhất một yếu tố phân biệt để tránh tình trạng người dùng tra cứu nhầm thực thể này với thực thể khác. Tất cả các mối quan hệ đều được ghi nhận bằng các kí hiệu chuẩn xác. Nếu cần thiết thì viết thêm lời mô tả quan hệ để tránh hiểu lầm. Tất cả các thực thể và các thuộc tính của thực thể mà khách hàng quan tâm đề được liệt kê trongmô hình. Là hình ảnh của dữ liệu với độ trung thực cao (High fidelity image): Những người dùng dữ liệu muốn có hình ảnh dữ liệu với độ trung thực cao, giống như những người say mê âm nhạc muốn có một dàn nhạc với âm thanh có độ trung thực cao nhất không bị bóp méo. Một mô hình dữ liệu là một hình ảnh với độ trung thực cao khi nó mô tả trung thành thế giới thực tại và cung cấp được thông tin chính xác cho người dùng. Độ trung thực của một mô hình dữ liệu phụ thuộc phần lớn vào sự phản ảnh đầy đủ và chính xác các mối quan hệ giữa các thực thể. Chẳng hạn, nếu một mối quan hệ thực tế là m:m thì nó cũng phải được ghi nhận như vậy trong mô hình. Một mô hình dữ liệu hoàn hảo sẽ dễ hiểu, dễ dùng đồng thời phản ánh được đầy đủ và chính xác thực tế theo đúng yêu cầu của người dùng. 4.3. Nâng cao chất lượng của mô hình dữ liệu Để có được một mô hình dữ liệu hoàn hảo thì phải tốn thời gian. Khách hàng phải giải thích vấn đề một cách đầy đủ sao cho người thiết kế có thể hiểu rõ mọi yêu cầu của khách hàng nhằm thiết kế được một mô hình đáp ứng yêu cầu đó. Mô hình hóa dữ liệu giống như một quá trình thử nghiệm và cải biến dần: cán bộ thiết kế dần dần tạo ra một mô hình của CSDL nhờ sự tiếp xúc và trao đổi thường xuyên với khách hàng. Đôi khi mô hình dữ liệu bộc lộ những thiếu sót nghiêm trọng khiến nhà thiết kế phải thay đổi hàng loạt. Sau đây là một số gợi ý để nâng cao chất lượng của mô hình dữ liệu và giảm bớt những sự sửa đổi không đáng phải tiến hành. a. Mở rộng hay thu hẹp mô hình dữ liệu Mô hình dữ liệu có thể mở rộng và có thể thu hẹp được. Mô hình dữ liệu sẽ được mở rộng khi ta tăng phạm vi ứng dụng, bổ sung thực thể, thuộc tính và các mối quan hệ để bao trùm cả các trường hợp ngoại lệ. Nói chung, các mô hình dữ liệu thường lớn dần lên, có khi gấp hai ba lần quy mô ban đầu, bởi vì nó cần phản ánh độ phức tạp của thực tế mà người thiết kế không dễ gì nhận thức được đầy đủ ngay từ đầu. Đừng cố ý hạn chế sự tăng trưởng của mô hình dữ liệu mà hãy để cho nó lớn lên đến mức cần thiết. Một mô hình dữ liệu có thể thu hẹp lại khi ta tổng quát hóa các thực thể của nó. Mô hình cũng được thu hẹp khi ta có những cải tiến để biểu diễn các quan hệ một cách đáng tin cậy đúng đắn và ít vụng về hơn. Sau đây là một vài ví dụ về sự cải biến mô hình dữ liệu: Ví dụ 1: Xét trường hợp một công ty có những phòng ban và những tổ đội. Một phòng ban có nhiều tổ đội nhưng mỗi tổ đội chỉ thuộc về một phòng ban. Thoạt đầu, giả sử công ty chỉ cho phép mỗi cán bộ công nhân viên (CBCNV) làm việc trong một tổ đội duy nhất. Mô hình dữ liệu phản ánh cơ cấu tổ chức theo công việc của công ty được thể hiện như ở hình sau: Mô hình cơ cấu tổ chức theo công việc Trong suốt thời kì làm việc cho công ty, một CBCNV có thể thuyên chuyển từ bộ phận này sang bộ phận khác. Thậm chí, công ty có thể thay đổi chủ trương, cho phép một người đồng thời kiêm nhiệm ở nhiều bộ phận. Muốn ghi nhận cả lịch sử, tức là việc làm trong quá khứ, và thể hiện được chủ trương mới của công ty thì cần mở rộng mô hình. Vì một tổ có nhiều CBCNV và một CBCNV có thể làm việc cho nhiều tổ nên ta có quan hệ m:m giữa tổ và CBCNV . Cần có một thực thể giao để biểu diễn mối quan hệ này, ta gọi nó là một thực thể Chuc_vu. Mỗi hiện diện của thực thể, tức là mỗi chức vụ mà CBCNV nào đó đảm nhiệm được xác định duy nhất bởi ngày bắt đầu, kết hợp với mã tổ và mã CBCNV như hình sau: Mô hình cơ cấu tổ chức theo công việc- Phiên bản 2 Bây giờ ta lại muốn theo dõi các khoản tiền công đã trả cho CBCNV. Một người có nhiều phiếu trả lương (Pay Slip) nhưng mỗi phiếu chỉ thuộc vể một người. Mỗi phiếu trả lương có nhiều dòng ghi tổng lương và các khoản khấu trừ như bảo hiểm y tế, bảo hiểm xã hội… Các dòng của phiếu trả lương tương tự như những dòng của một hóa đơn; mỗi dòng chỉ thuộc về một phiếu. Một lần nữa, mô hình lại được mở rộng như hình sau: Mô hình cơ cấu tổ chức theo công việc (phiên bản 3) b. Yếu tố phân biệt – Thực thể độc lập và thực thể phụ thuộc Nếu không có một yếu tố phân biệt rõ ràng và đơn giản nào thì hãy sáng tạo ra một yếu tố hay nhờ hệ QTCSDL tạo ra. Đơn giản nhất là dùng một mã ngắn gọn làm yếu tố phân biệt. Nếu ta tự tạo ra một yếu tố phân biệt thì cần đảm bảo cho nó có giá trị trùng lặp đối với các cá thể khác nhau. Đừng chất đầy thông tin vào một yếu tố phân biệt làm cho nó quá tải. Có công ty chất dẻo đã từng đặt ra mã sản phẩm một cách duy nhất mà không còn chỉ ra màu sắc, loại nguyên liệu tạo nên sản phẩm…Màu sắc và loại nguyên liệu đều là những thuộc tính. Nếu mã quá dài thì dễ mắc phải lỗi khi nạp dữ liệu và ít người có thể nhớ cách giải mã để biết được ý nghĩa đầy đủ của nó. Một yếu tố phân biệt chỉ có một nhiệm vụ là xác định duy nhất từng cá thể. Việc chất thêm gánh nặng cho nó sẽ làm nảy sinh những công việc đáng lẽ không cần làm. Thực thể độc lập hay phụ thuộc: Một thực thể khác phải dựa vào một thực thể khác để tồn tại hay để được xác định một cách duy nhất thì được gọi là thực thể phụ thuộc. Chẳng hạn, giả sử trong một nhà máy có nhiều phân xưởng, mỗi phân xưởng có những tổ sản xuất. Các phân xưởng có những tên khác nhau nhưng các tổ trong một phân xưởng thì chỉ được đánh số là 1, 2, 3… Khi đó phải dựa vào tên phân xưởng thì mới phân biệt được các tổ ở những phân xưởng khác nhau, bởi thế tổ trở thành thực thể phụ thuộc vào Phan xưởng còn Phân xưởng là thực thể độc lập. Khái niệm độc lập hay phụ thuộc chỉ là tương đối bởi vì: Nếu đặt cho mỗi tổ một tên sao cho không có hai tổ nào trong nhà máy trùng nhau đồng thời cho phép một số tổ trực thuộc ban giám đốc chứ không trực thuộc về phân xưởng nào thì tổ sẽ trở thành thực thể độc lập. c. Vị trí và trật tự Trong mô hình dữ liệu không có quy định gì về vị trí và thứ tự xuất hiện của các thực thể. Tuy nhiên, thực thể nào có nhiều quan hệ với nhiều thực thể khác thì nên đứng giữa để dễ vẽ và khiến cho mô hình gọn đẹp hơn . Các thuộc tính của một thực thể cũng có thể được liệt kê theo thứ tự tùy ý. Tuy nhiên nên sắp xếp liên tiếp các thuộc tính có liên quan với nhau. Chẳng hạn, họ đệm (họ và chữ lót) nên đứng ngay trước tên. Các cá thể tức các dòng trong bảng cũng không cần được nạp và theo thứ tự nào cả. Có nhiều phương tiện dễ dàng xử lý các dòng theo một trình tự nào đó; mệnh đề order by của SQL chính là một trong những phương tiện đó. d. Thực thể chỉ có một cá thể Đừng dè dặt khi tạo ra một thực thể chỉ có một cá thể. Xét mô hình dữ liệu sau để quản lý dữ liệu về các máy điện thoại. Công ty điện thoại độc quyền Vì Việt Nam chỉ có một công ty điện thoại độc quyền là “Công ty Bưu chính Viễn thông” nên thực thể Cong_ty chỉ có một cá thể. Việc đưa thực thể này vào mô hình khiến cho sự kiện về công ty được ghi nhận. Hơn nữa nếu sau này nhà nước huỷ bỏ chế độ độc quyền thì sẽ xuất hiện thêm nhiều công ty điện thoại khác nữa, lúc đó không cần phải sửa đổi mô hình dữ liệu. e. Chú ý tới các trường ngoại lệ Luôn thăm dò và phát hiện các trường hợp ngoại lệ để thiết kế lại mô hình nhằm xử lý được cả những trường hợp đó. Mô hình càng bao trùm được nhiều trường hợp ngoại lệ thì càng có độ trung thực cao. Để phát hiện được những trường hợp ngoại lệ thì hãy luôn luôn hỏi khách hàng những câu hỏi tương tự như sau: Có phải lúc nào cũng như vật không ? Liệu có tình huống nào khiến cho mối quan hệ này trở thành nhiều – nhiều hay không ? Trong tương lai có giữ ngyên quy định đó không ? Đã có trường hợp nào bất thường xảy ra hay chưa? f. Tham khảo các mô hình dữ liệu đã từng được sử dụng Một mô hình đã từng được sử dụng chắc chắn sẽ có một độ trung thực khá cao vì nó đã trải qua nhiều lần sàng lọc và sửa đổi. Việc thừa kế có chọn lọc những di sản của một mô hình dữ liệu cũ sẽ tốt hơn so với việc thiết kế một mô hình mới hoàn toàn. 4.4 Chuẩn hóa a. Chuẩn hóa là gì? Chuẩn hóa là quá trình cải tiến một bản thiết kế CSDL tồi sao cho nó khắc phục được những điều bất thường khi đổi mới dữ liệu và tránh được hiện tượng không nhất quán về dữ liệu. Nếu ta mô hình hóa dữ liệu một cách hoàn toàn đúng đắn và đã dùng mô hình để thiết kế CSDL với độ trung thực cao thì chẳng cần chuẩn hóa nữa. Tuy nhiên, đôi khi các nhà phân tích hệ thống vẫn lợi dụng các hệ thống tệp dữ liệu cũ của cơ quan rồi tiến hành chuẩn hóa để tạo ra một CSDL mới. Trong quá trình chuẩn hóa ta áp dụng các quy tắc để dần dần chuyển đổi hệ thống tệp cũ sang dạng chuẩn thứ nhất, thứ hai… b. Sự phụ thuộc hàm Sự phụ thuộc hàm là một mối quan hệ giữa các thuộc tính trong một thực thể. Nó chỉ đơn thuần có nghĩa là một hay một số thuộc tính xác định giá trị của thuộc tính khác. Chẳng hạn, cho biết mã của một cổ phiếu thì ra có thể xác định tên của công ty của cổ phiếu ấy, giá cổ phiếu, số lượng cổ phiếu hiện có và phần trăm lãi được chia (Dividend) là bao nhiêu. Như vậy, tên công ty, giá cổ phiếu, số lượng cổ phiếu và phần trăm lãi được chia của một cổ phiếu phụ thuộc vào mã cổ phiếu như một hàm. Người ta thường biểu diễn sự phụ thuộc này một cách ngắn gọn như sau: Mã cổ phiếuà tên công ty, giá cổ phiếu, số lượng cổ phiếu, phần trăm lãi cổ phiếu Một yếu tố phân biệt xác định tất cả các thuộc tính của một thực thể. Ngoài ra, một công thức như: tiền lời=phần trăm lãi cổ phiếu/ Giá cổ phiếu*100 cũng là một dạng phụ thuộc hàm. Trong trường hợp này ta viết (phần trăm lãi cổ phiếu, giá cổ phiếu) à tiền lời. Đây cũng là một ví dụ về sự phụ thuộc hàm đầy đủ bởi vì chỉ có thể tính ra tiền lời khi dựa vào cả hai thuộc tính: phần trăm lãi cổ phiếu và giá cổ phiếu. c. Dạng chuẩn thứ nhất Một bảng thuộc dạng chuẩn thứ nhất (1 NF –First Normal Form) khi và chỉ khi tất cả các cột của bảng đều chỉ chứa những giá trị nguyên tố, nghĩa là tất cả các dòng của bảng đều có cùng một số cột và tại mỗi cột trên mỗi dòng chỉ cố một giá trị duy nhất. Ví dụ: Giả sử một hóa đơn ghi nhiều món hàng đã bán. Nếu ta gộp dữ liệu về tất cả các món hàng vào một hóa đơn thì bởi vì mỗi hóa đơn chỉ được dành một dòng trong bảng nên sẽ có hai khả năng khiên scho bảng không thuộc dạng chuẩn thứ nhất: - Có một số cột phải chứa nhiều giá trị tương ứng với nhiều món hàng - Nếu tách các cộ sao cho mỗi cột chỉ chứa một giá trị thì số cột trên các dòng sẽ không bằng nhau bởi vì các hóa đơn không ghi cùng một số món hàng như sau. d. Dạng chuẩn thứ hai Một bảng thuộc dạng chuẩn thứ hai (2 NF) khi và chỉ khi nó thuộc dạng chuẩn thứ nhất và tất cả các cột không thuộc khóa chính đều phụ thuộc đầy đủ vào khóa chính. Nói cách khác, một bảng không thuộc dạng chuẩn thứ hai khi có một cột không thuộc khóa chính mà chỉ phụ thuộc vào một phần của khóa chính. Ví dụ: Giả sử một CSDL chỉ có một bảng ghi các khoản mục hàng hóa do khách hàng đặt trước: HÀNG ĐẶT MA_HANG MA_KH SO_LUONG TIN_DUNG 12 34 57 679 25 3 Bình thường Không tốt Tên bảng là “ hang đặt”. Các tiêu đề cột có nghĩa là “Mã hàng”, “Mã khách hàng”, “Số lượng” và “Tình trạng tín dụng của khách hàng”. Khóa chính của bảng này là tổng hợp của mã hàng và mã khách hàng. Vấn đề khiến cho bảng này không thuộc dạng chuẩn thứ hai là: tình trạng tín dụng của khách hàng chỉ phụ thuộc vào mã khách hàng, tức là một phần của khóa chính chứ không phụ thuộc đầy đủ vào khóa chính. Phân tích vấn đề này ta nhận thấy một mặt hàng có thể được nhiều khách hàng đặt và một khách hàng có thể đặt mua nhiều mặt hàng. Đó là mối quan hệ Nhiều – nhiều. Như trước đây đã chỉ ra, để thể hiện mối quan hệ m:m ta phải tạo ra một thực thể thứ ba. Mô hình dữ liệu cần có 3 thực thể : MẶT HÀNG, HÀNG ĐẶT VÀ KHÁCH HÀNG. Tín dụng phải là một thuộc tính của khách hàng. Mô hình dữ liệu ‘đặt hàng” sau khi đã sửa đổi cho phù hợp với dạng chuẩn thứ hai e. Dạng chuẩn thứ ba Một bảng thuộc dạng thứ ba (3NF) khi và chỉ khi nó thuộc dạng chuẩn thứ hai và không có sự phụ thuộc bắc cầu. Nói cách khác, một bảng không thuộc dạng chuẩn thứ ba khi có một cột không thuộc khóa chính mà phụ thuộc vào một cột khác cũng không thuộc khóa chính. Ví dụ: xét bảng cổ phiếu sau đây: MA_CO_PH TEN_NUOC HOI_DOAI Trong bàng này MA_CO_PH là khóa chính. Mã cổ phiếu xác định duy nhất tên nước có công ty bán cổ phiếu còn tên nước thì xác định duy nhất giá hối đoái của nước. Ta viết: Mã cổ phiếu àTên nướcàHối đoái Như vậy đã có sự phụ thuộc bắc cầu: Hối đoái phụ thuộc vào Tên nước, Tên nước phụ thuộc vào Mã cổ phiếu. Phân tích kĩ ta sẽ thấy một nước có nhiều cổ phiếu nhưng một cổ phiếu chỉ thuộc về một nước, tức là phải tách bảng đã cho thành hai bảng theo mô hình dữ liệu với mối quan hệ một-nhiều sau đây: Mô hình dữ liệu “chứng khoán” sau khi đã sửa đổi cho phù hợp với dạng chuẩn thứ ba 6. Các dạng chuẩn khác Ngoài ba dạng chuẩn thông thường nêu trên, còn có ba dạng chuẩn khác nữa với những đòi hỏi khắt khe và tinh vi hơn, đó là các chuẩn Boyce-Codd, dạng chuẩn thứ 4 và thứ 5. Thực tế, sự không tuân thủ ba dạng chuẩn vừa nêu không gây hậu quả nghiêm trọng lắm. Mặt khác, vì quá khắt khe và tinh vi nên các dạng chuẩn ấy đã vượt quá phạm vi xem xét của các HQTCSDL hiện nay. Chương III: Thiết kế chương trình I. Quy trình phân tích thiết kế chương trình 1. Phân tích xác định yêu cầu Như trong phần nêu lên tính cấp bách của đề tài, hệ thống quản lý sinh viên nội trú của trường ĐHKTQD hiện nay có nhiều tính bất cập, cụ thể là hầu hết các công việc đều làm bằng tay, thủ công vừa mất thời gian vừa gây nên nhiều nhầm lẫn không đáng có, chính vì vậy yêu cầu đặt ra cho hệ thống hiện nay điều đầu tiên là phải có tốc độ nhanh, giảm nhẹ gánh nặng cho người quản lý, giảm đến mức tối đa những nhầm lẫn không đáng có, khi sinh viên có nhu cầu sẽ có một mẫu đăng kí được soạn thảo bằng Word sinh viên điền các thông tin cần thiết vào phiếu đăng kí, sau đó nộp cho ban quản lý nhập vào máy bằng phần mềm này, ban quản lý sẽ điền thông tin cần thiết vào máy và lưư vào cơ sở dữ liệu, đồng thời xếp phòng luôn cho sinh viên, sau khi hoàn thành phần nhập dữ liệu về thông tin đăng kí của sinh vien, điều cần làm tiếp theo là in danh sách sinh viên ở các phòng để sinh viên được biết, như vậy sẽ có báo cáo đầu ra là danh sách sinh viên trong KTX, báo cáo này cũng sẽ được cung cấp cho ban quản lý khi cần thiết, trong quá trình quản lý có thể sẽ có những sinh viên xin chuyển phòng, xin ra ngoài, hoặc có thể là xin vào KTX, khi đó có thể dùng modul “Quản lý sinh viên” thực hiện nhiệm vụ xóa, sửa, thêm, bớt cho các yêu cầu này. Hàng tháng, KTX cần phải quản lý tiền điện và đồ dùng vệ sinh cho sinh viên như giấy vệ sinh, xô, chậu, chổi lau nhà, … Khi đó sẽ có một modul chuyên quản lý phần này gọi là “Quản lý tiền điện-Đồ dùng”, gộp lại như vậy là vì chỉ khi nào phòng nào đó nộp tiền điện thì sẽ nhận được đồ dùng, nếu không thì sẽ không được nhận, cuối tháng người quản lý có thể xem xet xem phòng nào đã nộp tiền điện hoặc phòng nào chưa nộp để có thể đốc thúc hoặc đem ra hình phạt là cắt điện phòng đó cho đến khi nộp được tiền điện, thông tin này được cung cấp bằng báo cáo “Tiền điện – đồ dùng” . Đồng thời trong quá trình ở của sinh viên sẽ có những sinh viên vi phạm kỷ luật và ban quản lý cần lưu lại danh sách những sinh viên vi phạm kỷ luật này để có những hình phạt thích hợp, đồng thời có thể báo cáo lên giám đốc trung tâm dịch vụ danh sách sinh viên vi phạm kỷ luật trong quá trình ở KTX. Như vật sẽ có một modul chuyên quản lý phần này là “Kỷ luật” đầu vào là những sinh viên nào vi phạm kỷ luật đang trú trong KTX, và báo cáo đầu ra là “Danh sách sinh viên bị kỷ luật”. Tất cả những công việc trên khi thực hiện phải có khả năng lọc dữ liệu theo nhà, theo năm quản lý, theo tháng quản lý, ví dụ như tiền điện nhà 1, tháng 1, năm 2006. Đồng thời khi vào chương trình thì phải có xác thực quyền sử dụng, chọn nhà quản lý để tránh gây khó khăn khi tìm kiếm cũng như lọc bớt những sinh viên không thuộc phạm vi quản lý của nhà hiện tại. 2. Mô hình IFD của chương trình Dựa vào những yêu cầu của hệ thống đã phân tích như trên chúng ta có sơ đồ IFD của quá trình duyệt đơn đăng kí nội trú của sinh viên, in danh sách sinh viên theo phòng để sinh viên có thể xem phòng mình ở, đồng thời cung cấp danh sách sinh viên hiện có cho ban quản lý khi cần thiết. Khi có danh sách sinh viên rồi, trong trường hợp có sinh viên nào vi phạm kỷ luật, sẽ được lưu vào danh sách sinh viên vi phạm kỷ luật, với điều kiện là sinh viên vi phạm phải thuộc về danh sách sinh viên đang nội trú. Khi có sự yêu cầu của ban giám đốc máy tính sẽ cung cấp danh sách sinh viên vi phạm nội quy. Từ đó ta có mô hình IFD của hệ thống đó nhu sau: Tiếp theo là sơ đồ luồng thông tin IFD của quá trình quản lý tiền điện và đồ dùng của các phòng hàng tháng. Theo yêu cầu quản lý, đầu năm sau khi sắp xếp chỗ ở cho sinh viên, ban quản lý sẽ tiến hành phân phát các đồ dùng cần thiết cho sinh viên, sau đó hàng tháng sẽ tiến hành thu tiền điện của các phòng và đồng thời phân phát đồ dùng cho tháng đó, sau khi xác định số điện phải nộp tiền thì sẽ có một danh sách tiền điện được cung cấp cho các phòng biết được số tiền phải nộp là bao nhiêu, từ đó ta có luồng thông tin sau: 3.Mô hình DFD của chương trình 4. Sơ đồ chức năng Sau đây là sơ đồ chức năng của chương trình, đó cũng là bản thiết kế hệ thống menu của chương trình, bao gồm các menu lớn sau: -Hệ thống: gồm các thiết lập chung cho hệ thống, phân quyền người dùng, thay người dùng khác. -Danh mục: gồm các modul để cập nhập các danh mục cho quá trình cập nhập cho danh sách sinh viên, tiền điện, kỷ luật…như danh mục nhà, danh mục phòng, danh mục tỉnh, danh mục dân tộc, danh mục tôn giáo, danh mục ngành, khóa học, lớp học. -Quản lý: gồm các modul quản lý sinh viên, quản lý tiền điện – đồ dùng, kỷ luật. -Báo cáo: là những thông tin đầu ra, gồm có: danh sách sinh viên, bảng kê tiền điện, bảng danh sách sinh viên bị kỷ luật. Sơ đồ chức năng của chương trình quản lý sinh viên KTX 5. Thiết kế cơ sở dữ liệu Cơ sở dữ liệu của hệ thống sẽ bao gồm những bảng sau: Bảng command: chứa các thông tin về hệ thống menu như tên menu, caption, file chương trinh cần gọi khi người dùng click chọn. Đây là kỹ thuật tạo menu động được sử dụng rộng rãi hiện nay. Bảng sysvar: là bảng lưu các biến hệ thống, được khai báo là public để sử dụng trong chương trình gồm có các trường STT, Name, Type, value, default. Bảng inivar: là bảng có cấu trúc tương tự như bảng sysvar, nó chứa thông tin về biến sử dụng cho các tùy chọn của hệ thống như người quản lý, năm quản lý, tháng, giá điện… Bảng userinfor: là bảng chứa thông tin về người dùng. Các bảng danh mục: Gồm dmnha (danh mục nhà), dmPhong (danh mục phòng), dmTG (danh mục tôn giáo), dmTinh (Danh mục tỉnh), dmDT (Danh mục tôn giáo), dmNganh (Danh mục ngành), dmKhoa (danh mục khóa), dmLop (danh mục lớp). Tất cả các bảng này đều có cấu trúc tương tự nhau gồm hai trường chính là mã và tên, ngoài ra còn có thể có thêm trường ghi chú. Các bảng dữ liệu về sinh viên (sinh_vien), bảng tiền điện (tien_dien), bảng kỷ luật (ky_luat). Trong chương trình những bảng trên được để trong các thư mục system (command, sysvar, inivar), cod ( chứa các bảng danh mục), data (sinh_vien, tien_dien, Ky_luat). Khi cập nhật danh sách sinh viên, tiền điện hàng tháng, hoặc sinh viên bị kỷ luật, sẽ có một số hoặc tất cả các danh mục cần dùng đến, các bảng danh mục là các bảng ở phía nhiều trong mối quan hệ một – nhiều với các bảng dữ liệu. Sau đây là thiết kế các bảng cùng với kiểu của chúng: -Bảng command: menuid : chứa id của menu cấp lớn nhất như hệ thống, danh mục, quản lý, báo cáo. Menuid0: chứa id các menu con của các menu lớn. Bar: caption của các menu Bar2: sử dụng trong trường hợp chuyển sang tiếng Anh Images : icon cho menu Pro: lệnh thực hiện modul chương trình khi gọi đến. Menuid+menuid0 tạo thành khóa chính. Bảng sysvar Name: Tên biến hệ thống, là khóa chính Type: kiểu biến Diễn giải : chú thích cho biến Value: giá trị cần gán khi tạo biến Default : giá trị mặc định khi biến là rỗng Bảng inivar Bảng này có cấu trúc như bảng sysvar Name là khóa chính Bảng userinfor User_id là khóa chính. Right : chứa các id của các menu mà người dùng được quyền truy cập. Is_admin: xác định xem người dùng có phải là Admin hay không. Các bảng danh mục: ở đây chỉ lấy một bảng làm minh họa, các bảng khác trong thư mục COD đều có cấu trúc tương tự -Bảng dmNha: Trong đó ma_nha là khóa chính. Bảng sinh_vien: Tên trường Kiểu Độ rộng Chú t