Detecting Changes with SqlDependency

Giám sát thay đổi của dữ liệu thông qua đối tượng SqlDependency trong .NET (Detecting Changes with SqlDependency)

Đối tượng SqlDependency có thể kết hợp với SqlCommand để giám sát được sự thay đổi của truy vấn so với truy vấn gốc.

Các bước dưới đây hướng dẫn qui trình thực hiện giám sát dữ liệu thay đổi

  1. Khởi tạo một kết nối SqlDependency với máy chủ (CSDL)
  2. Tạo đối tượng SqlConnection và SqlCommand để kết nối với máy chủ và định nghĩa câu truy vấn cần giám sát
  3. Tạo một đối tượng SqlDependency mới và ràng buộc nó với đối tượng SqlCommand
  4. Đăng ký sự kiện cho sự kiện OnChange của đối tượng SqlDependency
  5. Thực hiện câu lệnh bất kỳ (Execute) nào của đối tượng SqlCommand. Bởi vì lệnh này bị ràng buộc với đối tượng thông báo, máy chủ nhận ra rằng nó phải tạo ra một thông báo, và thông tin hàng đợi sẽ trỏ đến hàng đợi phụ thuộc
  6. Kết thúc, dừng giám sát của SqlDependency 

Mã nguồn tham khảo các bước thực hiện

void Initialization()  
    // Create a dependency connection.  
