Chương 3: Phân tích yêu cầu

1. Mô hình hóa 2. Chiến lược phát triển 3. Mô hình nghiệp vụ 4. Mô hình luồng dữ liệu 5. Mô hình hóa logic tiến trình 6. Mô hình hóa dữ liệu (mô hình hình luận lý )

3.1 Mô hình hóa

 Khái niệm  Mục đích  Các thao tác

Khái niệm

 Mô hình là một biểu diễn hình tượng của thực tế. Các mô hình có thể được xây dựng cho các hệ thống hiện có để giúp chúng ta hiểu kỹ hơn về những hệ thống đó. Hoặc cũng có thể xây dựng mô hình cho các hệ thống được đề xuất nhằm tài liệu hóa các yêu cầu nghiệp vụ hoặc thiết kế kỹ thuật.

Khái niệm

 Mô hình hóa chức năng (Process Modeling) với biểu đồ luồng

dữ liệu (Data Flow Diagram - DFD)  Hệ thống làm gì?

 Mô hình hóa chức năng là kỹ thuật dùng để tổ chức và tài liệu hóa cấu trúc và luồng dữ liệu xuyên qua các quá trình của một hệ thống và/hoặc các chức năng được thực hiện bởi các quá trình hệ thống.

 Mô hình hóa dữ liệu (Data Modeling) với biểu đồ quan hệ thực

thể (Entity Relationship Diagram - ERD)  Hệ thống có những dữ liệu nào?

 Mô hình hóa dữ liệu là kỹ thuật dùng để tổ chức và mô hình hóa dữ liệu của một hệ thống nhằm xác định các yêu cầu nghiệp vụ cho một cơ sở dữ liệu. Đôi khi mô hình hóa dữ liệu còn được gọi là mô hình hóa cơ sở dữ liệu.

 Mô hình hóa đối tượng (Object Modeling) với ngôn ngữ mô

hình hợp nhất (Unified Modeling Language - UML)  Cái gì và tại sao? (lôgíc của hệ thống)

Mục đích

 Để hiểu rõ hơn về hệ thống: các cơ hội để đơn giản hóa, tối ưu hóa (Tái cấu trúc quy trình)

 Để liên kết các hành vi và cấu trúc của hệ thống (các yêu cầu nghiệp vụ về: thông tin/dữ liệu và chức năng/quy trình)

 Để trực quan hóa và điều khiển kiến trúc hệ

 Để kiểm soát những rủi ro trong quá trình

thống (thiết kế)

phát triển

Các thao tác

 Lập kế hoạch chiến lược hệ thống

 Các mô hình quá trình nghiệp vụ của tổ chức mô tả các chức

năng nghiệp vụ quan trọng

 Tái cấu trúc quy trình nghiệp vụ

 Các mô hình chức năng “As is” làm đơn giản việc phân tích các

điểm yếu (Hệ thống hiện tại).

 Các mô hình chức năng “To be” làm đơn giản việc cải thiện (Hệ

thống mới được đề xuất).

 Phân tích hệ thống

 Mô hình hóa hệ thống hiện có bao gồm những thiếu sót của nó

(DFD lôgíc)

 Mô hình hóa các yêu cầu lôgíc (các quá trình và luồng dữ liệu

cần có dù hệ thống được xây dựng thế nào – DFD lôgíc) của hệ thống được đề xuất.

 Mô hình hóa các giải pháp kỹ thuật đề cử (DFD vật lý)  Mô hình hóa giải pháp được chọn (DFD vật lý)

2. Chiến lược phát triển hệ thống

 Chiến lược phát triển mô hình (MDD)  Chiến lược phát triển ứng dụng nhanh  Chiến lược cài đặt gói ƯD thương mại

Chiến lược phát triển mô hình

 Model-driven development – một chiến lược phát triển hệ thống nhấn mạnh vào việc vẽ các mô hình hệ thống để trợ giúp việc trực quan hóa và phân tích các vấn đề, xác định các yêu cầu nghiệp vụ, và thiết kế các hệ thống thông tin.

 Mô hình hóa chức năng – một kỹ thuật lấy quá trình làm trung tâm được phổ biến bởi phương pháp luận phân tích và thiết kế hướng cấu trúc, sử dụng các mô hình yêu cầu nghiệp vụ để tạo các thiết kế phần mềm hiệu quả cho một hệ thống.

 Mô hình hóa dữ liệu – một kỹ thuật lấy dữ liệu làm trung tâm để mô hình hóa các yêu cầu dữu liệu nghiệp vụ và thiết kế hệ thống cơ sở dữ liệu phù hợp.

 Mô hình hóa đối tượng – một kỹ thuật kết nối dữ liệu và quá trình thành các cấu trúc duy nhất gọi là các đối tượng. Các mô hình đối tượng là các biểu đồ tài liệu hóa một hệ thống dưới dạng các đối tượng của nó và các tương tác giữa chúng.

Chiến lược phát triển mô hình

 Ưu điểm:

 Kế hoạch dài hạn hơn  Mô hình hóa hệ thống hiện tại và phân tích

yêu cầu trên phạm vi rộng hơn

 Phân tích nhiều giải pháp kỹ thuật khác nhau  Phù hợp với các hệ thống được hiểu rõ

 Nhược điểm:

 Thời gian thực hiện lâu  Sự tham gia thụ động của người sử dụng hệ thống bởi họ không nhìn thấy sản phẩm

 Các yêu cầu trong mỗi giai đoạn cần được xác định đầy đủ: điều này không thực tế và/hoặc không mềm dẻo

Chiến lược phát triển ƯD nhanh

 Rapid application development (RAD) – các kỹ thuật nhấn mạnh sự tham gia của người sử dụng trong việc xây dựng tiến hóa nhanh các bản mẫu hoạt động của một hệ thống để đẩy nhanh quy trình phát triển hệ thống đó.

 RAD được dựa trên việc xây dựng các bản mẫu, những

bản mẫu này tiến hóa thành các hệ thống hoàn thiện  Một bản mẫu là một mô hình hoạt động hoặc mô hình

biểu diễn với tỷ lệ nhỏ hơn của các yêu cầu của người sử dụng hoặc của một thiết kế đề xuất cho một hệ thống thông tin

 Một time box là một khoảng thời gian không thể mở rộng, thường là 60-120 ngày mà một hệ thống đề cử phải được đưa vào hoạt động. Các cải thiện sẽ được thực hiện trong những phiên bản ra đời sau đó.

Ưu – nhược điểm của RAD

 Ưu điểm:

 Xử lý được các yêu cầu không ổn định hoặc không chính

xác của người sử dụng

 Sự tham gia chủ động của người sử dụng vào việc xây

dựng sản phẩm thực tế: làm tăng sự nhiệt tình, hỗ trợ của họ

 Phát hiện sớm các lỗi hoặc sự bỏ sót: trong quá trình kiểm

thử và thay đổi bản mẫu

 Làm giảm rủi ro nhờ lặp đi lặp lại việc làm bản mẫu

 Nhược điểm:

 Tăng chi phí thời gian sống để hoạt động, hỗ trợ và bảo trì

