Обработка баз данных на Visual Basic®.NET

• имя клиента, его адрес, город, штат, почтовый индекс и телефонный номер;

• территориальный регион страны (северо-запад, юго-запад, средний запад, северо-восток, юг или юго-восток);

• дату последней покупки клиента".

Брэд предположил, что всю эту информацию можно поместить в одну таблицу и тогда его база данных будет отличаться изяществом и простотой. Однако в команде разработчиков нашлись отважные люди, которые осмелились сказать своему шефу, что, возможно, он и прав, но построенная таким образом база данных будет неэффективной, неорганизованной и чрезвычайно негибкой.

Информация, которую Брэд хочет включить в таблицу, не преобразуется напрямую в ее поля. Например, поскольку регион является функцией от штата, в котором проживает данный клиент, то вряд ли имеет смысл помещать поля State и Region в одну таблицу. Если все-таки пойти на это, то оператору, занимающемуся вводом данных, придется дважды вводить аналогичную информацию о клиенте. Логичнее хранить поле State в таблице Customer, а остальные сведения, относящиеся к регионам, – в таблице Region. Если по таблице Region всегда можно определить, в каком регионе находится тот или иной штат, то оператору не придется вводить регион для каждого клиента. Вместо этого достаточно ввести только название штата, а затем после обработки данных из таблиц Customer и Region автоматически будет определен регион проживания данного клиента.

Точно так же критически следует посмотреть на поле Name. Если вместо поля Name использовать два поля: FirstName и LastName, то это облегчит сортировку по фамилии клиентов, если таковая потребуется. Подобный аспект проектирования может показаться тривиальным, но остается лишь удивляться тому, сколько проектов баз данных не учитывают таких простых вещей, как эти. Важно понять, что все это гораздо легче предусмотреть на этапе проектирования базы данных, чем пытаться исправить дефекты, вызванные недальновидностью разработчиков, когда база данных уже заполнена информацией.

Поэтому Брэд и его сотрудники решили, что информация о клиентах компании Jones Novelties Incorporated будет храниться в таблице tblCustomer, которая содержит перечисленные ниже поля.

tblCustomer
ID
FirstName
LastName
Company
Address
City
State
PostalCode
Phone
Fax
Email

Данные, относящиеся к региону страны, в котором проживает клиент, следует хранить в таблице tblRegion. 

tblRegion
ID
State
RegionName

Между двумя этими таблицами существует отношение по полю State. Обратите внимание на то, что это поле присутствует в обеих таблицах. Отношение между таблицами Region и Customer является отношением один-ко-многим, поскольку для каждой записи в таблице tblRegion может существовать или одна, или ни одной, или много записей в таблице tblCustomer, совпадающих по полю State. (Далее в главе подробно описывается, как воспользоваться преимуществами такого отношения при выборке записей.)

Обратите внимание на то, какие имена были присвоены таблицам и полям этой базы данных. Во-первых, имя каждой таблицы начинается с префикса tbl. Этот префикс позволяет с первого взгляда определить, что вы имеете дело именно с таблицей, а не с другим типом объектов базы данных, в котором могут храниться записи. Заметьте, что каждое имя поля состоит из полных слов (а не сокращений), но не включает пробелов или таких специальных символов, как символы подчеркивания.

Несмотря на то что механизм управления базами данных Microsoft SQL Server позволяет использовать в именах объектов баз данных пробелы, символы подчеркивания и другие символы, не входящие в число алфавитно-цифровых, все-таки стоит избегать их использования, поскольку это затрудняет запоминание точного написания имени поля. (В этом случае вам не придется, например, гадать, как называется поле, содержащее имя: FirstName или FIRST_NAME.) Эта директива может показаться сейчас незначительной, но, когда вы начнете писать код для базы данных, содержащей 50 таблиц и 300 полей, вы по достоинству оцените существующие соглашения о присвоении имен, особенно на первом этапе разработки.

Рассмотрим последний пункт из предварительного списка Брэда, предусматривающий регистрацию ответа на вопрос: "Когда данный клиент в последний раз делал у нас покупку?". Разработчик базы данных решил, что эта информация может храниться в таблице, которая предназначена для хранения данных, относящихся к заказам клиентов. Ниже приведена структура этой таблицы.

tblOrder
ID
CustomerID
OrderDate
Amount

В этой таблице поле ID уникальным образом идентифицирует каждый заказ. Поле CustomerID, с другой стороны, связывает заказ с клиентом. Чтобы установить эту связь, идентификатор клиента копируется в поле CustomerID таблицы Order. Таким образом, совсем нетрудно отыскать все заказы для конкретного клиента (как будет продемонстрировано ниже).

Манипулирование данными с помощью объектов

После создания таблиц можно приступить к манипуляциям с данными: вводить данные в таблицы, извлекать их из таблиц, проверять и изменять структуру таблиц. Для манипулирования структурой таблиц используются команды определения данных (более подробно они описываются в главе 2, "Запросы и команды на языке SQL"), а для манипулирования данными – объекты DataSet или DataReader платформы .NET.

Объект DataSet обычно представляет подмножество записей, которые извлекаются из базы данных. Оно концептуально аналогично таблице (а в некоторых случаях — группе связанных полей), но также содержит несколько важных собственных свойств. Объекты DataSet можно легко представить в виде XML-данных и использовать для передачи удаленных данных (как, например, при передаче результатов выполнения запроса от сервера к клиенту или при обмене данными между двумя серверами). В Visual Basic .NET объекты DataSet не ограничены только сохранением извлеченных данных. Например, объект DataSet может использоваться для управления статическими данными в XML-документе или файле конфигурации, либо для управления динамическими данными, созданными на основе пользовательских данных в более сложных ситуациях.

Как и при работе с технологией ADO, в Visual Basic .NET и ADO.NET можно использовать подключенные и неподключенные объекты DataSet. Неподключенный объект DataSet с данными передается приложению, соединение с базой данных закрывается, а базе данных ничего не известно о манипуляциях с этими данными до тех пор, пока приложение вновь не обратится к базе данных. Допустим, что пользователь открывает форму и щелкает на кнопке для обновления данных. В таком случае приложение должно снова соединиться с базой данных и выполнить код изменения данных. В то же время с помощью подключенного объекта DataSet используемые данные "блокируются" и все изменения данных мгновенно воспроизводятся в базе данных. Эта технология более подробно рассматривается в главе 5, "ADO.NET: объект DataSet".

Объект DataReader работает аналогично объекту DataSet, но обладает другими возможностями и характеристиками производительности. Одно из отличий отражено в его названии: объект DataReader считывает данные, т.е. он предоставляет доступ к данным только для чтения. Для объекта DataReader также не предусмотрен простой способ представления данных в формате XML.

Для простоты (что также рекомендуется делать на практике) в данной книге объект DataReader используется для выполнения базовых операций доступа к данным, а объект DataSet — только в случае крайней необходимости, например для создания Web-служб (более подробно они рассматриваются в главе 12, "Web-службы и технологии промежуточного уровня").