Giáo trình Cơ sở dữ liệu - Vũ Đức Thi

.....................................................
Tên kho ...................................................................................................................
Địa chỉ kho...............................................................................................................
Ngày đề nghi đặt hàng ..........................................................................................
Ngày đặt hàng ........................................................................................................
Ngày giao hàng ......................................................................................................
Đơn giá sản phẩm ..................................................................................................
Mã số sản phẩm .....................................................................................................
Nhãn hiệu sản phẩm..............................................................................................
Số lượng hàng cần đặt ..........................................................................................
Số lượng hàng đặt mua ........................................................................................
Số lượng hàng được giao ..................................................................................... 
6.3.3. Xây dựng mô hình dữ liệu 
Giai đoạn này bao gồm 5 động tác:
	- Định tập hợp các khoá chính 
	- Nhận diện các thực thể 
	- Nhận diện các quan hệ 
	- Phân bổ các thuộc tính còn lại 
	- Vẽ sơ đồ khái niệm dữ liệu
6.3.3.1. Xác định tập hợp các khoá chính 
Tập hợp K của những khoá chính là tập hợp tất cả những loại dữ liệu đóng vai trò nguồn (thuộc vế trái ) trong ít nhất một phụ thuộc hàm.
Trong ví dụ trên ta có : K =
	{'Mã số công ty cung cấp'
	 'Tên kho'
	'Ngày đề nghi đặt hàng'
	'Ngày đặt hàng'
	'Ngày giao hàng'
	'Mã số sản phẩm'}
6.3.3.2 Nhận diện các thực thể
Mỗi phần tử của tập hợp K sẽ là khoá chính của một thực thể
Trong ví dụ trên, ta nhận ra được 4 thực thể:
'Nhà cung cấp' với khoá chính là 'Mã số của công ty cung cấp'
'Kho' với khoá chính là 'Tên kho'
'Lịch' với khoá chính là 'Ngày' 
(các thực thể 'Lịch đặt hàng', 'Lịch đề nghi mua hàng' và 'Lịch giao hàng' hoàn toàn tương đương với nhau nên được gộp thành một thực thể duy nhất là 'Lịch')
'Sản phẩm' với khoá chính là 'Mã số sản phẩm'
6.3.3.3 Nhận diện các quan hệ 
Có 2 trường hợp : 
a. Nếu gốc của một phụ thuộc hàm bao gồm ít nhất 2 phần tử thuộc tập hợp K thì nó tương ứng với một quan hệ N - P giữa các thực thể có khoá chính là các phần tử này.
Trong ví dụ trên, ta nhận ra được 4 quan hệ :
	'Đơn giá của nhà cung cấp'
	'Dòng đề nghị mua hàng'	
	'Dòng đơn đặt hàng'
	'Dòng phiếu giao hàng'
b. Một phụ thuộc hàm giữa 2 phần tử của tập hợp K xác định một quan hệ nhị nguyên kiểu 1-N giữa hai thực thể có khoá chính là các phần tử này. 
6.3.3.5. Vẽ sơ đồ khái niệm dữ liệu
Từ các thực thể và quan hệ đã nhận diện, ta có thể vẽ lên một sơ đồ khái niệm dữ liệu sau:
Lịch
 0,n
Nhà cung cấp
Kho
 0,n 1,n 1,n 1,n 
 1,n 1,n 0,n 
 Dòng đơn Giá Dòng đơn Dòng đề nghị 
 giao hàng	 cung cấp đặt hàng mua hàng
 1,n 1,n 1,n 1,n 1,n 