hệ thống (hoạt động và sửa chữa liên tục)

 Quá trình phân tích vấn đề ngắn ngủi có thể đem lại hệ quả

là việc giải quyết những vấn đề sai

 Ngăn cản người phân tích xem xét các kỹ thuật khác thay vì chỉ xét tới kỹ thuật đang được dùng để làm bản mẫu

Chiến lược cài đặt gói ƯD thương mại

 Commercial application package – một ứng dụng phần mềm có thể mua về và tùy biến cho phù hợp các yêu cầu nghiệp vụ của một số lượng lớn các tổ chức hoặc một ngành nghề cụ thể. Một thuật ngữ khác là hệ thống thương mại dùng ngay (commercial off-the-shelf (COTS) system)

Ưu – nhược điểm của COST

 Ưu điểm

 Cài đặt nhanh hệ thống mới (nhiều chức năng tương tự nhau giữa các tổ chức khác nhau, không cần thiết phải xây dựng từ đầu)

 Không cần các chuyên gia và nhân sự cho việc phát triển  Chi phí phát triển thấp (nhưng tốn chi phí tùy biến và cài đặt)  Người bán chịu trách nhiệm về việc cải thiện phần mềm và sửa lỗi

 Nhược điểm

 Phụ thuộc vào người bán  Việc tùy biến/nâng cấp trong tương lai rất tốn kém  Một hệ thống thương mại dùng ngay hiếm khi phản ánh được hệ

thống lý tưởng được tự phát triển

 Phải thay đổi các quy trình nghiệp vụ hiện tại để phù hợp với hệ

thống thương

3.2 Mô hình nghiệp vụ (Biểu đồ phân rã chức năng - BFD)

1.Khái niệm 2.Biểu đồ phân rã chức năng 3.Các dạng biểu đồ phân rã chức năng 4.Xác định phạm vi hệ thống

1. Khái niệm

 Mô hình hóa nghiệp vụ là mô tả chức năng

nghiệp vụ của tổ chức và những mối quan hệ bên trong giữa các chức năng đó

 Mô hình hóa nghiệp vụ thể hiện ra dưới dạng biểu đồ phân rã nghiệp vụ có thứ bậc đơn giản

Hệ thống thực hiện những công việc gì?

2. Biểu đồ phân rã chức năng

 Khái niệm  Ý nghĩa  Ký pháp sử dụng  Nguyên tắc xây dựng  Đặt tên chức năng

Khái niệm

 Chức năng nghiệp vụ là tập hợp các công việc mà tổ chức cần thực hiện trong hoạt động của mình

 Khái niệm chức năng:

 Là khái niệm mức logic (tên công việc và

mối liên hệ giữa chúng);

 Chức năng đó làm như thế nào, khi nào, ai làm là khái niệm vật lý (chưa xét đến)

Ý nghĩa

 Giới hạn phạm vi của hệ thống cần phải

phân tích.

 Tiếp cận hệ thống về mặt logic nhằm

 Phân biệt các chức năng và nhiệm vụ

làm rõ các chức năng mà hệ thống thực hiện để phục vụ cho các bước phân tích tiếp theo.

của từng bộ phận trong hệ thống, từ đó lọc bỏ những chức năng trùng lặp, dư thừa.

Ý nghĩa

 Hiểu cơ cấu tổ chức và giúp cho quá trình

khảo sát tiếp theo

