tiểu luận giữa kì cơ sở dữ liệu

ậ ớPhân công và đánh giá về khả năng làm việc nhóm: Mọi người trong nhóm đều tự giác tìm hiểu và hoàn thành công việc trong th i gian đã ờthống nhất trước, mặc dù có đôi lúc khó liên hệ

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN TOÁN ỨNG D NG VÀ TIN HỤỌC

Hà N i, 08-2021 ộ

Lời nói đầu

Do s phát tri n cự ể ủa cơ sở ữ ệ d li u, các công ty có th ể lưu trữ và qu n lý d li u m t cách ả ữ ệ ộthuận ti n Ngoài ra, h thệ ệ ống còn giúp doanh nghi p tìm ki m thông tin và hệ ế ồ sơ về bất kỳ người ho c s n ph m nào mặ ả ẩ ột cách nhanh chóng, trực tiếp làm tăng hiệu qu công ảviệc Đối với l p trình viên thì viậ ệc thao tác với cơ sở ữ ệu là điề ất thường xuyên, vì d li u rvậy, làm sao để nâng cao hiệu quả kinh doanh bằng cách tổ chức và sử d甃⌀ng d li u Ph i ữ ệ ảphát tri n và thi t k d li u sao cho phù h p v i nhu c u kinh doanh và c i thiể ế ế ữ ệ ợ ớ ầ ả ện cơ sởdữ li u sao cho h th ng hoệ ệ ố ạt động mượt mà Sau khi nhận được đề tài v ề cơ sở ữ ệ d li u trong lĩnh vực bán lẻ nhóm chúng em đã bắt tay vào làm vi c và dướệ i đây là tiểu lu n ậnhằm trình bày nh ng th mà chúng eữ ứ m đã tìm hiểu được N i dung chính c a ti u lu n ộ ủ ể ậnày là báo cáo v thông tin cề ủa cơ sở ữ ệu mà chúng em tìm đượ d li c, các câu l nh truy ệvấn, các thao tác nh m thằ ực hiệ ối ưu thờn t i gian truy v n, c p nh t d liấ ậ ậ ữ ệu Cơ sở ữ ệ d li u của chúng em có tên ‘AdventureWorks’ được cả nhóm tiến hành tìm kiếm và ch n l c ọ ọCác câu lệnh đều được vi t b ng ngôn ng SQL trên h qu n tr MySQL Do kh ế ằ ữ ệ ả ị ả năng còn hạn ch nên báo cáo không tránh kh i nh ng sai sót R t mong th y và các b n có th ế ỏ ữ ấ ầ ạ ểthông cảm và góp ý để ể ti u lu n nàậ y được hoàn thiện hơn.

Nhóm em cũng xin gửi l i cờ ảm ơn đến thầy Nguyễn Danh Tú đã giúp chúng em và các nhóm khác trong quá trình làm bài t p l n này ậ ớ

Phân công và đánh giá về khả năng làm việc nhóm:

Mọi người trong nhóm đều tự giác tìm hiểu và hoàn thành công việc trong th i gian đã ờthống nhất trước, mặc dù có đôi lúc khó liên hệ nhưng nhìn chung thì các bạn v n hoàn ẫthành tiến độ công vi c ệ

Phần 1: Đề tài nhóm

Thông tin sơ bộ về cơ sở dữ liệu

Trong bài tập này, chúng em s dử 甃⌀ng cơ sở ữ ệ d li u m u AdventureWorks c a Microsoft ẫ ủĐây là cơ sở dữ liệu minh họa cách thiết kế cơ sở dữ liệu trên SQL Server 2008