Sản phẩm
6.3.4 Xây dựng mô hình dữ liệu bằng trực giác
Phương pháp phân tích hệ thống nêu trên là một công cụ hữu hiệu và chuẩn xác để xây dựng phần lớn các loại mô hình dữ liệu. Nhưng nếu áp dụng hoàn toàn trong một hệ thông tin cỡ lớn sẽ đòi hỏi nhiều thời gian và công sức. Trong thực tế, các thiết kế viên kinh nghiệm, sau khi đã nhận thức được vấn đề qua khảo sát thường chọn cách xây dựng trực tiếp một mô hình sơ khởi rồi đi thẳng vào giai đoạn sau để kiểm soát và chuẩn hoá mô hình .
Phương pháp trực giác này có ưu điểm là ít tốn thời gian và đôi khi tạo ra những mô hình đơn giản và gần thực tế hơn. Nhưng ngược lại, nó chứa nhiều rủi ro hơn.
6.4. Kiểm soát và chuẩn hoá mô hình
Để đơn giản hoá và đồng thời đảm bảo tính nhất quán của mô hình dữ liệu, ta cần kiểm soát lại mô hình vừa xây dựng bằng một số qui tắc thực tiễn sau đây:
6.4.1 Chuẩn hoá mô hình
Chú ý việc chuẩn hoá toàn bộ mô hình dữ liệu thành các dạng BCNF không phải là bắt buộc. Tuy vậy các dạng 1FN, 2FN, 3NF nên luôn được thực hiện.
6.4.2 Tạo thêm một thực thể 
Việc tạo thêm một thực thể là cần thiết khi có ít nhất một quan hệ đang được xử lý liên quan tới nó.
Việc tạo thêm một thực thể là hợp lí khi:
a) Thuộc tính sẽ được chọn làm khoá chính của thực thể này là một loại dữ liệu thông dụng trong hoạt động của tổ chức đang khảo sát.
b) Ngoài khoá chính này, quan hệ còn có chứa những thuộc tính khác .
6.4.3. Biến một quan hệ thành thực thể 
Một quan hệ có kích thước lớn hơn 3 nên được biến thành thực thể để đơn giản hoá.
Có thể biến một quan hệ thành thực thể khi hội đủ các điều kiện sau:
- Quan hệ này có một khoá chính độc lập 
- Quan hệ này tương ứng với một khái niệm quen thuộc, thông dụng trong hoạt động của tổ chức.
 Môn học
 Thầy
 1,n 1,n
 R 
 0,n
 Ngày giờ
Quan hệ R được biến thành thực thể 'Thời khoá biểu':
 1,n 1,1 1,1 1,n
 Môn học
 Thầy
 Thời khoá biểu
 R1 R2
 1,1
 R3
 0,n
 Ngày giờ
6.4.4 Xoá một quan hệ
	Một quan hệ 1 - N phải được loại bỏ khỏi mô hình dữ liệu nếu nó là tổng hợp của 2 hay nhiều quan hệ 1 - N khác.
 1,n 1,1 1,n 1,1
 Môn học
 Học sinh
 Trường
 Gồm Học lớp 
 1,n 1,1 
 Học trường
Ta loại bỏ quan hệ Học trường
6.4.5 Phân tách một quan hệ phức tạp
Xét một quan hệ có kích thước lớn hơn hoặc bằng 3. Quan hệ có thể được phân tách thành nhiều quan hệ khác với kích thước nhỏ hơn mà không mất thông tin nếu tồn tại ít nhất một phụ thuộc hàm giữa các thực thể cấu thành quan hệ.
6.4.5.1 Trường hợp phụ thuộc hàm ẩn
Trong trường hợp này, một trong các bản số của quan hệ bằng (1,1) hoặc (0,1). Điều này chứng tỏ sự tồn tại của một số phụ thuộc hàm ẩn.
Ví dụ:
 Bệnh nhân
 Toa thuốc
 Bác sỹ
 0,n 0,n 1,1
 Khám bệnh
Sơ đồ 1
 1,n 1,1
 Bệnh nhân
 Toa thuốc
 Bác sỹ
 Dùng 
 1,n 1,1
 Cho toa
Sơ đồ 2
Chúng ta chọn sơ đồ 2
6.4.5.2. Trường hợp phụ thuộc hàm hiện
Cho một quan hệ R giữa 3 thực thể A, B, và C. Nếu tồn tại một hàm phụ thuộc A ®B thì R có thể được phân thành quan hệ giữa A với B và giữa B với C.	 
Trong ví dụ sau đây, phụ thuộc hàm Hoá đơn ® Khách hàng (mỗi hoá đơn chỉ liên quan đến một khách hàng duy nhất) cho phép ta đưa vào một quan hệ mới để diễn tả sự phụ thuộc này và đơn giản hoá mô hình.
 Khách hàng
 Hoá đơn
 Sản phẩm
 0,n 0,n 1,n 
 Dòng hoá đơn 
Sơ đồ 1
 	 0,n 1,1
 Khách hàng
 Hoá đơn
 Sản phẩm
 Liên quan
 0,n 1,n
 Dòng hoá đơn
Sơ đồ 2 
Chúng ta chọn sơ đồ 2 đơn giản hơn.
Chương 7
 Thuật toán và độ phức tạp
