Thông tin liên hệ đang phát triển có nghĩa là thay đổi cơ sở dữ liệu của bạn không?

Ngày nay, có một số cách để liên hệ với ai đó, phải không?

Chúng tôi có nhiều loại điện thoại khác nhau:điện thoại di động và điện thoại cố định, cá nhân và công việc. Chúng tôi có các địa chỉ khác nhau - nhà ở, gửi thư, thanh toán, doanh nghiệp, v.v. - và có thể là một số địa chỉ email nữa. Đừng quên Skype và các ứng dụng nhắn tin khác nhau. Bây giờ, hãy thêm LinkedIn và Facebook - nhân tiện, cả hai đều có các yếu tố nhắn tin riêng.

Cách đây không lâu, nhiều người trong số này không tồn tại. Vì vậy, bạn có thể đảm bảo khá nhiều rằng trong một vài năm tới, chúng tôi sẽ có một số cách thức mới để liên hệ với mọi người và tổ chức.

Chúng ta có thể lập mô hình tất cả thông tin liên hệ này theo cách mà chúng ta không phải thay đổi thiết kế cơ sở dữ liệu của mình khi có "thông tin mới nhất" không? Đọc để tìm hiểu…

Mô hình điểm liên hệ của bên

Trong một từ, có. Cơ sở dữ liệu có thể được thiết kế để chứa thông tin mà chúng tôi thậm chí chưa có.

Tôi sẽ đi thẳng vào và chỉ cho bạn giải pháp, sau đó tôi sẽ mô tả cách các phần hoạt động với nhau. Tôi sẽ gọi các cách khác nhau để liên hệ với các bên là đầu mối liên hệ , mặc dù tôi đã thấy phương thức liên hệ và thậm chí cả địa điểm liên hệ đã qua sử dụng.

Về mặt vật lý, tất cả các điểm tiếp xúc này sẽ được lưu trữ trong một cột bảng duy nhất, contact_point.contact_value . Hãy nghĩ đến số điện thoại, địa chỉ email hoặc địa chỉ web (URL) và bạn sẽ hiểu tại sao chúng tôi có thể lưu trữ tất cả chúng ở đây; chúng chỉ là các chuỗi (varchars) ở cấp độ này. Sự khác biệt nằm ở siêu dữ liệu. Ngoại lệ duy nhất cho điều này là địa chỉ bưu điện, sẽ được mô tả chi tiết hơn ở phần sau.

Các bảng màu vàng ở bên trái chứa siêu dữ liệu và các bảng màu xanh lam bên phải chứa dữ liệu kinh doanh.

Các danh mục chính

Mặc dù chúng ta có nhiều cách để liên hệ với ai đó, nhưng những cách này thực sự chỉ thuộc một số loại hoặc loại nhỏ. Bạn sẽ hiểu ý tôi khi nhìn vào danh sách dưới đây:

Theo một nghĩa nào đó, chúng là khác biệt về thể chất. Tất nhiên, bạn có thể sử dụng điện thoại di động để gọi điện thoại cố định hoặc điện thoại di động khác. Khi nói đến cuộc gọi thoại giữa điện thoại cố định và điện thoại di động, sự khác biệt không quá quan trọng. Tuy nhiên, chúng tôi có nhiều khả năng gửi tin nhắn văn bản (SMS) tới điện thoại di động hơn là điện thoại cố định.

Nhưng bạn không có khả năng cố tình gọi thoại cho một số fax. Rốt cuộc, bạn định nói gì với nó khi bạn nghe thấy nó, ngoài câu ‘Rất tiếc, nhầm số’? Đương nhiên, bạn có nhiều khả năng gọi bằng một máy fax khác, cho dù đó là máy fax thực hay máy giả lập. Bạn cũng sẽ không gửi thư đến điện thoại cố định hay cố gắng thực hiện cuộc gọi thoại tới một địa chỉ bưu điện.

Điều quan trọng là chúng tôi phải phân biệt các loại này vì chúng tôi tương tác khác nhau với chúng. Điều này sẽ đặc biệt đúng nếu ứng dụng của bạn có bất kỳ loại tích hợp nào với các dịch vụ truyền thông. Nó cần biết loại để tương tác.