AdventureWorks l y b i c nh trên d li u c a 1 công ty s n xuấ ố ả ữ ệ ủ ả ất đa quốc gia có qui mô lớn Công ty này s n xuả ất và kinh doanh xe đạp Thị trường c a công ty này bao g m c ủ ồ ảkhu vực Bắc M , Châu Âu và Châu Á Trong khi trỹ 甃⌀ ở chính củ s a công ty lại được đặ ởt Bothell, Washington gồm có 290 nhân viên, công ty cũng có 1 vài nhóm nhân viên kinh doanh khu v c các th ự ở ị trường hoạt động c a mình ủ Vào năm 2000, công ty Adventure Works Cycles có mua l i 1 nhà máy s n xu t nh là Importadores Neptuno Mexico ạ ả ấ ỏ ởNhà máy này tham gia s n xu t 1 vài thành ph n thi t y u trong toàn b dây chuy n s n ả ấ ầ ế ế ộ ề ảxuất ra thành ph m c a công ty Các thành phẩ ủ ần được nhà máy này sản xu t sấ ẽ được chuyển tới tr甃⌀ ở chính ở s Bothell để ắ l p ráp thành thành phẩm Năm 2001, Importadores Neptuno trở thành nhà máy duy nh t s n xu t phà phân ph i dòng s n phấ ả ấ ố ả ẩm xe đạp du lịch Kết thúc 1 năm tài chánh thành công, công ty Adventure Works Cycles đang tìm cách m r ng th ph n b ng cách t p trung vào các hoở ộ ị ầ ằ ậ ạt động bán hàng cho các khách hàng quan tr ng nh t cọ ấ ủa họ, m r ng thông tin s n ph m thông qua h th ng Website ở ộ ả ẩ ệ ốđồng th i tiết giảm chi phí bán hàng bằng cách giảm chi phí sản xuờ ất Cơ sở ữ liệu dAdventure Works gồm các tình hu ng giố ả định như: sản xu t, bán l , mua bán, qu n lí ấ ẻ ảsản ph m, qu n lí khách hàng và nhân s Trong bài t p này, chúng em ch y u s dẩ ả ự ậ ủ ế ử 甃⌀ng phần bán l (Sales) cẻ ủa CSDL này

4

Phần 1: Đề tài nhóm Sơ đồ R-E và E-R của CSDL AdventureWorks

• Sơ đồ R-E

• Sơ đồ E-R

6

Phần 1: Đề tài nhóm Thông tin v s ề ố lượng b n ghi ả

Theo MySQL Workbench, họ ước tính cơ sở ữ ệ d li u này n ng 207.8 MB g m 71 b ng ặ ồ ả

Tuy vậy, do CSDL này là m t công ty bao g m nhi u b ph n khác nhau, chúng em ch ộ ồ ề ộ ậ ỉsử d甃⌀ng phần “Sales” Phần Sales g m 19 b ng, chi tiồ ả ết như sau:

Trong đó, bảng Sales_salesorderdetail mang nhi u thông tin nhấề t v i 15.5MB dớ ữ li u ệ

Đánh giá chuẩn hóa của CSDL

• Qua khảo sát chung, nhóm em th y không có b ng nào có các thuấ ả ộc tính đa trị và không có cột nào được tính toán d a vào các c t khác Vì v y, nhóm em k t lu n ự ộ ậ ế ậcác b ng ả trong CSDL này đã đạt chu n 1 ẩ

• Các thu c tính mà không phộ ải là khóa thì đều ph甃⌀ thuộc hàm đầy đủ vào khóa chính, điều này có thể thấy đượ ở ất c các bc t ả ảng Do đó, CSDL này cũng đạt chuẩn 2

• CSDL này cũng đạt chuẩn 3 do chúng em không tìm thấy các ph甃⌀ thuộc hàm bắc cầu các b ng ở ả

• Tuy nhiên, chuẩn Boyce Codd đã bị vi phạm do trong bảng SaleReason, từ thuộc tính Name ta v n có th truy vẫ ể ấn được SaleReasonID

8

Phần 2: Các câu l nh truy v n và tệ ấ ối ưu truy vấn

Phần 2: Các câu l nh truy v n và tệấối ưu truy vấn

Các câu l nh truy v n ệấ

Nhóm em s dử 甃⌀ng 10 câu l nh truy v n trên MySQL nh sau: ệ ấ ư

1 Thông tin đơn hàng có OrderQty > 5 và LineTotal > 50.000000 SELECT

production_product.Name, Color, Size, Weight, Class, Style, OrderQty, UnitPrice, LineTotal, ShipTo, OrderDate, DueDate, ShipDate

person_address USING (StateProvinceID)

WHERE Color IS NOT NULL

2 Những nhân viên có doanh số l n h n doanh s trung bình ớ ơ ố

SELECT production_product.Name, OrderQty, UnitPrice, StandardCost,

LineTotal, ListPrice, Size, Style, SafetyStockLevel

