XÂY DỰNG WEBSITE GIỚI THIỆU VÀ QUẢN LÝ HỆ THỐNG CHÙA KHMER TẠI TRÀ VINH

Ngày nay, công nghệ thông tin đang ngày càng phát triển mạnh mẽ, nhu cầu tin học hóa của các tổ chức doanh nghiệp, cũng như các cơ quan nhà nước ngày càng cao. Việc tin học hóa không chỉ giúp cho các đối tượng sử dụng có thể dễ dàng quản lý các thông tin, mà còn giúp họ cải thiện đáng kể trong công tác lưu trữ, giảm thiểu việc sử dụng giấy tờ truyền thống, tiết kiệm được những khoảng không gian quý báu trong cơ quan, tổ chức nơi làm việc. Hơn nữa, với số lượng người dùng internet ngày càng tăng như hiện nay, những website thương mại, du lịch đang được xây dựng và triển khai ngày càng nhiều. Đối với những cá nhân không có điều kiện gặp gỡ, tiếp xúc trực tiếp với các sản phẩm, dịch vụ…, việc truy cứu thông tin thông qua các website được xem như một giải pháp tốt nhất giúp họ tiếp cận được những thông tin cần thiết. Từ những lý do đó, kết hợp với những kiến thức về công nghệ thông tin đã được trang bị trong suốt khóa học tại trường đã thúc đẩy tôi lựa chọn đề tài khóa luận là xây dựng một website giới thiệu và quản lý một hệ thống thông tin. Đặc biệt, đối với tỉnh Trà Vinh, một tỉnh có khá nhiều loại hình du lịch hấp dẫn và thú vị, tiêu biểu nhất là loại hình du lịch văn hóa, dân tộc, với các điểm đến là các chùa Khmer. Tuy nhiên, các thông tin về chùa Khmer cũng như việc quản lý hệ thống chùa của các cơ quan chức năng đang thực hiện một cách không đồng bộ, chưa nhất quán. Do đó, một website giới thiệu và quản lý hệ thống chùa Khmer tại Trà Vinh sẽ là một đề tài khá hay và mang tính cấp bách trong tình hình này.

Trang 1

TRƯỜNG ĐẠI HỌC TRÀ VINH KHOA KỸ THUẬT VÀ CÔNG NGHỆ

KHÓA LUẬN TỐT NGHIỆP

XÂY DỰNG WEBSITE GIỚI THIỆU VÀ QUẢN LÝ

HỆ THỐNG CHÙA KHMER TẠI TRÀ VINH

Giảng viên hướng dẫn: ThS PHAN QUỐC NGHĨA

Sinh viên thực hiện: THẠCH KỌNG SAOANE

Mã số sinh viên: 110107043

Trà Vinh, tháng 10 năm 2011

Trang 2

TRƯỜNG ĐẠI HỌC TRÀ VINH KHOA KỸ THUẬT VÀ CÔNG NGHỆ

KHÓA LUẬN TỐT NGHIỆP

XÂY DỰNG WEBSITE GIỚI THIỆU VÀ QUẢN LÝ

HỆ THỐNG CHÙA KHMER TẠI TRÀ VINH

Giảng viên hướng dẫn: ThS PHAN QUỐC NGHĨA

Sinh viên thực hiện: THẠCH KỌNG SAOANE

Mã số sinh viên: 110107043

Trà Vinh, tháng 10 năm 2011

Trang 3

LỜI MỞ ĐẦU

Ngày nay, công nghệ thông tin đang ngày càng phát triển mạnh mẽ, nhu cầu tinhọc hóa của các tổ chức doanh nghiệp, cũng như các cơ quan nhà nước ngày càng cao.Việc tin học hóa không chỉ giúp cho các đối tượng sử dụng có thể dễ dàng quản lý cácthông tin, mà còn giúp họ cải thiện đáng kể trong công tác lưu trữ, giảm thiểu việc sửdụng giấy tờ truyền thống, tiết kiệm được những khoảng không gian quý báu trong cơquan, tổ chức nơi làm việc Hơn nữa, với số lượng người dùng internet ngày càng tăngnhư hiện nay, những website thương mại, du lịch đang được xây dựng và triển khaingày càng nhiều Đối với những cá nhân không có điều kiện gặp gỡ, tiếp xúc trực tiếpvới các sản phẩm, dịch vụ…, việc truy cứu thông tin thông qua các website được xemnhư một giải pháp tốt nhất giúp họ tiếp cận được những thông tin cần thiết

Từ những lý do đó, kết hợp với những kiến thức về công nghệ thông tin đã đượctrang bị trong suốt khóa học tại trường đã thúc đẩy tôi lựa chọn đề tài khóa luận là xâydựng một website giới thiệu và quản lý một hệ thống thông tin Đặc biệt, đối với tỉnhTrà Vinh, một tỉnh có khá nhiều loại hình du lịch hấp dẫn và thú vị, tiêu biểu nhất làloại hình du lịch văn hóa, dân tộc, với các điểm đến là các chùa Khmer Tuy nhiên, cácthông tin về chùa Khmer cũng như việc quản lý hệ thống chùa của các cơ quan chứcnăng đang thực hiện một cách không đồng bộ, chưa nhất quán Do đó, một website giớithiệu và quản lý hệ thống chùa Khmer tại Trà Vinh sẽ là một đề tài khá hay và mangtính cấp bách trong tình hình này

Trang 4

đồ án tốt nghiệp, tôi xin chân thành cảm ơn ThS Phan Quốc Nghĩa, Thầy đã tận tình

hỗ trợ tư vấn, định hướng, hướng dẫn tôi trong suốt quá trình làm đồ án; cảm ơn ThS.Nguyễn Hoàng Duy Thiện, Thầy đã hỗ trợ cung cấp các thông tin, biểu mẫu cần thiết

để hoàn thành bài báo cáo; Hơn nữa, tôi cũng xin gửi lời cảm ơn đến Ban giới và Dântộc - Trường Đại học Trà Vinh, cùng một số chùa Khmer trong tỉnh đã cung cấp các tàiliệu, hình ảnh, biểu mẫu cần thiết để tôi có thể hoàn thành tốt đồ án tốt nghiệp

Qua việc làm đồ án này, bản thân tôi đã tiếp cận được nhiều kiến thức hấp dẫn vàquan trọng trong lĩnh vực du lịch văn hóa, dân tộc, có cơ hội củng cố và nâng cao đượcnhiều kiến thức chuyên môn Trong quá trình thực hiện đồ án, tôi đã cố gắng hết khảnăng đưa ra ý tưởng, giải quyết khá đầy đủ và chặt chẽ những yêu cầu của đề tài,nhưng do giới hạn về thời gian cùng với kiến thức bản thân có hạn, nên đồ án sẽ khôngtránh khỏi những khuyết điểm Do đó, bản thân tôi rất mong nhận được những góp ýquý báu của quý thầy cô và các bạn quan tâm để đồ án ngày một hoàn thiện hơn và từ

đó có thể áp dụng vào thực tiễn xã hội góp phần thúc đẩy ngành du lịch Trà Vinh pháttriển, hỗ trợ các cơ quan chức năng quản lý hệ thống Chùa Khmer một cách hiệu quả.Xin chân thành cảm ơn!