Cách các bên sử dụng điểm liên hệ

Điều này có lẽ trực quan hơn một chút, phù hợp hơn một chút với cách chúng ta nghĩ về các loại liên hệ. Dưới đây là danh sách dài hơn (nhưng không phải là danh sách đầy đủ!) Sẽ giúp bạn hiểu về các loại này:

Địa chỉ Bưu điện - Một Trường hợp Đặc biệt

Tất cả các loại điểm liên hệ này được lưu trữ trong một trường duy nhất, ngoại trừ địa chỉ bưu điện. Điều này thường yêu cầu một số dòng (hoặc trường).

Có một bài báo trên blog ở đây đề xuất một cách đơn giản, không có ngôn ngữ để lưu trữ các địa chỉ bưu điện. Nếu yêu cầu của bạn khá cơ bản - ví dụ:để in nhãn địa chỉ khá nhiều khi chúng được nhập vào hệ thống - cách tiếp cận này có thể là đủ. Nếu nhu cầu của bạn phức tạp hơn, có thể bạn sẽ phải phát triển một giải pháp khác.

Để có ý tưởng về mức độ phức tạp của địa chỉ, hãy xem sơ đồ này cho các loại địa chỉ tiêu chuẩn Anh BS7666. Tiêu chuẩn bao gồm một số phần bao gồm các Công báo Đường phố, Công báo Đất đai và Tài sản, và các điểm giao hàng. Nó không phân biệt giữa bất động sản thương mại hay nhà ở; giữa đất bị chiếm dụng, phát triển hoặc đất trống; giữa thành thị hay nông thôn; hoặc giữa các thực thể có thể gửi theo địa chỉ và đối tượng không có địa chỉ sau chẳng hạn như cột buồm (tháp) thông tin liên lạc. Để đạt được điều này, nó giới thiệu các thuật ngữ mà hầu hết chúng ta có lẽ không quen thuộc, chẳng hạn như Đối tượng địa chỉ chính (PAO), là tên được đặt cho một đối tượng địa chỉ có thể được định địa chỉ mà không cần tham chiếu đến một đối tượng có thể địa chỉ khác. Các ví dụ quen thuộc về PAO bao gồm tên tòa nhà hoặc số đường phố. Đối tượng địa chỉ thứ cấp (SAO) được cấp cho bất kỳ đối tượng địa chỉ nào được giải quyết bằng cách tham chiếu đến PAO. Đây có thể là tầng đầu tiên của một tòa nhà được đặt tên.

Để cho chúng ta hình dung về điều này, tôi nhanh chóng thiết kế ngược nó thành một công cụ mô hình hóa UML. Đây là những gì chúng tôi nhận được:

Quan điểm của tôi là nó có thể trở nên khá phức tạp và lộn xộn; thực sự việc xử lý địa chỉ trong một số miền có thể rất phức tạp.

Nếu bạn sắp xếp điều này thành một bảng quan hệ duy nhất, bạn sẽ nhận được một cái gì đó như sau:

Mặc dù điều này nắm bắt các thành phần địa chỉ BS7666, nhưng nó không cho bạn biết mô hình hoạt động như thế nào. Tất cả logic quan hệ của lược đồ XML bị ẩn trong logic ứng dụng.

Hai sơ đồ này đại diện cho hai thái cực của mô hình dữ liệu . Nhưng có cách trung gian nào để lập mô hình địa chỉ không?

Thực sự có thể có một mô hình địa chỉ tương đối đơn giản, linh hoạt và có thể cấu hình được.

Các thành phần địa chỉ

Thành phần địa chỉ thường là một dòng trên nhãn địa chỉ hoặc đúng hơn là một loại dòng trên nhãn địa chỉ. Loại thành phần mà chúng tôi thường sử dụng cho các địa chỉ ở Vương quốc Anh được liệt kê trong bảng sau:

Bạn có thể có ba hoặc bốn dòng địa chỉ, cộng với thị trấn bưu điện và mã bưu điện. Tuy nhiên, khó khăn bạn sẽ gặp phải là xác định những dòng này thực sự chứa gì khi nó quan trọng - ví dụ:khi ánh xạ dữ liệu giữa các hệ thống. Khi bạn thực hiện cấu hình dữ liệu, bạn sẽ thấy rằng Dòng địa chỉ 3 đôi khi chứa một địa phương phụ thuộc, nhưng đôi khi nó chứa một quận hoặc địa phương. Bây giờ bạn đang sử dụng ngôn ngữ tự nhiên (NLP); bạn phải nhận ra sự khác biệt giữa địa phương và quận. Và các hoán vị sẽ nhân lên khi bạn thêm nhiều quốc gia hơn.

Vì vậy, chúng tôi phải xác định tất cả các thành phần địa chỉ cho tất cả các quốc gia chúng tôi hoạt động.

Định dạng địa chỉ

Định dạng địa chỉ được tạo thành từ hai phần:tiêu đề và chi tiết của nó. Tiêu đề về cơ bản là tên hoặc tiêu đề mà định dạng địa chỉ được biết đến bởi. Các ví dụ có thể bao gồm:

Lấy ví dụ về Định dạng địa chỉ bưu điện đầy đủ của Vương quốc Anh (PAF), sau đó chúng tôi xác định các thành phần định dạng địa chỉ sau:

Ứng dụng của chúng tôi đọc siêu dữ liệu này và hiển thị các thành phần địa chỉ theo đúng thứ tự. Khi yêu cầu nắm bắt địa chỉ, siêu dữ liệu cho chúng tôi biết liệu thành phần địa chỉ có phải là thành phần bắt buộc hay không.

Thông thường, ứng dụng của chúng tôi yêu cầu mã bưu điện từ người dùng cuối và tra cứu các giá trị tương ứng và tự động điền các thành phần địa chỉ. Một số ứng dụng cho phép người dùng chỉnh sửa địa chỉ; những cái [khó chịu] khác thì không!

Nó không được hiển thị trong PDM, nhưng nếu tổ chức của bạn hoạt động trên phạm vi quốc tế, bạn có thể xác định mối quan hệ nhiều-nhiều giữa address_format_type và country để định dạng địa chỉ chính xác (dựa trên quốc gia của người dùng) được hiển thị cho người dùng cuối (party ).

Khi nào và chỉ khi contact_point là địa chỉ bưu điện contact_point_type , nó phải có mối quan hệ với address_format_type. Ngược lại, nó theo sau rằng các loại địa chỉ không phải bưu điện không bao giờ có mối quan hệ với address_format_type . Hơn nữa, định dạng phải được giữ nguyên cho vòng đời của contact_point , nếu không, bạn sẽ giới thiệu khả năng xảy ra các vấn đề về tính toàn vẹn của dữ liệu. (Vì điều này không phải như vậy , mục tiêu address_format_components phải là một tập hợp con của nguồn address_format_components ).

Cột contact_value không có ý nghĩa đối với địa chỉ bưu điện vì các giá trị được lưu trữ trong ddress_line.line_content . Ngược lại, contact_value là bắt buộc đối với tất cả các contact_point_types khác . Về cơ bản, contact_point.contact_value và address_line.line_content loại trừ lẫn nhau.

Mối quan hệ nhiều mặt giữa bên và đầu mối liên hệ

Bạn có thể nghĩ đến contact_point (cộng với address_line ) như chứa các giá trị và party_contact như xác định cách sử dụng. Điều này cho phép một contact_point để có nhiều mục đích sử dụng . Địa chỉ [bưu điện] nhà của chúng tôi cũng có thể là địa chỉ thanh toán và địa chỉ giao hàng của chúng tôi, tùy thuộc vào ngữ cảnh.

Cho đến nay, tường thuật đã giả định rằng một bên sở hữu một contact_point cụ thể . Nhưng mô hình dữ liệu không áp đặt quy tắc sở hữu này! Nó không làm cho bất kỳ hạn chế nào như vậy. Có một khả năng khác tồn tại với thiết kế này:nhiều bên cho cùng một điểm tiếp xúc.

