Làm thế nào để bạn tiếp cận thiết kế cơ sở dữ liệu? [đóng cửa]

Tôi chủ yếu là một nhà phát triển web và tôi có một vài dự án cá nhân mà tôi muốn khởi động.

Một điều làm tôi khó chịu là thiết kế cơ sở dữ liệu. Tôi đã trải qua quá trình chuẩn hóa db ở trường và những thứ tương tự nhưng nó đã được vài năm trước và tôi chưa bao giờ có kinh nghiệm với thiết kế cơ sở dữ liệu quan hệ ngoại trừ trường học.

Vì vậy, làm thế nào để bạn tiếp cận cơ sở dữ liệu từ góc độ ứng dụng web? Làm thế nào để bạn bắt đầu và những gì bạn tìm kiếm? Cờ cho thận trọng là gì?

Cuốn sách hay nhất tôi từng mua về thiết kế cơ sở dữ liệu là Thiết kế cơ sở dữ liệu cho những người bình thường của Michael Hernandez ISBN: 0-201-69471-9. Danh sách Amazon Tôi nhận thấy anh ta có phiên bản thứ ba.

Liên kết đến phiên bản thứ ba

Anh ấy sẽ hướng dẫn bạn toàn bộ quá trình (từ đầu đến cuối) của việc thiết kế cơ sở dữ liệu. Tôi khuyên bạn nên bắt đầu với cuốn sách này.

Bạn phải học cách nhìn mọi thứ theo nhóm hoặc khối. Thiết kế cơ sở dữ liệu có các khối xây dựng đơn giản giống như lập trình. Nếu bạn có được sự hiểu biết thấu đáo về các khối xây dựng đơn giản này, bạn có thể giải quyết bất kỳ thiết kế cơ sở dữ liệu nào.

Trong lập trình bạn có:

• Nếu xây dựng
• Nếu khác xây dựng
• Làm trong khi vòng
• Làm cho đến khi vòng
• Xây dựng trường hợp

Với cơ sở dữ liệu bạn có:

• Bảng dữ liệu
• Bảng tra cứu
• Mối quan hệ một đối một
• Một đến nhiều mối quan hệ
• Nhiều mối quan hệ
• Khóa chính
• Khóa ngoại

Bạn càng đơn giản làm cho mọi thứ tốt hơn. Cơ sở dữ liệu không gì khác hơn là nơi bạn đặt dữ liệu vào các lỗ cubbie. Bắt đầu bằng cách xác định những lỗ cubbie này là gì và loại công cụ bạn muốn trong đó.

Bạn sẽ không bao giờ tạo ra thiết kế cơ sở dữ liệu hoàn hảo ngay lần đầu tiên bạn thử. Đây là sự thật. Thiết kế của bạn sẽ trải qua một số tinh chỉnh trong quá trình. Đôi khi mọi thứ dường như không rõ ràng cho đến khi bạn bắt đầu nhập dữ liệu, và sau đó bạn có một khoảnh khắc ah ha .

Web mang đến những thách thức riêng. Các vấn đề về Bandwith. Không quốc tịch. Dữ liệu sai lệch từ các quá trình bắt đầu nhưng không bao giờ kết thúc.

Tôi thực hiện cả lập trình hướng đối tượng và thiết kế cơ sở dữ liệu (chủ yếu là giao dịch, nhưng một số OLAP) và trong hoàn cảnh của tôi, có rất nhiều chủ đề định kỳ (ít nhất là với OLTP).

Thực hành chuẩn hóa 3nf giúp tôi thực hành một số biến thể của nguyên tắc trách nhiệm duy nhất. Một bảng sẽ đại diện cho một khái niệm trong hệ thống của bạn - và các khái niệm nên liên quan đến nhau để chúng cố gắng bắt chước thực tế; chẳng hạn, nếu tôi đang xây dựng một hệ thống trong đó Khách hàng có thể có 0 hoặc nhiều Hoạt động, thì tôi tạo Bảng khách hàng và Bảng hoạt động. Bảng hoạt động có mối quan hệ khóa ngoại với bảng Khách hàng. Khi tôi xây dựng các thủ tục được lưu trữ, tôi sẽ đảm bảo sử dụng một tham gia bên ngoài để tham gia Khách hàng và hoạt động vì yêu cầu kinh doanh là Khách hàng có thể có 0 hoạt động.