Sinh viên thực hiện

Thạch Kọng Saoane

Trang 5

NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN

Trà Vinh, ngày tháng năm 2011

Giảng viên hướng dẫn

ThS Phan Quốc Nghĩa

Trang 6

NHẬN XÉT CỦA GIẢNG VIÊN PHẢN BIỆN

Trà Vinh, ngày tháng năm 2011

Giảng viên phản biện

ThS Nguyễn Thái Sơn

Trang 7

MỤC LỤC

Chương 1 ĐẶT VẤN ĐỀ 1

Chương 2 CƠ SỞ LÝ THUYẾT 3

2.1 Các mô hình trong phân tích - thiết kế hệ thống 3

2.2 Sơ lược về web động 5

2.3 Giới thiệu PHP 6

2.4 Giới thiệu Apache 7

2.5 Giới thiệu MySQL 8

2.6 Giới thiệu Javascript 8

Chương 3 PHÂN TÍCH – THIẾT KẾ HỆ THỐNG 9

3.1 Yêu cầu chức năng 9

3.1.1 Yêu cầu lưu trữ 9

3.1.2 Yêu cầu tra cứu 10

3.1.3 Yêu cầu tính toán 10

3.1.4 Yêu cầu kết xuất 10

3.1.5 Yêu cầu quản lý 11

3.2 Yêu cầu phi chức năng 11

3.3 Thiết kế dữ liệu 12

3.3.1 Mô hình thực thể - kết hợp (ERD) 12

3.3.2 Mô hình vật lý 23

3.3.3 Ràng buộc toàn vẹn 29

3.4 Thiết kế xử lý 36

3.4.1 DFD cấp 0 36

3.4.2 DFD cấp 1 36

3.4.3 DFD cấp 2 37

3.4.4 DFD cấp 3 40

3.5 Thiết kế giao diện 44

3.5.1 Thiết kế màn hình 44

3.5.2 Thiết kế hệ thống thực đơn 47

Trang 8

Chương 4 CÀI ĐẶT – THỬ NGHIỆM 48

4.1 Các bước chuẩn bị 48

4.2 Dữ liệu thử nghiệm 48

4.3 Một số kết quả thử nghiệm 51

Chương 5 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 66

5.1 Kết luận 66

5.1.1 Kết quả đạt được 66

5.1.2 Hạn chế 67

5.2 Hướng phát triển 67

Trang 10

DANH MỤC HÌNH

Hình 3.1 Giao diện tổng thể của trang chủ website giới thiệu 44

Hình 3.2 Giao diện tổng thể của các trang con trong website giới thiệu 45

Hình 3.3 Giao diện tổng thể của trang chủ website quản lý 46

Hình 3.4 Giao diện tổng thể của các trang con trong website quản lý 46

Hình 3.5 Hệ thống thực đơn chính.[6] 47

Hình 4.1 Thư mục cài đặt website 48

Hình 4.2 Giao diện khởi động Wamp Server 49

Hình 4.3 Giao diện tạo mới cơ sở dữ liệu 49

Hình 4.4 Giao diện Import cơ sở dữ liệu 50

Hình 4.5 Màn hình trang chủ 51

Hình 4.6 Màn hình các bài viết về chùa 52

Hình 4.7 Màn hình các bài viết cùng danh mục 52

Hình 4.8 Màn hình chi tiết bài viết 53

Hình 4.9 Khung bình luận bài viết 53

Hình 4.10 Màn hình danh sách các chùa 53

Hình 4.11 Màn hình thông tin cơ bản của chùa 54

Hình 4.12 Màn hình thông tin chi tiết chùa 54

Hình 4.13 Màn hình kết quả tìm kiếm 54

Hình 4.14 Màn hình trang quản lý thành viên 55

Hình 4.15 Màn hình trang thêm thành viên 55

Hình 4.16 Màn hình trang cập nhật thông tin thành viên 55

Hình 4.17 Màn hình trang quản lý thực đơn 56

Hình 4.18 Màn hình trang thêm thực đơn 56

Hình 4.19 Màn hình trang cập nhật thực đơn 57

Hình 4.20 Màn hình trang quản lý banner quảng cáo 57

Hình 4.21 Màn hình thêm banner quảng cáo 57

Hình 4.22 Màn hình trang cập nhật banner quảng cáo 58

Hình 4.23 Màn hình trang quản lý huyện (thành phố) 58

Trang 11

Hình 4.24 Màn hình trang thêm huyện (thành phố) 58

Hình 4.25 Màn hình trang cập nhật huyện (thành phố) 59

Hình 4.26 Màn hình trang quản lý xã (phường) 59

Hình 4.27 Màn hình trang thêm xã (phường) 59

Hình 4.28 Màn hình trang cập nhật xã (phường) 60

Hình 4.29 Màn hình trang quản lý ấp (khóm) 60

Hình 4.30 Màn hình trang thêm ấp (khóm) 60

Hình 4.31 Màn hình trang cập nhật ấp (khóm) 61

Hình 4.32 Màn hình trang quản lý chùa 61

Hình 4.33 Màn hình trang thêm chùa 61

Hình 4.34 Màn hình trang cập nhật thông tin chùa 62

Hình 4.35 Màn hình trang quản lý bài viết 62

Hình 4.36 Màn hình trang thêm bài viết 63

Hình 4.37 Màn hình trang cập nhật thông tin bài viết 63

Hình 4.38 Màn hình trang quản lý Sư sãi 64

Hình 4.39 Màn hình trang thêm Sư sãi 64

Hình 4.40 Màn hình trang cập nhật thông tin Sư sãi 64

Hình 4.41 Biểu mẫu danh sách trụ trì 65

Hình 4.42 Biểu mẫu danh sách chùa 65

Hình 4.43 Biểu mẫu danh sách sư sãi 65

Trang 12

DANH MỤC BẢNG

Bảng 3.1 Mô tả thực thể PAGODA 17

Bảng 3.2 Mô tả thực thể HAMLET 17

Bảng 3.3 Mô tả thực thể VILLAGE 18

Bảng 3.4 Mô tả thực thể DISTRICT 18

Bảng 3.5 Mô tả thực thể DIGNITY 18

Bảng 3.6 Mô tả thực thể MONK 19

Bảng 3.7 Mô tả thực thể COMMENT 19

Bảng 3.8 Mô tả thực thể ARTICLE 20

Bảng 3.9 Mô tả thực thể ROLE 20

Bảng 3.10 Mô tả thực thể USER_ACCOUNT 21

Bảng 3.11 Mô tả mối kết hợp has_address 21

Bảng 3.12 Mô tả mối kết hợp has_article 21

Bảng 3.13 Mô tả mối kết hợp has_dignity 21

Bảng 3.14 Mô tả mối kết hợp has_monk 22

Bảng 3.15 Mô tả mối kết hợp is_in_district 22

Bảng 3.16 Mô tả mối kết hợp is_in_village 22

Bảng 3.17 Mô tả mối kết hợp has_comment 22

Bảng 3.18 Mô tả mối kết hợp has_role 22