nghiên cứu)

 Xác định vùng (miền) nghiên cứu (phạm vi

 Cho thấy vị trí các công việc trong toàn hệ

 Là cơ sở để từ đó xây dựng kiến trúc của

thống, tránh sự trùng lặp

hệ chương trình

Các mức độ phân cấp chức năng

 Một lĩnh vực hoạt động (area of

activities)

 Một hoạt động (activity)  Một nhiệm vụ (task)  Một hành động (action)

Lưu ý

 BFD không có tính động  BFD chỉ cho thấy các chức năng mà không thể hiện trình tự xử lý của các chức năng đó  BFD không chỉ ra sự trao đổi thông tin giữa các chức năng.

=> BFD thường được sử dụng làm mô hình chức năng trong bước đầu phân tích.

Kí pháp sử dụng

 Ký pháp:

TÊN CHỨC NĂNG

 Liên kết giữa các chức năng nghiệp vụ:

Tên CN

Tên CN2

Tên CN1

Tên CNn

Ví dụ

Biểu đồ chức năng dạng chuẩn

IBM (1960-1970)

Chức năng xử lý thông tin Chứng từ (trên giấy) Danh sách (in trên giấy)

Tệp ghi đĩa từ Lưu (trên băng từ) Lưu (tại chỗ)

Nguyên tắc phân rã chức năng

 Phân rã chức năng từ mức gộp đến mức chi tiết  Mỗi chức năng được phân rã phải là một bộ phận thực sự tham gia thực hiện (tính thực chất)

 Chức năng ở mức cuối (chức năng lá) phải thực

 Việc thực hiện tất cả các chức năng ở mức dưới trực tiếp phải đảm bảo thực hiện được chức năng ở mức trên (tính đầy đủ)

hiện được

 Không nên phân rã chức năng quá 6 mức

Nhập a, b, c

Giải pt bậc 2

Xet a => tính delta

tìm x

Nhập a, b, c

Tìm nghiệm

 Khai báo a, b, c  cin a, b, c  if a= 0

Xuất kết quả

pt=> ptb1

 Else

 If delta > 0 thì pt có 2 n0 x1, x2  If delta = 0 thì pt có 1 n0 x0  If delta < 0 thì pt vo nghiệm}

 { Lập delta=b2 - 4ac

Đặt tên chức năng

 Mỗi chức năng có một tên duy nhất  Tên chức năng phải là một mệnh đề động từ gồm một

động từ và bổ ngữ

 tên phải thể hiện khái quát các chức năng con của nó, phản ánh được thực tế nghiệp vụ mà nó thực hiện

 Ví dụ: chức năng “lập đơn hàng”, “bảo trì kho”.

Mô tả chức năng lá

Các chức năng lá trong biểu đồ cần mô tả trình tự và

cách thức tiến hành nó bằng lời và có thể sử dụng biểu đồ hay một hình thức nào khác. Mô tả thường bao gồm các nội dung sau: - Tên chức năng - Các sự kiện kích hoạt (khi nào? Cái gì dẫn đến? điều kiện gì?) - Quy trình thực hiện - Yêu cầu giao diện cần thể hiện (nếu có) - Dữ liệu vào (các hồ sơ sử dụng ban đầu) - Công thức (thuật toán) tính toán sử dụng (nếu có) - Dữ liệu ra (các báo cáo hay kiểm tra cần đưa ra) - Quy tắc nghiệp vụ cần tuân thủ

Ví dụ: Mô tả chức năng lá “kiểm tra khách hàng”

không và thời gian nợ có quá hạn hợp đồng không

2.2 Nếu không …

Khi khách hàng đến người ta mở sổ khách hàng để xem có khách hàng nào như trong đơn hàng không (tên gọi, địa chỉ…). 1. Nếu không có, đó là khách hàng mới. 2. Ngược lại là khách cũ thì cần tìm tên khách hàng trong sổ nợ, và xem khách có nợ không? 2.1 Nếu có thì nợ bao nhiêu, có quá số nợ cho phép

Xác định các chức năng

 Ở mức cao nhất của nghiệp vụ, chức năng chính có thể là

một trong các loại sau:  Sản xuất sản phẩm.  Cung cấp dịch vụ (bán hàng, bảo dưỡng).  Quản lý tài nguyên (tài sản, nguồn nhân lực, con

người…).

 Khi đã xác định được loại mà nó thuộc vào thì sẽ đặt tên

cho chức năng cao nhất này.

 Tiếp theo, để xác định các chức năng con thì từ chức năng chính, ta đặt nó trong chu kỳ sống gồm các giai đoạn:  Xác định nhu cầu.  Mua bán.  Bảo hành, bảo dưỡng.  Thanh lý hoặc chuyển nhượng.

3. Các dạng biểu diễn mô hình nghiệp vụ

 Dạng công ty

 Dạng chuẩn Sơ đồ phân cấp hình cây

Dạng bảng gồm nhiều dòng, được xếp thành các cột. Mỗi cột thể hiện một mức phân rã

Khách hàng

1. Bộ phận kế hoạch

1.1 Lập kế hoạch chiến lược

1.2 Lập kế hoạch hàng năm

Thông tin

Mua hàng

Bán hàng

2. Bộ phận tài chính

2.1 Lập kế hoạch ngân sách

2.2 Quản lý thu chi

2.3 Tổng hợp báo cáo

Ví dụ: Hệ thống gửi xe Xét khách hàng

Khách

Gởi xe

Lấy xe

Sự cố

Ghi TT xe

Nhận vé xe

Trả vé xe

Thanh toán

Ví dụ: Hệ thống gửi xe Xét khách hàng

1. Gởi xe

2. Lấy xe

1.1 Thông tin xe 1.2 Nhận vé

3. Sự cố

2.1 Trả vé 2.2 Thanh toán

Ví dụ: ATM Xét khách hàng

Khách

Đăng ký thẻ

Sử dụng

CC thông tin Nhận thẻ

KTMK

Các thao tác

Sự cố

4. Xác định phạm vi hệ thống

 Người ta thường sử dụng các ma trận  Có 2 ma trận cơ bản nhất là:

chức năng

 Ma trận yếu tố quyết định thành công và

 Ma trận thực thể-chức năng

Ma trận yếu tố quyết định thành công và chức năng

 Gồm có:

 Dòng là các chức năng  Cột là yếu tố quyết định thành công hay

 Ô giao giữa dòng và cột sẽ ghi chữ E

không

 Mục đích: Xác định chức năng của hệ

thống

(essential- Quyết định) hay D (desirable- Không quyết định)

Ma trận yếu tố quyết định thành công và chức năng

Các yếu tố quyết định thành công

Các bộ phận chức năng

rộng trường thụ

Nguyên liệu đủ số lượng, đảm chất bảo về lượng

Mở thị tiêu 10%

Kiểm soát chi phí, không tăng giá

1. Bộ phận kế hoạch

E

D

2. Bộ phận tài chánh

E

D

3. Bộ phận lao động tiền lương

D

4. Bộ phận quản lý cơ điện

5. Bộ phận quản lý công nghệ

D

6. Bộ phận quản lý chất lượng

D

7. Bộ phận tiếp thị

E

8. Bộ phận tiêu thụ

E

9. Bộ phận nguyên liệu

E

10. Bộ phận hành chánh

11. Bộ phận bảo vệ an ninh

HTTT cần xây dụng hỗ trợ các nhiệm vụ chức năng này

Ma trận thực thể-chức năng

 Gồm có:

 Dòng là: các thực thể; các chức năng  Cột là yếu tố quyết định thành công hay

 Ô giao giữa dòng và cột sẽ ghi chữ R

không

 Mục đích: Xác định nghiệp vụ cần

thiết gắn với từng chức năng

(read) hay C (create) hay U (sửa, xóa, thêm)

Các thực thể

Một ma trận thực thể và chức năng

1. Kế hoạch chiến lược

2. Kế hoạch hàng năm

3. Kế hoạch điều hành

4. Phiếu xuất vật tư

5. Phiếu nguyên vật liệu

6. ….

7. Nguyên liệu

8. Hợp đồng mua nguyên liệu

…………………….

Các chức năng nghiệp vụ

C

1.1 Lập kế hoạch chiến lược

C

1.2 Lập kế hoạch hàng năm

C

1.3 Lập kế hoạch tác nghiệp

C

1.4 Xét cấp phát vật tư phụ tùng

8.1 Tổ chức ký kết hợp đồng tiêu thụ

8.2 Tổ chức cung ứng sản phẩm

8.2 Quản lý kho thành phẩm

R

9.1 Tổ chức vùng nguyên liệu

R

C

9.2 Ký kết hợp đồng mua nguyên liệu

…………………

Cho biết mối liên kết giữa chức năng và thực thể dữ liệu, phát hiện sai sót

3.4 Mô hình luồng (dòng) dữ liệu

1. Mô hình hóa tiến trình nghiệp vụ 2. Biểu đồ luồng dữ liệu mức ngữ cảnh 3. Biểu đồ luồng dữ liệu (DFD) 4. Phân rã biểu đồ luồng dữ liệu 5. Phát triển các biểu đồ luồng dữ liệu

cho một ứng dụng

1. Mô hình hóa tiến trình nghiệp vụ

 Mô hình hóa tiến trình nghiệp vụ

(modeling bussiness process) là sự biểu diễn đồ thị các chức năng của quá trình

 Mục đích là thu thập việc thao tác,

lưu trữ và phân phối dữ liệu giữa các bộ phận trong một hệ thống

1. Mô hình hóa tiến trình nghiệp vụ

 Biểu đồ luồng dữ liệu mức ngữ cảnh  Biểu đồ luồng dữ liệu logic của hệ thống hiện thời, của hệ thống mới  Biểu đồ luồng dữ liệu vật lý của hệ thống hiện thời, của hệ thống mới

2. Biểu đồ ngữ cảnh (context diagram)

 Là biểu đồ biểu diễn tổng quan hoạt

động của hệ thống

 Xác định phạm vi của hệ thống  Diễn tả toàn bộ hệ thống bằng một ô

xử lý

 Không có kho dữ liệu

Ví dụ 1

VD 2

3. Biểu đồ luồng dữ liệu data flow diagram (DFD)

 Quy tắc chung  Quy tắc vẽ tiến trình  Quy tắc vẽ kho dữ liệu  Quy tắc vẽ tác nhân  Quy tắc vẽ luồng dữ liệu

3.1 Một số khái niệm  Luồng dữ liệu  Kho dữ liệu  Tiến trình  Tác nhân 3.2 Quy tắc vẽ

3.1 Một số khái niệm

 Một trong những công cụ hữu hiệu của giai đoạn

phân tích (is one of the tools used in the analysis phase).

 Sử dụng DFD để biểu diễn một cách linh hoạt

các thực thể ngoài, các chức năng, luồng dữ liệu và các kho dữ liệu

 Khái niệm DFD:

 Luồng dữ liệu  Kho dữ liệu  Tiến trình  Tác nhân

(data flow) (data store) (process) (actor)

 Biểu đồ luồng dữ liệu gồm có:

Phân loại

 DFD luận lý (logic) diễn tả hệ thống

làm gì mà không diễn tả điều đó làm như thế nào

 DFD vật lý (physical) diễn tả hệ

thống sẽ được thực hiện như thế nào, trong đó đề cập đến phần cứng, phần mềm, tập tin và con người

Công dụng

 Diễn tả hoạt động của hệ thống hiện

hành

 Phương tiện trao đổi giữa người phân

tích và người sử dụng

 Dùng để xây dựng tài liệu đặc tả thiết

kế xử lý hệ thống

Ký hiệu Demarco/Yourdon

Tác nhân ngoài

Luồng dữ liệu

Tiến trình

Kho dữ liệu

Ký hiệu Gane/Sarson

Tác nhân ngoài

Luồng dữ liệu

Tiến trình

Kho dữ liệu

Luồng dữ liệu (data flow)

 Định nghĩa

Luồng dữ liệu (data flow) là các dữ liệu di chuyển từ một vị trí này đến vị trí khác trong hệ thống trên một vật mang nào đó

 Kí hiệu

Mũi tên có chiều chỉ hướng dữ liệu di chuyển và tên của dữ liệu được ghi ở trên nó. Tên luồng dữ liệu phải là 1 mệnh đề danh từ và phải thể hiện được sự tổng hợp của các phần tử dữ liệu riêng biệt chứa trong đó

Tên luồng dữ liệu

Kho dữ liệu (data store)

 Định nghĩa

Kho dữ liệu (data store) là vị trí lưu trữ dữ liệu Một kho dữ liệu có thể biểu diễn các dữ liệu được lưu trữ ở nhiều vị trí khác nhau (máy tính khác nhau, thư mục …)

 Kí hiệu

Hình chữ nhật khuyết 1 cạnh (trái hoặc phải). Đầu không khuyết dùng 1 ô ghi số hiệu kho, bên trong hình chữ nhật ghi tên kho. Tên kho là một mệnh đề danh từ

D1

Tên kho dữ liệu

D2

Tiến trình (process)

 Định nghĩa

n

Tiến trình (process) là một hay một số công việc hoặc hành động có tác động lên các dữ liệu (di chuyển, thay đổi, lưu trữ, phân phối. n Quá trình xử lý dữ liệu trong 1 hệ thống thường gồm nhiều tiến trình khác nhau

Tên tiến trình

- Tiến trình vật lý: nếu có chỉ ra con người hay phương tiện

Tên tiến trình thực thi chức năng đó

- Tiến trình logic: ngược lại với Tiến trình vật lý

 Kí hiệu

Người/ phương tiện thực hiện

Hình chữ nhật góc tròn, có 2 hoặc 3 phần

 phần trên ghi số hiệu của tiến trình  phần dưới ghi tên tiến trình (người + phương tiện)

Tên tiến trình phải là 1 mệnh đề gồm động từ và bổ ngữ

Tác nhân (actor)

 Định nghĩa

Tác nhân (actor) là một người, một nhóm người, bộ phận, một tổ chức hay 1 hệ thống khác nằm ngoài phạm vi này và có tương tác với nó về mặt thông tin (nhận hay gởi dữ liệu)

 Kí hiệu

Hình chữ nhật dùng để kí hiệu một tác nhân, bên trong ghi tên tác nhân Tên tác nhân phải là 1 danh từ

Tên Tác nhân

3.2 Quy tắc vẽ - Quy tắc chung

 Các cái vào của 1 tiến trình cần khác

cái ra

 Các đối tượng trong một biểu đồ phải

có tên duy nhất  Mỗi tiến trình có 1 tên duy nhất  Tác nhân, kho dữ liệu có thể vẽ lặp lại  Các luồng dữ liệu đi vào 1 tiến trình đủ để tạo thành các luồng dữ liệu đi ra

Quy tắc vẽ tiến trình

 Không có tiến trình chỉ có thông tin ra

mà không có thông tin vào

 Không có tiến trình chỉ có thông tin vào

mà không có thông tin ra

 Đối tượng chỉ có thông tin ra thì chỉ có thể là tác nhân (nguồn) & ngược lại

Quy tắc vẽ kho dữ liệu

 Không có luồng dữ liệu từ kho dữ liệu

này đến kho dữ liệu khác

 Dữ liệu không thể di chuyển trực tiếp từ một tác nhân đến một kho dữ liệu & ngược lại

M

Quy tắc vẽ tác nhân

 Dữ liệu không thể di chuyển trực tiếp

đến 1 tác nhân hay ngược lại

 Dữ liệu phải qua tiến trình và luồng

dữ liệu

M

Quy tắc vẽ luồng dữ liệu

 Một luồng dữ liệu không thể quay

lại nơi mà nó vừa đi khỏi

 Một luồng dữ liệu không thể tự tách

 Một luồng dữ liệu đi vào một kho

nghĩa là kho dữ liệu được cập nhật

 Một luồng dữ liệu đi ra khỏi một

kho nghĩa là kho dữ liệu được đọc

Info A

4. Phân rã biểu đồ luồng dữ liệu

4.1 Định nghĩa 4.2 Đảm bảo sự cân bằng giữa hai mức kề

nhau

4.3 Biểu đồ luồng dữ liệu mức sơ cấp 4.3 Lưu ý

4.1 Định nghĩa

Quá trình phân nhỏ mỗi tiến trình của một biểu đồ luồng dữ liệu thành một (hay nhiều) biểu đồ luồng dữ liệu mới (nếu có thể) gọi là phân rã biểu luồng dữ liệu đã cho

Một phần của DFD hệ thống đặt bữa ăn

Phân rã 1.0 Tiến trình 1.0 nó chuyển yêu cầu của khách thành 4 đầu ra khác nhau. Nhƣ vậy tiến trình 1.0 là đối tƣợng để phân rã. Giả sử ta có thể phân rã tiến trình 1.0 thành một biểu đồ mới nhƣ sau

4.2 Đảm bảo sự cân bằng giữa hai mức kề nhau

Khi phân rã một tiến trình của một biểu đồ

luồng dữ liệu thành một biểu đồ ở mức sau thì phải bảo toàn:  Luồng dữ liệu vào & ra  Các tác nhân ngoài  Kho dữ liệu

đơn hàng

Đơn hàng và phiếu thanh toán

Phiếu T.Toán

4.2 Đảm bảo sự cân bằng giữa hai mức kề nhau Tại mức thấp nhất của biểu đồ luồng dữ liệu, có thể thêm các luồng dữ liệu mới để biểu diễn dữ liệu được bổ sung: đó là các thông báo lỗi hay điều khẳng định nào đó. Luồng dữ liệu bổ sung được biểu diễn bằng mũi tên đức nét

4.3. Lưu ý

Những qui tắc để dừng quá trình phân rã:

Khi một tiến trình là 1 quyết định hay 1 một tính toán đơn giản, một thao tác dữ liệu (đọc, cập nhật, tạo, ghi, xóa) Khi người dùng hệ thống nhận ra được mọi công việc hoặc nhà phân tích đã lập được tài liệu chi tiết để thực hiện các nhiệm vụ phát triển hệ thống một cách tuần tự Khi mỗi luồng dữ liệu không cần chia nhỏ hơn để chỉ ra rằng các dữ liệu khác nhau đều đã được quản lí Khi đã chỉ ra được mỗi nhiệm vụ nghiệp vụ, hoặc một giao dịch, thông tin hiển thị và báo cáo là những luồng dữ liệu đơn, hay những tiến trình tách biệt ứng với mỗi lựa chọn trên thực đơn mức thấp nhất của hệ thống

5. Phát triển biểu đồ luồng dữ liệu cho một ứng dụng

 Hướng cấu trúc cổ điển (top – down)

 Hướng cấu trúc hiện đại (sự kiện)

Hướng cấu trúc cổ điển (top – down)

DFD logic

 DFD logic + [Con ng + CSCV]1 => DFD

vật lý 1

 DFD logic + [Con ng + CSCV]2 => DFD

vật lý 2

 DFD logic + [Con ng + CSCV]3 => DFD

vật lý 3

Hướng cấu trúc hiện đại (sự kiện)

Ví dụ Biểu đồ luồng dữ liệu mức 0

Thông tin về xe

Thông tin phản hồi

Vé xe ra

KHÁCH

Vé xe vào

HỆ THỐNG QUẢN LÝ TRÔNG GỬI XE

Thông tin sự cố

Biên bản sự cố

Biểu đồ DFD ngữ cảnh

Biểu đồ luồng dữ liệu mức i (i>=1)

 Biểu đồ mức i được phân rã từ biểu đồ

mức i -1

• Thay thế tiến trình được xét của biểu đồ luồng

dữ liệu mức i-1 bằng các tiến trình con tương ứng

• Giữ nguyên toàn bộ các tác nhân ngoài, các kho dữ liệu (nếu có) & các luồng dữ liệu liên quan đến tiến trình được xét trong biểu đồ i-1 • Thêm vào các luồng dữ liệu giữa các tiến trình

con, giữa tiến trình và kho dữ liệu

 Cách phân rã:

Biểu đồ DFD mức 1

Tiến trình duy nhất của biểu đồ ngữ cảnh đƣợc thay bằng 3 tiến trình mới tƣơng ứng trong hình sau:

Phát triển biểu đồ DFD mức 2…

Nhận xe

Phát triển biểu đồ DFD mức 2…

Trả xe

Phát triển biểu đồ DFD mức 2…

Giải quyết sự cố

So sánh DFD với biểu đồ tiến trình (flowchart)

 Các quá trình

 Các quá trình song song

tuần tự

 Thể hiện luồng dữ liệu xuyên suốt hệ thống

 Thể hiện luồng điều khiển trình tự

Vẽ các biểu đồ DFD cho hệ thống sau

 Quản lý điểm môn học của sinh viên

trường đại học A

 Yêu cầu:

 DFD mức ngữ cảnh  DFD mức 1

Tóm tắt bài toán

 Kho dữ liệu:

 Tiến trình:

 Thông tin sinh viên  Thông tin môn học  Điểm theo môn học

 Nhập thông tin sv  Nhập điểm  Xem điểm

 Luồng dữ liệu:  Tiến trình  Tác nhân  Kho dữ liệu

 Tác nhân:  Sinh viên  Quảnt lý

Tiến trình xem điểm

 Tính điểm

 Công thức (môn có BTL, môn không có

BTL)

 Xem điểm

 Đưa kết quả ra bảng tạm

xem

Hệ thống

Sinh Sinh viên viên

Quản Quản lý lý

Thong tin sv

Quản lý

2.0

Nhập tt

3.0

Sinh viên

Nhập điểm

mh sv

1.0

Xem điểm

Điểm mh sv

Thong tin sv Thong tin sv

3.5 Mô hình hóa logic tiến trình

1. Mô hình hóa với cấu trúc tiếng Anh 2. Mô hình hóa với cấu trúc bảng quyết định 3. Mô hình hóa với cấu trúc cây quyết định 4. Nhận xét 5. Mô hình hóa logic thời gian

 Biểu đồ luồng dữ liệu đủ tốt để xác định các tiến trình, nhưng nó không chỉ ra đầy đủ sự logic bên trong của mỗi tiến trình.

 Ngay đối với các tiến trình ở biểu đồ

luồng dữ liệu sơ cấp cũng chưa chỉ ra tất cả nội dung xử lý của nó.

 Cần có thêm mô hình.

1. Mô hình hóa logic với tiếng Anh cấu trúc

 Sử dụng một số từ tiếng Anh để diễn tả các tiến trình cho gọn và dễ hiểu  Chỉ sử dụng các động từ read, write,

print, sort, move, meger, add, multiply, divide

 Sử dụng một số cấu trúc điều khiển cơ bản như: điều kiện, chọn, lặp

READ (…) SELECT CASE CASE 1 (…) DO (…) CASE 2 (….) DO (….)

BEGIN IF IF (. …..) THEN …… ELSE …… READ (. . . . .) END IF

READ (…..) WHILE …… DO BEGIN IF IF (……)

THEN

DO READ (. ….) BEGIN IF IF (….) THEN …… ELSE ….. END IF UNTIL (……)

….. ELSE ……… END IF END DO

Ví dụ

Tiến trình 1.0: cập nhật hàng nhập mới

DO READ (bản ghi phiếu giao hàng tiếp theo) FIND matching (bản ghi thẻ-kho tương ứng) ADD (SL từ bản ghi phiếu giao hàng) TO (SL tồn

kho trên bản ghi thẻ kho) UNTIL END OF FILE

Giải pt bậc 2

Chia thành 3 tiến trình sau:  Nhập dữ liệu  Tính delta  Xuất kết quả

read (a); read (b); read (c); Tính deleta Delta = b*b – 4*a*c; Tính x1, x2 Write << x1; Write << x2;

do While dk;

Tiến trình 2.0: Cập nhật hàng xuất sử dụng

DO READ (bản ghi hàng tồn kho tiếp theo) FIND matching (bản ghi thẻ kho tương ứng) SUBSTRACT (SL sử dụng từ bản ghi mục hàng)

FROM (SL tồn trên bản ghi thẻ kho)

UNTIL END OF FILE

Tiến trình 3.0: lập đơn hàng

DO READ (bản ghi thẻ kho tiếp theo) IF (số lượng tồn kho) IS LESS THAN (số dự

trữ tối thiểu) THEN

(lập đơn hàng) ENDIF UNTIL END OF FILE

Tiến trình 4.0: tạo hóa đơn thanh toán

READ (ngày hiện thời) SORT (bản ghi phiếu giao) BY date DO READ (bản ghi phiếu giao tiếp theo) IF (date IS 30 OR GREATER THEN (ngày hiện tại)) THEN (lập giấy thanh toán) UNTIL END OF FILE

2. Mô hình hóa logic với Bảng quyết định

 Bảng quyết định là một biểu đồ của

một tiến trình logic

 Cấu trúc:

 Điều kiện, miền giá trị  Các hành động  Các quy tắc

S: Nhân viên ăn lƣơng; H: Nhân viên làm việc theo giờ

Ví dụ

ĐIỀU KIỆN

Quy tắc

Loại nhân viên

Giờ làm việc

<40

=40

>40

HÀNH ĐỘNG

Trả lương cơ bản

Tính lương theo giờ

Tính giờ làm thêm

Ghi báo cáo vắng

Rút gọn bảng ?

Ví dụ

Điều kiện

Loại biến

delta

Giá trị

<>0

Hành động

Thông báo

Tính delta

Tính x

Tính x1, x2

3. Mô hình hóa logic với cây quyết định

 Là kỹ thuật đồ thị để mô tả hay lựa chọn tình huống như một loạt các nút hay rẽ nhánh theo sự kiện

 Điểm quyết định (decision point): Nút – Hình

tròn

 Các hành động: Hình elip  Đường đi: Nối từ điểm quyết định đến hành

động – Đường thẳng, có ghi giá trị

 Cách biểu diễn:

Ví dụ

Đúng

Trả lƣơng cơ bản

LCB

Sai

Đúng

Trả lƣơng cơ bản; BC vắng mặt

Làm việc <40g

Sai

Đúng

Trả lƣơng giờ

Làm việc =40g

Sai

Trả lƣơng giờ; Trả giờ làm thêm

Đúng

Tuổi <60

Sai

Đúng

Còn công tác

Nghỉ hƣu

A là nam

Sai

Đúng

Tuổi <55

4. Nhận xét

Tiêu chuẩn

Tiếng Anh cấu trúc

Bảng quyết định

Cây quyết định

thứ 2

thứ 3

tốt nhất

Xác định điều kiện và hành động

Tốt nhất

thứ 3

tốt nhất

Hình thành điều kiện và hành động theo trình tự

Kiểm tra sự nhất quán và đầy đủ

thứ 3

tốt nhất

5. Mô hình hóa logic thời gian

 Sử dụng với các ứng dụng mà thời gian là nhân tố cực kỳ quan trọng  Là biểu đồ quan trọng khi PTTK theo

hướng đối tượng

 Có 2 loại:

 Biểu đồ chuyển trạng thái  Bảng chuyển trạng thái

Biểu đồ chuyển trạng thái

 Mô tả điều kiện tồn tại cho một tiến trình hoặc một thành phần của hệ thống  Ký pháp:

 Hình chữ nhật: Trạng thái  Hình mũi tên: Sự kiện

Ví dụ

C1. Bật nút ON

-Bật đèn -Hiện thông báo

1. Nghỉ

2. Bán hàng

-Tắt đèn

C2. Bật nút OFF

Nguyên tắc chuyển sang biểu đồ chuyển trạng thái

 Xác định mọi trạng thái có thể hay

trạng thái bắt đầu

 Vẽ HCN biểu diễn trạng thái  Nối các trạng thái bằng những mũi

tên

 Ghi sự kiện  Liệt kê các hành động

Bảng chuyển trạng thái

 Dòng: Biểu diễn trạng thái  Cột: Biểu diễn sự kiện  Ô: Chứa 1 trong 3 khả năng

 Trạng thái mới  Sự kiện bị bỏ qua  Không thể xảy ra

3.6 Mô hình hóa dữ liệu

1. Mô hình hóa dữ liệu 2. Các phần tử của biểu đồ quan hệ thực

thể (ERD)

3. Xây dựng biểu đồ quan hệ thực thể

(ERD)

4. Xây dựng biểu đồ dữ liệu quan hệ

(RDM)

5. Từ điển dữ liệu

1. Mô hình hóa dữ liệu

 Diễn tả và quản lý dữ liệu  Khái niệm  Từ mô hình dữ liệu tới cài đặt CSDL  Vai trò của biểu đồ quan hệ thực thể

Diễn tả và quản lý dữ liệu (phương tiện sơ đẳng)

 Mã hóa

 Sử dụng số hoặc ký tự để đặt tên cho

 Từ điển dữ kiệu

một đối tượng nào đó  VD: masv; tcth36aqn

 Là tư liệu tập trung về tên gọi của các

đối tượng

 Xem lại Chương 2

Khái niệm

 Là mô hình để tổ chức và tài liệu hóa

dữ liệu của hệ thống

 Kỹ thuật này xác định các yêu cầu đối

với CSDL

 Có hai biểu đồ:

 Biểu đồ thực thể quan hệ  Biểu đồ dữ liệu quan hệ

Từ mô hình dữ liệu tới cài đặt CSDL

 ERD (Entity Relationship Diagram): là mô

 RDM (Relational Data Model): là bản thiết kế việc cài đặt của mô hình ERD trong môi trường CSDL quan hệ (độc lập phần mềm) [Thiết kế]

 Sơ đồ quan hệ: là sơ đồ thể hiện cách thức mô hình dữ liệu được cài đặt với hệ quản trị CSDL

hình khái niệm của các thực thể dữ liệu, các thuộc tính và các quan hệ trong hệ thống [Phân tích]

Vai trò của biểu đồ quan hệ thực thể

 CSDL = Dữ Liệu + Quan Hệ  ERD được dùng để mô hình hóa dữ

liệu và quan hệ của chúng

 ERD là biểu diễn đồ họa của mô hình

dữ liệu khái niệm

 ERD là độc lập tài nguyên (không gắn

với môi trường CSDL nào)

2. Các phần tử của biểu đồ quan hệ thực thể (ERD)

 Thực thể  Thuộc tính  Mối quan hệ

Thực thể (entity)

một đối tượng khái niệm mà ta cần thu thập và lưu trữ dữ liệu về nó

 Là nhóm các thuộc tính tương ứng với

 Là tập các thể hiện của đối tượng mà nó biểu diễn. Thể hiện của thực thể là một thực thể cụ thể

 Có các loại: Con người; Vật thể; Sự kiện;

 Trong ERD thực thể được ký hiệu là “hình

Khái niệm

chữ nhật”

Mỗi thực thể tương ứng với một bảng dữ

liệu trong CSDL của hệ thống

Ví dụ

Thực thể cụ thể

 Khách hàng Nguyễn A  Đơn hàng số 1999

Thực thể Trừu tượng

 Khoa Công Nghệ  Tài khoản số 687955

Thuộc tính (property hay attribute)

 Mỗi thực thể bao gồm nhiều thông tin, mỗi thông tin là một thuộc tính của thực thể, ứng với một trường trong bảng dữ liệu tương ứng

nào đó của một thực thể

 Là giá trị dùng để mô tả một khía cạnh

 Ví dụ: Kiểu thực thể khách hàng được mô tả bằng các kiểu thuộc tính: tên, địa chỉ, số tài khoản  Tên: Nguyễn A  Địa chỉ: 12 Hùng Vương, Quảng Ngãi  Số tài khoản: 123456789

Hai thông số cơ bản

 Kiểu dữ liệu (Data type): là một

thuộc tính xác định kiểu dữ liệu có thể lưu trữ được

 Phạm vi (Domain): Xác định các giá trị mà thuộc tính đó có thể chứa

Các loại thuộc tính  Thuộc tính khóa:

 Thể hiện cách tham khảo duy nhất  Gồm một hay nhiều thuộc tính  Nếu khóa chỉ gồm một kiểu thuộc tính duy nhất

thì gọi thuộc tính đó là một định danh (identifier). Tên định danh được viết với các tiền tố ID, #, SH, Mã

 Đóng vai trò kết nối các thực thể  Với thực thể này là thuộc tính khóa, với thực thể

khác là thuộc tính mô tả

 Thuộc tính mô tả:  Mô tả đối tượng  Không phải khóa  Thuộc tính liên kết:

Mối quan hệ

 Một quan hệ là tài liệu hóa một liên kết (association) giữa một, hai hay nhiều thực thể

 Ví dụ:

 Khách hàng A đặt mua các mặt hàng 36

và 78

 Anh Sơn là học trò của thầy Phan

Các liên kết

 Một kiểu liên kết (association type) là một

tập hợp các liên kết có cùng ý nghĩa  Một kiểu liên kết được định nghĩa giữa

nhiều kiểu thực thể. Số các kiểu thực thể tham gia vào kiểu liên kết được gọi là số ngôi của kiểu liên kết

nghĩa của liên kết

 Tên của kiểu liên kết là động từ phản ánh ý

Giá trị ứng số trong các quan hệ

 1..1 một và chỉ một  0..1 không hay một  m..n từ m tới n  0..* từ không tới nhiều  *..0 từ nhiều tới không  1..* từ một tới nhiều

sinhvien

 Có 1 masv

(masv, tensv, …)

 Có 1 masv

1-1

Lophp

(mamonhp,

1-n

masv, malop, …)

Lop (malop, tenlop,…)

 Có nhiều malop

 Chỉ có 1 malop

3. Xây dựng biểu đồ quan hệ thực thể

 Các bước xây dựng mô hình hóa dữ

liệu logic

 Trình tự xây dựng ERD  Quy tắc xây dựng ERD  Các kiểu ký hiệu ERD

Các bước xây dựng mô hình hóa dữ liệu logic

 Mô hình dữ liệu ngữ cảnh  Mô hình dữ liệu dựa trên khóa  Mô hình dữ liệu với các thuộc tính đầy đủ  Mô hình dữ liệu được chuẩn hóa Nguyên tắc  Đơn giản  Không dư thừa  Linh động và dễ điều chỉnh

Trình tự xây dựng ERD

 Xác định các thực thể  Xác định các quan hệ giữa các thực

thể

 Hoàn thiện các quan hệ với các số

yếu tố

 Xây dựng mô hình

Xác định các thực thể - Cách 1  Thông tin liên quan tới giao dịch chủ yếu

của hệ thống  Hóa đơn bán hàng thuộc về quá trình bán

hàng

 Đơn đặt hàng thuộc về quá trình mua hàng  Thông tin liên quan tới thuộc tính hoặc tài

 Thông tin đã được khái quát dưới dạng thống kê liên quan tới lập kế hoạch hay quản lý  Bảng chấm công  Lịch trực

nguyên của hệ thống  Khách hàng, nhà cung cấp  Kho hàng

Đặt câu hỏi ghi nhận thông tin về thực thể

 Cái gì mà ta cần lưu thông tin về

nó?

 Cái gì là cốt yếu trong hệ thống?  Cái gì mà ta nói về nó trong hệ

thống?

 Có gì mà có thể dùng để phân biệt sự kiện của tập thực thể này so với tập thực thể khác?

Xác định các thực thể - Cách 2

 Dựa vào bảng mô tả hệ thống (hiện tại, tương lai), xem xét các danh từ có trong đó xem có phải là thông tin cần lưu trữ không?

 Ví dụ: chương trình quản lý kho hàng

 Theo dõi hàng tồn trong một kho nào đó tại một thời

điểm nào đó

 Theo dõi chi tiết xuất nhập tồn của mỗi loại hàng

hóa

 in chi tiết xuất nhập vật tư cho mỗi khách hàng

Vật tư, Kho hàng; Khách hàng

Các tập thực thể là:

Xác định mối quan hệ

 Quan hệ giữa các thực thể thường diễn tả bởi các động từ, nó xác định sự tác động giữa các thực thể với nhau

 Nếu lưu thông tin về tập thực thể này trong tập thực thể kia thì sẽ xuất hiện một quan hệ để tạo mối liên kết

 Quan hệ giữa hai thực thể là gián tiếp thì không

cần xây dựng mối quan hệ giữa chúng

 Cần chú ý:

Ví dụ: Hệ thống quản lý tồn kho gồm

Xác định các thực thể chi tiết  Quan hệ giữa danh mục tồn kho và danh mục

nhà cung cấp

 Quan hệ n-n vì :

mỗi loại sản phẩm trong DM tồn kho có thể có hơn một nhà cung cấp trong DM nhà cung cấp

 Tách quan hệ n-n thành các quan hệ 1-n: Tạo

danh mục đặt hàng có quan hệ 1-n với hai thực thể trên

Quy tắc xây dựng ERD

 Mỗi thực thể phải có tên  Mỗi thực thể phải có định danh  Mỗi thể hiện không thể là thực thể  Mỗi quan hệ phải có tên  Số ứng số trong các quan hệ phải rõ

ràng

Các kiểu ký hiệu ERD

Thuộc tính 1

Thuộc tính 4

Thực thể 1

Thực thể 2

Thuộc tính 2

Thuộc tính 3

Thuộc tính 2

Thuộc tính 3

Các kiểu ký hiệu ERD

0..*

DM K.hàng

Chi tiết K.hàng

mua

0..*

Bao

0..*

Bao

DM bán hàng

DM tồn kho

Chi tiết bán hàng

gồm

0..*

Chi tiết đặt hàng

0..*

DM bảo hành

DM nhà CC

DM đặt hàng

Mô hình thực thể/ liên kết (Entity/ Association Model)

 Là mô hình dữ liệu do PP. Chen đề xuất

năm 1976

 Là mô hình mô tả tập hợp dữ liệu được

 E/A xuất phát với ba khái niệm cơ bản:

dùng trong hệ thống theo cách gom cụm

Thực thể; Liên kết; Thuộc tính

 Ví dụ: Các thông tin về tên, tuổi, chiều cao, cân nặng, địa chỉ … được gom cụm với nhau xung quang một người

Biểu diễn đồ họa các khái niệm của mô hình E/A - Chen’s

ứng số

0..*

Giao nộp

Đơn hàng ID. đơn hàng Ngày đơn hàng

Khách hàng ID. Khách hàng Tên khách hàng

Kiểu liên kết

Kiểu thực thể Hình chữ nhật 2 ngăn: Ngăn 1: tên thực thể Ngăn 2: danh sách các thuộc tính Tên thực thể là danh từ

Sở hữu

0..*

Người

Căn hộ

0..*

ID. Người tên

0..1

ID. Căn hộ Địa chỉ

thuê

Mô hình thực thể / liên kết mở rộng

 Do xu thế hướng đối tượng tác động nên từ năm 1980 người ta đã đưa thêm một số điểm mở rộng vào mô hình E/A

 Các điểm mở rộng

 Các kiểu thuộc tính đa trị  Các kiểu thuộc tính phức hợp  Các kiểu thực thể con

4. Xây dựng biểu đồ dữ liệu quan hệ (RDM)

 Mô hình quan hệ được đề xuất và phát triển

vào năm 1970 bởi E.F.Codd

 RDM (Relational Data Model) là công cụ tiếp theo của ERD dùng để mô hình hóa dữ liệu nhằm mục đích xác định danh sách các thuộc tính của các thực thể

 Xác định các thuộc tính cần thiết  Chuẩn hóa các thực thể  Xác định các mqh giữa các thuộc tính với các

thực thể

 Xây dựng mô hình RDM

 Quy trình xây dựng RDM:

Xác định các thuộc tính (nhắc lại)

 Dựa vào các yếu tố:

 Từ thông tin thu thập được, ta lập

danh sách các thuộc tính cho các thực thể trong ERD. Phân biệt các thuộc tính khóa

 Sự hiểu biết về hệ thống  Quá trình thu thập thông tin

Phân tích và chuẩn hóa dữ liệu

 Chuẩn bị mô hình dữ liệu cho việc cài đặt thành một CSDL. Không dư thừa, mềm dẽo, dễ thích ứng

 Là kỹ thuật tổ chức các thuộc tính dữ liệu sao cho chúng được nhóm thành các thực thể không dư thừa, ổn định:  Không có sự lặp lại thuộc tính ở các bảng

khác nhau, trừ khóa

 Không chứa các thuộc tính có giá trị là

kết quả được tính từ các thuộc tính khác

Khái niệm phụ thuộc hàm

 Phụ thuộc hàm đơn trị:

1 khách hàng

 Phụ thuộc hàm đa trị:

 1 giá trị của khóa trong bảng xác định được 1 giá trị cho các thuộc tính khác  VD: Mỗi mã khách hàng chỉ có duy nhất

 1 giá trị của khóa trong bảng ứng với nhiều giá trị của các thuộc tính khác  VD: Mỗi mã sinh viên có nhiều mã môn

học đi kèm

Ví dụ: mã khách hàng, tên khách hàng, ngày, sl …

Chuẩn hóa dạng 1 - 1NF

 Các thuộc tính nào có thể xuất hiện

mã khách hàng, ngày, sl …

nhiều lần cùng với 1 thực thể thì loại bỏ

 Các thuộc tính bị loại bỏ cùng với mã khách hàng, tên khách hàng

khóa của thực thể ban đầu tạo thành tập thực thể mới

Chuẩn hóa dạng 2 – 2NF

 Các thuộc tính trong thực thể phải phụ

thuộc hàm vào toàn bộ khóa

 Đối với các thực thể chỉ có 1 trường là khóa

 Đối với các thực thể có khóa bao gồm 2

thì đương nhiên thõa mãn chuẩn 2

thuộc tính trở lên, nếu trong đó có những thuộc tính phụ thuộc hàm đơn trị vào một bộ phận của khóa thì tách các thuộc tính đó ra thành 1 thực thể với khóa là một bộ phận khóa của thực thể ban đầu mà nó phụ thuộc hàm

Chuẩn hóa dạng 3 – 3NF

 Tách các thuộc tính phụ thuộc hàm đơn trị vào thuộc tính không phải là khóa, đưa chúng vào thực thể mới có khóa chính là thuộc tính mà nó phụ thuộc hàm

 Tất cả các thuộc tính phải phụ thuộc đơn trị vào khóa và không phụ thuộc hàm đơn trị vào bất kỳ thuộc tính nào không phải là khóa trong thực thể

Ví dụ

Số hóa đơn: ….. Ngày: …… Khách hàng: ….. Mã số KH: … Địa chỉ: ……

Th.tiền

Mã hàng

Tên hàng

Đơn giá

Số lượng

Quá trình chuẩn hóa

Số hóa đơn, ngày, mã khách hàng, tên khách hàng, địa chỉ, mã hàng, tên hàng, đơn giá, số lượng, thành tiền

Số hóa đơn, ngày, mã khách hàng, tên khách hàng, địa chỉ; Số hóa đơn, mã hàng, tên hàng, đơn giá, số lượng

Số hóa đơn, ngày, mã khách hàng; mã khách hàng, tên khách hàng, địa chỉ; Số hóa đơn, mã hàng, đơn giá, số lượng; mã hàng, tên hàng;

Số hóa đơn, ngày, mã khách hàng mã khách hàng, tên khách hàng, địa chỉ Số hóa đơn, mã hàng, đơn giá, số lượng mã hàng, tên hàng

Các thực thể

Hóa đơn (số hóa đơn, mã khách hàng,

Khách hàng (mã khách hàng, tên, địa chỉ) Đơn hàng (số hóa đơn, mã hàng, số lượng,

ngày)

Mặt hàng (mã hàng, tên hàng)

đơn giá)

Mô hình ERD

Kết hợp các tập thực thể chung

đặt hàng)

Không thỏa dạng chuẩn 3 vì:  Đơn hàng (số đơn hàng, mã khách hàng, ngày Địa chỉ giao phụ thuộc hàm vào Mã số khách hàng là thuộc tính không phải khóa  Đơn đặt hàng (số đơn hàng, tình trạng, địa chỉ của thực thể

giao)  Gộp lại, ta có:

 Bước 1: Đơn hàng (số đơn hàng, mã khách

hàng, ngày đặt hàng, tình trạng, địa chỉ giao)

 Bước 2: Đơn hàng (số đơn hàng, mã khách

hàng, ngày đặt hàng, tình trạng)

 Xét 2 tập thực thể:

Xác định các mối quan hệ

Đơn hàng bán (số hiệu đơn hàng, mã khách hàng, ngày đặt hàng) Khách hàng (mã khách hàng, tên khách hàng, địa chỉ) Dòng đơn hàng (số hiệu đơn hàng, mã hàng, số lượng, đơn giá) Mặt hàng (mã hàng, tên hàng) Giao nhận (số hiệu giao nhận, mã khách hàng, ngày giao) Dòng giao hàng (số hiệu giao nhận, số hiệu đơn hàng, mã hàng, số

lượng giao)

Ma trận thực thể/khóa

Đơn hàng

Khách hàng

Mặt hàng

Giao nhận

Thực thể thuộc tính khóa

Dòng đơn hàng

Dòng giao nhận

Số hiệu đơn hàng

Mã số khách hàng

Mã hàng