7.1. Khái niệm thuật toán
Nếu cho trước một bài toán, thì một cách giải bài toán được phân định ra thành một số hữu hạn bước, có kết thúc cuối cùng gọi là thuật toán.
Khi giải bài toán sẽ nẩy sinh ra các vấn đề sau:
- Độ phức tạp bài toán. Mỗi bài toán có độ phức tạp khác nhau. 
- Một bài toán có nhiều thuật toán giải nó.
- Dùng nhiều ngôn ngữ lập trình để cài đặt phần mềm cho một thuật toán
- Có thể dùng nhiều cấu trúc dữ liệu cho một thuật toán.
Một số sai sót cơ bản khi giải bài toán:
- Hiểu sai bài toán.
- Tìm sai thuật toán.
- Do không hiểu ngôn ngữ lập trình nên có nhầm lẫn.
- Bản thân dữ liệu quét không hết trường hợp.
- Yêu cầu giải quyết bài toán.
- Phần mềm dễ sử dụng .
- Tốc độ tính toán nhanh .
- Bộ nhớ phù hợp .
Trong đó tính dễ sử dụng là một yêu cầu cơ bản nhất.
7.2. Độ phức tạp thuật toán
Khái niệm thuật toán chính xác liên quan đến các khái niệm máy Turing, hàm đệ qui, thuật toán Marcop, ngôn ngữ hình thức của N.Chomsky. Những khái niệm này không nằm trong khuôn khổ Giáo trình này. Chúng tôi trình bày một khái niệm quan trọng liên quan trực tiếp đến thuật toán. Đó là độ phức tạp thuật toán. Nhờ có khái niệm này chúng ta có thể đánh giá và so sánh được các thuật toán với nhau. Hay nói một cách khác, chúng ta có thể có công cụ đo, để lựa chọn một thuật toán tốt cho lời giải bài toán cần giải quyết. Thông thường chúng ta có hai loại đánh giá: Một là độ phức tạp về thời gian tính của thuật toán, hai là độ phức tạp về phạm vi bộ nhớ dùng cho thuật toán. Đối với một thuật toán, thời gian tính và phạm vi bộ nhớ cần dùng thường mâu thuẫn nhau. Có nghĩa là, nếu thời gian tính của thuật toán là ngắn thì thông thường phạm vi bộ nhớ dùng cho thuật toán đó lại lớn. Mà chúng ta lại muốn chọn một thuật toán thời gian tính thì ngắn và bộ nhớ dùng cũng nhỏ. Như vậy, trong từng trường hợp cụ thể, chúng ta sẽ quyết định chọn lựa thuật toán nào. Trong phạm vi Giáo trình này chúng ta chỉ trình bày về độ phức tạp thời gian tính. Đó là độ phức tạp thường được đề cập nhiều nhất. Đồng thời, trong phạm vi giới hạn của giáo trình, chúng ta cũng chỉ trình bày độ phức tạp của thuật toán theo góc độ tin học. 
Giả sử T là thuật toán giải quyết bài toán A. Chúng ta gọi T(n) là độ phức tạp thời gian của thuật toán T. Thông thường T(n) được biểu diễn dưới dạng sau: T(n) = O(g(n)). Trong đó hàm g(n) là cấp của T(n); n là độ dài thông tin đưa vào.
Ví dụ: T(n) = O(n2)
Chúng ta hiểu f(n) = O(g(n)), nếu $ hằng số C và số nguyên n0.
Sao cho: 
	"n ³ n0 ta luôn có: f(n) £ Cg(n)
 (Nói cách khác là g(n) là hàm chặn trên của f(n) từ một chỉ số nào đó trở đi).
Rõ ràng, trong quá trình đánh giá thuật toán, nếu có g(n) nhỏ nhất thì đó là sự đánh giá chính xác nhất.
Có thể thấy rằng, bài toán tìm g(n) nhỏ nhất khá phức tạp.
Bây giờ, chúng ta đưa ra độ phức tạp thời gian là hàm nhiều biến. Giả sử T(n1,... , nk ) là độ phức tạp thời gian của thuật toán T và T(n1,... , nk) = O(g(n1,....nk)). Khi đó chúng ta hiểu rằng tồn tại các số C , n01...n0k sao cho với mọi n1 ³ n01, ...., nk ³ n0k
	T(n1,...,nk) £ Cg(n1,..., nk)
Ví dụ: Đầu vào là R = {a1,....., an},
	 r = {h1,..., hm}