Bảng 3.19 Mô tả mối kết hợp has_account 22

Bảng 3.20 Mô tả chi tiết bảng PAGODA 25

Bảng 3.21 Mô tả chi tiết bảng HAMLET 25

Bảng 3.22 Mô tả chi tiết bảng VILLAGE 26

Bảng 3.23 Mô tả chi tiết bảng DISTRICT 26

Bảng 3.24 Mô tả chi tiết bảng DIGNITY 26

Bảng 3.25 Mô tả chi tiết bảng ROLE 26

Bảng 3.26 Mô tả chi tiết bảng MONK 27

Bảng 3.27 Mô tả chi tiết bảng COMMENT 27

Bảng 3.28 Mô tả chi tiết bảng ARTICLE 28

Trang 13

Bảng 3.29 Mô tả chi tiết bảng USER_ACCOUNT 28

Bảng 3.30 Bảng tầm ảnh hưởng của ràng buộc R1 29

Trang 14

DANH MỤC SƠ ĐỒ

Sơ đồ 2.1 Mô hình hoạt động của Apache.[8] 7

Sơ đồ 3.1 Mô hình thực thể - kết hợp 12

Sơ đồ 3.2 Mô hình dữ liệu mức vật lý 23

Sơ đồ 3.3 Sơ đồ DFD cấp 0 36

Sơ đồ 3.4 Sơ đồ DFD cấp 1 36

Sơ đồ 3.5 Sơ đồ xử lý “Xác nhận đăng nhập” 37

Sơ đồ 3.6 Sơ đồ xử lý “Giới thiệu thông tin chùa” 38

Sơ đồ 3.7 Sơ đồ xử lý “Quản lý hệ thống chùa” 39

Sơ đồ 3.8 Sơ đồ xử lý “Quản lý Sư sãi” 40

Sơ đồ 3.9 Sơ đồ xử lý “Quản lý chùa Khmer” 40

Sơ đồ 3.10 Sơ đồ xử lý “Quản lý bài viết” 41

Sơ đồ 3.11 Sơ đồ xử lý “Quản lý xã (phường)” 41

Sơ đồ 3.12 Sơ đồ xử lý “Quản lý ấp (khóm)” 42

Sơ đồ 3.13 Sơ đồ xử lý “Quản lý huyện (thành phố)” 42

Sơ đồ 3.14 Sơ đồ xử lý “Quản lý thành viên” 43

Sơ đồ 3.15 Sơ đồ xử lý thực đơn 47

Trang 15

Chương 1 ĐẶT VẤN ĐỀ

Người Khmer sinh tụ ở Nam Bộ rất lâu đời và họ đã kiến tạo nên một nền văn hoárực rỡ Người Khmer ở Đồng bằng Sông Cửu Long (ĐBSCL) nói riêng, ở Nam Bộ nóichung chiếm gần 6,7% dân số toàn vùng Trong đó, tập trung đông nhất ở tỉnh TràVinh – vùng đất được thiên nhiên ưu đãi có hơn 30% người dân tộc Khmer sinh sốngvới các lễ hội phong phú, đa dạng, tạo nên một bản sắc đặc trưng cho văn hóa Khmer,biểu hiện rõ nét bởi những ngôi chùa cổ kính cùng lối kiến trúc độc đáo

Với 141 ngôi chùa, Trà Vinh là một tỉnh có hệ thống chùa Khmer dày đặc nhấttrong tất cả các tỉnh ở khu vực ĐBSCL nói riêng, ở Việt Nam nói chung Chùa Khmerđược xây dựng và phát triển từ những năm xa xưa, có chùa được xây dựng từ thế kỷthứ VI, thứ VII Theo Hòa thượng Dương Nhơn, Phó chủ tịch Hội đồng Trị sự Giáohội Phật giáo Việt Nam: “nhà chùa theo Phật giáo Nam tông Khmer chính là trung tâmvăn hóa luôn giữ bản sắc của người dân tộc Đặc điểm của người dân tộc Khmer là gắnliền với Phật giáo, vì các Sư đến chùa tu đều là con em của đồng bào dân tộc ChùaPhật là nơi tu hành của các vị Sư – là cội nguồn, là nơi làm lễ của đồng bào dân tộc vớiÔng – Bà, Cha – Mẹ, là trung tâm văn hoá, là môi trường đạo đức và là nơi giáo dụcđào tạo con em của đồng bào dân tộc”

Về kiến trúc và cách tổ chức, các chùa được xây dựng khang trang, uy nghiêmtrong một khuôn viên có diện tích rộng lớn tại một ấp nào đó trong xã Mỗi chùaKhmer đều có một Pháp danh phiên âm từ tiếng Phạn, Tuy nhiên, để thuận tiện và dễnhớ mỗi chùa đều có một Thế danh (tên thường gọi), Thế danh này có thể là tên củađịa phương mà chùa tọa lạc hoặc một tên nào đó tùy theo đặc trưng của từng chùa.Trong chùa, người có chức vị cao nhất là Sư Cả Vị Sư Cả có nhiệm vụ phối hợp vớiBan Quản trị chùa (Sư Cả bổ nhiệm và Phật tử bầu chọn) quản lý tổng thể các hoạtđộng trong chùa, chịu trách nhiệm trước Pháp luật về các thông tin của chùa tên chùa,năm thành lập chùa, diện tích khuôn viên chùa, số lượng cũng như lí lịch của các Sưsãi trong chùa, số lượng Phật tử của chùa Về lý lịch của Sư sãi, mỗi vị Sư trong chùa(kể cả Sư cả) được quản lý bởi các thông tin như: họ tên, pháp danh, phẩm giới(Thượng tọa, Đại đức, Hòa thượng, Tỳ kheo, Sa di…), năm sinh, nơi ở, trình độ học

Trang 16

Trong đơn vị quản lý hành chính nhà nước, chùa Khmer là thành viên của Hội Đoànkết Sư sãi Yêu nước, chịu sự chỉ đạo của Giáo hội Phật giáo Việt Nam, dưới sự kiểmsoát của Ủy ban Mặt trận Tổ quốc các cấp Hơn nữa, mỗi chùa Khmer đều có nhữngnét đặc trưng riêng biệt, những đặc điểm lịch sử nổi bật khác nhau Những nét đặctrưng này đã làm cho chùa trở thành một nơi thu hút khách du lịch khắp mọi miền đấtnước cũng như du khách nước ngoài Để tôn thêm những nét đẹp, những tinh hoa vănhóa dân tộc đó, mỗi chùa còn có thêm những thông tin về lịch sử chùa, những bài viết

mô tả nét đẹp của chùa Từ đó, có thể làm phong phú thêm những địa điểm du lịch củaTỉnh, thúc đẩy sự phát triển của ngành du lịch Trà Vinh nói riêng, của đất nước ViệtNam nói chung

