Xin chào! Tên tôi là Andrey Semenov, tôi là nhà phân tích cấp cao tại Sportmaster. Trong bài đăng này tôi muốn nêu vấn đề không chuẩn hóa cơ sở dữ liệu hệ thống ERP. Chúng ta sẽ xem xét các điều kiện chung cũng như một ví dụ cụ thể - giả sử đây sẽ là một quán rượu độc quyền tuyệt vời dành cho cướp biển và thủy thủ. Trong đó cướp biển và thủy thủ phải được phục vụ khác nhau, bởi vì ý tưởng về vẻ đẹp và cách tiêu dùng của những quý ông tốt bụng này khác nhau đáng kể.
Làm thế nào để làm cho mọi người hạnh phúc? Làm thế nào bạn có thể tránh việc thiết kế và bảo trì một hệ thống như vậy một cách điên cuồng? Phải làm gì nếu không chỉ những tên cướp biển và thủy thủ thông thường mới bắt đầu đến quán rượu?
Mọi thứ đều đang được cắt giảm. Nhưng hãy đi theo thứ tự.
1. Hạn chế và giả định
Tất cả những điều trên chỉ áp dụng cho cơ sở dữ liệu quan hệ. Hậu quả của việc không chuẩn hóa dưới dạng các dị thường sửa đổi, xóa và chèn, được đề cập kỹ lưỡng, bao gồm cả trên Internet, không được xem xét. Ngoài phạm vi của ấn phẩm này, có những trường hợp trong đó việc không chuẩn hóa là một trường hợp phổ biến, với các ví dụ cổ điển: chuỗi và số hộ chiếu, ngày và giờ, v.v.
Bài viết sử dụng các định nghĩa trực quan và có thể áp dụng thực tế của các dạng chuẩn mà không cần tham chiếu đến các thuật ngữ toán học. Ở dạng mà chúng có thể được áp dụng để kiểm tra các quy trình kinh doanh thực tế (BP) và thiết kế phần mềm công nghiệp.
Người ta lập luận rằng thiết kế kho dữ liệu, công cụ báo cáo và thỏa thuận tích hợp (sử dụng biểu diễn thông tin dạng bảng) khác với thiết kế cơ sở dữ liệu hệ thống ERP ở chỗ dễ sử dụng và việc sử dụng tính năng phi chuẩn hóa có ý thức để đạt được nó có thể được ưu tiên hơn tính toàn vẹn dữ liệu bảo vệ. Tôi chia sẻ quan điểm này và những gì được mô tả dưới đây chỉ áp dụng cho dữ liệu chính và mô hình dữ liệu giao dịch của hệ thống ERP.
Giải thích về các dạng chuẩn được đưa ra bằng cách sử dụng một ví dụ có thể hiểu được ở cấp độ hàng ngày đối với hầu hết người đọc. Tuy nhiên, như một minh họa trực quan, trong đoạn văn 4-5, một nhiệm vụ “hư cấu” có chủ ý đã được sử dụng một cách có chủ ý. Nếu bạn không làm điều này và lấy một số ví dụ trong sách giáo khoa, ví dụ, mô hình lưu trữ thứ tự tương tự từ điểm 2, bạn có thể thấy mình ở trong tình huống mà trọng tâm của người đọc sẽ chuyển từ việc phân rã quy trình được đề xuất thành một mô hình, đến trải nghiệm và nhận thức cá nhân về cách xây dựng các quy trình và mô hình lưu trữ dữ liệu trong IS. Nói cách khác, hãy lấy hai nhà phân tích CNTT có trình độ, để một người cung cấp dịch vụ cho các nhà hậu cần vận chuyển hành khách, người kia cung cấp dịch vụ cho các nhà hậu cần vận chuyển máy móc để sản xuất vi mạch. Yêu cầu họ tạo một mô hình dữ liệu để lưu trữ thông tin về chuyến đi đường sắt mà không cần thảo luận trước về các BP tự động.
Có một xác suất khác XNUMX là trong các mô hình được đề xuất, bạn sẽ không chỉ tìm thấy một tập hợp thuộc tính khác nhau đáng chú ý mà còn tìm thấy các tập hợp thực thể khác nhau, bởi vì mỗi nhà phân tích sẽ dựa vào các quy trình và nhiệm vụ quen thuộc với mình. Và trong tình huống như vậy thì không thể nói mô hình nào là “đúng”, vì không có tiêu chí đánh giá.
2. Hình thức thông thường
Dạng bình thường đầu tiên của cơ sở dữ liệu đòi hỏi tính nguyên tử của tất cả các thuộc tính.
Cụ thể, nếu đối tượng A có các thuộc tính không khóa a và b, sao cho c=f(a,b) và trong bảng mô tả đối tượng A mà bạn lưu giá trị của thuộc tính c thì dạng chuẩn đầu tiên sẽ bị vi phạm trong cơ sở dữ liệu . Ví dụ: nếu thông số kỹ thuật của đơn đặt hàng chỉ ra một số lượng, đơn vị đo lường của nó phụ thuộc vào loại sản phẩm: trong một trường hợp, nó có thể là miếng, trong một lít khác, trong gói thứ ba gồm các miếng (trong mô hình ở trên Good_count_WR) , thì tính nguyên tử của các thuộc tính trong cơ sở dữ liệu bị vi phạm. Trong trường hợp này, để nói cụm bảng của đặc tả đơn hàng phải là gì, bạn cần mô tả có mục tiêu về quy trình làm việc trong IS và vì các quy trình có thể khác nhau nên có thể có nhiều phiên bản “chính xác”.
Dạng bình thường thứ hai của cơ sở dữ liệu yêu cầu tuân thủ biểu mẫu đầu tiên và bảng riêng cho từng thực thể liên quan đến quy trình làm việc trong IS. Nếu trong một bảng có các phụ thuộc c=f1(a) và d=f2(b) và không có phụ thuộc c=f3(b), thì dạng chuẩn thứ hai bị vi phạm trong bảng. Trong ví dụ trên, không có sự phụ thuộc giữa thứ tự và địa chỉ trong bảng Đơn hàng. Thay đổi tên đường phố hoặc thành phố và bạn sẽ không có tác dụng gì đối với các thuộc tính thiết yếu của đơn hàng.
Cơ sở dữ liệu dạng chuẩn thứ ba yêu cầu tuân thủ dạng chuẩn thứ hai và không có sự phụ thuộc chức năng giữa các thuộc tính của các thực thể khác nhau. Quy tắc này có thể được xây dựng như sau: “mọi thứ có thể tính toán được đều phải được tính toán”. Nói cách khác, nếu có hai đối tượng A và B. Trong bảng lưu trữ các thuộc tính của đối tượng A, thuộc tính C được biểu hiện và đối tượng B có thuộc tính b, sao cho tồn tại c=f4(b), thì dạng chuẩn thứ ba bị vi phạm. Trong ví dụ bên dưới, thuộc tính Số lượng số lượng (Tổng_số_WR) trên bản ghi đơn hàng tuyên bố rõ ràng là vi phạm dạng thông thường thứ ba
3. Cách tiếp cận của tôi để áp dụng chuẩn hóa
1. Chỉ quy trình kinh doanh tự động hóa mục tiêu mới có thể cung cấp cho nhà phân tích các tiêu chí để xác định các thực thể và thuộc tính khi tạo mô hình lưu trữ dữ liệu. Tạo mô hình quy trình là điều kiện tiên quyết để tạo mô hình dữ liệu thông thường.
2. Việc đạt được dạng chuẩn thứ ba theo nghĩa chặt chẽ có thể không thực tế trong thực tế tạo ra hệ thống ERP nếu đáp ứng một số hoặc tất cả các điều kiện sau:
- quy trình tự động hiếm khi có thể thay đổi,
- thời hạn nghiên cứu và phát triển rất chặt chẽ,
- yêu cầu về tính toàn vẹn dữ liệu tương đối thấp (các lỗi tiềm ẩn trong phần mềm công nghiệp không dẫn đến việc khách hàng phần mềm mất tiền hoặc mất khách hàng)
- vv
Trong các điều kiện được mô tả, chi phí để xác định và mô tả vòng đời của một số đối tượng và các thuộc tính của chúng có thể không được chứng minh theo quan điểm hiệu quả kinh tế.
3. Mọi hậu quả của việc không chuẩn hóa mô hình dữ liệu trong IS đã được tạo có thể được giảm thiểu bằng cách nghiên cứu sơ bộ kỹ lưỡng về mã và thử nghiệm.
4. Phi chuẩn hóa là cách chuyển chi phí nhân công từ giai đoạn nghiên cứu nguồn dữ liệu và thiết kế quy trình nghiệp vụ sang giai đoạn phát triển, từ giai đoạn triển khai sang giai đoạn phát triển hệ thống.
5. Nên phấn đấu đạt được dạng cơ sở dữ liệu bình thường thứ ba nếu:
- Hướng thay đổi trong quy trình kinh doanh tự động khó dự đoán
- Có sự phân công lao động yếu kém trong nhóm thực hiện và/hoặc nhóm phát triển
- Các hệ thống trong mạch tích hợp phát triển theo kế hoạch riêng
- Dữ liệu không nhất quán có thể dẫn đến việc công ty mất khách hàng hoặc tiền bạc
6. Việc thiết kế mô hình dữ liệu chỉ được thực hiện bởi nhà phân tích liên quan đến các mô hình của quy trình nghiệp vụ mục tiêu và quy trình trong IS. Nếu một nhà phát triển đang thiết kế một mô hình dữ liệu, anh ta sẽ phải đắm mình vào lĩnh vực chủ đề đến mức đặc biệt, anh ta hiểu được sự khác biệt giữa các giá trị thuộc tính - một điều kiện cần thiết để cô lập các thuộc tính nguyên tử. Vì vậy, đảm nhận các chức năng bất thường.
4 Bài toán minh họa
Giả sử bạn có một quán rượu robot nhỏ ở cảng. Phân khúc thị trường của bạn: thủy thủ và cướp biển vào cảng và cần nghỉ ngơi. Bạn bán trà với húng tây cho các thủy thủ, rượu rum và lược xương để chải râu cho bọn cướp biển. Bản thân dịch vụ trong quán rượu được cung cấp bởi một nữ tiếp viên robot và một nhân viên pha chế robot. Nhờ chất lượng cao và giá thấp, bạn đã đánh bật các đối thủ cạnh tranh của mình, để mọi người xuống tàu đều đến quán rượu của bạn, quán rượu duy nhất ở cảng.
Tổ hợp hệ thống thông tin quán rượu bao gồm các phần mềm sau:
- Hệ thống cảnh báo sớm về khách hàng nhận dạng danh mục của họ dựa trên các đặc điểm đặc trưng
- Hệ thống điều khiển dành cho robot tiếp viên và robot pha chế rượu
- Hệ thống quản lý kho và giao hàng đến điểm bán
- Hệ thống quản lý quan hệ nhà cung cấp (SURP)
Quy trình:
Hệ thống cảnh báo sớm nhận biết người rời tàu. Nếu một người cạo râu sạch sẽ, cô ấy xác định anh ta là thủy thủ; nếu một người bị phát hiện có râu thì anh ta được xác định là cướp biển.
Bước vào quán rượu, vị khách nghe thấy lời chào từ bà chủ robot phù hợp với hạng mục của mình, ví dụ: “Ho-ho-ho, cướp biển thân mến, hãy đến bàn số…”
Khách đi đến bàn quy định, nơi người pha chế robot đã chuẩn bị sẵn hàng hóa cho anh ta theo đúng chủng loại. Người pha chế robot truyền thông tin đến hệ thống kho hàng rằng phần giao hàng tiếp theo sẽ được tăng lên; kho IS, dựa trên số dư còn lại trong kho, tạo ra yêu cầu mua hàng trong hệ thống quản lý.
Mặc dù hệ thống cảnh báo sớm có thể được phát triển bởi bộ phận CNTT nội bộ của bạn nhưng chương trình quản lý robot tại quầy bar có thể được tạo bởi một nhà thầu bên ngoài dành riêng cho doanh nghiệp của bạn. Và hệ thống quản lý kho hàng và mối quan hệ với nhà cung cấp là những giải pháp đóng gói tùy chỉnh từ thị trường.
5. Ví dụ về việc không chuẩn hóa và tác động của nó đối với việc phát triển phần mềm
Khi thiết kế quy trình kinh doanh, các chuyên gia về chủ đề được phỏng vấn đều nhất trí khẳng định rằng trên khắp thế giới, cướp biển uống rượu rum và chải râu bằng lược xương, còn thủy thủ uống trà với cỏ xạ hương và luôn cạo râu sạch sẽ.
Một danh mục các loại khách hàng xuất hiện với hai giá trị: 1 - cướp biển, 2 - thủy thủ, chung cho toàn bộ mạch thông tin của công ty.
Hệ thống thông báo khách hàng ngay lập tức lưu trữ kết quả xử lý hình ảnh dưới dạng mã định danh (ID) của khách hàng được nhận dạng và loại của nó: thủy thủ hoặc cướp biển.
ID đối tượng được công nhận
Danh mục khách hàng
100500
Cướp biển
100501
Cướp biển
100502
Thủy thủ
Chúng ta hãy lưu ý một lần nữa rằng
1. Thủy thủ của chúng ta thực chất là những người cạo trọc đầu
2. Cướp biển của chúng ta thực chất là những người có râu
Những vấn đề nào trong trường hợp này cần được loại bỏ để cấu trúc của chúng ta phấn đấu đạt được dạng chuẩn thứ ba:
- vi phạm tính nguyên tử thuộc tính - Danh mục khách hàng
- trộn lẫn thực tế được phân tích và kết luận trong một bảng
- mối quan hệ chức năng cố định giữa các thuộc tính của các thực thể khác nhau.
Ở dạng chuẩn hóa, chúng ta sẽ nhận được hai bảng:
- kết quả nhận dạng dưới dạng một tập hợp các đặc điểm đã được thiết lập,
ID đối tượng được công nhận
Lông mặt
100500
vâng
100501
vâng
100502
Không
- kết quả của việc xác định loại máy khách như một ứng dụng logic được nhúng trong IS để diễn giải các đặc điểm đã thiết lập
ID đối tượng được công nhận
ID nhận dạng
Danh mục khách hàng
100500
100001
Cướp biển
100501
100002
Cướp biển
100502
100003
Thủy thủ
Làm thế nào một tổ chức lưu trữ dữ liệu được chuẩn hóa có thể tạo điều kiện thuận lợi cho sự phát triển của tổ hợp IP? Giả sử bạn đột nhiên có được khách hàng mới. Hãy để những tên cướp biển Nhật Bản có thể không có râu nhưng họ bước đi với một con vẹt trên vai, còn những tên cướp biển bảo vệ môi trường, bạn có thể dễ dàng nhận ra họ nhờ hình ảnh màu xanh lam của Greta trên ngực trái.
Đương nhiên, những tên cướp biển môi trường không thể sử dụng lược xương và yêu cầu một loại tương tự được làm từ nhựa biển tái chế.
Bạn cần phải làm lại các thuật toán của chương trình cho phù hợp với các đầu vào mới. Nếu tuân theo các quy tắc chuẩn hóa thì bạn sẽ chỉ phải bổ sung đầu vào cho một số nhánh quy trình trong một số hệ thống và chỉ tạo các nhánh mới cho những trường hợp đó và trong những IS có lông mặt quan trọng. Tuy nhiên, vì các quy tắc không được tuân theo, bạn sẽ phải phân tích toàn bộ mã, trong toàn bộ mạch, nơi sử dụng các giá trị của thư mục loại máy khách và xác định rõ ràng rằng trong một trường hợp, thuật toán phải tính đến chuyên gia hoạt động của khách hàng và các đặc điểm vật lý khác.
Ở dạng đó tìm kiếm để chuẩn hóa, chúng ta sẽ nhận được hai bảng chứa dữ liệu vận hành và hai thư mục:
- kết quả nhận dạng dưới dạng một tập hợp các đặc điểm đã được thiết lập,
ID đối tượng được công nhận
Greta trên ngực trái
Con chim trên vai
Lông mặt
100510
1
1
1
100511
0
0
1
100512
1
0
- kết quả của việc xác định loại khách hàng (đặt nó ở chế độ xem tùy chỉnh trong đó hiển thị mô tả từ các thư mục)
Liệu sự không chuẩn hóa được phát hiện có nghĩa là hệ thống không thể được sửa đổi để đáp ứng các điều kiện mới? Dĩ nhiên là không. Nếu chúng ta tưởng tượng rằng tất cả các hệ thống thông tin được tạo ra bởi một nhóm với tỷ lệ luân chuyển nhân viên bằng 1,5, các quá trình phát triển được ghi lại rõ ràng và thông tin được chuyển giao trong nhóm mà không bị mất mát, thì những thay đổi cần thiết có thể được thực hiện với nỗ lực không đáng kể. Nhưng nếu quay trở lại điều kiện ban đầu của bài toán, 0,5 bàn phím sẽ bị xóa chỉ để in các biên bản thảo luận chung và XNUMX bàn phím khác để xử lý thủ tục mua sắm.
Trong ví dụ trên, cả ba dạng thông thường đều bị vi phạm, chúng ta hãy thử vi phạm chúng một cách riêng biệt.
Vi phạm dạng chuẩn thứ nhất:
Giả sử hàng hóa được chuyển đến kho của bạn từ kho của nhà cung cấp bằng cách nhận hàng bằng một con linh dương nặng 1.5 tấn thuộc quán rượu của bạn. Quy mô đơn đặt hàng của bạn quá nhỏ so với doanh thu của nhà cung cấp nên chúng luôn được hoàn thành riêng lẻ mà không cần chờ sản xuất. Bạn có cần các bảng riêng biệt với quy trình kinh doanh như: phương tiện, loại phương tiện, có cần tách biệt kế hoạch và thực tế trong đơn đặt hàng của bạn với các nhà cung cấp đã rời đi không?
Hãy tưởng tượng xem lập trình viên của bạn sẽ phải viết bao nhiêu kết nối “thêm” nếu bạn sử dụng mô hình bên dưới để phát triển một chương trình.
Giả sử chúng tôi quyết định rằng cấu trúc đề xuất phức tạp không cần thiết; trong trường hợp của chúng tôi, việc tách kế hoạch và thực tế trong hồ sơ đơn hàng là thông tin dư thừa và đặc tả đơn hàng được tạo ra được viết lại dựa trên kết quả chấp nhận hàng hóa đã đến, hiếm khi xảy ra sai sót. - Việc phân loại và vận chuyển hàng hóa không đạt chất lượng được giải quyết bên ngoài IS.
Và rồi một ngày bạn thấy toàn bộ quán rượu chứa đầy những tên cướp biển phẫn nộ và nhếch nhác. Chuyện gì đã xảy ra thế?
Hóa ra là khi doanh nghiệp của bạn phát triển thì mức tiêu thụ của bạn cũng tăng theo. Ngày xửa ngày xưa, ban quản lý đã đưa ra quyết định rằng nếu một con linh dương bị quá tải về số lượng và/hoặc trọng lượng, một trường hợp cực kỳ hiếm gặp, thì nhà cung cấp sẽ ưu tiên tải đồ uống.
Hàng hóa chưa giao đã kết thúc ở đơn hàng tiếp theo và rời đi trên chuyến bay mới, sự hiện diện của số dư tối thiểu trong kho tại quán rượu khiến không thể nhận thấy những trường hợp thiếu sót.
Đối thủ cạnh tranh cuối cùng đã đóng cửa tại cảng, và trường hợp quá tải của gazelle bị thủng, được bỏ qua bằng cách ưu tiên dựa trên giả định về việc có đủ số dư tối thiểu và định kỳ cho xe chở quá tải, đã trở thành thông lệ. Lý tưởng nhất là hệ thống được tạo sẽ hoạt động theo các thuật toán được nhúng trong đó và sẽ không có bất kỳ cơ hội nào để theo dõi lỗi hệ thống trong việc hoàn thành các đơn đặt hàng đã lên kế hoạch. Chỉ có danh tiếng bị tổn hại và khách hàng không hài lòng mới có thể phát hiện ra vấn đề.
Một người đọc chú ý có thể nhận thấy rằng số lượng đặt hàng trong đặc tả đơn hàng (T_ORDER_SPEC) trong phần 2 và phần 5 có thể đáp ứng hoặc không đáp ứng yêu cầu của dạng chuẩn thứ nhất. Tất cả phụ thuộc vào việc liệu, với loại hàng hóa đã chọn, các đơn vị đo lường cơ bản khác nhau có thể rơi vào cùng một lĩnh vực hay không.
Vi phạm dạng chuẩn XNUMX:
Khi nhu cầu của bạn tăng lên, bạn mua thêm một vài loại xe có kích cỡ khác nhau. Trong bối cảnh trên, việc tạo danh mục phương tiện được coi là dư thừa, do đó, tất cả các thuật toán xử lý dữ liệu phục vụ nhu cầu giao hàng và kho bãi đều coi việc di chuyển hàng hóa từ nhà cung cấp đến kho là chuyến bay của một chiếc xe tải 1,5 tấn độc quyền. linh dương. Vì vậy, cùng với việc mua xe mới, bạn vẫn tạo một danh mục xe, nhưng khi hoàn thiện nó, bạn sẽ phải phân tích tất cả các mã tham chiếu đến việc di chuyển của hàng hóa để tìm hiểu xem liệu ở mỗi địa điểm cụ thể, các tham chiếu có ngụ ý đến các đặc điểm hay không. của chính chiếc xe mà hoạt động kinh doanh bắt đầu.
Vi phạm dạng chuẩn thứ ba:
Tại một thời điểm nào đó, bạn bắt đầu tạo chương trình khách hàng thân thiết, một bản ghi về một khách hàng thường xuyên sẽ xuất hiện. Ví dụ: tại sao phải dành thời gian tạo các chế độ xem quan trọng để lưu trữ dữ liệu tổng hợp về doanh số bán hàng cho một khách hàng riêng lẻ để sử dụng trong báo cáo và chuyển sang hệ thống phân tích, nếu khi bắt đầu chương trình khách hàng thân thiết, mọi thứ mà khách hàng quan tâm đều có thể được lưu vào hồ sơ của khách hàng ? Và quả thực, thoạt nhìn thì chẳng có ích gì. Nhưng mỗi khi doanh nghiệp của bạn kết nối, chẳng hạn như các kênh bán hàng mới, phải có ai đó trong số các nhà phân tích của bạn sẽ nhớ rằng thuộc tính tổng hợp như vậy tồn tại.
Khi thiết kế từng quy trình mới, chẳng hạn như bán hàng trên Internet, bán hàng thông qua nhà phân phối được kết nối với hệ thống khách hàng thân thiết chung, ai đó phải lưu ý rằng tất cả các quy trình mới phải đảm bảo tính toàn vẹn dữ liệu ở cấp độ mã. Đối với một cơ sở dữ liệu công nghiệp có hàng nghìn bảng, đây dường như là một nhiệm vụ bất khả thi.
Tất nhiên, một nhà phát triển có kinh nghiệm sẽ biết cách ngăn chặn tất cả các vấn đề nêu trên, nhưng theo tôi, nhiệm vụ của một nhà phân tích có kinh nghiệm không phải là đưa chúng ra ánh sáng.
Tôi muốn bày tỏ lòng biết ơn tới nhà phát triển hàng đầu Evgeniy Yarukhin vì những phản hồi quý báu của ông trong quá trình chuẩn bị xuất bản.
Văn chương
Connolly Thomas, Begg Caroline. Cơ sở dữ liệu. Thiết kế, triển khai và hỗ trợ. Lý thuyết và thực hành
Nguồn: www.habr.com