Giáo trình Phân tích, thiết kế, xây dựng và quản trn các hệ thống cơ sở dữ liệu

tiết các thông tin. Bước tiếp theo chúng ta phải làm đó 
là: 
2. Thiết kế cơ sở dữ liệu mức khái niệm 
Trong bước này chúng ta sẽ phải mô tả dữ liệu dưới dạng 
mô hình thực thể liên kết. Bản thiết kế đầu tiên như trong 
hình sau. Sách BOOK và khách hàng CUSTOMER là 
những kiểu thực thể chúng ta có thể xác định được đầu tiên, 
hai kiểu thực thể này kết nối với nhau thông qua liên kết 
đơn đặt hàng “Orders”. Với mỗi đơn đặt hàng, những thông 
tin sau cần phải được lưu lại: số lượng Quantity, ngày đặt 
hàng Order_date và ngày giao hàng Ship_date. Khi ngày 
giao hàng Ship_date mang giá trị rỗng, tương ứng với 
thông tin cho biết là đơn đặt hàng chưa được giao. Ngay 
sau khi đơn đặt hàng được giao, giá trị trong ngày giao 
hàng Ship_date sẽ được đặt lại giá trị và nó cho biết đơn 
giao hàng đó đã được giao. 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 385
CUSTOMEROrdersBOOK
Isbn
Title
Author
Cid Cardnum
Quantity Ship_date
Qty_in_stock
Price
Year_published
Order_date Cname Address
Hình 6.2.1 Sơ đồ thực thể - liên kết giữa BOOK và CUSTOMER 
Đến đây chúng ta đã có một bản thiết kế đầu tiên và chúng 
ta cần phải thảo luận thêm trong nhóm thiết kế cơ sở dữ 
liệu về một số trường hợp có thể xảy ra trên thực tế và cách 
giải quyết ở bước này như thế nào? 
CH (câu hỏi): Nếu một khách hàng đặt 2 đơn đặt hàng cho 
cùng một quyển sách trong cùng một ngày thì sẽ phải xử lý 
như thế nào? 
TL (trả lời): Đối với lần đặt hàng thứ nhất, nó sẽ được tạo 
ra một đơn đặt hàng trong liên kết đơn hàng “Orders”, đối 
với lần đặt hàng thứ 2 nó sẽ được xử lý bằng cách cập nhật 
lại thuộc tính số lượng Quantity trong liên kết “Orders” đã 
tạo. 
CH: Nếu một khách hàng đặt 2 đơn đặt hàng cho 2 quyển 
sách khách nhau trong cùng một ngày thì sẽ được xử lý như 
thế nào: 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 386
TL: Khi đó ta coi mỗi lần đặt sách là một đơn đặt hàng 
khác nhau như trong các trường hợp thông thường. Tức là 
mỗi một thể hiện của liên kết “Orders” liên quan đến khách 
hàng cho mỗi quyển sách đó. 
CH: Nếu khách hàng đặt hàng cùng một quyển sách nhưng 
ở 2 ngày khác nhau thì sẽ được xử lý như thế nào? 
TL: Cũng tương tự như trong trường hợp trên, ta sẽ phải 
lưu 2 thể hiện cho 2 đơn đặt hàng đó và chúng sẽ có giá trị 
tại thuộc tính ngày đặt hàng Order_date khác nhau. 
CH: Nếu xử lý như vậy thì không thể được, bởi các giá trị 
kết nối giữa hai thuộc tính mã hiệu khách hàng Cid và số 
hiệu sách Isbn khi được liên kết với nhau không thể xác 
định ra duy nhất một đơn hàng trong “Orders”. Như vậy 
bản thiết kế ban đầu này chưa cho phép khách hàng đặt các 
đơn đặt hàng khác nhau cho cùng một cuốn sách trong 
những ngày khác nhau. 
TL: Đúng như vậy, có lẽ khách hàng chưa quan tâm đến 
trường hợp này, chúng ta cần phải tìm hiểu thêm. 
Chúng ta hãy chuyển sang bước thiết kế tiếp theo và xem 
xét vấn đề trên sẽ được xử lý tiếp như thế nào 
3. Thiết kế cơ sở dữ liệu mức logic 
Ở bước này chúng ta ánh xạ sơ đồ thực thể liên kết trong 
hình 6.2.1 sang mô hình quan hệ, sinh ra các quan hệ như 
sau: 
Create table BOOK (Isbn char(10), 
Title char(80), 
Author char(80), 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 387
Qty_in_stock integer, 
Price real, 
Year_published integer, 
primary key (Isbn)) 
Create table CUSTOMER (Cid integer, 
Cname char(80), 
Address char(200), 
Cardnum char(16), 
primary key (Cid), 
unique (Cardnum)) 
Create table ORDER (Isbn char(10), 
Cid integer, 
Quantity integer, 
Order_date date, 
Ship_date date, 
primary key (Isbn, Cid), 
foreign key (Isbn) references BOOK, 
foreign key (Cid) references CUSTOMER) 
Chúng ta nhận thấy rằng liên kết nhiều-nhiều “Orders” đã 
được chuyển thành một quan hệ (bảng). 
Quay trở lại vấn đề phát sinh trong phần trên, đến đây 
chúng ta nhận thấy rằng, quan hệ ORDER chứa một trường 
Order_date và khoá của bàng bao gồm 2 thuộc tính Cid và 
Isbn. Chính vì lý do này mà khách hàng không thể đặt 2 
đơn hàng cho cùng một cuốn sách ở các ngày khác nhau, 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 388
hạn chế này chúng ta hoàn toàn không muốn và trên thực tế 
có những trường hợp như vậy xảy ra. Khi đó để loại bỏ hạn 
chế này, chúng ta chỉ cần chèn thêm thuộc tính Order_date 
vào khoá của quan hệ ORDER, và có quan hệ mới như sau: 
Create table ORDER (Isbn char(10), 
Cid integer, 
Quantity integer, 
Order_date date, 
Ship_date date, 
primary key (Isbn, Cid, Order_date), 
foreign key (Isbn) references BOOK, 
foreign key (Cid) references CUSTOMER) 
Tuy nhiên đây có vẻ như không hợp lý với sơ đồ thực thể 
liên kết, và chúng ta quyết định phải gặp lại khách hàng. 
Khách hàng lại cho chúng ta biết thêm một số yêu cầu mà 
chưa được đề cập đến ở lần trước đó như sau: “Khách hàng 
có thể đặt mua một số đầu sách trong cùng một đơn đặt 
hàng. Ví dụ, nếu khách hàng muốn mua 3 quyển sách Văn 
học và 2 quyển Luật học thì họ có thể yêu cầu trong cùng 
một đơn đặt hàng”. Và chúng ta có thể hỏi khi đó nó sẽ ảnh 
hưởng như thế nào đến quá trình giao hàng nếu cửa hàng 
không đủ số lượng cho hai đầu sách đó? Cửa hàng sẽ giao 
đầy đủ tất cả các cuốn sách theo đơn hàng hay có thể giao 
từng loại? Và khách hàng cho chúng ta biết như sau: “Ngay 
sau khi cửa hàng có đủ số lượng sách của một đầu sách như 
yêu cầu trong đơn hàng, cửa hàng sẽ tiến hành giao hàng 
ngay mặc dù trong đơn đặt hàng có nhiều đầu sách. Tức là 
có thể xảy ra trường hợp 3 cuốn sách Văn học sẽ được giao 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 389
ngày hôm nay bởi trong kho của cửa hàng có 5 cuốn loại 
này, tuy nhiên sách Luật học có thể ngày mai mới được 
giao bởi trong kho chỉ có một cuốn, và ngày mai số lượng 
sách đó mới về tới kho của cửa hàng. Thêm vào đó, khách 
hàng có thể đặt nhiều đơn hàng trong một ngày và họ cũng 
muốn biết thông tin về các đơn đặt hàng mà họ đã đặt”. 
Như vậy, chúng ta nhận thấy rằng đã có 2 yêu cầu mới phát 
sinh trong lần gặp gỡ khách hàng này: thứ nhất, hệ thống 
phải đáp ứng được khả năng đặt nhiều đầu sách khác nhau 
trong cùng một đơn đặt hàng duy nhất. Thứ 2, một khách 
hàng có thể đặt các đơn hàng khác nhau trong cùng một 
ngày. Để có thể giải quyết được vấn đề này, chúng ta cần 
đưa thêm một thuộc tính mới vào quan hệ ORDER, đó là 
thuộc tính số hiệu đơn hàng Order_id, sẽ xác định duy nhất 
một đơn hàng do khách hàng đặt. Tuy nhiên, vì khách mua 
có thể đặt nhiều đầu sách khác nhau trong cùng một đơn 
hàng nên giá trị trong hai thuộc tính Order_id và Isbn kết 
hợp với nhau mới có thể xác định được các giá trị trong 
thuộc tính Quantity và Ship_date trong quan hệ ORDER. 
Các đơn hàng sẽ được gán bởi các số hiệu đơn hàng khác 
nhau theo thứ tự tuần tự, và đơn hàng sau sẽ có giá trị số 
hiệu đơn hàng lớn hơn đơn hàng trước. Nếu có nhiều đơn 
hàng của cùng một khách trong cùng một ngày thì chúng 
cũng được phân biệt với nhau do các số hiệu đơn hàng là 
khác nhau. Câu lệnh SQL để tạo quan hệ ORDER này sẽ 
như sau: 
Create table ORDER (Order_id integer, 
Isbn char(10), 
Cid integer, 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 390
Quantity integer, 
Order_date date, 
Ship_date date, 
primary key (Order_id, Isbn), 
foreign key (Isbn) references BOOK, 
foreign key (Cid) references CUSTOMER) 
4. Tinh chỉnh lược đồ 
Tại bước này, chúng ta phải phân tích tập các quan hệ có 
thể gây ra sự dư thừa số liệu. Trong quan hệ BOOK chỉ có 
duy nhất một trường khoá đó là Isbn, và không có phụ 
thuộc hàm nào khác thoả trên quan hệ này. Do vậy quan hệ 
BOOK là đã ở dạng chuNn 3NF. Quan hệ CUSTOMER 
cũng có duy nhất một thuộc tính khoá đó là Cid, bởi số hiệu 
thẻ tín dụng là duy nhất nên phụ thuộc hàm Cardnum → 
Cid cũng thoả. Không còn phụ thuộc hàm nào khác nên 
CUSTOMER cũng ở dạng chuNn 3NF. 
Như trên đã xác định cặp (Order_id, Isbn) là khoá của quan 
hệ ORDER. Thêm vào đó, mỗi đơn hàng được đặt bởi một 
khách mua của một ngày cụ thể nên 2 phụ thuộc hàm sau là 
thoả: 
Order_id → Cid, và Order_id → Order_date 
Do vậy chúng ta có thể kết luận rằng quan hệ ORDER 
không ở dạng chuNn 3NF. Nên chúng ta phải tiến hành 
phân rã ORDER thành 2 quan hệ sau: 
ORDER(Order_id, Cid, Order_date) và 
 ORDER_LINE(Order_id, Isbn, so_luong, Ship_date) 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 391