Tuy nhiên, cũng theo Hòa thượng Dương Nhơn, “những yếu kém của Phật giáoNam Tông bao gồm những khó khăn về mặt giáo quyền, tình trạng thiếu liên thôngtrong việc học hành của các nhà sư, bất đồng trong tổ chức lễ hội tôn giáo, dân tộc Sựyếu kém trong quản lý, điều hành cơ sở thờ tự và hoạt động Phật sự chậm được khắcphục” Đồng thời, nhu cầu truy cứu thông tin về các chùa của Hội Đoàn kết Sư sãi Yêunước, Hội Mekong, Ban Dân tộc, Ban Tôn giáo, Ủy ban Mặt trận Tổ quốc các cấpchưa thực sự thống nhất Hơn nữa, các thông tin chính xác về mỗi chùa chưa đượccung cấp đầy đủ đến người dân cũng như du khách

Từ những vấn đề trên, một hệ thống Website chuyên cung cấp các thông tin vềchùa Khmer Trà Vinh là một hệ thống rất cần thiết trong tình hình này Nó không chỉgiúp cho các cán bộ chuyên trách công tác dân tộc trong tỉnh dễ dàng quản lý nhữngthông tin cần thiết về ngôi chùa, những người dân Trà Vinh hiểu rõ được nét văn hóađặc trưng của tỉnh nhà, mà còn giúp cho tất cả mọi người chúng ta nắm được một cáchchính xác về hệ thống chùa Khmer Trà Vinh Hơn nữa, thông qua hệ thống Website,những khách du lịch trong và ngoài nước có thể biết được những thông tin cần thiết vềnhững địa điểm du lịch văn hóa dân tộc hấp dẫn Từ đó, họ có thể chọn lựa cho riêngmình những kỳ nghỉ, những chuyến tham quan thật đặc sắc và thú vị

Trang 17

Chương 2 CƠ SỞ LÝ THUYẾT 2.1 Các mô hình trong phân tích - thiết kế hệ thống

Việc xây dựng một hệ thống quản lý nào đó bao giờ cũng phải trải qua giai đoạnphân tích và thiết kế hệ thống thông tin Với kỹ thuật phân tích và thiết kế hệ thốngngày nay, cùng với sự phổ biến và tiện dụng của các mô hình, một mô hình thực thể -kết hợp để mô hình hóa dữ liệu ở mức quan niệm, một mô hình quan hệ để mô hìnhhóa dữ liệu ở mức vật lý, và lưu đồ dòng dữ liệu (DFD) để mô hình hóa các xử lý của

hệ thống là những sự lựa chọn thích hợp nhất đối với hệ thống này

 Mô hình thực thể - kết hợp (ERD): Ðặc điểm của kiểu mô hình này là giàu ngữnghĩa, dễ hình dung và được chuẩn hóa bằng những quy tắc chặt chẽ Trong mô hìnhnày, thực thể tương ứng với một lớp đối tượng (các phần tử có cùng một số đặc tínhnào đó) thuộc tổ chức trong quá trình mô hình hóa Thực thể được định danh bằng tên,thường là danh từ mang ý nghĩa của lớp đối tượng được mô hình hóa; còn mối kết hợptương ứng với một mối quan hệ giữa các thực thể tham gia vào quan hệ đó thuộc tổchức trong quá trình mô hình hóa Mối kết hợp được định danh bằng tên, thường làđộng từ hay tính từ mang ý nghĩa về mối quan hệ giữa các lớp đối tượng liên quantrong tổ chức Ngoài ra, trong mô hình ta còn có các khái niệm như: thuộc tính (củamột thực thể hoặc của một mối kết hợp) là một phần tử của mô hình tương ứng với mộtđặc tính của một lớp đối tượng hoặc một mối quan hệ giữa các đối tượng thuộc tổ chứctrong việc mô hình hóa; bản số của một thực thể đối với một mối kết hợp là cặp (bản sốtối thiểu, bản số tối đa); khóa của một thực thể là một thuộc tính hoặc một số thuộc tínhcủa thực thể, sao cho với mỗi giá trị của các thuộc tính này, tương ứng một và chỉ mộtthể hiện của thực thể; khóa của một mối kết hợp nhận được bằng cách kết hợp khóacủa các thực thể tham gia vào mối kết hợp đó Tập hợp tất cả các giá trị của các thuộctính khóa của một mối kết hợp xác định duy nhất một thể hiện của mối kết hợp đó

 Mô hình quan hệ: dùng khái niệm quan hệ biểu diễn các lớp đối tượng cũng nhưmối liên quan giữa chúng Ðặc điểm của kiểu mô hình này là nghèo nàn về ngữ nghĩa,khó diễn đạt cho những người tham gia xây dựng hệ thống thông tin, đặc biệt là đối với

Trang 18

người dùng Chính vì vậy mà mô hình quan hệ thích hợp với mức logic về dữ liệu hơn

là với mức quan niệm

 Lưu đồ dòng dữ liệu (data flow diagram) là cách phân tích thành phần xử lý củamột hệ thống thông tin thuộc trường phái các nước Bắc Mỹ Lưu đồ dòng dữ liệu biểudiễn sự kết nối giữa các hoạt động của hệ thống, thông qua việc trao đổi dữ liệu khi hệthống hoạt động Trong lưu đồ dòng dữ liệu phải thể hiện những xử lý nào khởi đầu,

xử lý nào phụ thuộc vào những xử lý khác và mỗi xử lý cần những dữ liệu gì Tùy từngmức độ mà lưu đồ dòng dữ liệu được phân rã chi tiến dần, đến khi có thể chuyển chongười lập trình để triển khai Có thể nói lưu đồ dòng dữ liệu chỉ có hai mức: mức quanniệm và mức vật lý, không có ranh giới giữa hai mức trên bởi mức logic Trong lưu đồdòng dữ liệu ta có các khái niệm: Ô xử lý hay quá trình xử lý, Dữ liệu vào, Dữ liệu ra,Nguồn / đích, Kho dữ liệu Chúng tồn tại ở các cấp: Cấp 0: Cấp thấp nhất, ban đầu cóthể xem toàn bộ hệ thống chỉ bao gồm một ô xử lý; Cấp n có được bằng cách phân rãmỗi ô xử lý cấp n-1 thành nhiều ô xử lý cấp n.[1]

Trang 19

2.2 Sơ lược về web động

 Web động là thuật ngữ được dùng để chỉ những website có cơ sở dữ liệu vàđược hỗ trợ bởi các phần mềm phát triển web Với web động, thông tin hiển thị đượcgọi ra từ một cơ sở dữ liệu khi người dùng truy vấn tới một trang web Trang web đượcgửi tới trình duyệt gồm những câu chữ, hình ảnh, âm thanh hay những dữ liệu số hoặc

ở dạng bảng hoặc ở nhiều hình thức khác nữa

 Thông tin trên web động luôn luôn mới vì nó dễ dàng được cập nhật thườngxuyên thông qua việc sử dụng các công cụ cập nhật của các phần mềm quản trị web.Thông tin luôn được cập nhật trong một cơ sở dữ liệu và người dùng Internet có thểxem những chỉnh sửa đó ngay lập tức Vì vậy website được hỗ trợ bởi cơ sở dữ liệu làphương tiện trao đổi thông tin nhanh nhất với người dùng Internet Điều dễ nhận thấy