(CASE

END) SellerLevel FROM

sales_salesorderdetail

INNER JOIN

production_product USING (ProductID)

Kết qu d li uả ữ ệ

4 Thông tin các lô hàng SELECT

sales_salesorderheader.SalesOrderID, sales_salesorderheader.OrderDatem sales_salesorderheader.DueDate, sales_salesorderheader.ShipDate, sales_salesorderheader.Status, sales_salesorderheader.SubTotal,

sales_salesorderheader.TaxAmt, sales_salesorderheader.Freight, METHOD

FROM sales_salesorderheader

INNER JOIN purchasing_shipmethod USING (ShipMethodID) INNER JOIN purchasing_purchaseorderheader USING (ShipMethodID) GROUP BY SalesOrderID;

12

Phần 2: Các câu l nh truy v n và tệ ấ ối ưu truy vấn

Kết qu d li u ả ữ ệ

SELECT Product, DiscountPct, Type, Category, OrderQty, UnitPrice, LineTotal FROM

Sales_specialoffer

INNER JOIN sales_specialofferproduct USING (SpecialOfferID) INNER JOIN production_product USING (ProductID) INNER JOIN sales_salesorderdetail USING (ProductID) WHERE TYPE < > ‘No Discount’

GROUP BY Product

Kết qu d li u ả ữ ệ

6 S lượng thành viên có level 2 tr lên t ng nhóm ngành ở ừ

SELECT JobTitle, Count(BusinessEntityID)

FROM person_person INNER JOIN humanresources_employee USING

(BusinessEntityID)

WHERE OrganizationLevel > 2 GROUP BY Jobtitle

14

Phần 2: Các câu l nh truy v n và tệ ấ ối ưu truy vấn

Kết qu d li u ả ữ ệ

SELECT ProductID, Name, ProductNumber, SafetyStockLevel CASE SafetyStockLevel

WHEN ’1000’ THEN ‘HIGH’ WHEN ’800’ THEN ‘MEDIUM’

END StockLevel FROM production_product

Kết qu d li u ả ữ ệ

SELECT person_stateprovince.Name, StateProvinceCode, CountryRegionCode,

TaxType, TaxRate, Type

FROM person_stateprovince

INNER JOIN sales_salestaxrate USING (StateProvinceID)

INNER JOIN production_productcategory USING (ProductCategoryID)

18

Phần 2: Các câu l nh truy v n và t i ệ ấ ố ưu truy vấn

Kết qu d li u ả ữ ệ

Tối ưu truy vấn

1 Index

bản ghi trong trường đó trỏ đến bản ghi tương ứng trong bảng được đánh chỉ m甃⌀c • Cách t o Indexạ : CREATE INDEX index_name

ON table_name(column_name)

• Phân loại index

o Clustered Index: là Index độc nhấ ớt v i m i bỗ ảng, được tự độ ng tạo thành m i khi m t b ng mỗ ộ ả ới được tạo ra, dùng khóa chính

20

Phần 2: Các câu l nh truy v n và tệ ấ ối ưu truy vấn (Primary key) để sắp xếp dữ liệu trong bảng đó, đảm bảo khóa chính được sắp xếp theo thứ tự tăng dần

o Non clustered Index: là cấu trúc lưu lại thông tin đã được sắp x p ếcủa một trường d liữ ệu c甃⌀ ể th và m t con tr t m i bộ ỏ ừ ỗ ản ghi trong trường đó trỏ đến bản ghi tương ứng trong bảng được đánh chỉ m甃⌀c

• Cách Index tìm kiếm dữ ệ li u

Sau khi Index được khởi tạo, khi dữ liệu được truy vấn có liên quan đến index đó, nó sẽ dùng phương pháp tìm kiếm tối ưu: binary search (tìmkiếm nhị phân) Binary search hoạt động b ng cách liên tằ 甃⌀c so sánh kết quả với d li u ữ ệ ở giữa xem nó đã vượt qua giá trị m甃⌀c tiêu hay chưa và thực hi n ti p tệ ế 甃⌀c việc so sánh đó vớ ộ ửi m t n a ph n d li u có ch a giá ầ ữ ệ ứtrị m甃⌀c tiêu

• Một s lo i Index khác ố ạ