Tôi cũng coi chừng các cơ hội mở rộng bằng cách sử dụng các bảng cầu nối (liên kết). Chẳng hạn, nếu tôi đang cố gắng thể hiện quy tắc kinh doanh trong đó một cuốn sách có thể có số lượng tác giả (biến) không giới hạn, tôi sẽ tạo Bảng sách, bảng Tác giả và bảng cầu nối / liên kết có tham chiếu khóa ngoài cho cả hai Sách và tác giả.

Ngoài ra, tôi sử dụng các khóa thay thế trên tất cả các bảng (thường là các cột nhận dạng tự động tăng, nhưng có lẽ là Guids - sự đánh đổi với các hướng dẫn trong mã là chúng chiếm nhiều không gian bộ nhớ hơn một số nguyên đơn giản) và tôi tránh dựa vào các khóa tự nhiên cho tôi tra cứu (ngoại trừ với Bridge / Link Table). Theo mặc định, tôi cũng tạo các chỉ mục trên các cột khóa ngoài phổ biến và xem xét các thủ tục / truy vấn hệ thống được lưu trữ theo thời gian để tối ưu hóa các chiến lược lập chỉ mục. Một chiến lược lập chỉ mục khác mà tôi sử dụng là tìm kiếm các vị trí trong mã của mình nơi tôi xây dựng bộ sưu tập dựa trên cột tìm kiếm và thêm các chỉ mục thích hợp vào các cột tìm kiếm.

Tôi thiết kế lược đồ cơ sở dữ liệu của mình trước, sau đó sử dụng ORM để tạo các đối tượng từ nó. Tôi là một trường học hơi cũ theo cách đó; Tôi không tin tưởng ORM để tạo ra một lược đồ cơ sở dữ liệu thông minh, hiệu quả. Đó là công việc của con người và là một phần của nghề thiết kế phần mềm.

Tôi thấy cuốn sách của Bill Karwin, SQL Antipotypes , thực sự hữu ích cho việc lập kế hoạch cơ sở dữ liệu. Điểm mà nó làm cho toàn diện nhất là cơ sở dữ liệu cung cấp nhiều cơ hội để bảo vệ tính toàn vẹn và ý nghĩa của dữ liệu của bạn và đó là một lỗi phổ biến của các nhà thiết kế để bỏ qua các tính năng này vì nhiều lý do hấp dẫn. Xem xét các vấn đề này ngay từ đầu và để chúng thông báo cho toàn bộ thiết kế là đáng giá và nhịp đập cố gắng để viết lên các vết nứt sau đó.

Tôi thích sử dụng một cơ sở dữ liệu có các ràng buộc toàn diện để thực thi logic và tính toàn vẹn của doanh nghiệp ở cấp cơ sở dữ liệu. Thường thì tôi thấy cơ sở dữ liệu là ứng dụng và bất cứ thứ gì truy cập vào nó như một giao diện đơn thuần. Điều này làm cho việc bổ sung các "giao diện" khác trở thành một trải nghiệm dễ chịu và đơn giản hơn và có lợi ích tích cực cho bảo mật.

Tôi cũng nghĩ rằng điều quan trọng là phải xem cấu trúc của cơ sở dữ liệu như một thực thể thay đổi, thay vì giả định rằng bạn cần phải bọc lại và niêm phong nó trước khi bắt đầu bất cứ điều gì khác. Bạn nên lập kế hoạch thay đổi và điều chỉnh DB trong hệ thống phiên bản của bạn. Có một bài luận hay về điều này: Thiết kế cơ sở dữ liệu tiến hóa của Martin Fowler & Pramod Sadalage (và cả một cuốn sách về chủ đề của Sadalage, mặc dù tôi chưa đọc nó).

Cuối cùng, các vấn đề ngoại vi của tài khoản / vai trò người dùng, phần cứng / vị trí / kết nối của máy chủ, v.v ... rất quan trọng và đôi khi bị bỏ qua. Hãy ghi nhớ những điều này khi lập kế hoạch.

thiết kế cơ sở dữ liệu không thể được thực hiện hoàn toàn mà không xem xét cách sử dụng dữ liệu, vì vậy đây là danh sách các bước ngắn:

• viết câu ngắn để nắm bắt mối quan hệ giữa các thực thể
• vẽ sơ đồ mối quan hệ thực thể đại diện cho các câu
• tạo một mô hình dữ liệu lôgic chuẩn hóa từ sơ đồ ER
• tạo ma trận CRUD cho các ứng dụng và thực thể
• sử dụng ma trận để xác minh phạm vi bảo hiểm của vòng đời của mỗi thực thể
• trích xuất các hóa đơn cho mỗi ứng dụng
• kiểm tra các đường dẫn điều hướng qua các bộ phận con cho từng thao tác chính / CRUD
• xem xét các báo cáo sẽ được yêu cầu
• thiết kế mô hình dữ liệu vật lý dựa trên tất cả những điều trên; không chuẩn hóa, phân vùng và sử dụng lược đồ sao khi thích hợp

Để thiết kế thành công cơ sở dữ liệu, bạn cần xem xét một số điều trước tiên:

• Tôi cần lưu trữ dữ liệu gì và nó liên quan đến dữ liệu khác tôi lưu trữ như thế nào. Dữ liệu này sẽ cần thay đổi theo thời gian như thế nào? Tôi có cần phải có thể xem ảnh chụp nhanh đúng lúc (đơn hàng đó từ năm 2009) hay tôi chỉ cần những gì hiện tại (chỉ người dùng hoạt động)?
• Làm cách nào để đảm bảo dữ liệu của tôi có ý nghĩa và duy trì ý nghĩa theo thời gian (tính toàn vẹn dữ liệu)?
• Làm thế nào tôi có thể chắc chắn rằng truy cập dữ liệu nhanh?
• Làm cách nào để giữ an toàn cho dữ liệu của tôi?

Vì vậy, trước khi bắt đầu thiết kế cơ sở dữ liệu, trước tiên bạn cần tìm hiểu về chuẩn hóa và các tính năng của cơ sở dữ liệu được sử dụng để giữ tính toàn vẹn của dữ liệu.

Sau đó, bạn cần phải hiểu điều chỉnh hiệu suất. Đây không phải là sớm, hiệu suất là điểm thất bại quan trọng của hầu hết các cơ sở dữ liệu và rất khó để sửa chữa một khi bạn có hàng triệu hồ sơ.

Và cuối cùng, bạn cần hiểu cách bảo mật dữ liệu và dữ liệu nào cần được bảo mật và những kiểm soát nội bộ nào bạn cần để đảm bảo dữ liệu không bị thay đổi độc hại hoặc để đảm bảo bạn có thể theo dõi các thay đổi theo thời gian để tìm ra ai và khi nào một thay đổi đã được thực hiện và để có thể trở lại các phiên bản trước.

Cũng rất hữu ích khi đọc một chút về cơ cấu lại cơ sở dữ liệu trước khi bạn bắt đầu vì sẽ cần phải tái cấu trúc lại sau và rất hữu ích khi biết cách thiết lập mọi thứ để bạn có thể tái cấu trúc dễ dàng nhất có thể.

Nói chung, dữ liệu tồn tại lâu hơn ứng dụng trong nhiều năm, nó là trái tim của ứng dụng và không nên được coi là một kho dữ liệu ngu ngốc mà hầu như không liên quan.

Nói chung, thiết kế cơ sở dữ liệu tốt là thiết kế cơ sở dữ liệu tốt - câu hỏi lớn hơn cho việc sử dụng web sẽ là cách bạn truy cập dữ liệu và quản lý những thứ mà người ta có thể xem xét yêu cầu trạng thái mà về cơ bản web không có.

Nghĩ về nó, cách tiếp cận của tôi dựa trên kinh nghiệm thực sự khá nhiều ... nhưng cho dù bạn bắt đầu với lược đồ hay các đối tượng bạn thực sự đang cố gắng làm điều tương tự, ví dụ như xây dựng một mô hình dữ liệu có thể sử dụng được - cho một số lượng đáng kể các dự án có thể có mối quan hệ khá trực tiếp giữa mô hình và lược đồ (không phải trong mọi trường hợp và có lẽ không phải cho tất cả các bảng / đối tượng), vì vậy thực sự vấn đề xây dựng một mô hình phong nha bắt đầu từ bất cứ nơi nào bạn thấy thoải mái và làm việc từ đó.

Về mặt xây dựng một mô hình phong nha - @Tim có cơ sở dữ liệu và xây dựng mô hình đối tượng của bạn sẽ tương tự nhau - điều gì là độc nhất, thứ bậc, có nhiều mối quan hệ, v.v. đến cơ sở dữ liệu, đảm bảo rằng bạn làm tất cả những thứ tốt.