Bạn cần phải xem xét các tác động một cách cẩn thận trước khi mạo hiểm theo con đường này.

Đây là một ví dụ. Ở Vương quốc Anh, các Tổ chức Trao giải (AO) thường sử dụng giáo viên làm giám khảo. Một giáo viên có hai mối quan hệ:một mối quan hệ với trường học nơi người đó làm việc và mối quan hệ khác với AO với tư cách là giám khảo. Trường sẽ có một ngân hàng gồm contact_points với nhiều số điện thoại khác nhau và có thể là một hoặc nhiều địa chỉ bưu điện. Đó sẽ là những thông tin như địa chỉ chính của trường (địa chỉ bưu điện), email chính (địa chỉ email), fax chính (số fax) và điện thoại chính (số điện thoại).

Hoàn toàn khả thi khi người kiểm tra của chúng tôi có thể sử dụng cùng một contact_points là trường học của anh ấy hoặc cô ấy, nhưng anh ấy hoặc cô ấy sẽ sử dụng party_contact để xác định chúng là liên quan đến công việc. Nếu số điện thoại chính của trường thay đổi, số cơ quan của giáo viên sẽ tự động được cập nhật, điều này khá dễ hiểu.

Nếu bạn đi xuống tuyến đường này, bạn sẽ cần xác định ở cấp ứng dụng bên nào hoặc các bên nào được phép cập nhật contact_points .

Một Word Nhanh về Hiệu suất

Các bảng siêu dữ liệu màu vàng sẽ được các truy vấn sử dụng liên tục. Do đó, chúng có khả năng vẫn còn trong bộ nhớ. Trên hầu hết các RDBMS, bạn có thể ghim các bảng vào bộ nhớ để đảm bảo điều này. Trong Oracle, tôi sẽ tạo chúng dưới dạng các bảng được tổ chức theo chỉ mục, nhỏ và hoạt động tốt. Làm bất cứ điều gì tương đương đối với RDBMS của bạn.

Bạn cũng muốn đảm bảo rằng party_contact các hàng được đặt cùng vị trí trong cùng một khối (hoặc trang) bằng cách sử dụng chỉ mục nhóm trên party_id . Làm tương tự với address_line.contact_point_id . Điều này làm giảm lượng IO.

Có một tùy chọn khác nếu bạn muốn có party để sở hữu độc quyền một contact_point . Sau đó, bạn có thể hợp nhất contact_point vào party_contact để tạo party_contact_point (vẫn được nhóm trên party_id ). Điều này đơn giản hóa mô hình và có thể hỗ trợ hiệu suất.

Thay đổi danh bạ không có nghĩa là thay đổi cơ sở dữ liệu

Chúng ta đang sống trong một thời kỳ mà có thể nói rằng sự thay đổi là hằng số duy nhất.

Điều đó không có nghĩa là mỗi khi một cái gì đó thay đổi, nó phải ảnh hưởng đến cơ sở dữ liệu của bạn. Với một chút suy nghĩ, chúng tôi có thể chứng minh thiết kế của mình trong tương lai - có lẽ nhiều hơn những gì chúng tôi đã làm cho đến nay. Làm như vậy giúp chúng tôi phản hồi nhanh chóng với sự thay đổi không thể tránh khỏi.

Nếu bạn đang bắt tay vào một dự án đồng xanh, tôi khuyên bạn nên sử dụng Mô hình nhóm (trong đó Contact Point là một phần) cho các tổ chức và mọi người. Tại sao không mở mô hình và điều chỉnh nó theo nhu cầu của bạn? Vui lòng lấy một bản sao và biến nó thành của riêng bạn.

Nhưng nếu cơ sở dữ liệu hoặc các cơ sở dữ liệu của bạn đã được xác định, thì lược đồ tôi đã trình bày ở đây vẫn có thể được sử dụng, ở dạng XML, để xác định tải trọng của bạn khi tích hợp dữ liệu giữa các hệ thống.