Chúng ta có	T(n,m) = O(g(n,m))
Trong trường hợp có nhiều đối số thì phức tạp thời gian được tính theo đối số có giá trị lớn nhất.
Ví dụ: T(n,m) = O(n2+2m). Khi đó độ phức tạp thời gian của thuật toán T là hàm số mũ.
Việc đánh giá như trên gọi là độ phức tạp thời gian tồi nhất.
Trong thực tế có nhiều cách đánh giá độ phức tạp thời gian. Ví dụ như độ phức tạp thời gian trung bình. Độ phức tạp này gắn với nhiều độ đo khác nhau (độ đo xác suất). Giáo trình này đánh giá độ phức tạp thời gian theo cách tồi nhất (tìm g(n) chặn trên). 
- Giả sử một độ phức tạp thuật toán chia làm nhiều đoạn, mỗi đoạn có độ phức tạp tương ứng là T1(n),...,Tq(n).
Khi đó chúng ta đặt T(n) = O (max(T1(n),..., Tq(n)).
- Nếu Ti là hàm nhiều biến: T1 (n1,...,nm), ..., Tq(n1,...,nm), thì lúc đó T1(n1,..., nm) = O (max(T1(n1,..., nm),..., Tq(n1,..., nm)).
- Giả sử T là thuật toán giải quyết bài toán A.
Ta chia hai khúc T1 và T2 và T2 lồng trong T1. Khi đó T(n) = O(T1(n). T2(n)).
Ví dụ: 	x:= 3;
 	x:= x + 1.
Dễ thấy độ phức tạp T(n) = O(c) ( hay O(1)).
Ví dụ:	x:= 3;
	 For i:= 1 to n do x:= x+1
 Thì:	T(n) = O(cn).
Ví dụ:	For i: = 1 to n do
	For j: = 1 to n do x:= x+1
	T(n) = O(c.n.n) = O (c.n2)
Trong trường hợp thuật toán có các đoạn lồng thắt vào nhau thì độ phức tạp là tích (Thể hiện bài toán có những toán tử lặp chu trình).
- Trong thuật toán chia thành nhiều đoạn. Có đoạn lồng thắt của đoạn khác: tính tích, có đoạn rời rạc: tính max.
Thông thường người ta chia các bài toán thành ba lớp. Đó là lớp bài toán được giải quyết bằng một thuật toán có độ phức tạp là hàm mũ, lớp bài toán NP - đầy đủ và lớp bài toán được giải quyết bằng một thuật toán có độ phức tạp là hàm đa thức.
- Đối với lớp bài toán được giải bằng thuật toán là hàm mũ và lớp bài toán NP - đầy đủ (Thường gọi là các bài toán không khả thi) thực tế trong tin học các bài toán này không có khả năng thực hiện vì thời gian tính quá lớn. Khi đó, chúng ta phải tách bài toán thành các dạng riêng biệt, và cố gắng đưa nó về lớp bài toán có độ phức tạp là hàm đa thức.
- Đối với các bài toán được giải bằng thuật toán có độ phức tạp là hàm đa thức, chúng ta cố gắng giảm số mũ k xuống (gần sát tuyến tính (mũ 1)).
Để hạ k (tăng tốc độ) thông thường người ta dùng cấu trúc dữ liệu, sử dụng ngôn ngữ gần ngôn ngữ máy.
 Thông thường người ta coi các thông số vào (input) bình đẳng với nhau.
Tài liệu tham khảo
[1] Armstrong W.W. Dependency Structures of Database Relationships. Information Processing 74, Holland publ. Co. (1974), 580-583.
[2] Beeri C. Bernstein P.A. Computational problems related to the design of normal form relational schemas. ACM trans on Database Syst. 4.1 (1979), 30-59
[3] Beeri C. Dowd M., Fagin R.. Staman R. On the structure of Armstrong relations for Functional Dependencies . J.ACM 31,1 (1984), 30-46.
[4] Codd E. F. A relational model for large shared data banks. Communications ACM 13 (1970 ), 377-387.
[5] Demetrovics J., Logical and structural Investigation of Relational Datamodel. MTA - SZTAKI Tanulmanyok, Budapest, 114 (1980), 1-97.
[6] Demetrovics J., Libkin, L. Functional dependencies in relational databases : A Lattice point of view. Discrete Aplied Mathematics 40 (1992), 155-185.
[7] Demetrovics J., Thi V.D. Some results about functional dependencies. Acta Cybernetica 8,3 (1988), 273-278.
[8] Demetrovics J., Thi V.D. Relations and minimal keys. Acta Cybernetica 8,3 (1988), 279-285.
[9] Demetrovics J., Thi V.D. On keys in the Relational Datamodel. Inform. Process Cybern. EIK 24, 10 (1988), 515 - 519
[10] Demetrovics J., Thi V.D. Algorithm for generating Armstrong relations and inferring functional dependencies in the relational datamodel. Computers and Mathematics with Applications. Great Britain. 26,4(1993), 43 - 55.
[11] Demetrovics J., Thi V.D. Some problems concerning Keys for relation Schemes and Relationals in the Relational Datamodel. Information Processing Letters. North Holland 46,4(1993),179-183
[12] Demetrovics J., Thi. V.D. Some Computational Problems Related to the functional Dependency in the Relational Datamodel. Acta Scientiarum Mathematicarum 57, 1 - 4 (1993), 627 - 628.
[13] Demetrovics J., Thi V.D. Armstrong Relation, Functional Dependencies and Strong Dependencies. Comput. and AI. (submited for publication).
[14] Demetrovics J., Thi V.D. Keys, antikeys and prime attributes. Ann. Univ. Scien. Budapest Sect. Comput. 8 (1987), 37 - 54.
[15] Demetrovics J., Thi V.D. On the Time Complexity of Algorithms Related to Boyce-Codd Normal Forms. J. Serdica, the Bulgarian Academy of Sciencies, No.19 (1993), 134 - 144.
[16] Demetrovics J., Thi V.D. Generating Armstrong Relations for Relation schemes and Inferring Functional Dependencies from Relations.
International Jounal on Information Theories and Applications, ITA-93, 1, 4 (1993), 3 - 12.
[17] Demetrovics J., Thi V.D. Some problems concerning Armstrong relations of dual schemes and relation schemes in the relational datamodel. Acta Cybernetica 11, 1-2 (1993), 35 - 47.
[18] Demetrovics J., Thi V.D. Normal Forms and Minimal Keys in the Relational Datamodel. Acta Cybernetica Vol. 11,3 ( 1994), 205 - 215.
[19] Demetrovics J., Thi, V.D. Some results about normal forms for functional dependency in the relational datamodel. Discrete Aplied Mathematics 69 (1996), 61 - 74.
[20] Garey M.R., Johnson D.S Computers and Intractability: A Guide to theory of NP - Completeness. Bell Laboratories. W.H Freeman and Company. San Francisco 1979. 
[21] Gottlob G. Libkin L. Investigations on Armstrong relations dependency inference, and excluded functional dependencies. Acta Cybernetica Hungary IX/4 (1990), 385 - 402.
[22] Jou J.H, Fischer P.C. The complexity of recognizing 3NF relation schemes . IPL 14 (1982), 187 - 190.
[23] * Libkin L. Direct product decompositions of lattices, closures and relation schemes. Discrete Mathematics, North-Holland, 112 (1993), 119-138.
[24] Lucchesi C.L., Osborn S.L. Candidate keys for relations. J. Comput. Syst. Scien 17,2 (1978), 270 - 279
[25] Maier D. Minimum covers in the relational database model. JACM 27,4 (1980), 664 - 674.
[26] * Mannila H., Raiha K.J. Algorithms for inferring functional dependencies from relations. Data and Knowledge Engineering, North - Holland, V. 12, No. 1 ( 1994 ), 83 - 99.
[27] * Mannila H., Raiha K.J. On the complexity of inferring functional dependencies. Discrete Applied Mathematics, North - Holland, 40 ( 1992 ), 237 - 243.
[28] * Thalheim B. The number of keys in relational and nested relational databases. Discrete Applied Mathematics, North - Holland, 40 (1992), 265 - 282.
[29] Thi V.D. Investigation on Combinatorial Characterizations Related to Functional Dependency in the Relational Datamodel. MTA-SZTAKI Tanulmanyok. Budapest, 191 (1986), 1 - 157. Ph.D. dissertation.
[30] Thi V.D. Minimal keys and Antikeys. Acta Cybernetica 7.4 (1986), 361 - 371
[31] Thi V.D. Minimal keys and Antikeys. Acta Cybernetica 7, 4 (1986), 361 - 371.
[32] Thi V.D. Strong dependencies and s-semilattices. Acta Cybernetica 7, 2 (1987), 175 - 202.
[33] Thi V.D. Logical dependencies and irredundant relations. Computers and Artificial Intelligence 7 (1988), 165 - 184.
[34] Thi V.D., Anh N.K. Weak dependencies in the relational datamodel. Acta Cybernetica 10, 1-2 (1991), 93 - 100.
[35] Thi V.D., Thanh L.T. Some remark on Functional Dependencies in the relational Datamodel J. Acta Cybernetica, Hungary Vol. 11, 4 (1994), 345 - 352.
[36] Thi V.D. On the equivalent descriptions of family of functional dependencies in the relational datamodel. J. Computer Science and Cybernetic, Hanoi Vietnam, Vol 11, 4 (1995), 40 - 50.
[37] Thi V.D. Some Computational problems related to normal forms. J. Computer Science and Cybernetic, Hanoi Vietnam, Vol 13, 1 (1997), 53 - 65.
[38] Thi V.D. On the nonkeys. J. Computer Science and Cybernetic, Hanoi Vietnam, Vol 13, 1 (1997), 11 - 15.
[39] Thi V.D. Some results about hypergraph. J. Computer Science and Cybernetic, Hanoi Vietnam, Vol 13, 2 (1997), 8 - 15.
[40] Tsou D.M., Fischer P.C. Decomposition of a relation scheme into Boyce-Codd normal form. SIGACT NEWS 14 (1982), 23 - 29.
[41] Ullman J.D. Principles of database and knowledgw base systems. Computer Science Press, Second Edition (1992).
[42] Yannakakis M., Paradimitriou C. Algebraic dependencies. J. Comp. Syst. Scien. 25 (1982), 2 - 41.
[43] Yu C.T., Johnson D.T. On the complexity of finding the set of candidate keys for a given set of functional dependencies. IPL 5, 4 (1976), 100 - 101.
[44] Zaniolo C. Analysis and design of relational schemata for database systems. Ph. D. UCLA (1976).
[45] Collongues A., Hugues J., Laroche B. MERISE - Phương pháp thiết kế hệ thống thông tin tin học hoá phục vụ quản lí doanh nghiệp (Bản dịch ). Nhà xuất bản Khoa học kĩ thuật, 1994.
[46] Hồ Sĩ Khoa. Các phương pháp xây dựng các mô hình khái niệm dữ liệu
[47] Các tài liệu hướng dẫn sử dụng hệ MEGA
[48] Demetrovics J., Denev. , Pavlov R. Cơ sở toán của khoa học tính toán. Hungary, 1985.
Mục lục 
	Trang
 Chương mở đầu 9	
Chương 2
 Các kiến thức cơ bản về cơ sở dữ liệu 	
2.1. Khái quát về mô hình dữ liệu	
2.2. Các khái niệm cơ bản và hệ tiên đề Armstrong
2.3. Họ phụ thuộc hàm và các mô tả tương đương 
2.4. Các thuật toán liên quan đến các khoá 
2.5. Mối liên hệ giữa quan hệ Armstrong và sơ đồ quan hệ
Chương 3
Các dạng chuẩn 
 và các thuật toán liên quan 	
3.1. Các khái niệm chung
3.2. Dạng chuẩn 2 ( 2NF )
3.3. Dạng chuẩn 3 ( 3NF )
3.4. Dạng chuẩn Boyce - Codd ( BCNF )
3.5. Các thuật toán liên quan
3.6. Dạng chuẩn của các hệ khoá
3.7. Ví dụ
Chương 4 
Các phép toán xử lí bảng
4.1. Các phép toán cơ bản
4.2. Các phép toán khác
4.3. Các ví dụ
Chương 5
 Một số áp dụng mô hình dữ liệu trong các hệ quản trị cơ sở dữ liệu ( QTCSDL) hiện có 	
5.1. Mô tả chung 	
5.2. Những khái niệm cơ bản 	
5.3. Mối quan hệ giữa các thực thể 	
5.4. Các dạng chuẩn trong các hệ QTCSDL hiện có 	
Chương 6
 Một số công đoạn xây dựng 
các dự án thiết kế tổng thể các hệ thống 	 cơ sở dữ liệu hiện nay 	
6.1. Khảo sát thông tin 	
6.2. Thiết kế mô hình dữ liệu 	
6.3. Kiểm soát và chuẩn hoá mô hình 
Chương 7
 Thuật toán và độ phức tạp 
7.1. Khái niệm thuật toán
7.2. Độ phức tạp thuật toán
Tài liệu tham khảo