o Partial Index (Ch mỉ 甃⌀c m t ph n): ộ ầ Thay vì lưu tấ ả ữ ệt c d li u trong m t c t, ch mộ ộ ỉ 甃⌀c m t phộ ần lưu dữ ệ li u của một ph n cầ ột đó với điều kiện xác định

VD: CREATE INDEX Partial_Index on Traffic(dlstate) WHERE

dlstate=‘VA’

SELECT COUNT * FROM Traffic WHERE dlstate=‘VA’

Sử d甃⌀ng partial index giúp gi m b nhả ộ ớ lưu trữ tuy nhiên vi c này khi n index s không ệ ế ẽđược sử d甃⌀ng đến thường xuyên, thậm chí sẽ không bao gi ờ được sử d甃⌀ng đến

o Multicolumn Index (ch mỉ 甃⌀c nhiề ột): Tương tự như Index u cthông thường, nhưng index trước sẽ chứa thêm con trỏ trỏ đến index sau

22

Phần 2: Các câu l nh truy v n và tệ ấ ối ưu truy vấn

CREATE INDEX vehicle_year_make_model on

• Ví d甃⌀: Không có index: ≈ 327 (ms)

Có index: ≈ 23 (ms)

24

Phần 2: Các câu l nh truy v n và tệ ấ ối ưu truy vấn Không có index: ≈ 16865,5 (ms)

Có index: ≈ 15810,2 (ms)

2 Partition

trên b nh c a h th ng, cho phép vi c phân chia các ph n d li u c a b ng ộ ớ ủ ệ ố ệ ầ ữ ệ ủ ả(partitions) dựa trên m t t p h p các ộ ậ ợ điều ki n ệ đượ định nghĩac (partitioning function) Do đó, khi truy vấn trong một bảng đã được phân vùng, việc quét vùng sẽ ít hơn và do đó truy vẫn sẽ nhanh hơn

Các cách Partitioning:

• RANGE PARTITIONING • LIST PARTITIONING • HASH PARTITIONING • KEY PARTITIONING Lợi th khi s dế ử 甃⌀ng partition:

Xóa: Xóa b m t ỏ ộ phân vùng cũ một cách d dàng, gễ ần như ngay lập t c, thay vì ứdùng delete có th m t r t nhi u th i gian ể ấ ấ ề ờ

26

Phần 2: Các câu l nh truy v n và t i ệ ấ ố ưu truy vấn

Phương pháp xóa bằng Partitioning

Thời gian s dử 甃⌀ng: 31 (ms), nhanh hơn đáng kể so với việc xóa truyền th ng ố

có thời gian s dử 甃⌀ng: 3204 (ms)

CALL procedure_name ([param1, param2,…]);

DROP PROCEDURE procedure_name;

5) Một s th tố ủ ục cập nhật d li u ữ ệ

a Insert

28

Phần 3: C p nh t d li u ậ ậ ữ ệ

b Update

c Delete

Giao d ch (Transaction) ị

1) Transaction là gì?

Có thể hiểu Transaction là một tiến trình xử lý có xác định điểm đầu và điểm cuối, được chia nhỏ thành các operation (phép thực thi), tiến trình được thực thi một cách tuần tự và độc lập các operation đó theo nguyên tắc hoặc tất cả đều thành công hoặc một operation thất bại thì toàn bộ tiến trình thất bại Nếu việc thực thi một operation nào đó bị fail đồng nghĩa với việc dữ liệu phải rollback về trạng thái ban đầu Có thể lấy ví d甃⌀ về 1 Transaction đơn giản nhất là tiến trình cài đặt phần mềm hoặc gỡ bỏ phần mềm Việc cài đặt được chia thành các bước, thực hiện tuần tự từ đầu đến cuối, nếu toàn bộ các bước thực thi thành công đồng nghĩa với việc tiến trình cài đặt hoặc gỡ bỏ phần mềm thành công và ngược lại, một phép thất bại thì tiến trình phải rollback lại tức sẽ không có bất kỳ thay đổi nào trên máy tính

2) Cách bắt đầu một transaction

Để bắt đầu 1 transaction begin transaction;

Nếu các thao tác trên transaction thành công commit;

Ngược lại, nếu m t trong các thao tác gặp lỗi ộ rollback;

30

Phần 3: C p nh t d li u ậ ậ ữ ệ