là những website thường xuyên được cập nhật sẽ thu hút nhiều khách hàng tới thămhơn những website ít có sự thay đổi về thông tin Web động có tính tương tác vớingười sử dụng cao Với web động, chúng ta hoàn toàn có thể dễ dàng quản trị nộidung và điều hành website của mình thông qua các phần mềm hỗ trợ mà không nhấtthiết chúng ta cần phải có kiến thức nhất định về ngôn ngữ html, lập trình web

 Web động thường được phát triển bằng các ngôn ngữ lập trình tiên tiến nhưPHP, ASP, ASP.NET, Java, CGI, Perl, và sử dụng các cơ sở dữ liệu quan hệ mạnh nhưAccess, My SQL, MS SQL, Oracle, DB2 Tuy nhiên, hệ thống này sẽ được phát triểntheo chỉ thị số 07/2008/CT-BTTTT do Bộ trưởng Bộ Thông tin và Truyền thông LêDoãn Hợp ký ban hành ngày 30/12/2008; chỉ thị số 17/CT-UBND, ngày 30/11/2010của Chủ tịch Ủy ban Nhân dân tỉnh Trà Vinh Trần Hoàn Kim về việc tăng cường sửdụng phần mềm mã nguồn mở trong hoạt động của cơ quan nhà nước, nên hệ thống sẽđược lập trình, cài đặt và vận hành bằng các phần mềm nguồn mở như chương trìnhmáy chủ APACHE, hệ quản trị cơ sở dữ liệu MYSQL, ngôn ngữ lập trình PHP Với bộ

ba Apache/MySQL/PHP, chúng ta sẽ tiết kiệm được một khoảng rất lớn các chi phímua bản quyền, chi phí cài đặt và vận hành hệ thống

Trang 20

2.3 Giới thiệu PHP

PHP viết tắt của PHP Hypertext Preprocessor, là ngôn ngữ Server – Side script,tương tự như ASP, JSP… và được thực thi ở phía Server Một tập tin PHP thôngthường sẽ có phần mở rộng là php Ngôn ngữ PHP có cú pháp gần giống với ngônngữ C và PERL Tất cả các câu lệnh đều nằm trong cặp dấu <?php ?> hoặc <? ?> PHP

có các ưu điểm sau:

 PHP được sử dụng làm Server Side Scripting, Command Line Scripting, Xâydựng ứng dụng Desktop

 PHP là ngôn ngữ lập trình đa môi trường, thích ứng với nhiều loại web servernhư: Apache, Microsoft IIS, Caudium, Netscape, Enterprise Server Có khả năng hoạtđộng trên nhiều hệ điều hành như: UNIX, Mac OSX, Windows NT/98/2000/XP… Sửdụng cơ sở dữ liệu trên nhiều loại hệ quản trị cơ sở dữ liệu như: Adabas D, dBase,DB2, MySQL, MS SQL, Oracle…

 PHP là một ngôn ngữ lập trình miễn phí, được sử dụng rộng rãi trong môitrường phát triển Web, chiếm hơn 32% tên miền website

Cơ chế truyền nhận dữ liệu trong PHP: để truyền nhận dữ liệu trong PHP, ta sửdụng đối tượng Form bằng các phương thức GET hoặc POST, nhập dữ liệu thông quacác đối tượng Form Field, thực hiện việc truyền dữ liệu thông qua Submit

 Phương thức GET trong PHP: Tham số dược truyền đi thông qua địa chỉ URLtheo dạng http://domain/pathfile?parameter1=value1&parameter2=value2 Việc nhận

dữ liệu thông qua biến toàn cục $_GET[“parameter”] hay $_REQUEST[“parameter”].Phương thức GET có những ưu điểm như: người dùng có thể bookmark địa chỉ URL,hoặc người dùng có thể giả lập phương thức GET để truyền dữ liệu mà không cầnthông qua đối tượng Form Tuy nhiên, phương thức GET lại có một số khuyết điểmnhư: không có tính bảo mật (trường hợp dữ liệu được truyền là một mật khẩu), dunglượng truyền đi bị giới hạn, URL sau khi submit sẽ được lưu lại trên server

 Phương thức POST trong PHP: tham số truyền đi được ẩn bên trong đối tượngForm Nhận dữ liệu thông qua biến toàn cục $_REQUEST[“parameter”] hay

$_POST[“parameter”] Tuy phương thức POST vẫn còn tồn tại khuyết điểm như: kết

Trang 21

quả trang web không thể bookmark, có thể gây lỗi khi người dùng thực hiện thao tácquay lại trang kết quả, dữ liệu có thể không được truyền đi do vấn đề an ninh mạng,nhưng nó lại có ưu điểm là bảo mật cao và không giới hạn dung lượng dữ liệu đượctruyền đi.

Session trong PHP: Session là thông tin về client được lưu trên máy server Mụcđích của session là lưu biến dữ liệu dùng chung cho nhiều trang trong một phiên làmviệc của client chẳng hạn như: các thông tin đăng nhập hệ thống nhằm hạn chế việctruy cập vào hệ thống khi chưa đăng nhập, hoặc lưu các thông tin sử dụng trong chứcnăng thay đổi ngôn ngữ của trang web.[2]

2.4 Giới thiệu Apache

Apache là một hệ mã có chức năng thu nhận những thông điệp đến từ mạng Web,

và phân phát nó cho những chương trình xử lí trong máy tính, rồi hồi âm kết quả việc

xử lí, trả lại cho nơi xuất xứ của thông điệp Tiếng Anh gọi một hệ phân phát như thế làWeb Server Apache là hệ được phổ thông nhất trên thế giới Trong hiện tại, Apachekhông có sẵn trong phần mã thông thường của các máy Nhưng bạn có thể đi tìm nótrên mạng Internet và cài nó vào máy của bạn

Sơ đồ 2.1 Mô hình hoạt động của Apache.[8]

2.5 Giới thiệu MySQL

MySQL là một phần mềm quản trị CSDL mã nguồn mở, miễn phí nằm trong nhómLAMP (Linux - Apache - MySQL - PHP), MySQL là một phần mềm quản trị CSDLdạng server-based (gần tương đương với SQL Server của Microsoft).MySQL quản lý dữ liệu thông qua các CSDL, mỗi CSDL có thể có nhiều bảng quan hệ

Trang 22

chứa dữ liệu MySQL có cơ chế phân quyền người sử dụng riêng, mỗi người dùng cóthể được quản lý một hoặc nhiều CSDL khác nhau, mỗi người dùng có một tên truycập (user name) và mật khẩu tương ứng để truy xuất đến CSDL.

2.6 Giới thiệu Javascript

JavaScript là một ngôn ngữ lập trình kịch bản dựa trên đối tượng được phát triển từcác ý niệm nguyên mẫu Ngôn ngữ này được dùng rộng rãi cho các trang web, nhưngcũng được dùng để tạo khả năng viết script sử dụng các đối tượng nằm sẵn trong cácứng dụng

Chương 3 PHÂN TÍCH – THIẾT KẾ HỆ THỐNG 3.1 Yêu cầu chức năng

3.1.1 Yêu cầu lưu trữ

