›
›

Bài giảng Hệ thống thông tin quản lý - Chương 3: Khảo sát, Phân tích, Thiết kế hệ thống - ThS. Nguyễn Anh Hào

ppt 92 trang phuongnguyen 30
Download
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Hệ thống thông tin quản lý - Chương 3: Khảo sát, Phân tích, Thiết kế hệ thống - ThS. Nguyễn Anh Hào", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

  • pptbai_giang_he_thong_thong_tin_quan_ly_chuong_3_khao_sat_phan.ppt

Nội dung text: Bài giảng Hệ thống thông tin quản lý - Chương 3: Khảo sát, Phân tích, Thiết kế hệ thống - ThS. Nguyễn Anh Hào

  1. Ch.III 1 HỆ THỐNG THÔNG TIN QUẢN LÝ Ch.3: Khảo sát, Phân tích, Thiết kế hệ thống Tháng 9-2007 ThS. Nguyễn Anh Hào
  2. Ch.III Phương pháp luận PT-TK-HT 2 Thế giới ý niệm Tư duy logic để tìm giải pháp Hệ thống củ Phân tích Hệ thống mới đang làm gì Sẽ phải làm gì Yêu cầu đối với Hệ thống là gì Thiếtkế Khảo sát Khảo Hệ thống Hệ thống củ đang hoạt động mới sẽ vận hành Bối cảnh như thế nào như thế nào chung giữa vấn đề và giải pháp Thế giới thực
  3. Ch.III 1.Khảo sát hiện trạng 3  Khảo sát hiện trạng là 1 quá trình khám phá cách mà hệ thống đã được thiết kế và vận hành trong tổ chức, làm bộc lộ các quan hệ nội tại giữa các thành phần trong hệ thống; để từ đó hiểu được hệ thống đang hoạt động như thế nào.  Khảo sát hiện trạng là một quá trình tổng hợp thông tin mang tính chất hệ thống, không thể dựa vào lời phát biểu của 1 nhân viên trong tổ chức, vì • Mỗi nhân viên chỉ nhìn hệ thống theo một lĩnh vực chuyên môn mà anh ta/ cô ta đang phụ trách, do đó các phát biểu thường không bộc lộ được các ràng buộc tổng thể của hệ thống • Các phát biểu của nhiều người thường có mâu thuẩn nhau do mỗi người có cách nhìn khác nhau về hệ thống hiện tại
  4. Ch.III Nội dung khảo sát 4 1. Tìm hiểu tổ chức • Mục đích, mục tiêu, các kế hoạch ngắn và dài hạn • Vai trò của hệ thống đang khảo sát trong tổ chức 2. Tìm hiểu các quy trình giữa các bộ phận trong hệ thống • “Công việc”: quy trình-thủ tục, đầu vào, kết quả • “Nguồn lực”: khối lượng, phương tiện (facilities), nhân lực 3. Tìm hiểu thông tin – dữ liệu của quy trình • Quy định, hướng dẫn, tiêu chuẩn • Dòng dữ liệu, forms/reports (thông tin gì, khi nào, tại sao, ) 4. Hệ thống thông tin quản lý trên máy tính hiện có • Phạm vi, mức độ và cách nó trợ giúp users thực hiện công việc • Vai trò (roles) của các users trong hệ thống. • Phần mềm, mạng máy tính, thiết bị,
  5. Ch.III Phương pháp khảo sát 5  Truyền thống 1. Phỏng vấn cá nhân, nhóm (interviews) 2. Phiếu thăm dò (questionaires) 3. Quan sát người sử dụng 4. Phân tích tài liệu  Hiện đại 1. “Tương tác” : Prototyping 2. “Cải cách” : Business Process Reengineering (BPR)
  6. Ch.III Phỏng vấn cá nhân (interviews) 6 Phỏng vấn: tiếp xúc, hỏi vài người để lấy thông tin. • Phỏng vấn những người nhân viên: Công việc của họ, thông tin mà họ cần để làm việc, cách xử lý thông tin, • Phỏng vấn những người quản lý: Xu huớng của tổ chức, các chính sách đang và sẽ áp dụng, mong muốn thay đổi, những ý kiến đánh giá về hệ thống hiện tại, Ưu điểm • Có cơ hội hỏi thêm về những gì vừa mới biết Khuyết điểm • Có thể có mâu thuẩn ý kiến riêng giữa các cá nhân • Tốn nhiều thời gian nếu cần phỏng vấn nhiều người
  7. Ch.III Phỏng vấn nhóm (group interviews) 7 Phỏng vấn nhiều người chủ chốt cùng một lúc (qua cuộc họp, hội thảo) Ưu điểm • Ít tốn thời gian hơn phỏng vấn từng người • Gia tăng sự trao đổi về các “findings” giữa những người tham gia phỏng vấn • Hạn chế bớt sự mâu thuẩn ý kiến cá nhân Khuyết điểm: khó thu xếp cho cuộc phỏng vấn • Do khoảng cách về kiến thức chuyên môn • Sắp xếp thời điểm và địa điểm họp cho nhiều người cùng một lúc • Do quan hệ giữa các cá nhân
  8. Ch.III Phiếu thăm dò (questionaires) 8 Gửi câu hỏi khảo sát đến nhiều người. Câu hỏi khảo sát phải hết sức rõ ràng, dể hiểu và dể trả lời đối với đa số. Ưu điểm • Rẻ hơn các loại phỏng vấn, và qua thống kê trên số lượng lớn phiếu thăm dò quay về có thể nhận được thông tin tương đối khách quan. Khuyết điểm • Không có cơ hội để hỏi thêm ! • Không chắc chắn ai là tác giả, và mức độ thông tin (trả lời) chính xác đến cở nào !! • Số phiếu quay về có thể không như mong muốn (quá ít)
  9. Ch.III So sánh Interviews và Questionaires 9 Tính chất Interviews Questionaires Giàu thông tin Cao T.bình - Thấp Thời gian Có thể rất lâu Thấp – T.bình Chi phí Có thể cao vừa phải Tìm hiểu sâu thêm Tốt Giới hạn Độ tin cậy Cao. Đã biết rõ người Không cao. Không xác được phỏng vấn. định được tác giả. Mức độ cộng tác Người được phỏng Không rõ các cam kết vấn cùng tham gia giải quyết vấn đề và cam kết thực hiện Người tham dự Số lượng giới hạn, đáp Số lượng lớn, đáp ứng ứng tốt không tốt.
  10. Ch.III Quan sát người nhân viên 10 Để biết họ thường làm gì, và ứng xử thế nào cho công việc, đồng thời để đánh giá mức độ hiệu quả của các quy trình và các công cụ hổ trợ cho các công việc. Ưu điểm • Kiểm chứng được công việc thực tế • Ước lượng được cường độ công việc (workload) Khuyết điểm • Sự quan sát có thể không khách quan, do người sử dụng thay đổi thói quen hàng ngày. • Tốn nhiều thời gian ngồi quan sát.
  11. Ch.III Thu thập tài liệu 11 Phân tích các tài liệu (văn bản) mô tả hệ thống, các tiêu chuẩn, yêu cầu cho hệ thống. • Tham khảo các văn bản quy trình đang sử dụng. • Bản thiết kế hệ thống. • Các mẫu nhập liệu (forms), các báo cáo (reports). Ưu điểm: • Có nhiều thông tin chi tiết • Có thể khái quát được toàn bộ hệ thống Khuyết điểm: • Tài liệu có thể không đúng vì bị lạc hậu so với thực tế
  12. Ch.III Prototyping 12 Sau khi hiểu sơ lược yêu cầu, phân tích viên chuyển chúng thành ‘demo’ cho người sử dụng, và qua quá trình xem xét sửa đổi, bản demo được hoàn chỉnh dần từ tổng quát đến chi tiết – để phân tích viên hiểu rõ chi tiết yêu cầu. Ưu điểm • Giúp cho phân tích viên hiểu đúng yêu cầu • Giúp cho người sử dụng hiểu khả năng của sản phẩm Khuyết điểm • Khó thống nhất quan điểm sử dụng từ nhiều users • Khó diễn tả các xử lý tiềm ẩn bên trong hệ thống
  13. Ch.III Business Process Reengineering 13 Pp.truyền thống mang tính chất “cải tiến” hệ thống, dùng CNTT để hổ trợ mô hình và nghiệp vụ đã có sẵn. Pp. “cải cách”: Thay đổi tiến trình kinh doanh chính để tạo ra sự đột phá bằng cách tái cấu trúc lại các tiến trình kinh doanh (Business Process Reengineering) để tận dụng ưu thế của phương pháp mới hoặc công nghệ mới (E-commerce !). • Thay đổi mô hình và nghiệp vụ để ứng dụng CNTT • Phá bỏ các nguyên tắc lạc hậu trì trệ trong tổ chức • Quan điểm: "Nếu một tổ chức được xây dựng lại từ đầu, thì nó cần phải hoạt động như thế nào?" • Ví dụ: Nhà sách “Amazon.com” bán sách điện tử thay cho các quyển sách giấy không có chi phí lưu kho, không có quầy giao dịch và trưng bày, mỡ rộng kinh doanh, nhưng phải đối mặt với vấn đề “copy rights”.
  14. Ch.III Đánh giá sơ lược sau khảo sát 14 1. Nhận xét và kết luận sơ lược sau khi khảo sát • Mức độ công việc (workload): Tần suất, khối lượng cao ở đâu, khi nào. • Hiệu quả xử lý: nghẽn cổ chai, xung khắc thông tin (conflict), hiệu quả của các báo cáo • Chi phí xử lý: Các tiến trình tương tự nhau có bị lặp lại ở nhiều nơi không ? 2. Nhận định sơ lược về cơ hội và thách thức để khắc phục, cải tiến hoặc cải cách để định hướng tập trung phân tích 1. Nội bộ của tổ chức. 2. Môi trường bên ngoài.
  15. Ch.III 2. Phân tích hệ thống 15  Sau khi khảo sát và thu thập thông tin mô tả cho hệ thống hiện tại, người phân tích viên cần phải hệ thống hóa lại những gì đã biết để • Kiễm tra phát hiện thiếu sót hoặc mâu thuẩn trong cách hiểu biết của mình • Chia sẽ hiểu biết của mình với nhóm công tác  Thuy nhiên, việc này chỉ thực sự hiệu quả khi các đặc trưng quan trọng nhất của hệ thống được làm nổi bật (sáng tỏ) cho dể hiểu, các chi tiết không quan trọng phải được loại bỏ.  Ngôn ngữ tự nhiên thường gây hiểu lầm, và không trợ giúp cho việc khái quát hóa nên người ta thay thế chúng bằng các mô hình (models).
  16. Ch.III Mô hình 16  Mô hình là cách diễn tả các đặt trưng quan trọng nhất của hệ thống theo một quan điểm phân tích nào đó, và lược bỏ các chi tiết không quan trọng. Trong hệ thống thông tin, mô hình là một hệ thống lược đồ sử dụng các ký hiệu, hình ảnh gợi nhớ để diễn tả ý, thay cho các phát biểu dài dòng, như lược đồ DFD, ERD, UMLs.  Mô hình có 3 đặc tính cơ bản: 1. Ngữ pháp (notations): là các quy tắc sử dụng các ký hiệu hình thức cho mô hình, để loại bỏ những mô tả vô lý hoặc tối nghĩa. 2. Ngữ nghĩa (semantics): là nội dung (ý) cần diễn tả lại. 3. Ngữ cảnh (context): là kiến thức chung giữa người xem và người tạo ra mô hình để nội dung ngữ nghĩa của mô hình được truyền đạt trọn vẹn cho người đọc. Vì lý do này, một lược đồ cho hệ thống chỉ được tạo ra chỉ từ một quan điểm phân tích nào đó.
  17. Ch.III Lược đồ dòng dữ liệu - Data Flow Diagram 17  DFD là lược đồ sử dụng 4 ký hiệu cùng với các quy tắc vẽ để diễn tả các dòng dữ liệu di chuyển trong hệ thống. Process : Là một hành động hoặc một hệ thống con xử lý trên dữ liệu (biến đổi, lưu trữ hoặc phân phối dữ liệu). Data store : Là bộ phận dùng để lưu trữ dữ liệu, như tập tin, hồ sơ, CSDL, Source/Sink : Là thành phần phát sinh dữ liệu (source) cho hệ thống, hoặc tiêu thụ dữ liệu (sink) từ hệ thống. Data Data flow : dòng dữ liệu cơ bản của lược đồ, chỉ ra 1 nội dung dữ liệu (không đổi) được gởi từ đâu và đi đến đâu.  Quy ước • Dùng Động từ để đặt tên cho Process • Dùng Danh từ để đặt tên Data store, Source, Sink và Data flow
  18. Ch.III Dòng dữ liệu 18  Dòng dữ liệu được tạo thành từ các vật mang dữ liệu (ví dụ: chứng từ, hóa đơn, phiếu nhập xuất kho, ) qua các xử lý trung gian biến đổi dữ liệu theo các quy tắc quản lý của tổ chức (business rules).  Các dòng vật chất, tiền tệ, dịch vụ, thông tin quan trọng trong hệ thống là nguồn gốc làm phát sinh dòng dữ liệu trên lược đồ. Dữ liệu trên dòng dữ liệu Dòng dữ liệu của tiến trình Tên Tuổi hrs/week tính lương trong tổ chức Smith 25 44 Chen 42 35 Lập bảng bảng chấm Lưu bảng bảng chấm Tính lương chấm công công chấm công công
  19. Ch.III Dòng dữ liệu 19  Các dòng dữ liệu trong hệ thống có kiễm soát như công ty, doanh nghiệp đều phải tuân thủ các quy tắc quản lý (business rules); vì vậy các quy tắc quản lý (và quy trình) của hệ thống là cơ sở để thiết lập các dòng dữ liệu trong lược đồ DFD.  Ví dụ: Bộ phận giao dịch nhận đơn đặt hàng từ khách hàng, kiểm tra đơn đặt hàng để hiệu chỉnh nếu cần, sau đó lưu vào hồ sơ đặt hàng. Đơn đặt 1.0 Đơn đặt 2.0 Đơn đặt Khách hàng hàng Nhận đơn hàng Kiễm tra hàng Các hiệu chỉnh Đơn đặt 3.0 hàng Lưu HS D1 Hồ sơ đặt hàng
  20. Ch.III Lược đồ ngữ cảnh 20  Lược đồ ngữ cảnh (context diagram) là lược đồ DFD được dùng để mô tả khái quát toàn bộ các dòng dữ liệu đi từ nguồn (SOURCE) vào hệ thống và đi từ hệ thống ra đến đích (SINK) mà không quan tâm đến các xử lý biến đổi và lưu trữ dữ liệu bên trong hệ thống.  Lược đồ ngữ cảnh cho biết hệ thống cần chuyển giao dữ liệu gì và nó nhận được dữ liệu gì từ môi trường bên ngoài.  Ví dụ: nhà hàng Hoosie Burger có một hệ thống “đặt hàng các món ăn” được mô tả tổng quát theo các quy tắc quản lý như sau: hệ thống sẽ nhận yêu cầu từ khách hàng, in biên lai thanh toán tiền cho khách hàng, chuyển yêu cầu cho nhà bếp thực hiện và in các báo cáo quản lý cho người quản lý nhà hàng vào cuối ngày.
  21. Ch.III Lược đồ ngữ cảnh 21 Ngữ cảnh của hệ thống nhận đặt món ăn của Hoosie Burger KHÁCH HÀNG NHÀ BẾP 0 Yêu cầu Hệ thống Yêu cầu Biên lai Nhận đặt Những gì nằm Món ăn bên ngoài ranh giới này chỉ có Trong lược đồ này, toàn Báo cáo quản thể là source bộ hệ thống chỉ được vẽ lý hoặc sink bằng 1 xử lý duy nhất, không có data store. NGƯỜI QUẢN LÝ
  22. Ch.III Quy tắc phân rã 22 Ngữ cảnh / DFD mức n DFD mức n+1 Một lược đồ DFD mức n+1 là lược đồ DFD mô tả chi tiết hơn cho một xử lý trong lược đồ DFD mức n DFD mức n+2
  23. Ch.III Quy tắc vẽ lược đồ 23 1. Nếu một đối tượng chỉ có outputs, chắc chắn đối tượng đó phải là source. Tương tự, nếu một đối tượng chỉ có inputs, nó phải là sink. 2. Một xử lý phải có cả inputs lẫn outputs. Không có xử lý nào chỉ có inputs mà không có outputs, hoặc ngược lại. 3. Một dataflow là một mũi tên phải có nhãn và có duy nhất một hướng để chỉ rõ nơi đi và nơi đến của dữ liệu. Do đó, nếu một nội dung dữ liệu được chuyển đi và nhận về giửa hai đối tượng thì nó phải được vẽ bằng 2 mũi tên (theo 2 hướng ngược nhau). 4. Không có dòng dữ liệu trực tiếp giữa các data store, source, sink; vì đây là những đối tượng “thụ động”; để di chuyển dữ liệu giữa các đối tượng này cần phải có ít nhất một xử lý của hệ thống. 5. Không có dòng dữ liệu rẽ nhánh (hoặc gộp) có nội dung (nhãn) khác nhau. Nội dung dữ liệu ở các nhánh phải giống y như nhau. 6. Không có dòng dữ liệu trực tiếp đi từ một xử lý đến chính nó (vì một xử lý không cần gửi dữ liệu cho chính nó).
  24. Ch.III Quy tắc cân bằng 24 1. Nếu một xử lý i (mức n) được phân rã thành một lược đồ DFD mức n+1 cho xử lý này thì nội dung dữ liệu vào ra của xử lý i phải được bảo toàn (không thêm/bớt). 2. Nếu dòng dữ liệu ở mức n là dạng tổng quát (như “thông tin khách hàng”, ) trong khi các dòng dữ liệu ở lược đồ DFD mức n+1 là dạng chi tiết (“tên khách”, “địa chỉ”, ) thì phải sử dụng từ điển dữ liệu để liên kết chúng với nhau. A Process i X A, B Process i X Mức n Mức n A X A X DFD n+1 DFD n+1 B B
  25. Ch.III Lược đồ dòng dữ liệu mức 0 (DFD-0) 25 Hệ thống đặt món ăn của nhà hàng Hosier Burger được mô tả như sau: 1. Chức năng “tiếp nhận và xử lý yêu cầu gọi món”: nhận yêu cầu từ khách hàng, chuyển yêu cầu gọi món đến nhà bếp, phát sinh biên lai thu tiền cho khách, tạo ra dữ liệu ‘hàng đã bán’ và ‘hàng xuất kho’ cho 2 chức năng ‘cập nhật hồ sơ hàng bán’ và ‘cập nhật hồ sơ hàng tồn kho’. 2. Cập nhật hồ sơ hàng đã bán: cập nhật hồ sơ hàng đã bán theo đúng khuông mẫu dữ liệu của hồ sơ này. 3. Cập nhật hồ sơ hàng tồn kho: Cập nhật hồ sơ hàng tồn kho theo đúng khuông mẫu của hồ sơ này. 4. Phát sinh báo cáo quản lý: lấy dữ liệu hàng đã bán mỗi ngày từ hồ sơ hàng đã bán và dữ liệu hàng xuất kho mỗi ngày từ hồ sơ hàng tồn kho để in báo cáo cho người quản lý nhà hàng.
  26. Ch.III DFD-0 của hệ thống đặt món ăn 26 KHÁCH HÀNG 1.0 NHÀ BẾP Yêu cầu 1 Nhận và xử lý yêu cầu Yêu cầu gọi món Biên lai 2 gọi món 5 3.0 2.0 3 4 Cập nhật hồ Cập nhật hồ Dữ liệu Dữ liệu Hàng xuất sơ hàng tồn sơ hàng đã Hàng đã Hàng xuất kho Hàng đã bán kho kho bán bán Decoupling 2.0, 4.0 D2 Hồ sơ tồn kho D1Hồ sơ hàng bán 4.0 Lượng hàng xuất Lượng hàng đã Phát sinh mỗi ngày báo cáo bán mỗi ngày Báo cáo NGƯỜI quản lý quản lý QUẢN LÝ
  27. Ch.III DFD-1 của xử lý 1.0 27 1.1 1.3 Yêu cầu Tiếp nhận Yêu cầu Chuyển yêu Yêu cầu cầu thành 1 yêu cầu từ yêu cầu gọi gọi món 5 khách hàng món ăn Should be decomposed Yêu cầu Yêu cầu Yêu cầu 1.2 1.4 1.5 Phát sinh Phát sinh dữ Phát sinh dữ 2 biên lai thu liệu hàng đã liệu hàng đã Biên lai tiền bán xuất Hàng đã bán Hàng xuất kho 3 4
  28. Ch.III Ứng dụng của DFD 28 1. Phát hiện dòng dữ liệu dư thừa • Dữ liệu có đưa vào Datastore nhưng không được dùng (không có Process nào lấy ra) 2. Phát hiện nhiều Processes cùng cập nhật 1 dữ liệu • Có thể sinh ra không nhất quán (và sai lệch xử lý) nếu có thay đổi trên 1 trong các process này 3. Phát hiện kém hiệu quả trong xử lý (inputs, outputs) • Inputs nhiều hơn mức cần thiết để tạo ra outputs • Dư thừa xử lý (vd: inputs = outputs). 4. Để thiết kế Forms, Reports, CSDL và Chương trình. • Dùng DFD làm phương tiện trao đổi ý kiến giữa những người phát triển hệ thống
  29. Ch.III Sử dụng DFD để phân tích BPR (IBM 1993) 29 Hiện trạng SALEPERSON SALEPERSON 1.0 5.0 Request Log Create Contract Request Quote Letter 2.0 Check Documentation Documentation Credit- worthiness 3.0 4.0 Documentation Modify Documentation Determine Rate Loan Interest Status Agreement Rate D2 CREDIT FILES D1 INTEREST FILES
  30. Ch.III Sử dụng DFD để phân tích BPR (IBM 1993) 30 Phân tích (a) Emp.1 Emp.2 Emp.3 Emp.4 Emp.5 Process 1.0 Process 2.0 Process 3.0 Process 4.0 Process 5.0 Req.1 Contract 1 Process 1.0 Process 2.0 Process 3.0 Process 4.0 Process 5.0 Req.2 Contract 2 (b) Emp.1 Process 1.0 Process 2.0 Process 3.0 Process 4.0 Process 5.0 Contract 1 Emp.2 Process 1.0 Process 2.0 Process 3.0 Process 4.0 Process 5.0 Contract 2
  31. Ch.III Sử dụng DFD để phân tích BPR (IBM 1993) 31 Kết quả Contract SALEPERSON Rate 1.0 D1 INTEREST FILES Request Process contract Status D2 CREDIT FILES Supporting data SPECIALISTS
  32. Ch.III Processing Logic 32  DFD trợ giúp phân rã hệ thống, nhưng tên của các xử lý không đủ mô tả các xử lý.  Processing Logic trợ giúp mô tả rõ hơn cấu trúc xử lý bên trong Process dựa trên các Business Rules (quy tắc quản lý) của tổ chức. 1. Structured English: mô tả ngắn gọn về các quy tắc xử lý bằng ngôn ngữ tự nhiên (tiếng Việt hoặc tiếng Anh) 2. Decision Table và Decision Tree: thể hiện các quy tắc xử lý “IF THEN ” bằng bảng hoặc lưu đồ rẽ nhánh (tree) trong trường hợp có nhiều quy tắc xử lý phức tạp 3. Data Dictionary: là từ điển dữ liệu giải thích ý nghĩa của từng thành tố dữ liệu được các processes sử dụng hoặc tạo ra.
  33. Ch.III Structured English 33 Tên LoạiHĐ Tuổi hrs/week Smith H 25 44 Chen S 42 35 1.1 1.2 1.3 Lập bảng bảng chấm Lưu bảng bảng chấm Tính lương chấm công công chấm công công Process logic 1.1 Process logic 1.2 Process logic 1.3 Nơi: Tổ sản xuất Nơi: P.Tổ chức Nơi: P.Kế toán Xử lý: Cuối tuần Xử lý: Khi nhận BCC Xử lý: Khi đủ BCC Ghi số giờ làm của Tập họp, vào sổ tất cả IF Tg > 40 THEN mỗi người thành bảng các bảng chấm công, Trả = 40 * mức chấm công (BCC) nộp chuyển cho P.Kế toán. Trả + = (Tg-40)*mức*1.2 P.Tổ chức ELSE Trả = Tg * mức Structured English
  34. Ch.III Decision Table 34 Decision Table thay thế Structured Enlish nhằm thể hiện các luận lý phức tạp. ĐIỀU KIỆN QUY TẮC ÁP DỤNG (1) Employee type S H H H (2) Hours worked - 40 CÁC XỬ LÝ Pay base salary  Calculate hourly wage    Calculate Over time  Produce absence report  S: Salary H: Hours
  35. Ch.III Decision Tree 35 Decision tree minh họa cấu trúc chọn hành động xử lý theo điều kiện bằng lưu đồ rẽ nhánh. Salary 1 Pay base salary Hourly 40 Chú thích 1. Type of employee ? Pay hourly wage; 2. Hours work ? Pay overtime wage
  36. Ch.III Data dictionary 36  Là một mô tả cho từng phần tử dữ liệu được dùng trong hệ thống. Thông thường, từ điển dữ liệu được lập thành một bảng gồm các cột như ví dụ sau: Tên gọi Ý nghĩa Cấu trúc dữ liệu Nguồn gốc Bảng chấm Ghi số giờ công của Tên, tuổi, số giờ Process 1.1 công từng nhân viên công trong tuần Tiền lương Tiền công theo giờ Mức chuẩn + phụ Process 1.3 công trong tháng trội Mức chuẩn Mức lương trả trong Giờ công trong Process 1.3 định mức 40 giờ / định mức * giá tuần định mức Phụ trội Mức trả vượt định Giờ công vượt Process 1.3 mức 40 giờ / tuần trội * giá định mức * 1.5
  37. Ch.III Bài tập vẽ DFD 37  Công ty Wonder Widget (WWC) có một hệ thống giám sát các đơn đặt hàng từ khách hàng. WWC lấy mã số của các món hàng được yêu cầu từ danh mục hàng (Master Item Number List), lấy đơn giá của món hàng từ hồ sơ giá (Master Price List), và kiễm tra mức tín dụng của khách hàng trong hồ sơ tín dụng (Credit Rating File). Các phiếu đặt hàng được chấp nhận sẽ lưu trong hồ sơ đặt hàng được chấp nhận (Accepted Orders File), các phiếu đặt hàng bị từ chối được lưu trong hồ sơ đặt hàng bị từ chối (Rejected Orders File). Hệ thống kho được kiễm tra để xem số lượng hàng có đủ cho các phiếu đặt hàng được chấp nhận không. Nếu đủ, phiếu đặt hàng được phê duyệt và gửi đến trung tâm giao hàng. Nếu không đủ, phiếu sẽ bị từ chối và đưa vào hồ sơ đặt hàng bị từ chối. Hồ sơ đặt hàng bị từ chối được dùng để phát sinh báo cáo phiếu đặt hàng bị từ chối cho giám đốc của WWC. Hãy vẽ lược đồ ngữ cảnh và DFD level 0 cho hệ thống.  Các từ in nghiêng là nội dung dữ liệu, các từ gạch dưới là source hoặc sink. Hệ thống không giám sát việc giao hàng và thanh toán tiền.
  38. Ch.III Entity Relationship Diagram 38 DFD và Processing Logic chỉ ra làm thế nào, ở đâu và khi nào dữ liệu được xử lý, nhưng không chỉ ra định nghĩa, cấu trúc và các quan hệ của dữ liệu. Entity Relationship Diagram (ERD) là lược đồ thể hiện cấu trúc trừu tượng hóa của dữ liệu trong tổ chức, dựa trên khái niệm thực thể (entity) và quan hệ (relationship) giữa các thực thể, để nhằm thể hiện nội dung, ý nghĩa của dữ liệu trong hệ thống.
  39. Ch.III Thực thể (Entity) 39  Nhân viên, Sinh viên, Môn học, là các thực thể, là một khái niệm tổng quát hóa cho một nhóm các đối tượng (thể hiện, entity instance) trong thế giới thực có chung một số đặc điểm (thuộc tính). Vd: môn “PTTK”, môn “THQL” là các thể hiện của thực thể Mônhọc. 1. Thực thể xác thực mô tả các đối tượng tồn tại thực sự trong thế giới thực: Xe đạp, xe hơi, nhà, quyển sách, 2. Thực thể chức năng mô tả mục đích, chức năng, hoặc nhiệm vụ của con người, thiết bị hoặc tổ chức: Sinh viên, nhân viên, khách hàng, nhà kho, 3. Thực thể sự kiện mô tả các sự kiện hoặc biến cố: biên nhận, biên bản họp, kỳ thi, 4. Thực thể quan hệ mô tả các quan hệ giữa các đối tượng: Quản lý, đăng ký, hợp đồng,
  40. Ch.III Thực thể (Entity) 40 Attribute (thuộc tính) là đặc điểm diễn tả thực thể. • MãNV, Tên, Địachỉ, KỹNăng là các thuộc tính được quan tâm khi nghĩ về thực thể NhânViên. Key: (khóa) là 1 thuộc tính (hoặc kết hợp nhiều thuộc tính) để phân biệt từng thể hiện trong thực thể. • MãNV là 1 thuộc tính dùng để phân biệt các nhân viên trong tập thực thể NhânViên. • Nếu biết MãNV của 1 nhân viên, ta sẽ tìm được tên của nhân viên, địa chỉ và kỹ năng của nhân viên đó, dựa trên dữ liệu của thực thể NhânViên. • Giá trị của khóa không bao giờ bị rỗng, trùng nhau, hoặc thay đổi khi thể hiện tương ứng vẫn còn tồn tại.
  41. Ch.III Các ký hiệu 41 Thực thể Thuộc tính Khóa Thuộc tính đa trị Ví dụ: một nhân viên có 1 mã nhân viên dùng để phân biệt. Cơ quan chỉ quan tâm quản lý tên nhân viên, địa chỉ nhà riêng, và các kỹ năng của từng nhân viên. Thực thể nhân viên được diển tả như sau: Emp_Name Emp_Address Emp_ID Emp_Skill EMPLOYEE
  42. Ch.III Multivalue Attribute 42 là một thuộc tính có nhiều giá trị được sử dụng đồng thời để mô tả cho một thực thể. Vd: thuộc tính “Skill” của 1 nhân viên. Một nhân viên thường có nhiều kỹ năng, do đó EMP_skill sẽ có nhiều giá trị khác nhau EMP_ID EMP_Name EMP_Skill 0210-67 Susan Language 0210-67 Susan Interpersonal Emp_Name Emp_Address Emp_ID Emp_Skills EMPLOYEE
  43. Ch.III Relationship 43  Là mối liên kết giữa một hoặc nhiều thực thể để chỉ ra sự liên kết về nội dung (và ý nghĩa) giữa các thực thể trong mối liên kết. Ví dụ: “Mỗi SINH VIÊN đăng ký nhiều MÔN HỌC”. Sự liên kết nội dung giữa thực thể Sinh viên và thực thể Môn học là việc đăng ký môn để học của mỗi sinh viên.  Cardinality: là số thể hiện của thực thể B có thể (hoặc phải) liên kết với mỗi thể hiện của thực thể A. Vd: một sinh viên phải đăng ký học ít nhất là 1 môn, và nhiều nhất là 6 môn trong một học kỳ. Mandatory 1 Optional 0 - 1 n n Mandatory Many Optional 0 - Many
  44. Ch.III Cardinality 44 Mỗi thể hiện của A có đúng 1 thể hiện R A B tương ứng ở B theo quan hệ R1 1 (cardinality = [1,1]). Mỗi thể hiện của A chỉ có 1 thể hiện R2 tương ứng ở B, hoặc không có thể hiện A B tương ứng theo quan hệ R2 (cardinality = [0,1]). Mỗi thể hiện của A có ít nhất là 1 và tối N A R3 B đa là N thể hiện tương ứng ở B theo quan hệ R3 (cardinality = [1,N]). Mỗi thể hiện của A có tối đa là N thể N hiện tương ứng ở B, hoặc không có thể A R4 B hiện tương ứng theo quan hệ R4 (cardinality = [0,N]).
  45. Ch.III Unary Relationship 45 Is PERSON Married EMPLOYEE Manages to One to One One to Many “Một người chỉ được kết “Một nhân viên có thể quản hôn với một người khác” lý nhiều nhân viên” Has ITEM Components Quantity “1 Item có thể có thành Many to Many phần, mỗi thành phần cũng là 1 Item”
  46. Ch.III Binary Relationship 46 EMPLOYEE Has a NAME CARD One to One (1:1) “Một nhân viên phải có (duy nhất) 1 bảng tên.” PRODUCT Contains PRODUCT LINE One to Many (1:N) “Một dây chuyền sản phẩm phải chứa 1 hoặc nhiều sản phẩm. Một sản phẩm phải thuộc 1 dây chuyền sản xuất.” STUDENT Registers COURSE Many to Many (M:N) “Một sinh viên phải đăng ký 1 hoặc nhiều môn học. Một môn học có thể có nhiều sinh viên đăng ký, hoặc không có sinh viên đăng ký”
  47. Ch.III Ternary Relationship 47 GOODS VENDOR Sell CUSTOMER “Một nhà cung cấp có thể bán nhiều mặt hàng cho nhiều khách hàng; khách hàng có thể mua hàng từ nhiều nhà cung cấp khác nhau ”
  48. Ch.III Associative Entity (thực thể liên kết) 48 Là thực thể liên kết các thể hiện của một hoặc nhiều thực thể khác và có thêm các thuộc tính riêng trên liên kết giữa các thực thể PART VENDOR SHIPMENT WAREHOUSE Shipment ID Quantity
  49. Ch.III Thiết lập lược đồ ERD 49 1. Định nghĩa các thực thể, dựa trên vai trò, ý nghĩa của thực thể đối với hệ thống. Nên chọn danh từ để dùng làm tên cho thực thể, vd: MONHOC, SINHVIEN, KHOA, 2. Định nghĩa các quan hệ giữa các thực thể. Tên của các quan hệ thường được diễn tả bằng động từ để chỉ các hành động, sự kiện liên kết các thể hiện trong các thực thể có quan hệ nhau. 3. Xác định các thuộc tính của thực thể và quan hệ. Thuộc tính của thực thể (hoặc quan hệ) là những đặc tính mà tất cả các thể hiện của thực thể (hoặc quan hệ) đều có. Thêm thuộc tính để tăng tính mô tả, hoặc để có thê dữ liệu phân biệt các thể hiện. Bỏ bớt thuộc tính nếu chúng dư thừa hoặc không liên quan đến vai trò, ý nghĩa của thực thể trong hệ thống. 4. Xác định cardinality cho mỗi quan hệ.
  50. Ch.III ERD cho hệ thống quản lý kho của Hoosie burger 50  Các thay đổi trong kho phát sinh bởi 2 sự kiện: Khi nhận được nguyên liệu từ nhà cung cấp (và hóa đơn kèm theo từ nhà cung cấp), và tiêu thụ nguyên liệu khi làm thức ăn bán cho khách hàng. Mỗi hóa đơn mua hàng có mã số của nhà cung cấp, số hóa đơn (số HĐM), ngày phát hành, tiền trả => “Hoá đơn mua hàng” là một thực thể diễn tả sự kiện nhận hàng về kho.  Mỗi nguyên liệu tồn kho có mã hàng, mô tả cho món hàng, loại hàng, số lượng tồn kho, và số lượng tối thiểu để đặt hàng lại (MOQ: Minimum Order Quantity) => “Hàng tồn” là thực thể mô tả trạng thái của kho.  Mỗi hóa đơn mua hàng có kèm danh mục các mặt hàng được giao để chỉ ra rằng nhà cung cấp đã giao thêm một số mặt hàng trong danh sách các mặt hàng lưu vào kho. Mỗi mặt hàng được giao có kèm theo số lượng giao => “Nhập hàng” là một quan hệ giữa “hóa đơn mua hàng” và “hàng tồn kho”, “số lượng nhập” là thuộc tính của quan hệ này.
  51. Ch.III ERD cho hệ thống quản lý kho của Hoosie burger 51  Các mặt hàng trong kho sẽ được sử dụng như nguyên liệu để làm ra sản phẩm. Mỗi sản phẩm có mã số sản phẩm và mô tả sản phẩm. Vậy “Sản phẩm” là một thực thể mô tả cho sản phẩm.  Mỗi sản phẩm được làm từ nhiều loại nguyên liệu khác nhau nên nhà hàng duy trì các công thức nấu ăn để xác định sản phẩm nào cần (những) nguyên liệu gì và liều lượng bao nhiêu => “Công thức” nấu ăn là một quan hệ giữa “Sản phẩm” và “Hàng tồn”. Liều lượng sử dụng của một loại nguyên liệu trong một công thức nấu ăn là thuộc tính của quan hệ này.  Mỗi lần bán hàng sẽ có một hóa đơn bán hàng được phát sinh, có số hóa đơn bán hàng, và ngày bán => “Hóa đơn bán hàng” là một thực thể mô tả cho sự kiện bán hàng.  Khách hàng có thể mua nhiều món ăn cùng một lúc; do đó mỗi lần bán hàng sẽ có nhiều món hàng (sản phẩm) được liệt kê thành danh mục trong hóa đơn bán hàng, mỗi mục có số lượng bán => “Xuất bán” là một quan hệ giữa thực thể “Hóa đơn bán hàng” và thực thể “Sản phẩm”, trong đó “Số lượng bán” là thuộc tính của quan hệ này.
  52. Ch.IIIERD cho hệ thống quản lý kho của Hoosie Burger 52 Số_HĐB Ngày_PH Số_HĐM TiềnTrả Ngày HÓAĐƠN HÓAĐƠN BÁNHÀNG MUAHÀNG Mã_NCC Slg_bán XUẤTBÁN NHẬPHÀNG Slg_nhập Slg_dùng Mã_Hàng SẢNPHẨM CÔNGTHỨC HÀNGTỒN MOQ Môtả Mã_SP MôTả Slg_tồnkho Loại
  53. Ch.III Bài tập vẽ ERD 53 1. Mỗi bệnh nhân có một hồ sơ bệnh án, mỗi hồ sơ bệnh án chỉ thuộc về 1 bệnh nhân. 2. Mỗi nhân viên thuộc 1 phòng, một phòng có ít nhất 1 hay nhiều nhân viên. Không có nhân viên nào không thuộc phòng nào. 3. Một tác phẩm phải thuộc 1 thể loại. Một thể loại có nhiều tác phẩm. 4. Một nhân viên (có thể) tham gia 1 hoặc nhiều dự án. Một dự án có nhiều nhân viên tham gia. 5. Một giảng viên dạy nhiều môn học. Một môn học có thể có nhiều giảng viên dạy. 6. Mỗi sinh viên sau mỗi lần thi một môn học sẽ có một điểm xác định cho lần thi đó. 7. Trong siêu thị, các quầy hàng bán nhiều mặt hàng, mỗi mặt hàng có một gía niêm yết tại quầy hàng đó. 8. Một giảng viên sử dụng nhiều tài liệu tham khảo để soạn bài giảng. Một bài giảng củng có thể do 1 giảng viên soạn dựa trên một số tài liệu tham khảo.
  54. Ch.III Bài tập vẽ ERD 54 Hàng hóa được xuất cảng trong các container và mỗi container được định danh bởi số của container, đích đến và kích cở của nó. Đại lý vận chuyển (Shipping Agent) chịu trách nhiệm gom nhóm các container vào một lô hàng và cho lô hàng một số định danh và giá trị của lô. Các con tàu, xác định bởi số của con tàu và quốc gia đăng ký, thực hiện các chuyến hải trình, mỗi chuyến hải trình mang một số lô hàng đi đến đích của chúng. Mỗi chuyến hải trình được cho số hải trình và trọng tải. Hãy vẽ luợc đồ ERD chỉ ra tất cả các thực thể, thuộc tính, và quan hệ. Để vẽ các ERD, chúng ta cần xác định các thực thể trước, sau đó là quan hệ giữa các thực thể, và cuối cùng là các thuộc tính cho thực thể và quan hệ. Các từ gạch dưới là các thực thể, và các động từ in nghiêng là các quan hệ giữa các thực thể. Trong mô tả không nêu rõ cardinality (số quan hệ), do đó số quan hệ có thể được cho bằng cách suy diễn hợp lý.
  55. Ch.III 3. Thiết kế hệ thống 55 Standards Information Mnagement processor Inputs Transform Outputs Reports DBMS Computer Based Information System Feedback loop Forms Information System
  56. Ch.III Thiết kế forms/reports 56 (Users) forms reports (Users) Inputs SOURCE CBIS Outputs SINK Forms : khuông mẫu nhận dữ liệu vào hệ thống. Reports : khuông mẫu thông tin cho người sử dụng. Xác định thông tin nội bộ hoặc bên ngoài tổ chức Mẫu biểu (forms/reports) phải phù hợp với phạm vi sử dụng (bên trong/bên ngoài tổ chức). Tài liệu xoay vòng: Là tài liệu sử dụng cho cả nội bộ và bên ngoài, từ tổ chức ra khách hàng và quay về. • Phiếu bảo hành, thẻ tín dụng, hóa đơn định kỳ. • Barcode, vạch từ, vi mạch là phương tiện hổ trợ tự động hóa đọc hoặc ghi dữ liệu cho các loại tài liệu này.
  57. Ch.III Chức năng giao tiếp (trên form/report) 57 1. Bảo vệ hệ thống khỏi các tác tác động không mong muốn từ môi trường 2. Lọc bỏ các nội dung vào/ra không cần thiết 3. Mã hóa và giải mã các nội dung vào/ra 4. Phát hiện lổi và sửa lổi 5. Lưu trữ tạm thời thông tin, dữ liệu vào/ra bằng vùng đệm. 6. Tổng hợp và chuyển đổi dữ liệu sang khuông mẫu cần thiết cho hệ thống (form) hoặc cho hệ thống khác (report).
  58. Ch.III Tương tác trên form 58 Prev Next First Last New Update Cancel Customer Information Number 1273 Search Phone 19087541358 Name Contemporary Design Order list (23 MAY 1998) Item # Product U.Price Amount Price 1 Hotdog – Size U 0.5 5 2.5 2.5 Add item Delete item Total
  59. Ch.III Tương tác trên form 59 1. Nội dung và thứ tự nhập liệu phải phù hợp với thông tin trên các loại tài liệu bằng giấy mà người sử dụng có. 2. Thời điểm có đủ dữ liệu cho form nhập liệu. 3. Dữ liệu phải có format và kiểm tra (validation) khi nhập: • Dữ liệu phải thuộc miền giá trị hợp lệ, và • Dữ liệu phải thỏa mãn các ràng buộc toàn vẹn. 4. Dữ liệu và các điều khiển cho nhập liệu phải nhất quán. • Mỗi ô nhập liệu (và điều khiển) trên form phải có tên gọi (nhãn, label) để phân biệt dữ liệu hoặc điều khiển khác nhau. • Nếu dữ liệu (hoặc điều khiển) xuất hiện trên nhiều form khác nhau thì tên gọi của nó vẫn không thay đổi. • Các điều khiển nhập liệu phải phù hợp với nội dung của dữ liệu và các quy tắc quản lý của tổ chức.
  60. Ch.III Tương tác trên report 60 Navigation Pine Valley Furniture Page : 2 of 2 Detail customer account information Subject Today : 11-OCT-98 Customer number: 1273 Update Name: Contemporary Design Columns CURRENT DATE PURCHASE PAYMENT BALANCE 21-JAN-98 (22,000.00) (22,000.00) 21-JAN-98 13,000.00 (9,000.00) 02-MAR-98 (16,000.00) (25,000.00) 02-MAR-98 15,500.00 (9,500.00) 23-MAY-98 (support details) 5,000.00 (4,500.00) 12-JUN-98 (9,285.00) (13,785.00) 12-JUN-98 3,785.00 (10,000.00) 21-SEP-98 5,371.65 (4,628.35) YTD-SUMARY (47,285.00) 42,656.65 (4,628.35) High light Conclusion
  61. Ch.III Hiệu quả của form/report 61 1. Hình thức thể hiện có thể làm người xem bị phân tâm (nhàm chán hoặc nhận thức sai), vì • Thông tin (bảng số liệu) không phù hợp với công việc • Các biểu đồ có tỉ lệ không phù hợp, thiếu giải thích • Sử dụng màu sắc và highlight không đúng 2. Khả năng tiếp thu của người xem phụ thuộc vào: • Trình độ, kinh nghiệm, kỹ năng của người đọc • Thời gian để người đọc hiểu thông tin trên biểu mẫu • Sự trợ giúp thông tin để giải thích, ghi chú, quy ước ▪ Vd: Giải thích ý nghĩa của các cột trong các reports để tránh hiểu lầm cho người đọc.
  62. Ch.III Thiết kế cơ sở dữ liệu 62 1. Chuyển đổi từ ERD sang các bảng quan hệ (table) và các quan hệ giữa các bảng (relationship), để phù hợp với các hệ quản trị CSDL phổ biến hiện nay là loại Relational Database. 2. Thiết lập các cơ chế ràng buộc toàn vẹn dữ liệu để ngăn chặn các thao tác có thể gây sai sót trên CSDL 3. Chuẩn hóa các bảng quan hệ để bảo đãm toàn vẹn dữ liệu 4. Trộn các bảng quan hệ để tránh trùng lặp dữ liệu giữa các bảng. 5. Mã hóa hoặc nén dữ liệu lưu trữ , để giữ bí mật thông tin, tránh trùng lặp dữ liệu, hoặc giảm bớt không gian lưu trữ dữ liệu. 6. Tổ chức lưu trữ để thuận tiện truy xuất và sao lưu phục hồi khi có sự cố, hư hỏng trên CSDL
  63. Ch.III Relation (bảng quan hệ) 63  Là một cấu trúc bảng mô tả cho 1 thực thể • Mỗi cột ứng với mỗi thuộc tính, gọi là Field (trường) • Mỗi hàng ứng với mỗi thể hiện, gọi là Record (mẫu tin) • Vd: EMPLOYEE2 (Emp_ID, Name, Dept_Name, Salary, Course_Title, Date_Complete). Emp_ID, Course_Title là một khóa chính kết hợp từ 2 thuộc tính của bảng quan hệ.
  64. Ch.III Relation (bảng quan hệ) 64  Không phải tất cả các bảng dữ liệu đều là quan hệ; nó phải thoả mãn các điều kiện sau: 1. Mỗi bảng có 1 tên duy nhất 2. Mỗi thuộc tính trong bảng có 1 tên duy nhất. 3. Mỗi dòng là duy nhất. Không thể có 2 dòng có tất cả các cột đều giống nhau. 4. Mỗi giá trị của thuộc tính là nguyên tố. Thuộc tính ‘composite’ là thuộc tính kết hợp nhiều thuộc tính. Vd: Địa_chỉ = Số_nhà + Đường + Phường + Quận + Tp  Các bảng quan hệ được tạo ra từ việc chuyển đổi lược đồ ERD sang bảng.
  65. Ch.III Thực thể sang bảng: 1.Single attribute 65 Customer_Name Customer_ID CUSTOMER Customer_Address CUSTOMER Customer_ID Customer_Name Customer_Address
  66. Ch.III Thực thể sang bảng: 2.Composite attribute 66 Customer_Name City State Street Zip Customer_ID CUSTOMER Customer_Address CUSTOMER Customer_ID Customer_Name Street City State Zip
  67. Ch.III Thực thể sang bảng: 3.Multivalue attribute 67 Employee_Name Employee_Address Employee_ID EMPLOYEE Skills EMPLOYEE Employee_ID Employee_Name Employee_Address EMPLOYEE_SKILL Employee_ID Employee_Skill Khóa ngoại
  68. Ch.III Thực thể sang bảng: 4.Weak-entity 68 Emp_ID Emp_Name Dept_DOB Dept_Name Dept_Gender EMPLOYEE DEPENDENT “Strong entity” “Weak entity” EMPLOYEE Emp_ID Employee_Name DEPENDENT Emp_ID Dept_Name Dept_DOB Dept_Gender Khóa ngoại Khóa phụ
  69. Ch.III Chuyển quan hệ 2 ngôi 1:M 69 Customer_Name Customer_ID CUSTOMER Customer_Address 1 Submits M Order_ID ORDER Order_Date
  70. Ch.III Chuyển quan hệ 2 ngôi 1:M 70 CUSTOMER Customer_ID Customer_Name Customer_Address ORDER Order_ID Customer_ID Order_Date Foreign key
  71. Ch.III Chuyển quan hệ 2 ngôi M:N 71 Unit_Of_Measure RAW Material_ID MATERIALS Standard_Cost 0,N Supplies Unit_Price 1,M Vendor_ID VENDOR Vendor_Name Vendor_Address
  72. Ch.III Chuyển quan hệ 2 ngôi M:N 72 RAW MATERIALS Material_ID Standard_Cost Unit_Of_Measure QUOTE Material_ID Vendor_ID Unit_Price VENDOR Vendor_ID Vendor_Name Vendor_Address
  73. Ch.III Chuyển quan hệ 2 ngôi 1:1 73 Name Nurse_ID NURSE Date_Of_Birth Mandatory In_Charge Date_Assigned Optional CARE Center_Name CENTER Location
  74. Ch.III Chuyển quan hệ 2 ngôi 1:1 74 NURSE Nurse_ID Name Date_Of_Birth Mandatory 1 CARE CENTER Center_Name Location Nurse_In_Charge Date_Assigned Foreign key
  75. Ch.III Chuyển thực thể quan hệ 75 Customer_ID CUSTOMER Customer_Name Amount Shipment_No SHIIPMENT Date Vendor_ID VENDOR Address
  76. Ch.III Chuyển thực thể quan hệ 76 CUSTOMER Customer_ID Customer_Name SHIPMENT Shipment_No Amount Date Customer_ID Vendor_ID VENDOR Vendor_ID Address
  77. Ch.III Ràng buộc toàn vẹn 77  Ràng buộc trên miền giá trị của mỗi field • Mỗi thuộc tính của thực thể được quy định một miền gía trị hợp lệ. Các giá trị nằm ngoài miền giá trị này là các giá trị vô nghĩa đối với thực thể, cần phải loại bỏ.Ví dụ: thuộc tính Nam/Nữ chỉ có 2 gía trị  Ràng buộc toàn vẹn thực thể (và bảo toàn các liên kết) • Không có khóa chính nào có thể rỗng – tất cả các khóa chính phải có chứa dữ liệu để phân biệt các dòng (mẫu tin) trong bảng • Bảo toàn liên kết khi thêm, xoá, sửa dữ liệu để không mất dữ liệu  Để tăng tính toàn vẹn dữ liệu, đồng thời các bảng quan hệ có cấu trúc tốt (chứa tối thiểu dữ liệu dư thừa + cấu trúc cho phép thiết lập các ràng buộc toàn vẹn thực thể), người ta cần phải chuẩn hóa các bảng quan hệ.
  78. Ch.III Các bước chuẩn hóa bảng quan hệ 78 Bảng có các Bỏ thuộc tính thuộc tính đa trị đa trị Bảng ở dạng chuẩn 1 Bỏ phụ thuộc hàm (1st normal form) từng phần Bảng ở dạng chuẩn 2 Bỏ phụ thuộc hàm (2nd normal form) Bắc cầu Bảng ở dạng chuẩn 3 (3rd normal form)
  79. Ch.III Chuẩn 1 (First Normal Form) 79 Bảng quan hệ dạng chuẩn 1 là bảng quan hệ không chứa thuộc tính đa trị (multivalued attribute). Đặc điểm: có nhiều dữ liệu bị trùng lặp giữa các mẫu tin 1st-NF relation
  80. Ch.III Chuẩn 2 (Second Normal Form) 80 Bảng dạng chuẩn 2 là bảng ở dạng chuẩn 1 và mọi thuộc tính không phải là khóa phụ thuộc hàm vào toàn bộ khóa chính • Mỗi thuộc tính không khóa được xác định bởi toàn bộ khóa chính, không phải chỉ một phần của khóa chính • Không có sự phụ thuộc từng phần trên khóa chính DateCompleted phụ thuộc hàm hoàn toàn vào (EmpID, CourseTitle) EmpID CourseTitle Name DeptName Salary DateCompleted NOT 2nd NF !! Name, DeptName, Salary chỉ phụ thuộc vào (Emp_ID)
  81. Ch.III Biến đổi thành chuẩn 2 81 1. Các thuộc tính chỉ phụ thuộc vào 1 phần khóa chính là EmpID kết hợp với EmpID để tạo thành 1 bảng chuẩn 2 EmpID Name DeptName Salary (2nd NF) 3. Đặt quan hệ giữa 2 bảng mới EmpID CourseTitle DateCompleted (2nd NF) 2. Các thuộc tính phụ thuộc hoàn toàn vào khóa chính kết hợp với khóa chính để tạo thành 1 bảng chuẩn 2
  82. Ch.III Chuẩn 3 (Third Normal Form) 82 Bảng dạng chuẩn 3 là bảng dạng chuẩn 2 và không chứa phụ thuộc hàm bắt cầu . Phụ thuộc hàm bắc cầu: một thuộc tính C phụ thuộc hàm vào thuộc tính B, thuộc tính B lại phụ thuộc hàm vào thuộc tính A, ký hiệu là A → B → C). Cust_ID Name Salesperson Region Cust_ID → Salesperson → Region : phụ thuộc bắc cầu
  83. Ch.III Biến đổi thành dạng chuẩn 3 83 (bảng không chứa thuộc tính phụ (bảng chứa thuộc tính phụ thuộc thuộc bắc cầu ‘Region’) bắc cầu ‘Region’ và khóa của nó) Salesperson → Region Cust_ID → Name, Salesperson SPERSON Salesperson Region SALES1 Cust_ID Name Salesperson
  84. Ch.III Trộn các bảng quan hệ 84 Sau khi thực hiện normalization, một số bảng quan hệ có thể dư thừa vì cùng mô tả cùng một hoặc một số thực thể tương tự nhau, có thể trộn (merge) thành 1 bảng EMPLOYEE1(Emp_ID, Name, Address,Phone) EMPLOYEE2(Emp_ID, Name, Address, Jobcode, Number_of_years) • Sau khi trộn, ta được: EMPLOYEE(Emp_ID, Name, Address, Phone, Jobcode, Number_of_years) Việc trộn các bảng phải bảo toàn ý nghĩa của dữ liệu 1.Trường hợp đồng nghĩa 2.Trường hợp đồng âm, dị nghĩa 3.Có thể sinh ra phụ thuộc hàm bắc cầu, cần loại bỏ
  85. Ch.III Trộn các bảng quan hệ 85 Ví dụ: 1.Đồng nghĩa STUDENT1(Stu_ID, Name) STUDENT2(Matriculation_number, Name,Address) Nếu Stu_ID và Matriculation_number cùng được dùng để diễn tả cùng một nội dung là số an sinh xã hội (Social Security Number), hai bảng này có thể trộn lại và sử dụng khóa mới là SSN : STUDENT (SSN, Name, Address)
  86. Ch.III Trộn các bảng quan hệ 86 Ví dụ: 2.Đồng âm, dị nghĩa STUDENT1(Stu_ID, Name, Address) • “Address”: địa chỉ của SV trong khuôn viên trường STUDENT2(Stu_ID, Name, PhoneNumber, Address) • “Address”: địa chỉ nhà riêng của SV Vì Address ở 2 bảng mô tả cho 2 nội dung khác nhau, nên khi trộn 2 bảng, 2 thuộc tính này cần đặt lại 2 tên khác nhau để phân biệt: STUDENT (Stu_ID, Name, Campus_Address, Permanent_Address)
  87. Ch.III Trộn các bảng quan hệ 87 Ví dụ: 3.Phụ thuộc hàm bắc cầu STUDENT1 (Stu_ID, Major) là bảng 3rd NF STUDENT2 (Stu_ID, Advisor) là bảng 3rd NF Sau khi trộn 2 bảng, sẽ có bảng mới là STUDENT (Stu_ID, Major, Advisor) Tuy nhiên, nếu Major → Advisor thì bảng trên không là bảng chuẩn 3rd NF, cần phải bỏ phụ thuộc hàm bắc cầu một lần nữa để tạo ra 2 bảng: STUDENT (Stu_ID, Major) MAJOR_ADVISOR (Major, Advisor)
  88. Ch.III Nén dữ liệu bằng Lookup Table 88 BILLING_ADDRESS Cust_No Block_no Street City_State 1273 2226 Plainfield Ave NJ 6390 2110 Plainfield Ave NJ 40 bytes BILLING_ADDRESS Cust_No Block_no Ref City_State 1273 2226 1001 NJ 6390 2110 1001 NJ 4 bytes LOOKUP_STREET Ref Street 1001 Plainfield Ave Range: 0 9999 7024 Oak
  89. Ch.III Đánh giá khả thi cho các cải tiến 89 Tính khả thi của các cải tiến được xem xét trên các yếu tố sau:  Năng lực của hệ thống mới đối với các kế hoạch phát triển tổ chức.  Khả năng làm thỏa mãn các tiêu chí đánh giá mức độ thành công (CSFs) của tổ chức.  Phạm vi thay đổi của hệ thống thông tin mới trong tổ chức, đuợc diễn tả theo mức độ từ thấp đến cao tương ứng với mức độ rủi ro và thành quả sẽ đạt đuợc như sau: 1. Tự động hóa (thay thế xử lý nhân công) 2. Hợp lý hóa (sắp xếp tối ưu công việc trên dây chuyền) 3. Tái cấu trúc tiến trình kinh doanh (giữ nguyên mục tiêu, thay đổi phương pháp, cấu trúc tổ chức, nguồn lực) 4. Chuyển dịch cơ cấu tổ chức (thay đổi mục tiêu kinh doanh)
  90. Ch.III Bài tập 90 1. Giả sử ta có bảng quan hệ R(A, B, C, D, E) với khóa chính A,B và phụ thuộc hàm C→D và D → E. Hãy chuyển quan hệ sang dạng chuẩn 3NF. 2. Quan hệ MEETING có các thuộc tính và khóa như sau: MEETING(CourseName, CourseTitle, Day, Time, BuildingName, Room#, Address). Giả sử có 2 phụ thuộc hàm trên quan hệ này: • Address phụ thuộc hàm vào BuildingName • CourseTitle phụ thuộc hàm vào CourseName Hãy chuyển quan hệ sang dạng 3NF. 3. Quan hệ BUILDING có các thuộc tính và khóa như sau: BUILDING(Street, Street#, City, OwnerName, OwnerAddress, PropertyTax). Giả sử có 3 phụ thuộc hàm trên quan hệ này: 1. OwnerName phụ thuộc hàm vào street, street#, city 2. PropertyTax phụ thuộc hàm vào street, street#, city 3. OwnerAddress phụ thuộc hàm vào ownerName Hãy chuyển quan hệ sang dạng 3NF.
  91. Ch.III Bài tập 91 4. Một hãng xe hơi có CSDL lưu các thông tin sau:  Thông tin vê nhà cung cấp (Suppliers) Mỗi nhà cung cấp được hãng xe hơi gán một số định danh Supplier# để phân biệt nhau Mỗi nhà cung cấp có tên (SupplierName), và thành phố (SupplierCity) Mỗi nhà cung cấp cung cấp 1 hoặc nhiều phụ tùng cho xe  Thông tin vê phụ tùng xe (Parts) Mỗi phụ tùng xe có một tên (PartName), số định danh (Part#) và giá (PartPrice) Mỗi phụ tùng được cung cấp bởi 1 hay nhiều nhà cung cấp Part# là số dùng để phân biệt các phụ tùng xe với nhau  Thông tin vê đợt cung cấp (Supply) Mỗi đợt cung cấp có nhà cung cấp cung cấp một phụ tùng Mỗi đợt cung cấp có số lượng(quantity), ngày (date), tên bộ phận (partName), thành phố của nhà cung cấp (SupplierCity), và mã vùng của nhà cung cấp (Supplier_Postal)
  92. Ch.III Bài tập 92 Giả sử hãng đã biết được các quan hệ phụ thuộc như sau: 1. Số lượng trong mỗi đợt cung cấp hàng phụ thuộc hoàn toàn vào supplier#,part#,date 2. PartName được xác định bởi Part# 3. SupplierCity,SupplierPostal phụ thuộc vào Supplier# 4. Nếu biết SupplierPostal, ta sẽ biết được SupplierCity a) Hãy vẽ lược đồ ERD cho CSDL. b) Chuyển lược đồ ERD sang bảng quan hệ và chuẩn hóa thành dạng 3NF.