Như vậy cả 2 quan hệ trên đều ở dạng chuNn 3NF. Và đến 
đây chúng ta có các câu lệnh SQL tạo quan hệ như sau: 
Create table ORDER (Order_id integer, 
Cid integer, 
Order_date date 
primary key (Order_id), 
foreign key (Cid) references CUSTOMER) 
Create table ORDER_LINE (Order_id integer, 
Isbn char(10), 
Quantity integer, 
Ship_date date 
primary key (Order_id, Isbn), 
foreign key (Order_id) references ORDER, 
foreign key (Isbn) references BOOK) 
Hình 6.4.1 là sơ đồ thực thể liên kết được sửa đổi theo cách 
thiết kế mới như trên. Chú ý rằng, chúng ta sẽ có sơ đồ này 
ngay nếu ngay từ đầu chúng ta coi ORDER là một kiểu 
thực thể thay vì là một liên kết. Mặc dù vậy, việc chúng ta 
chưa thể hiểu được đầy đủ các nghiệp vụ ngay từ lần gặp 
gỡ đầu tiên với khách hàng là một điều hết sức bình thường. 
Quá trình tinh chỉnh lược đồ này có thể được lặp đi lặp lại 
nhiều lần, đặc biệt đối với những bài toán lớn có nghiệp vụ 
phức tạp và đó thực sự là một qui trình phát sinh trong thực 
tế bởi hầu hết các thiết kế ban đầu đều được làm mịn dần 
trong quá trình xây dựng dự án. 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 392
CUSTOMER
Orders
BOOK
Isbn
Title
Author
Cid Cardnum
Quantity Ship_date
Qty_in_stock
Price
Year_published
Order_id Cname Address
Hình 6.4.1 Sơ đồ thực thể - liên kết được tinh chỉnh
Order_line Place_order
Order_date
Sau giai đoạn này chúng ta sẽ chuyển sang việc thiết kế cơ 
sở dữ liệu vật lý 
5. Thiết kế cơ sở dữ liệu vật lý 
Chủ cửa hàng sách mong muốn rằng khách hàng của họ sẽ 
tìm kiếm sách thông qua số ISBN trước khi đặt hàng mua 
sách. Việc đặt đơn hàng mua sách bao gồm: chèn 1 bản ghi 
vào quan hệ ORDER và một hoặc nhiều bản ghi vào quan 
hệ ORDER_LINE. Nếu số lượng sách yêu cầu có đủ trong 
cửa hàng, công việc giao hàng được chuNn bị và Ship_date 
trong quan hệ ORDER_LINE được đặt giá trị tương ứng. 
Thêm vào đó, số lượng sách trong cửa hàng sẽ thay đổi 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 393
theo thời gian, tăng lên khi cửa hàng nhập thêm sách và 
giảm đi khi khách hàng đặt mua. 
Như vậy chúng ta phải bắt đầu bằng việc xem xét đến vấn 
đề tìm kiếm sách thông qua giá trị ISBN. Vì Isbn là trường 
khoá nên việc tìm kiếm trên nó sẽ trả lại nhiều nhất là 1 bản 
ghi. Như vậy để tăng tốc độ tìm kiếm khi khách mua của 
cửa hàng tìm sách, chúng ta sẽ phải tạo một chỉ số băm 
không phân cụm (unclustered hash index) trên trường Isbn. 
Tiếp theo chúng ta phải cân nhắc đến vấn đề cập nhật số 
lượng sách. Để cập nhật giá trị Qty_in_stock cho mỗi một 
đầu sách, đầu tiên phải tìm đến bản ghi đó thông qua giá trị 
ISBN, tệp chỉ số trên sẽ giúp công việc tìm kiếm nhanh hơn. 
Ngoài ra, do khách mua cũng sẽ thường xuyên tìm kiếm 
sách thông qua tiêu đề hay tên tác giả, nên chúng ta quyết 
định xây dựng thêm các tệp chỉ số trên 2 trường Author và 
Title, hơn nữa việc bảo trì các tệp chỉ số này không phức 
tạp lắm do danh mục đầu sách ít khi thay đổi (chỉ khi có 
thêm đầu sách mới), mặc dù số lượng sách trong cửa hàng 
liên tục thay đổi. 
Với quan hệ CUSTOMER, mỗi một khách mua được xác 
định bởi một giá trị định danh duy nhất. Do hầu hết các tìm 
kiếm trên CUSTOMER là dựa trên các giá trị này nên 
chúng ta quyết định tạo một tệp chỉ số băm phân cụm trên 
trường Cid để tăng tốc độ tìm kiếm. 
Sang đến quan hệ ORDER, chúng ta nhận thấy rằng có 2 
loại truy vấn: chèn thêm các đơn hàng mới và trả về các 
đơn hàng đã đặt. Cả 2 truy vấn này đều sử dụng thuộc tính 
Order_id như là khoá tìm kiếm, do vậy chúng ta quyết định 
xây dựng một tệp chỉ số trên nó. Tuy nhiên phải lựa chọn 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 394
giữa hai loại tệp chỉ số là B-tree hay băm. Trong trường 
hợp này giá trị các đơn hàng tăng theo thời gian, tương ứng 
với các giá trị trong thuộc tính Order_date, sắp xếp theo 
Order_id cũng hiệu quả như sắp xếp theo ngày đặt, do vậy 
chúng ta quyết định lựa chọn loại B-tree phân cụm làm tệp 
chỉ mục cho trường Order_id. 
Trong quan hệ ORDER_LINE, hầu hết các thao tác trên 
quan hệ này là phép chèn, một số phép cập nhật trên thuộc 
tính Ship_date, và phép liệt kê danh mục các sách đặt mua 
của một đơn hàng đã cho. Nếu quan hệ này được sắp xếp 
theo Order_id, khi đó tất cả các phép chèn đơn giản chỉ là 
việc thêm vào cuối quan hệ và do đó rất hiệu quả. Một tệp 
chỉ mục phân cụm B-tree nên được xây dựng cho giá trị 
này, tệp chỉ số này cũng làm tăng tốc độ cho câu lệnh tìm 
kiếm liệt kê các sách đã đặt mua của một đơn hàng nào đó. 
Với phép cập nhật giá trị trong thuộc tính Ship_date, chúng 
ta cần phải tìm kiếm trên giá trị của 2 trường là Order_id và 
Isbn. Tệp chỉ số trên Order_id xây dựng phía trên cũng hữu 
ích cho phép tìm kiếm này, tuy nhiên nếu chúng ta có một 
tệp chỉ số trên cả 2 thuộc tính thì vẫn sẽ nhanh hơn. 
Một số điều chỉnh đối với cơ sở dữ liệu: 
Giả thiết sau khi cơ sở dữ liệu được đưa vào sử dụng và 
khách hàng bắt đầu đặt mua sách qua trang web, sau vài 
tháng, chúng ta nhận được một số phàn nàn của cửa hàng 
rằng khách mua của họ thấy việc xử lý các đơn đặt hàng 
của họ ngày càng chậm. Mặc dù các thao tác vẫn được thực 
hiện thành công, nhưng do số lượng bản ghi trong các quan 
hệ ORDER và ORDER_LINE ngày càng nhiều và các quan 
hệ này ngày càng lớn so với ban đầu nên ảnh hưởng đến tốc 
độ xử lý đơn hàng? Nếu điều này xảy ra, chúng ta phải xem 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 395
xét lại bản thiết kế. Chúng ta nhận thấy rằng, ở đây, có 2 
loại đơn hàng, một loại đơn hàng đã được thực hiện xong 
tương ứng với các đầu sách trong đơn đã được giao và một 
loại còn chưa hoặc đang được thực hiện tương ứng với các 
đầu sách trong đơn hàng chưa hoặc đang được giao. Và hầu 
hết các khách mua có nhu cầu tìm kiếm trên loại đơn hàng 
thứ 2 (chưa hoặc đang được giao). Ngoài ra, cũng nhận 
thấy rằng, đối với loại đơn hàng này thì số lượng rất nhỏ so 
với loại đơn hàng đã được thực hiện xong. Do vậy chúng ta 
quyết định tiến hành điều chỉnh thêm đối với 2 quan hệ này, 
chúng ta tiến hành phân vùng (partition) ngang 2 quan hệ 
này thành 4 quan hệ mới đó là NEWORDER, OLDORDER, 
NEWORDER_LINE và OLDORDER_LINE. Rõ ràng, một 
đơn hàng luôn đi thành từng cặp hoặc cũ hoặc mới tương 
ứng với nhau. Đến đây chúng ta đã khắc phục được hiện 
tượng tìm kiếm trên những đơn hàng còn đang được thực 
hiện giao. 
Tuy nhiên, đối với những truy vấn như tìm tất cả các đơn 
hàng của một khách hàng nào đó thì vẫn chậm, bởi khi đó 
hệ thống vẫn phải tìm kiếm trên cả 2 loại quan hệ cũ và 
mới trên, nhưng việc tìm kiếm này là có thể chấp nhận 
được và nó ít khi xảy ra, thường là các báo cáo tháng, quý, 
năm của cửa hàng. 
6. Vấn đề an toàn bảo mật 
Chúng ta đã hoàn tất việc thiết kế vật lý cho cơ sở dữ liệu. 
Tiếp theo chúng ta phải xem xét đến vấn đề an toàn dữ liệu. 
Thông thường, có 3 nhóm người dùng có nhu cầu truy cập 
cơ sở dữ liệu, đó là: khách mua, nhân viên cửa hàng, và chủ 
cửa hàng. Ngoài ra, cũng cần có người quản trị hệ thống, 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 396
chịu trách nhiệm đối với các hoạt động của cơ sở dữ liệu và 
có quyền truy nhập vào toàn bộ cơ sở dữ liệu. 
• Với chủ cửa hàng, anh ta sẽ có đầy đủ các quyền trên 
tất cả các quan hệ, tuy nhiên anh ta không được phép 
tạo dựng thêm các đối tượng dữ liệu mới. Do vậy 
người quản trị sẽ phân quyền thao tác đầy đủ trên các 
đối tượng dữ liệu trong cơ sở dữ liệu cho anh ta. 
• Với khách mua, họ chỉ được phép tìm kiếm trên quan 
hệ BOOK và có thể đặt hàng trực tuyến, nhưng họ 
không được phép truy nhập đến các bản ghi của các 
khách hàng khác cũng như các đơn đặt hàng khác. Do 
vậy ở đây chúng ta phải giới hạn theo 2 cách. Cách 
thứ nhất, phải sử dụng các đặc trưng an toàn của cơ 
sở dữ liệu để giới hạn phạm vi truy suất đến các dữ 
liệu nhạy cảm. Ví dụ khi tạo lập một khoản mục mới 
cho khách hàng, người quản trị cơ sở dữ liệu sẽ tạo 
dựng luôn những khung nhìn chỉ cho phép anh ta 
xem các dữ liệu của riêng mình thông qua các khung 
nhìn đó. Cách thứ 2, chúng ta có thể giới hạn thông 
qua việc tạo các giao diện trong ứng dụng trên Web. 
Và mọi truy vấn đều được gắn thêm giá trị Cid của 
khách mua hiện thời. 
• Với các nhân viên của cửa hàng, tùy từng đối tượng 
mà người quản trị sẽ phân cho họ các quyền thao tác 
trên từng đối tượng dữ liệu cụ thể. Ví dụ với người 
quản lý kho, anh ta chỉ được phép cập nhật trên quan 
hệ BOOK. Với người quản lý các thông tin về khách 
hàng thì chỉ có thể thao tác trên quan hệ 
CUSTOMER mà thôi. Còn với những người quản lý 
các đơn hàng, họ có các quyền cập nhật trên hai quan 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 397
hệ NEWORDER và NEWORDERLINE, nhưng với 
các quan hệ còn lại như BOOK, CUSTOMER thì chỉ 
có quyền xem mà thôi. 
Cụ thể, để hạn chế quyền truy nhập của khách mua, chúng 
ta có thể tạo một tài khoản có tên là khachmua và gán cho 
tài khoản này các quyền sau: 
Select on BOOK, NEWORDER, OLDORDER, 
NEWORDER_LINE, OLDORDER_LINE 
Insert on NEWORDER, NEWORDER_LINE 
Với các nhóm nhân viên, như trên đã phân tích, họ có thể 
có quyền chèn thêm một đầu sách mới, cập nhật lại số 
lượng sách trong cửa hàng và sửa lại thông tin đặt hàng của 
khách trong một số trường hợp, cập nhật lại thông tin liên 
quan đến khách hàng ngoại trừ giá trị tại trường Cardnum. 
Trên thực tế, nhóm này còn không được phép biết đến các 
giá trị tại thuộc tính này. Do vậy chúng ta phải tạo thêm các 
khung nhìn sau: 
Create view CUSTOMERINFO (Cid, Cname, Address) as 
Select Cid, Cname, Address 
From CUSTOMER 
Và cấp các quyền sau cho nhóm nhân viên này: 
Select on CUSTOMERINFO, BOOK, NEWORDER, 
OLDORDER, NEWORDER_LINE, OLDORDER_LINE 
Insert on CUSTOMERINFO, BOOK, NEWORDER, 
OLDORDER, NEWORDER_LINE, OLDORDER_LINE 
Update on CUSTOMERINFO, BOOK, NEWORDER, 
OLDORDER, NEWORDER_LINE, OLDORDER_LINE 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 398
Delete on BOOK, NEWORDER, OLDORDER, 
NEWORDER_LINE, OLDORDER_LINE 
Ngoài ra, do sử dụng trang web trên mạng, nên việc gửi 
nhận thông tin trên mạng có thể cần được mã hoá và nên sử 
dụng giao thức SSL (Security Socket Layer). 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 399
Tài liệu tham khảo 
[1] C.Goble - J.Keane, Advances in Databases, Springer , 
1997. 
[2] H.David, Data Analysis for Database Design. Third ed, 
Butterworth, 2003. 
[3] J.Teorey, Database Modeling & Design , Morgan Kauf, 
1999. 
[4] R.McFadden and al., Modern Database Management. 
(5th. Ed.), Addison-Wesley, 2000. 
[5] R.Raghu, G.Jahannes, Database Management Systems, 
McGraw-hill, 2000. 
[6] C.J.Date, Nhập môn các hệ cơ sở dữ liệu (Hồ Thuần 
dịch), Nhà xuất bản thống kê, 1986. 
[7] Hồ Thuần, Đề cương chi tiết giáo trình cơ sở dữ liệu 
nâng cao, Bộ GD&ĐT, 1998. 
[8] Nguyễn Kim Anh, Nguyên lý của các hệ cơ sở dữ liệu, 
Nhà xuất bản Đại học quốc gia Hà Nội, 2004. 
 [9] Nguyễn Văn Ba, Phân tích và thiết kế hệ thống thông 
tin, Nhà xuất bản Đại học quốc gia Hà Nội, 2002. 
[10] Trần Thành Trai, Phân tích và thiết kế hệ thống thông 
tin quản lý, Nhà xuất bản thống kê, 1994. 
[11] Vũ Đức Thi, Cơ sở dữ liệu kiến thức và thực hành , 
Nhà xuất bản thống kê, 1997. 
Phân tích, thiết kế, xây dựng và quản trị các hệ thống cơ sở dữ liệu 400
[12]  
[13]  
[14]  
[15] 
asp 
[16]  
[17]