Từ vấn đề đặt ra cùng với cơ sở lý thuyết về hệ thống chùa Khmer tỉnh Trà Vinh, hệthống thông tin Website chùa Khmer tỉnh Trà Vinh cần phải lưu trữ một số thông tinvào cơ sở dữ liệu như:

 Thông tin của từng chùa Khmer: mỗi chùa Khmer bao gồm các thông tin cầnlưu trữ như: tên chùa, Pháp danh, địa chỉ, năm xây dựng, diện tích, họ và tên Sư Cả, số

Trang 23

lượng Sư sãi trong chùa, số lượng hộ gia đình Phật tử, số lượng Phật tử, lịch sử củachùa.

 Thông tin các Sư sãi trong chùa: mỗi chùa có ít nhất một Sư sãi, mỗi Sư sãitrong chùa cần lưu trữ các thông tin như: họ và tên Sư, Phẩm giới, Pháp danh của Sư(nếu Sư đang giữ giới Tỳ Kheo), năm sinh, nơi ở, năm xuất gia, trình độ học vấn của

Sư (bao gồm tiếng Việt và tiếng Khmer), chức vị của Sư trong chùa

 Để thuận tiện cho việc tra cứu thông tin, hệ thống cần thiết phải lưu trữ một sốthông tin về địa chỉ mà chùa tọa lạc như các thông tin về ấp (khóm), xã (phường),huyện (thành phố) Về thông tin của ấp, ta cần phải lưu trữ tên ấp hoặc khóm, ấp(khóm) đó thuộc xã hay phường nào Phải biết tên xã (phường), và xã (phường) đó lạithuộc huyện nào hay nằm trong địa phận thành phố trực thuộc tỉnh

 Hơn nữa, do mỗi chùa có những nét đẹp đặc trưng riêng nên chúng ta cũng cầnphải lưu trữ những bài báo, bài viết quảng bá về chùa đó Hoặc mở rộng hơn, chúng tacũng cần phải có một hệ thống lưu trữ những bài viết về lễ hội, về văn hóa hay kiếntrúc chùa Khmer để phục vụ cho những khách du lịch hoặc những người quan tâm.Bên cạnh đó, từ những cơ sở lý thuyết về thiết kế Website nói chung, Website giớithiệu địa danh du lịch nói riêng, chúng ta cũng cần phải thiết kế sao cho hệ thống cóthể lưu trữ một số thông tin khác như:

 Ý kiến bình luận bài viết: chức năng gửi ý kiến bình luận yêu cầu chúng ta phảithiết kế sao cho có thể lưu trữ được những bình luận mà bạn đọc đã phản hồi về bàiviết Một số thông tin cần lưu trữ như: tên, địa chỉ email, tiêu đề bình luận cùng với nộidung mà bạn đọc bình luận

 Số người truy cập và số người đang truy cập: hệ thống cần phải được thiết kếsao cho có thể lưu trữ được những thông tin này để khách viếng thăm có thể biết đượctổng số người truy cập cũng như số người đang truy cập

 Thông tin thành viên: do Website này cũng là một hệ thống quản lý nên cầnphải lưu trữ các thông tin thành viên Thành viên của Website có thể là Quản trịWebsite, Sư Cả của các chùa, và một số thành viên khác như các cán bộ chuyên trách

về công tác dân tộc, cán bộ Mặt trận Tổ quốc các cấp… Đối với mỗi thành viên, hệ

Trang 24

thống yêu cầu lưu trữ các thông tin như Tên đăng nhập của từng thành viên, mật khẩuđăng nhập, Email và quyền đăng nhập của họ.

3.1.2 Yêu cầu tra cứu

Hệ thống yêu cầu chức năng tra cứu các thông tin như:

 Thông tin chùa: Thông tin của các chùa được tra cứu theo các tiêu chí như:huyện (thành phố), xã (phường), ấp (khóm)…

 Danh sách Sư sãi của mỗi chùa

 Tra cứu bài viết theo tiêu chí là những từ khóa tìm kiếm

3.1.3 Yêu cầu tính toán

Hệ thống yêu cầu chức năng đếm tổng số người truy cập và số người đang truy cậpvào Website

3.1.4 Yêu cầu kết xuất

Hệ thống cho phép người dùng bình thường in danh sách các chùa theo từng huyện(thành phố) hoặc toàn tỉnh; Cho phép các thành viên in danh sách Sư sãi của mỗi chùa(mỗi Sư sãi trong danh sách in ra có đầy đủ các thông tin như mô tả), in danh sách trụtrì của các chùa trong tỉnh hoặc theo từng huyện (thành phố)

3.1.5 Yêu cầu quản lý

Hệ thống yêu cầu một số chức năng quản lý cho từng loại thành viên như sau:

 Quản trị viên: quản lý hệ thống website như thực đơn, thành viên, ấp (khóm), xã(phường), huyện (thành phố), thông tin tất cả các chùa, các bài viết…

 Sư cả chùa: quản lý các thông tin của chùa mà mình giữ chức vị trụ trì, quản lýcác thông tin về Sư sãi trong chùa đó, gửi các bài viết giới thiệu các chùa đến hệ thốnglưu trữ

 Các thành viên khác: có thể là cán bộ chuyên trách về công tác dân tộc, cán bộMặt trận Tổ quốc các cấp… hệ thống sẽ cho phép các thành viên này gửi các bài viết

về các chùa đến hệ thống lưu trữ

Trang 25

3.2 Yêu cầu phi chức năng

 Giao diện: giao diện website phải thân thiện với người dùng

 Vận hành: dung lượng nhỏ, không phải tốn nhiều không gian lưu trữ

 Thực thi: thời gian thực thi các yêu cầu giữa Client – Server nhanh chóng

 Chu trình sống: nội dung linh hoạt, dễ sửa đổi, có tính mở rộng, có khả năngphát triển tiếp trong tương lai

 Kinh tế: không tốn nhiều chi phí thiết kế cũng như vận hành Tập trung sử dụngcác phần mềm mã nguồn mở

 Bảo mật: Website phải có sự phân quyền giữa các loại người dùng Không chophép truy cập vào nội dung của các tập tin nguồn

Trang 26

3.3 Thiết kế dữ liệu

3.3.1 Mô hình thực thể - kết hợp (ERD)

3.3.1.1 Mô hình

1,1 1,n

<pi> Integer<Undefined> <M>

Identifier_1 <pi>

HAMLET HamletID

Identifier_1 <pi>

DISTRICT DistrictID

Identifier_1 <pi>

MONK MonkID

Identifier_1 <pi>

ARTICLE ArticleID

Identifier_1 <pi>

DIGNITY DignityID

Identifier_1 <pi>

VILLAGE VillageID

<pi> Integer<Undefined> <M>Identifier_1 <pi>

is_in_district has_dignity

is_in_village

has_article has_address has_monk

COMMENT CommentID

<pi> Integer<Undefined> <M>Identifier_1 <pi>

has_comment

USER_ACCOUNT Username

<pi> Characters (32)<Undefined> <M>

Identifier_1 <pi>

has_account

ROLE RoleID

Identifier_1 <pi>

has_role

Sơ đồ 3.2 Mô hình thực thể - kết hợp

Trang 27