Ngoài ra, hãy đảm bảo rằng bạn có tập lệnh hoặc ddl trong mã để cho phép bạn tạo lược đồ từ đầu và cập nhật khi bạn thực hiện thay đổi (ddl trong mã là phương pháp ưa thích của tôi - Tôi có một hệ thống và nó hoạt động).

Tôi bắt đầu với một bảng trắng lớn và một loạt các màu bút khác nhau. Màu sắc khác nhau có nghĩa là những thứ khác nhau. Và tôi chỉ bắt đầu vẽ. Thông thường tôi vẽ những thứ xác định bằng màu đen, những thứ có khả năng màu xanh lam và những thứ không có màu xanh lá cây. Màu đỏ là cho ghi chú quan trọng. Tôi xóa và vẽ lại một cách cẩn thận. Tôi nghĩ về những loại điều tôi cần truy vấn và đảm bảo mô hình hỗ trợ nó. Nếu nó không tôi sẽ chỉnh cho đến khi nó làm.

Cuối cùng, nếu mô hình trở nên quá lớn, tôi sẽ chuyển nó sang Visio và làm việc trên các mảnh trở lại trên bảng trắng.

Cuối cùng tôi nghĩ về điểm mở rộng. Sai lầm lớn nhất tôi thấy hầu hết mọi người mắc phải là thiết kế cơ sở dữ liệu của họ và sau đó nói "Tôi đã hoàn thành với cơ sở dữ liệu" và tiếp tục. Bạn chưa bao giờ thực hiện với cơ sở dữ liệu. Mỗi yêu cầu thay đổi bạn nhận được có khả năng giảm xuống mức đó. Vì vậy, hãy suy nghĩ về cách thêm vào nó. Hãy suy nghĩ về những loại yêu cầu nào có khả năng và xem liệu bạn có thể kết nối chúng không. Nếu bạn không nghĩ gì về khả năng mở rộng, bạn sẽ rơi vào nợ thiết kế lớn khi những yêu cầu thay đổi đó xuất hiện.

Đối với "SQL thì ORM" hoặc ngược lại, điều đó tùy thuộc vào bạn. Chỉ cần chắc chắn rằng mô hình của bạn làm cho một nền tảng tốt đầu tiên.

Tôi thiết kế các đối tượng trước sau đó tôi sử dụng ORM (chẳng hạn như nHibernate) để tạo lược đồ. Nó cho tôi linh hoạt hơn rất nhiều so với việc làm ngược lại.

Bước tiếp theo là tối ưu hóa lược đồ được tạo.

Đã lâu lắm rồi tôi mới thấy một dự án nơi các bảng cơ sở dữ liệu được thiết kế đầu tiên.

Một số điều không được tuyên bố rõ ràng cho đến nay bởi các nghiên cứu sinh khác:

• Tốt nhất là thiết kế cơ sở dữ liệu được thực hiện bởi một người chuyên nghiệp. Tất nhiên là học được, nhưng tôi sẽ không đề xuất xây dựng một mô hình vừa hoặc lớn nếu một người không thành thạo trong mô hình hóa hoặc thiết kế cơ sở dữ liệu. Lý do cho điều này là chi phí của một thiết kế sai thường rất cao.

• Biết các mục tiêu hệ thống và yêu cầu người dùng tốt. Nếu không biết các yêu cầu, bạn không thể thiết kế mô hình dữ liệu chính xác.

• Biết mã nào sẽ làm trong các chương trình và mã nào để DB chăm sóc. Điều này là bắt buộc để bạn đặt cột dữ liệu là null, không phải null, v.v. Điều này cũng được yêu cầu để bạn chỉ định RI chính xác.

• Xác định tốt các khóa chính của bạn. Đi cho các phím đơn giản khi bạn có thể.

• Xem xét nhu cầu tích hợp với các ứng dụng khác.

• Xem xét sử dụng các mô hình dữ liệu phổ quát và tuân theo các tiêu chuẩn ngành trong việc đặt tên và kích thước cột dữ liệu.

• Hãy nghĩ về nhu cầu trong tương lai (khi biết và khi áp dụng)

• Có chế độ của bạn được xem xét bởi những người khác.

• Sử dụng một công cụ để mô hình hóa - Hoặc là một công cụ ERD hoặc một công cụ UML.

• Xem lại và hiểu mã DDL được tạo. Đừng coi đó là điều hiển nhiên.