void SomeMethod()  
    // Assume connection is an open SqlConnection.  
    // Create a new SqlCommand object.  
    using (SqlCommand command=new SqlCommand(  
        "SELECT ShipperID, CompanyName, Phone FROM dbo.Shippers",   
        // Create a dependency and associate it with the SqlCommand.  
        SqlDependency dependency=new SqlDependency(command);  
        // Maintain the refence in a class member.  
        // Subscribe to the SqlDependency event.  
        // Execute the command.  
        using (SqlDataReader reader = command.ExecuteReader())  
            // Process the DataReader.  
// Handler method  
void OnDependencyChange(object sender,   
   SqlNotificationEventArgs e )  

if (e.Type == SqlNotificationType.Change)
NotificationHub nHub = new NotificationHub();
  // Handle the event (for example, invalidate this cache entry).  
void Termination()  
    // Release the dependency.  

Đọc dữ liệu từ Excel

Mã nguồn dưới đây hướng dẫn cách đọc dữ liệu từ Excel vào cơ sở dữ liệu

var fullFileName =”PathOfExcelFile”;
var connectionString = string.Format(“Provider=Microsoft.ACE.OLEDB.12.0;Extended Properties=Excel 8.0;data source={0};”, fullFileName);
var adapter = new OleDbDataAdapter(“select * from [Ten_Sheet$]”, connectionString);
var ds = new DataSet();
string tableName = “tableName”;
adapter.Fill(ds, tableName);
DataTable data = ds.Tables[tableName];
dataGridView1.DataSource = data;

What is a Data Dictionary?

A Data Dictionary, also called a Data Definition Matrix, provides detailed information about the business data, such as standard definitions of data elements, their meanings, and allowable values. While a conceptual or logical Entity Relationship Diagram will focus on the high-level business concepts, a Data Dictionary will provide more detail about each attribute of a business concept.

Essentially, a data dictionary provides a tool that enables you to communicate business stakeholder requirements in such a way that your technical team can more easily design a relational database or data structure to meet those requirements. It helps avoid project mishaps such as requiring information in a field that a business stakeholder can’t reasonably be expected to provide, or expecting the wrong type of information in a field.

The Key Elements of a Data Dictionary

A Data Dictionary provides information about each attribute, also referred to as fields, of a data model. An attribute is a place in the database that holds information. For example, if we were to create a Data Dictionary representing the articles here on Bridging the Gap, we’d potentially have attributes for article title, article author, article category, and the article content itself.

A Data Dictionary is typically organized in a spreadsheet format. Each attribute is listed as a row in the spreadsheet and each column labels an element of information that is useful to know about the attribute.

Let’s look at the most common elements included in a data dictionary.

  • Attribute Name – A unique identifier, typically expressed in business language, that labels each attribute.
  • Optional/Required – Indicates whether information is required in an attribute before a record can be saved.
  • Attribute Type – Defines what type of data is allowable in a field. Common types include text, numeric, date/time, enumerated list, look-ups, booleans, and unique identifiers.

While these are the core elements of a data dictionary, it’s not uncommon to document additional information about each element, which may include the source of the information, the table or concept in which the attribute is contained, the physical database field name, the field length, and any default values.

Script check database and table was existed

Script check database and table was existed

DECLARE @dbname nvarchar(128)
SET @dbname = N’dbTest5′

IF (EXISTS (SELECT name FROM master.dbo.sysdatabases WHERE (‘[‘ + name + ‘]’ = @dbname OR name = @dbname)))
use master
drop database dbtest5
create database dbtest5

use dbtest5

— Run this script at any time, either to:
— (a) Create the demo tables in a different database (see note in previous example)
— (b) Restore the demo tables to their original state

if exists (select * from sysobjects where name = ‘PurchaseItem’) drop table PurchaseItem
if exists (select * from sysobjects where name = ‘Purchase’) drop table Purchase
if exists (select * from sysobjects where name = ‘Customer’) drop table Customer
if exists (select * from sysobjects where name = ‘MedicalArticles’) drop table MedicalArticles
if exists (select * from sysobjects where name = ‘Product’) drop table Product

create table Customer
ID int not null primary key,
Name nvarchar(30) not null

create table Purchase
ID int not null primary key,
CustomerID int null references Customer (ID),
Date datetime not null,
Description varchar(30) not null,
Price decimal not null

create table PurchaseItem
ID int not null primary key,
PurchaseID int not null references Purchase (ID),
Detail varchar(30) not null,
Price decimal not null

create table MedicalArticles
ID int not null primary key,
Topic varchar (20),
Abstract nvarchar (2000)

create table Product
ID int not null primary key,
Description varchar(30) not null,
Discontinued bit not null,
LastSale datetime not null

Dạng chuẩn 3

A database is in third normal form if it satisfies the following conditions:

Định nghĩa: một bảng có dạng chuẩn 3 nếu và chỉ nếu:

  • Bảng đó có dạng chuẩn 2 và
  • Các cột không phải là khóa chỉ phụ thuộc vào khóa (không phụ thuộc các cột không phải là khóa). Không có phụ thuộc bắc cầu .

Phụ thuộc bắc cầu được giải thích như sau: A phụ thuộc hàm vào B, B phụ thuộc hàm C -> suy ra A phụ thuộc hàm C thông qua B.

Ví dụ: 3rd Normal Form

Xem bảng dữ liệu dưới đây:

Example Not In Third Normal Form

Trong bảng trên, BookID xác định GenreID, GenreID xác định Genre Type -> suy ra BookID xác định Genre Type thông qua Genre ID -> Phụ thuộc bắc cầu. Vậy bảng này không thỏa mãn dạng chuẩn 3. Để đưa bảng này về dạng chuẩn 3, chúng ta tách GenreID và GenreType tạo thành 1 bảng mới và bảng Book_detail còn lại các trường: BookID, GenreID, Price.

3rd Normal Form Example

Kết quả cuối cùng, các trường trong bảng không còn phụ thuộc bắc cầu nữa -> bảng đã thỏa mãn dạng chuẩn 3.

Dạng chuẩn 2

Định nghĩa: một bảng có dạng chuẩn 2 nếu và chỉ nếu bảng có dạng chuẩn 1 và các cột không phải là khóa phụ thuộc hoàn toàn vào khóa. Có nghĩa các cột không phải là khóa không được phụ thuộc 1 phần của khóa.

Khi nói đến chuẩn 2 là nói đến khóa kép (composite key), có nghĩa khóa từ 2 hoặc nhiều cột. Nếu bảng nào có khóa chính là một cột thì đã thỏa mãn dạng chuẩn 2.

Ví dụ: 2nd Normal Form

Xem bảng dưới đây:

Example Not In Second Normal Form

Khóa của bảng là khóa kép bao gồm 2 trường CustomerID, StoreID. Cột còn lại là Purchase Location, cột này không phải khóa nhưng chỉ phụ thuộc vào cột Store ID -> phụ thuộc một phần của khóa -> Bảng này không thỏa mãn dạng chuẩn 2.

Để chuyển bảng này về dạng chuẩn 2 -> tách cột Purchase Location và StoreID qua bảng mới, giữ lại cột Store ID trong bảng cũ và ta có kết quả gồm 2 bảng:

2nd Normal Form Example

Hai bảng đã thỏa mãn dạng chuẩn 2.

Dạng chuẩn 1 – 1st Normal Form

Định nghĩa:

Một cơ sở dữ liệu thỏa mãn dạng chuẩn 1 nếu và chỉ nếu:

  • Các cột có giá trị nguyên tố (atomic values)
  • Không có nhóm cột lặp

Giá trị nguyên tố là giá trị của trường đó không thể chia nhỏ ra được nữa, nếu chia nhỏ ra thì giá trị đó không có nghĩa. Ví dụ trong bảng dưới đây, giá trị trong cột color có thể thể chia ra nhỏ hơn, hàng đầu tiên giá trị có thể chia thành red và green. Như vậy bảng Product không thỏa mãn dạng chuẩn 1

Nhóm các cột lặp là bảng có chứa 2 hoặc nhiều cột giống nhau (thông tin liên quan nhau). Ví dụ bảng Books có [Book ID], [Author 1], [Author 2], [Author 3] cũng không thỏa dạng chuẩn 1 vì [Author 1], [Author 2], và [Author 3] là các cột có giá trị giống nhau.

Ví dụ: 1st Normal Form

Làm thế nào để chuẩn hóa bảng dữ liệu Product về dạng chuẩn 1

Unnormalized Table Example

Để bảng PRODUCT chuyển về dạng chuẩn 1, chúng ta tách thành 2 bảng và dữ liệu kết quả như sau:


1st Normal Form Example

Bây giờ các bảng đã thỏa mãn dạng chuẩn một: không có nhóm cột lặp, giá trị nguyên tố.

Note: Ngoài ra, một số tài liệu còn định nghĩa, trong dạng chuẩn 1 bảng đó không chứa trường tính toán. Ví dụ: Bảng thành tiền được tính = số lượng x đơn giá. Vậy cột thành tiền không cần xuất hiện trong bảng.