3.3.1.2 Danh sách các đối tượng

 MONK: tương ứng với tập hợp các đối tượng là các vị Sư sãi tu hành trong chùa

 PAGODA: tương ứng với tập hợp các đối tượng là các ngôi chùa Khmer trong

 has_address: mô tả mối quan hệ giữa thực thể PAGODA và thực thể HAMLET

 Mỗi một thể hiện của thực thể PAGODA thuộc ít nhất một thể hiện của thực thểHAMLET, và thuộc nhiều nhất một thể hiện của thực thể HAMLET Hay nói cáchkhác, mỗi một chùa luôn tọa lạc tại một và chỉ một ấp nào đó trong hệ thống hànhchính nhà nước mà thôi Do đó, ta có bản số PAGODA – has_address là (1,1)

 Mỗi một thể hiện của thực thể HAMLET có thể không tồn tại một thể hiện nàocủa thực thể PAGODA, và có thể có nhiều hơn một thể hiện của thực thể PAGODA

Trang 28

Hay nói cách khác, mỗi một ấp có thể không có chùa nào tọa lạc, và cũng có thể cónhiều chùa tọa lạc Do đó, ta có bản số HAMLET – has_address là (0,n).

 has_article: mô tả mối quan hệ giữa thực thể PAGODA và thực thể ARTICLE

 Mỗi một thể hiện của thực thể PAGODA có thể không tồn tại thể hiện của thựcthể ARTICLE, và có thể có nhiều thể hiện của thực thể ARTICLE Hay nói cách khác,mỗi chùa có thể không có bài viết nào, mà cũng có thể có nhiều bài viết viết về chùa

đó Do đó, bản số của PAGODA - has_article là (0,n)

 Mỗi một thể hiện của thực thể ARTICLE có thể không mô tả cho thể hiện nàocủa thực thể PAGODA, hoặc chỉ mô tả cho một thể hiện của thực thể PAGODA Haynói cách khác, mỗi một bài viết chỉ có thể nói về một chùa nào đó, và có thể không nói

về bất kỳ chùa nào hết (mô tả kiến trúc, văn hóa, lễ hội… nào đó trong chùa) Do đó,bản số của ARTICLE - has_article là (0,1)

 has_dignity: mô tả mối quan hệ giữa thực thể MONK và thực thể DIGNITY

 Mỗi một thể hiện của thực thể MONK chỉ có một và chỉ một thể hiện của thựcthể DIGNITY Hay nói cách khác, mỗi một sư chỉ có một phẩm giới mà thôi Do đó,bản số của MONK - has_dignity là (1,1)

 Mỗi một thể hiện của thực thể DIGNITY sẽ có thể không tồn tại thể hiện nàocủa thực thể MONK, mà cũng có thể tồn tại nhiều thể hiện của thực thể MONK Haynói cách khác, một phẩm giới có thể có nhiều sư đang giữ, mà cũng có thể không có sưnào đang giữ phẩm giới đó Do đó, bản số của DIGNITY - has_dignity là (0,n)

 has_monk: mô tả mối quan hệ giữa thực thể PAGODA và thực thể MONK

 Mỗi một thể hiện của thực thể PAGODA sẽ tồn tại tối thiểu là một và không hạnchế tối đa số lượng thể hiện của thực thể MONK Hay nói cách khác, mỗi một chùa sẽ

có từ một vị sư trở lên Do đó, bản số của mối quan hệ PAGODA – has_monk là (1,n)

 Mỗi một thể hiện của thực thể MONK sẽ tồn tại trong một và chỉ một thể hiệncủa thực thể PAGODA Tức là, mội sư sẽ thuộc duy nhất một chùa Do đó, bản số củamối quan hệ MONK – has_monk là (1,1)

 is_in_district: mô tả mối quan hệ giữa thực thể VILLAGE và thực thểDISTRICT

Trang 29

 Mỗi một thể hiện của thực thể VILLAGE sẽ thuộc tối thiểu một thể hiện củathực thể DISTRICT, và cũng chỉ thuộc tối đa một thể hiện của thực thể DISTRICT.Hay nói cách khác, mỗi xã (phường) chỉ thuộc duy nhất một huyện (thành phố) Do đó,bản số của VILLAGE – is_in_district là (1,1)

 Mỗi một thể hiện của thực thể DISTRICT sẽ có tối thiểu một thể hiện của thựcthể VILLAGE, và tối đa là nhiều thể hiện của thực thể VILLAGE Nghĩa là, một huyện(thành phố) sẽ có thể có một xã (phường) mà cũng có thể có nhiều xã (phường) trựcthuộc Do đó, bản số của DISTRICT – is_in_district là (1,n)

 is_in_village: mô tả mối quan hệ giữa thực thể HAMLET và thực thểVILLAGE

 Mỗi một thể hiện của thực thể HAMLET sẽ thuộc tối thiểu một thể hiện củathực thể VILLAGE, và cũng chỉ thuộc tối đa một thể hiện của thực thể VILLAGE Haynói cách khác, mỗi ấp (khóm) chỉ thuộc duy nhất một xã (phường) Do đó, bản số củaHAMLET – is_in_village là (1,1)

 Mỗi một thể hiện của thực thể VILLAGE sẽ có tối thiểu một thể hiện của thựcthể HAMLET, và tối đa là nhiều thể hiện của thực thể HAMLET Nghĩa là, một xã(phường) sẽ có thể có một ấp (khóm) mà cũng có thể có nhiều ấp (khóm) trực thuộc

Do đó, bản số của VILLAGE – is_in_village là (1,n)

 has_comment: mô tả mối quan hệ giữa thực thể ARTICLE và thực thểCOMMENT

 Mỗi một thể hiện của thực thể ARTICLE sẽ tối thiểu không có bất kỳ thể hiệnnào của thực thể COMMENT, và sẽ có tối đa nhiều thể hiện của thực thể COMMENT.Hay nói cách khác, mỗi bài viết có thể không có bài bình luận nào hoặc có nhiều bàibình luận Do đó, bản số của ARTICLE – has_comment là (0,n)

 Mỗi một thể hiện của thực thể COMMENT sẽ thuộc tối thiểu một thể hiện củathực thể ARTICLE, và tối đa cũng chỉ một thể hiện của thực thể ARTICLE Nghĩa là,mỗi một bài bình luận chỉ bình luận cho một bài viết nào đó mà thôi Do đó, bản số củaCOMMENT – has_comment là (1,1)

Trang 30

 has_role: mô tả mối quan hệ giữa thực thể USER_ACCOUNT và thực thểROLE

 Mỗi một thể hiện của thực thể USER_ACCOUNT sẽ có tối thiểu một thể hiệncủa thực thể ROLE, và có tối đa cũng chỉ một thể hiện của thực thể ROLE Hay nóicách khác, mỗi tài khoản người dùng sẽ có một quyền duy nhất để đăng nhập hệ thống