• Atomicity - Tính b o toàn ả• Consistency - Tính nh t quán ấ• Isolation - Tính c l p độ ậ• Durability - Tính b n v ng ề ữ

• ROLLBACK: là lệnh điều khiển Transaction được sử d甃⌀ng để trao trả Transaction về trạng thái trước khi có các thay đổi mà chưa được lưu t i Database Lớ ệnh Rollback ch có thỉ ể được sử d甃⌀ng để Undo các Transaction trước khi xác nhận bằng lệnh Commit hay Rollback cuối cùng

• COMMIT: Khi m t Transaction hoàn chộ ỉnh được hoàn thành thì lệnh Commit phải được gọi ra Đây là lệnh điều khiển Transaction được sửd甃⌀ng để lưu các thay đổi gọi bởi một Transaction tới cơ sở dữ liệu Commit xong thì không thể Rollback được nữa

• SAVEPOINT: là một điểm trong m t Transaction giúp b n có th lùi ộ ạ ểTransaction trở l i mạ ột điểm nhất định mà không c n lùi Transaction ầvề tr ng ạ thái đầu trước khi có thay đổi đó

32

Phần 3: C p nh t d li u ậ ậ ữ ệ

Insert cuối cùng được khôi ph甃⌀c lại Vì v y ch có hoậ ỉ ạt động Insert đầu tiên di n ra sau khi b n Rollback v SP2 ễ ạ ề

• RELEASE SAVEPOINT: được sử d甃⌀ng để ạ ỏ ộ lo i b m t Savepoint bạn đã tạo ra Khi Savepoint bị xóa, bạn không thể sử d甃⌀ng lệnh Rollback để hoàn tác các Transaction về Savepoint đó nữa

VD: Vì đã xóa Savepoint SP3 rồi nên không th Rollback l i SP3 ể ạđược nữa

• SET TRANSACTION: có thể đượ ửc s d甃⌀ng để ở ạ kh i t o m t ộDatabase Transaction Lệnh này đượ ửc s d甃⌀ng để ỉ định các đặ ch c tính cho Transaction đó Ví d甃⌀, bạn có thể chỉ nh m t Transaction đị ộchỉ được đ c (read only) hoọ ặc đọc vi t (read write) ế

34

Phần 3: C p nh t d li u ậ ậ ữ ệ• Thực hi n vi c gệ ệ ọi Procedure để đổ cơ sở ữ ệ d li u

Kết lu n ậ

• Nhóm 16 đã thực hành trên h qu n tr CSDL MySQL, thệ ả ị ực hiện vi c thi t k , ệ ế ếchuẩn hóa, v sẽ ơ đồ, truy v n các câu l nh khá phấ ệ ức tạp, t i ố ưu được truy v n ấsử d甃⌀ng index, thành th o viạ ệc sử d甃⌀ng Procedure đổ d li u sang các CSDL ữ ệkhác

• Nhóm c ng hi u thêm ũ ể được những nghi p vệ 甃⌀ ực tế ủ th c a CSDL thông qua Transaction

• Trong quá trình làm vi c, qua trao i, các thành viên trong nhóm c ng ã giúp ệ đổ ũ đđỡ nhau g rối và trao i tích lũy thêm kinh nghiệm ỡ đổ

• Tuy phải làm vi c online, c ng có ôi lúc g p khó khệ ũ đ ặ ăn, nhưng nhóm ã v t đ ượqua được nh ng rào c n khó khữ ả ăn đó b ng cách s dằ ử 甃⌀ng các công c甃⌀ làm vi c ệonline trao i để đổ

• Nhóm c ng h c thêm ũ ọ được từ ầ th y và các nhóm trình bày khác nh ng k nữ ỹ ăng mới như kế ốt n i CSDL với các ngôn ng l p trình, s dữ ậ ử 甃⌀ng các ngôn ng l p ữ ậtrình t sinh ra query và các k nđể ự ỹ ăng thuyết trình, trình bày slide thuy t ếtrình,…

Nhóm chúng em xin c m ả ơn thầy Nguy n Danh Tú ã gi ng d y, t o m t môi ễ đ ả ạ ạ ộtrường h c t p, trao ọ ậ đổi b ích giúp chúng em trao ổ đổi, trau d i kồ ĩ năng của bản thân!