Bài giảng Phân tích thiết kế hệ thống - Chương 2: Tiếp cận hướng cấu trúc - Nguyễn Anh Hào

Bắc cầu104Chuẩn 1 (First Normal Form)	Bảng quan hệ dạng chuẩn 1 là bảng quan hệ không chứa thuộc tính đa trị hoặc có các cột đồng nghĩa.Đặc điểm: có nhiều dữ liệu bị trùng lặp giữa các mẫu tin1st-NF relation105Chuẩn 2 (Second Normal Form)	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 thì phụ thuộc hàm vào toàn bộ khóa chínhKhông có sự phụ thuộc hàm vào 1 phần của khóa chínhDateCompleted phụ thuộc hàm hoàn toàn vào (EmpID, CourseTitle)Name, DeptName, Salary chỉ phụ thuộc vào (Emp_ID)EmpIDCourseTitleNameDeptNameSalaryDateCompletedNOT 2nd NF !!106Chuẩn 2 (Second Normal Form)Các bảng quan hệ thỏa mãn các yêu cầu sau là bảng ở dạng chuẩn 2 (2NF)Là bảng quan hệ không có thuộc tính không khóaLà bảng quan hệ có khóa là thuộc tính nguyên tố (không thể có phụ thuộc hàm vào 1 phần khóa chính)Là bảng quan hệ có thuộc tính không khóa thì phụ thuộc hàm đầy đủ vào toàn bộ khóa.107Biến đổi thành dạng chuẩn 2EmpIDNameDeptNameSalary(2nd NF)EmpIDCourseTitleDateCompleted(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 21. 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 23. Đặt quan hệ giữa 2 bảng mới108Chuẩn 3 (Third Normal Form)	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  Salesperson  Region : phụ thuộc bắc cầuCust_IDNameSalespersonRegion109Biến đổi thành dạng chuẩn 3CustID  Name, SalespersonSalesperson  RegionCust_IDNameSalespersonRegionSalespersonSPERSONSALE1110Trộn các bảng quan hệ (Merge)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. EMPLOYEE1(Emp_ID, Name, Address,Phone) EMPLOYEE2(Emp_ID, Name, Address, Jobcode, Number_of_years)Có thể trộn 2 bảng này thành 1: 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ệu111Trộn các bảng quan hệ: SynonymsSTUDENT1(Stu_ID, Name)STUDENT2(Matriculation_number, Name,Address)	Nếu Stu_ID và Matriculation_number cùng được dùng để diễn tả cho một thuộc tính Social Security Number (số an sinh xã hội), 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)112Trộn các bảng quan hệ: HomonymsSTUDENT1(Stu_ID, Name, Address)Address: địa chỉ của SV trong khuôn viên trườngSTUDENT2(Stu_ID, Name, PhoneNumber, Address)Address: địa chỉ nhà riêng của SV	Vì Address ở 2 bảng mang 2 ý nghĩa khác nhau, nên khi trộn 2 thuộc tính này cần đặt lại tên:STUDENT (Stu_ID, Name, Campus_Address, Permanent_Address)113Trộn các bảng quan hệ: Transitive dependencySTUDENT1 (Stu_ID, Major) là bảng 3rd NFSTUDENT2 (Stu_ID, Advisor) là bảng 3rd NF	Nếu trộn 2 bảng ta cóSTUDENT (Stu_ID, Major, Advisor)	Tuy nhiên, nếu Major  Advisor thì bảng trên không là 3rdNF, cần phải bỏ transitive dependency một lần nữa:STUDENT (Stu_ID, Major)MAJOR_ADVISOR (Major, Advisor)114Bài tậpGiả 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(Course#, CourseTitle, Day, Time, BuildingName, Room#, Address). Giả sử có 2 phụ thuộc hàm trên quan hệ này:BuildingName phụ thuộc hàm vào AddressCourseTitle chỉ phụ thuộc hàm vào Course# 	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#, City, BuildingName, OwnerAddress, Tax). Giả sử có 3 phụ thuộc hàm trên quan hệ này:BuildingName phụ thuộc hàm vào street#, cityTax phụ thuộc hàm vào CityOwnerAddress phụ thuộc hàm vào BuildingName 	Hãy chuyển quan hệ sang dạng 3NF.115Bài tập4. 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 nhauThô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)116Bài tậpGiả sử hãng đã biết được các quan hệ phụ thuộc như sau:Số lượng trong mỗi đợt cung cấp hàng phụ thuộc hoàn toàn vào supplier#,part#,datePartName được xác định bởi Part#SupplierCity,SupplierPostal phụ thuộc vào Supplier#Nếu biết SupplierPostal, ta sẽ biết được SupplierCitya) 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.117Nén dữ liệu bằng Lookup TableStreetRefLOOKUP_STREETPlainfield Ave1001Cust_NoBlock_noStreetBILLING_ADDRESS12732226Plainfield Ave63902110Plainfield AveCity_StateNJNJCust_NoBlock_noRef127322261001639021101001City_StateNJNJBILLING_ADDRESSOak7024Range: 0 .. 999940 bytes4 bytes118Phân khúc các fieldsCác fields có tần suất truy xuất (chủ yếu là đọc) không đều nhau, do đó cần phân lập các fields có mức độ truy xuất cao lưu trữ trong ổ dĩa có tốc độ cao để cải tiến tốc độ. PATIENTPatientNumberNameLocationAddressDateAdmittedDateDischargeStatusPATIENT-1PatientNumberNameLocationPATIENT-2AddressDateAdmittedDateDischargeStatus1st segment2nd segmentPointerTruy xuất thường xuyênTruy xuất không thường xuyênLow speedHigh speed119Phân khúc các recordsKhi số lượng records trong 1 bảng (trên 1 máy) quá nhiều thì các câu lệnh truy xuất dữ liệu sẽ thực thi rất lâu, cần chia tập các mẫu tin ra thành nhiều phân đoạn để lưu trữ và xử lý trên nhiều máy.1st segment2nd segmentCDRCallerABCD[Data]SUBSCRIBERSID001002CallerACSgmt1st 2nd PublicsegmentMachine 1Machine 2(Master)(Detail)(Call Data Records)120Forward recovery (rollforward)Là phương pháp Sử dụng bản backup mới nhất để restore, và thực hiện lại tất cả các lệnh cập nhật cần thiết sau khi đã khắc phục được lổi.Nếu chu kỳ backup càng dài thì thời gian cần thiết để khôi phục dữ liệu càng lâu. Tuy nhiên, backup thường xuyên sẽ làm nặng tải cho DBMS.BackupRestore Backup & Re-run all transactionsErrorTransactionsTransactionsTime121Backward recovery (rollback)Là phương pháp sử dụng bản dữ liệu hiện tại, thực hiện ‘undo’ tất cả các lệnh đã cập nhật dữ liệu, khắc phục lổi và thực hiện lại các lệnh này.Phương pháp này không cần bản backup, nhưng cần bản dữ liệu hiện tại (kể cả DBMS) không bị hư hỏng.ErrorTransactions3. Re-run all transactionsTime1.Reverse effects of all transactions2.Correct error1227. Cấu trúc phần mềmCấu trúc cần phải mềm dẻo, kiểm soát được, và hổ trợ cập nhật bổ sung sau nàyPhân rã hệ thống thành các module nhỏMỗi module chỉ nên thực hiện 1 chức năngMỗi module chỉ điều khiển một số ít module conHạn chế phát sinh dư thừa mã lệnhSử dụng lại những gì đã có (Re-use)Các mođun nên độc lập nhau và có kích thước hợp lýÁp dụng các công nghệ phù hợp cho thiết kếThiết kế theo chuẩn123Tính độc lập của moduleTính độc lập của các mô-đun có được bằng cách tạo các mô-đun với chức năng chuyên trách, và không có quá nhiều tương tác với các mô-đun khác. Mỗi một mô-đun giải quyết một yêu cầu hay một chức năng con cụ thể và có một giao diện đơn giản.Mô-đun độc lập làm cho việc kiểm thử và bảo trì dễ dàng hơn.Mô-đun độc lập tăng khả năng dùng lại cho các chương trình sau.Tính độc lập của mô-đun được xem xét ở hai khía cạnh: độ gắn kết (cohesion) và độ phụ thuộc (coupling).124CohesionCohesion xác định mức độ gắn kết của các thành phần bên trong một mô-đun để thực hiện chức năng của mô-dun.Độ gắn kết càng cao, mô-đun càng dể hiểu và dể bảo trì.Có 7 mức độ đánh giá sự gắn kết của mô-đun(High)	Functional 	Sequential 	Communication 	Procedural 	Temporal 	Logical(Low)	Coincidental125CouplingCoupling đo mức độ phụ thuộc nội tại (interdependence) giữa các mô-đun.Nếu ít phụ thuộc là tốt, ngược lại các mô-đun phụ thuộc càng nhiều thì càng khó bảo trì.Để đọc và hiểu về 1 mô-đun mà không cần phải hiểu các mô-đun khác.Để sửa 1 mô đun mà không bận tâm về các mô-đun khácVì phần mềm thiết kế theo cấu trúc, chắc chắn sẽ có phụ thuộc giữa các mô-đun mức cao – mức thấp (qua cách gọi hàm)126CouplingCoupling càng ở mức thấp càng tốt. (Low and best)	Data coupling 	Stamp coupling (Loose)	Control coupling 	Common coupling (Worst)	Content coupling1278. Cấu trúc file lưu trữMục đích tổ chức các files:Truy xuất nhanhXử lý được khối lượng dữ liệu lớnSử dụng hiệu quả bộ nhớ (dĩa) để lưu trữBảo vệ an toàn dữ liệu khỏi hư hỏng hoặc thất lạcGiảm tối đa yêu cầu tổ chức lại dữ liệuCho phép tăng trưởngGiữ bí mật thông tinCác kỹ thuật sắp xếp (sort) và tìm kiếmIndexingHashing128IndexingSID IndexKey001002003004005006PointerSUBSCRIBERSID001002005003004006CallerACDGHBSgmt1st 2nd 2nd2nd1st 1st sorted1N1NIndexing (tạo chỉ mục) là để thể hiện dữ liệu theo thứ tự (trên indexed-field) khi truy xuất qua chỉ mục, thứ tự vật lý của các mẫu tin dữ liệu không hề thay đổi.Vd: Xếp thứ tự trên SID, sau đó là Caller. Nếu sắp xếp vật lý (sort) các mẫu tin thì hệ thống sẽ phải sort 2 lần  nên thực hiện bằng cách tạo 2 index.“Indexed”Access129HashingIndexing cần phải lưu trữ file index có độ lớn tỉ lệ với độ dài của key và tổng số mẫu tin dữ liệu. Hashing dùng để giảm bớt kích thước file index.Hash IndexHn123456Pointer1MN pointers to N recordsHn(1..M)‘002’HashfunctionKeyN := Number(‘002’)Hn := MOD(KeyN, M)M là một số nguyên tố.130Client-Server n-tiersPresentation logicBusiness logicResourcesCS. 3-TiersWebPagesServicesDBMSWeb App.ArchitectureBusiness processesValid-ationFormatUI. ControlCheckViewsStored ProcsTables / RelationshipsViệc phân lớp trợ giúp hoạch định các module có kích thước nhỏ, phù hợp với yêu cầu chức năng, và trợ giúp áp dụng công nghệ.131