Do đó, bản số của USER_ACCOUNT – has_role là (1,1)

 Mỗi một thể hiện của thực thể ROLE sẽ tối thiểu không có thể hiện nào của thựcthể USER_ACCOUNT, và tối đa sẽ tìm thấy nhiều thể hiện của thực thểUSER_ACCOUNT Nghĩa là, mỗi một quyền đăng nhập sẽ có thể có tài khoản cóquyền đó và có thể không có tài khoản nào có quyền đó Do đó, bản số của ROLE –has_role là (0,n)

 has_account: mô tả mối quan hệ giữa thực thể PAGODA và thực thểUSER_ACCOUNT

 Mỗi một thể hiện của thực thể PAGODA sẽ có tối thiểu một thể hiện của thựcthể USER_ACCOUNT, và có tối đa nhiều thể hiện của thực thể USER_ACCOUNT.Hay nói cách khác, mỗi một chùa sẽ có ít nhất một tài khoản đăng nhập Do đó, bản sốcủa PAGODA – has_account là (1,n)

 Mỗi một thể hiện của thực thể USER_ACCOUNT sẽ tối thiểu không có thể hiệnnào của thực thể PAGODA, và tối đa cũng chỉ có một thể hiện của thực thể PAGODA.Nghĩa là, mỗi tài khoản có thể là tài khoản của một chùa nào đó, mà cũng có thể khôngphải là tài khoản của chùa nào hết (có thể là tài khoản của quản trị viên hoặc cán bộtrong ngành) Do đó, bản số của USER_ACCOUNT – has_account là (0,1)

Trang 31

3.3.1.3 Bảng mô tả các thực thể, mối kết hợp

Thực thể: PAGODADiễn giải: tập hợp các chùa Khmer

Khóa: PagodaID

Bảng 3.1 Mô tả thực thể PAGODA

Thực thể: HAMLETDiễn giải: tập hợp các ấp (khóm)

Trang 32

Thực thể: VILLAGEDiễn giải: tập hợp các xã (phường)

Khóa: DistrictID

Bảng 3.4 Mô tả thực thể DISTRICT

Thực thể: DIGNITYDiễn giải: mô tả phẩm giới của Sư

Trang 33

Diễn giải: tập hợp các Sư

Khóa: MonkID

Bảng 3.6 Mô tả thực thể MONK

Thực thể: COMMENTDiễn giải: tập hợp các bài bình luận

Khóa: CommentID

Bảng 3.7 Mô tả thực thể COMMENT

Thực thể: ARTICLE

Trang 34

Diễn giải: tập hợp các bài viết về Chùa

Khóa: ArticleID

ST

Bảng 3.8 Mô tả thực thể ARTICLE

Thực thể: ROLEDiễn giải: tập hợp các quyền đăng nhập

Khóa: RoleID

Bảng 3.9 Mô tả thực thể ROLE

Trang 35

Thực thể: USER_ACCOUNTDiễn giải: tập hợp các tài khoản người dùng

Khóa: Username

Bảng 3.10 Mô tả thực thể USER_ACCOUNT

Mối kết hợp: has_addressDiễn giải: mối kết hợp giữa thực thể PAGODA và thực thể HAMLET

Khóa: (không có thuộc tính)

Bảng 3.11 Mô tả mối kết hợp has_address

Mối kết hợp: has_articleDiễn giải: mối kết hợp giữa thực thể PAGODA và thực thể ARTICLE

Bảng 3.12 Mô tả mối kết hợp has_article

Mối kết hợp: has_dignityDiễn giải: mối kết hợp giữa thực thể MONK và thực thể DIGNITY

Bảng 3.13 Mô tả mối kết hợp has_dignity

Mối kết hợp: has_monk

Trang 36

Diễn giải: mối kết hợp giữa thực thể PAGODA và thực thể MONK

Bảng 3.14 Mô tả mối kết hợp has_monk

Mối kết hợp: is_in_districtDiễn giải: mối kết hợp giữa thực thể VILLAGE và thực thể DISTRICT

Bảng 3.15 Mô tả mối kết hợp is_in_district

Mối kết hợp: is_in_villageDiễn giải: mối kết hợp giữa thực thể HAMLET và thực thể VILLAGE

Bảng 3.16 Mô tả mối kết hợp is_in_village

Mối kết hợp: has_commentDiễn giải: mối kết hợp giữa thực thể ARTICLE và thực thể COMMENT

Bảng 3.17 Mô tả mối kết hợp has_comment

Mối kết hợp: has_roleDiễn giải: mối kết hợp giữa thực thể USER_ACCOUNT và thực thể ROLE

Bảng 3.18 Mô tả mối kết hợp has_role

Mối kết hợp: has_accountDiễn giải: mối kết hợp giữa thực thể PAGODA và thực thể USER_ACCOUNT

Bảng 3.19 Mô tả mối kết hợp has_account

Trang 37

FK_USER_ACC_HAS_ACCOU_PAGODA

FK_USER_ACC_HAS_ROLE_ROLE

PAGODA PagodaID

HamletID

integer integer

<pk>

<fk>

HAMLET HamletID VillageID

integer integer

<pk>

<fk>

DISTRICT DistrictID

integer<Undefined> <pk>

MONK MonkID

DignityID

PagodaID

integer integer integer

PagodaID

integer integer

<pk>

<fk>

DIGNITY DignityID integer<Undefined> <pk>

VILLAGE VillageID DistrictID

integer integer

<pk>

<fk>

COMMENT CommentID ArticleID

integer integer

<pk>

<fk>

USER_ACCOUNT Username

RoleID PagodaID

char(32) integer integer

Sơ đồ 3.3 Mô hình dữ liệu mức vật lý

Trang 38

3.3.2.2 Danh sách các bảng

 PAGODA (PagodaID, DharmaName, PagodaName, PagodaLeader, PagodaDes,

YearOfBuilt, Area, NumOfMonk, NumOfBuddhistFa, NumOfBuddhist, HamletID)

 HAMLET (HamletID, HamletName, VillageID)

 VILLAGE (VillageID, VillageName, DistrictID)

 DISTRICT (DistrictID, DistrictName)

 DIGNITY (DignityID, DignityName)

 MONK (MonkID, DharmaName, RealName, DateOfBirth, NativeVillage,

DateToPagoda, LevelOfStudy, LevelOfKhmer, Note, PagodaID, DignityID)

 ARTICLE (ArticleID, Title, Abstract, Body, ImageUrl, AddedDate, AddedBy,

UpdatedDate, DisplayOrder, ViewCount, IsActived, PagodaID)

 COMMENT (CommentID, Name, Email, Title, Content, CommentDate,

Trang 39

3.3.2.3 Mô tả chi tiết các bảng

Bảng: PAGODA (chùa)

Ghichú

Trang 40

Bảng: VILLAGE (xã (phường))

Ghichú

Bảng 3.22 Mô tả chi tiết bảng VILLAGE

Bảng: DISTRICT (huyện (thành phố))

Ghichú

Bảng 3.23 Mô tả chi tiết bảng DISTRICTBảng: DIGNITY (phẩm giới)

Ghichú

Bảng 3.24 Mô tả chi tiết bảng DIGNITYBảng: ROLE (Quyền đăng nhập)

Ghichú

Bảng 3.25 Mô tả chi tiết bảng ROLE

Định dạng
Số trang	82
Dung lượng	14,77 MB