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

Если вы уже работали с языком Visual Basic и программировали доступ к базам данных, то материал этой главы может показаться вам довольно тривиальным. Однако не стоит пропускать ее, поскольку здесь вы найдете профессиональные термины, которые могут меняться при переходе от одной системы управления базами данных (СУБД) к другой.

Несмотря на относительное постоянство концепций, лежащих в основе различных СУБД, одни и те же вещи имеют обыкновение называться по-разному при переходе от одной конкретной реализации к следующей. Например, многие программисты, разрабатывающие приложения клиент/сервер, называют запросы (query), хранимые в контейнере базы данных, представлениями (view), а программисты, работающие в среде Visual Basic или Access, называют их запросами или объектами QueryDef. По своей сути это одно и то же.

Если вы переходите к Visual Basic .NET от предыдущей версии Visual Basic, то вам следует познакомиться с некоторыми новыми возможностями программирования баз данных с помощью Visual Basic .NET. Дело в том, что в ней используется фундаментально другой способ доступа к данным, который отличается от способов доступа к данным в прежних версиях Visual Basic. Он основан на стандартах Internet с прицелом на создание приложений с возможностями удаленного доступа к данным. Интегрированная среда разработки Visual Studio .NET содержит огромный набор визуальных и интуитивно понятных инструментов, которые упрощают и ускоряют процесс создания баз данных и обеспечивают более высокую степень взаимодействия. Ранее для создания и поддержки баз данных необходимо было иметь глубокие знания многих инструментов. С помощью Visual Studio .NET разработчик может обратиться к многочисленным программам-мастерам, что позволяет избежать создания рутинного кода и повысить гибкость создаваемых приложений.

Если же вы не понаслышке знакомы с разработкой баз данных в прежней версии Visual Basic 6.0, возможно, вам имеет смысл забежать вперед и перейти к главе 4, "Модель ADO.NET: провайдеры данных", посвященной новым способам доступа к данным в Visual Basic .NET.

База данных (database) — это своего рода камера хранения информации. Поскольку существуют различные типы баз данных, необходимо отметить, что в данной книге рассматриваются реляционные базы данных, как самый распространенный в настоящее время тип баз данных. Реляционные базы данных обладают следующими возможностями:

• сохраняют данные в таблицах, которые, в свою очередь, состоят из строк, называемых здесь записями, и столбцов, называемых здесь полями;

• позволяют считывать подмножества данных из таблиц (или создавать для них запросы);

• позволяют связывать таблицы друг с другом (или создавать объединения) для выборки связанных записей, хранимых в различных таблицах.

Основные функции базы данных обеспечиваются платформой баз данных (database platform), т.е. программной системой, "отвечающей" за способ хранения данных и их выборку.

Вместе с Visual Basic.NET можно использовать множество различных платформ баз данных, но в этой книге в основном рассматривается платформа Microsoft SQL Server 2000. (Более подробно она рассматривается в главе 3, "Знакомство с SQL Server 2000".) Процессором базы данных (database engine) называется сам механизм, лежащий в основе платформы базы данных и непосредственно "отвечающий" за выполнение функций и управление данными.

Многие книги, посвященные компьютерному обеспечению, состоят из длинных списков программных средств с кратким описанием особенностей их работы. Если вам повезет, вы найдете описание того, как данный продукт связан с реальным миром.

Цель настоящей книги – представить программное обеспечение в терминах бизнес-решений. Поэтому каждая глава содержит несколько бизнес-вариантов, в которых некая фиктивная компания, столкнувшись с реальными проблемами в сфере бизнеса, пытается автоматизировать работу офиса. В приведенных бизнес-ситуациях используются наработки компании Jones Novelties Incorporated, которая занимается так называемым малым бизнесом — распространением сувениров, мелких дешевых товаров и организацией вечеринок.

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

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

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

Таблицы содержат записи — отдельные частицы данных внутри широкой категории, которую они представляют. Например, таблица с клиентами содержит информацию обо всех потребителях товаров и услуг данной компании. Записи могут содержать данные практически любого типа. Они могут редактироваться, извлекаться и удаляться с помощью хранимых процедур и/или запросов на языке структурированных запросов (Structured Query Language — SQL).

Записи, в свою очередь, содержат поля. Поле — это некоторый раздел данных в записи. Например, запись, которая представляет некий элемент в адресной книге, может состоять из полей имени и фамилии, адреса, названия города, почтового индекса и номера телефона.

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

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

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

В этой книге таблицы представлены в стандартном схематичном формате. В верхней части схемы приводится имя таблицы, а под ним — список названий полей.

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

Если вы новичок в мире программирования баз данных, но раньше использовали другие компьютерные приложения, вас, возможно, удивит, что приложение базы данных заставляет решать массу проблем еще до того, как вы приступите ко вводу данных. Например, приложение обработки текстов позволяет просто набирать и редактировать текст, а подробности, связанные с сохранением файла, вас не касаются — они решаются самим приложением. Однако с базами данных все обстоит по-другому, потому что заблаговременное проектирование структуры баз данных значительно повышает эффективность работы приложения. Если приложению будет известен точный объем и типы данных, подлежащих хранению, то процесс их сохранения и выборки может быть организован оптимальным образом. Создав свою первую многопользовательскую базу данных на 100 тыс. записей, вы узнаете, что первостепенным фактором в работе базы данных является скорость выборки. Поэтому особого внимания заслуживают любые усилия, направленные на ускорение процесса добавления информации в базу данных и выборки из нее.

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

Хотя эти наборы данных входят в различные таблицы, это вовсе не означает, что вы не можете использовать их вместе. Совсем наоборот. Если необходимые данные расположены в двух или нескольких таблицах реляционной базы данных, вы можете получить доступ к этим данным, используя отношения между таблицами. Отношения будут рассмотрены ниже, а пока остановимся на структуре таблиц.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этой таблице поле 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-службы и технологии промежуточного уровня").

Объект DataSet устроен так же, как и объект ADODB.Recordset в прежних версиях языка Visual Basic. Аналогично другим типам объектов языка Visual Basic, объект DataSet имеет свойства и методы. Более подробно он рассматривается в других главах книги, а здесь достаточно отметить, что на платформе .NET объекты используются для организации в приложении ясного, согласованного и относительно простого способа работы с базами данных.

Один из этапов проектирования базы данных заключается в объявлении типа каждого поля, что позволяет процессору базы данных эффективно сохранять и извлекать данные. В SQL Server предусмотрено использование 21 типа данных, которые перечислены в табл. 1.1.

Таблица 1.1. Типы данных в SQL Server

Хотя типы данных Visual Basic.NET более близки к типам данных полей SQL Server, чем типы данных Visual Basic 6, между ними все равно нет однозначного соответствия. Например, тип данных int в SQL Server соответствует типу integer в Visual Basic .NET, потому что оба они являются 32-битовыми целыми числами. Однако в SQL Server нельзя создать поле с определенным пользователем типом или типом Object языка Visual Basic .NET.

Для создания структуры базы данных рекомендуется не только подготовить список таблиц и полей, но и представить таблицы и поля в графическом виде. После этого вы не только сможете сказать, какие таблицы и поля доступны для вас, но и как они связаны друг с другом. Именно для этого и предусмотрена схема базы данных.

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

Схемы не теряют своей актуальности и после завершения процесса проектирования базы данных. Без такой схемы вам будет трудно выполнять многотабличные запросы. Толково составленная графическая схема поможет ответить на вопросы типа: "Какие таблицы мне нужно объединить, чтобы составить список всех заказов с объемом, превышающим $50,00, поступивших от клиентов из штата Миннесота в течение последних 24 часов?" (За дополнительной информацией по созданию запросов, включающих более одной таблицы, обращайтесь к главе 2, "Запросы и команды на языке SQL".)

Официальных способов создания схем баз данных не существует, но есть много средств, которыми можно воспользоваться при их создании. Например, графический редактор Visio отличается гибкостью, быстротой и простотой применения. Более того, он хорошо интегрируется с другими приложениями Windows, в частности с Microsoft Office. Этот редактор распространяется отдельно, а также входит в состав Visual Studio.NET Enterprise Architect.

Все сказанное в пользу Visio не означает, что при создании графической схемы базы данных вы должны использовать только программу Visio. Можно применять любые другие инструменты рисования, с которыми вы знакомы. Приемлемый вариант – программа Microsoft Windows Paint, можно также воспользоваться средствами рисования, предусмотренными в программе Microsoft Word.

Существует несколько способов создания баз данных в SQL Server. С помощью набора инструментов SQL Enterprise Manager базы данных можно создавать графически или программно (с помощью команд на языке SQL). Помимо него, существует множество других внешних инструментов для создания баз данных, например Visio, который описывается далее в главе.

Visual Studio .NET также содержит очень удобный инструмент для работы с базами данных SQL Server. Он входит в состав нового компонента Server Explorer, который предназначен для централизованного управления всеми видами серверного программного обеспечения. Для создания базы данных SQL Server с помощью компонента Server Explorer выполните перечисленные ниже действия.

1. Запустите интегрированную среду разработки Visual Studio .NET, выбрав команду меню Start→Programs→Microsoft Visual Studio .NET→Microsoft Visual Studio .NET.

2. В левой части окна Visual Studio .NET откройте окно Server Explorer, выбрав команду меню View→Server Explorer (учтите, что эта вкладка может иметь горизонтальную или вертикальную ориентацию).

3. В этом окне раскройте узел Servers, найдите ваш компьютер, а затем раскройте узел SQL Servers и найдите в нем экземпляр SQL Server, который установлен на вашем компьютере, как показано на рис. 1.1.

РИС. 1.1. Вкладка Server Explorer интегрированной среды разработки Visual Studio .NET, с помощью которой можно централизованно управлять серверными процессами

4. Для создания новой базы данных щелкните правой кнопкой мыши на имени экземпляра SQL Server, который установлен на вашем компьютере. На рис. 1.1 показан компьютер ROCKO, хотя ваш компьютер может иметь совершенно другое имя. В контекстном меню выберите команду New Database (Создать новую базу данных).

5. На экране появится диалоговое окно Create Database (Создать базу данных). Введите в нем имя базы данных Novelty и щелкните на кнопке OK.

6. После этого в окне Server Explorer появится новая база данных Novelty. При раскрытии узла этой базы данных будут отображены следующие категории объектов базы данных:

• Database Diagrams (Диаграммы базы данных);

• Tables (Таблицы);

• Views (Представления);

• Stored Procedures (Хранимые процедуры);

• Functions (Функции).

Для использования базы данных нужно создать в ней хотя бы одну таблицу. Для этого выполните перечисленные ниже действия.

1. В окне Server Explorer щелкните правой кнопкой мыши на узле Tables базы данных Novelty, а затем из контекстного меню выберите команду New Table (Создать таблицу).

2. После этого в окне Visual Studio .NET появится диалоговое окно для создания структуры новой таблицы. Создайте таблицу tblCustomer с перечисленными ниже определениями полей. 

Учтите, что поле ID используется для идентификаторов, т.е., оно содержит уникальное целое число для каждой строки данной таблицы.

3. После ввода этих определений таблица будет иметь вид, показанный на рис. 1.2.

4. Щелкните на поле ID и выберите команду меню Diagram→Set Primary Key (Диаграмма→Создать первичный ключ). Благодаря этому все значения данного поля будут уникальны, т.е. все клиенты будут иметь разные идентификаторы. (Более подробные сведения о первичных ключах приводятся в следующем разделе.)

5. Далее нужно указать, что поле ID используется в SQL Server в целях автоматической генерации идентификационных номеров для клиентов. Для этого щелкните правой кнопкой мыши на окне с определением таблицы и выберите в контекстном окне Indexes/Keys (Индексы/ключи).

6. После этого на экране появится диалоговое окно Property Pages (Страницы свойств) со вкладкой Indexes/Keys. Выберите вкладку Tables (Таблицы) со свойствами таблицы.

7. В списке Table Identity Column (Поле таблицы с идентификаторами) выберите поле ID.

8. Щелкните на кнопке Close (Закрыть).

РИС. 1.2. Создание определения таблицы с помощью Visual Studio .NET

9. Выберите команду меню File→Save Table1 (Файл→Сохранить таблицу Table1). В диалоговом окне Choose Name (Выбрать имя) введите имя tblCustomer и щелкните на кнопке OK. Обратите внимание, что после сохранения таблицы ее имя появится в списке таблиц базы данных Novelty в окне компонента Server Explorer.

Теперь, когда вы создали базовую таблицу, осталось определить индексы. Индекс (index) - это атрибут, который можно присвоить полю, чтобы облегчить для процессора баз данных выборку данных на основе информации, хранимой в этом поле. Например, в базе данных, содержащей сведения о сотрудниках, вероятно, будет реализована функция поиска клиента по фамилии, отделу или идентификационному номеру. Поэтому для каждого из этих полей имеет смысл создать индексы, чтобы ускорить процесс выборки записей на их основе.

Если вы поняли, какая польза от применения индексов в структуре базы данных, у вас может возникнуть вопрос: если наличие индексов значительно ускоряет поиск, почему бы не создать индексы для каждого поля каждой таблицы? Ответ прост: индексы — это не только плюс, но и минус. При увеличении количества индексов физически увеличивается размер базы данных, а значит, и объем занимаемой памяти и дискового пространства, в результате чего компьютер работает медленнее. В этом случае польза от применения индексов сводится к нулю. Не существует жесткого правила насчет оптимального количества индексов для каждой таблицы, но основная рекомендация состоит в создании индексов только по таким полям, которые, по вашему мнению, будут чаще всего использованы в запросах. (За дополнительной информацией о том, как использовать содержимое поля в качестве критерия запроса для выборки наборов записей, обращайтесь к главе 2, "Запросы и команды на языке SQL".)

Первичный ключ (primary key) – это специальный тип индекса. Поле, которое определено в качестве первичного ключа таблицы, служит для уникальной идентификации записей. Поэтому, в отличие от других типов индексов, никакие две записи в одной и той же таблице не могут иметь одинакового значения в поле их первичного ключа. Кроме того, при определении поля в качестве первичного ключа никакие две записи в этом поле не могут содержать пустое или неопределенное значение (null). Определив некоторое поле таблицы как первичный ключ, вы можете создать в своей базе данных отношения между этой и другими таблицами.

Каждая создаваемая вами таблица должна иметь по крайней мере один первичный ключ и должна быть проиндексирована по тем полям, которые чаще всего будут участвовать в запросах. В случае с таблицей tbl:, как и с многими другими таблицами баз данных, первичный ключ создается по полю ID. (В предыдущем разделе это поле уже было определено как первичное.) Вторичными индексами могут быть поля FirstName и LastName.

Попробуем создать еще два индекса для полей FirstName и LastName, для этого выполните перечисленные ниже действия.

1. Щелкните правой кнопкой мыши на окне с определением таблицы tblCustomer в окне компонента Server Explorer и выберите в контекстном меню команду Indexes/Keys.

2. После этого на экране появится страница свойств со списком существующих индексов, в котором уже присутствует индекс первичного ключа PK_tblCustomer. Щелкните на кнопке New (Создать) для создания нового индекса для поля FirstName.

3. В списке полей выберите поле FirstName, как показано на рис. 1.3, а затем щелкните на кнопке Close.

4. Повторите действия из пп. 1-3, чтобы создать индекс для поля FirstName.

ВНИМАНИЕ!

В нижней части диалогового окна Property Pages находится параметр Create UNIQUE (Создать уникальный индекс). Не устанавливайте флажок для этого параметра, потому что в таком случае в таблицу можно будет вводить только разные имена клиентов! Уникальные индексы следует создавать только для того, чтобы гарантировать уникальность значений данного поля.

РИС. 1.3. Диалоговое окно Property Pages после определения индекса для поля FirstName

5. Для сохранения внесенных изменений в базу данных выберите команду меню File→Save tblCustomer (Файл→Сохранить таблицу tblCustomer). После успешного сохранения внесенных изменений закройте окно создания схемы базы данных Visual Studio .NET.

Создав структуру данных для таблицы, можно приступить к вводу данных в нее. В окне Server Explorer предусмотрены удобные средства ввода данных в таблицу. Для этого нужно щелкнуть правой кнопкой мыши на таблице в окне Server Explorer и выбрать из контекстного меню команду Retrieve Data from Table (Извлечь данные из таблицы). В результате в окне Server Explorer появится сетка с полями ввода данных (рис. 1.4).

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

Получив эти базовые знания о создании таблицы с помощью Visual Studio .NET, вы сможете создавать базы данных практически любого вида. Однако для создания сложных баз данных с несколькими таблицами часто требуется установить отношения (связи) между ними. Чтобы упростить эту задачу, используется схема базы данных.

Схема базы данных (database diagram) – это визуальное представление таблиц в базе данных. Для создания таблиц и отношений между ними можно использовать инструменты создания схемы баз данных, которые предусмотрены в SQL Server. А для создания схемы баз данных с помощью окна Server Explorer среды Visual Studio .NET выполните перечисленные ниже действия. 

РИС. 1.4. Ввод данных в таблицу с помощью команды контекстного меню Retrieve Data from Table

1. Разверните узел базы данных Novelty в окне Server Explorer, щелкните правой кнопкой мыши на узле Database Diagrams и выберите в контекстном меню команду New Diagram (Создать схему).

2. В диалоговом окне Add Table (Добавить таблицу) будет приведен список таблиц базы данных. Выберите созданную ранее таблицу tblCustomer, щелкните на кнопке Add (Добавить), а затем на кнопке Close.

3. В результате будет создана новая схема базы данных с таблицей tblCustomer (рис. 1.5).

4. Для добавления второй таблицы в эту схему щелкните правой кнопкой мыши на пустом пространстве возле таблицы tblCustomer и выберите в контекстном меню команду New Table (Создать таблицу).

5. На экране появится диалоговое окно Choose Name, в которое следует ввести имя новой таблицы tblOrder.

6. После этого в окне схемы появится сетка для определения полей новой таблицы. Создайте в ней поля, показанные на рис. 1.6.

7. Выберите команду меню File→Save для сохранения схемы базы данных, и на экране появится диалоговое окно с просьбой подтвердить создание новой таблицы. Щелкните на кнопке Yes, и в окне Server Explorer появится вновь созданная таблица. 

РИС. 1.5. Схема базы данных Novelty, которая содержит все таблицы, выбранные в диалоговом окне Add Table

РИС. 1.6. Схема базы данных Novelty, которая содержит все таблицы, выбранные в диалоговом окне Add Table

После создания таблиц для клиентов и заказов следует установить связь (отношение) между ними. Например, при создании заказа идентификатор клиента ID из таблицы tblCustomer копируется из записи клиента в поле CustomerID таблицы tblOrder. Для указания этого отношения между таблицами на схеме базы данных выполните перечисленные ниже действия.

1. Щелкните на поле ID в таблице tblCustomer и перетащите его к полю CustomerID таблицы tblOrder.

2. На экране появится диалоговое окно Create Relationship (Создать отношение), в котором можно указать свойства отношения между двумя таблицами. После этого уже нельзя создавать заказы для клиентов с идентификаторами, которых нет в таблице клиентов. Это ограничение имеет большое практическое значение и потому с ним следует согласиться.

3. Схема базы данных обновляется для отражения нового отношения, как показано на рис. 1.7.

РИС. 1.7. Схема базы данных с обозначением отношения между табл tblCustomer и tblOrder

Для сохранения созданной схемы базы данных DatabaseDiagram1 выберите команду File→Save DatabaseDiagram1. В диалоговом окне Save New Database Diagram (Сохранить имя новой схемы базы данных) введите имя Relationships (Отношения) для новой схемы базы данных. При этом возможно появление диалогового окна с просьбой подтвердить создание новой таблицы. Щелкните на кнопке Yes для сохранения вновь созданной таблицы tblOrder.

SQL Server может сохранять схему базы данных вместе с самой базой данных. Таким образом, всегда можно получить доступ к схеме, даже с помощью других инструментов, например с помощью программы Enterprise Manager или среды Visual Studio .NET.

Помимо инструментов среды Visual Studio .NET, для создания, просмотра и изменения схем базы данных могут использоваться другие очень удобные средства. Программа Microsoft Visio обладает всеми необходимыми возможностями автоматического создания схемы для уже имеющейся базы данных, т.е. реинжиниринга базы данных. Эта функциональная возможность особенно полезна для работы с унаследованными базами данных, которые создавались очень давно и с использованием совсем других инструментов.

НА 3AMETKУ

Для создания базы данных SQL Server совсем необязательно знать особенности работы с программой Visio. Это всего лишь еще один способ создания и документирования схемы базы с помощью одного набора операций. Если вы предпочитаете использовать компонент Server Explorer среды Visual Studio (или инструмент Enterprise Manager) либо у вас нет программы Visio, то в таком случае можно пропустить данный раздел без ущерба для понимания остального материала.

Реинжиниринг (reverse engineering) базы данных заключается в проверке схемы существующей базы данных и создании диаграммы отношений между объектами базы данных (Entity Relationship Diagram – ERD). ERD-диаграмма — это способ символьного представления базы данных, основанный на широких категориях данных, или сущностях (entities), которые обычно хранятся в базе данных в виде таблиц.

Для реинжиниринга схемы базы данных с помощью программы Visio выполните перечисленные ниже действия.

1. Запустите программу Microsoft Visio 2002 for Enterprise Architects, выбрав команду Start→Programs→Microsoft Visio. В панели Choose Drawing Type (Выбрать тип рисования) выберите категорию Database (База данных).

2. Затем в панели Template (Шаблон) выберите параметр Database Model Diagram (Схема базы данных), и на экране появится основное окно программы Visio (рис. 1.8).

3. Выберите команду меню Database→Reverse Engineer (База данных→Реинжиниринг) для запуска программы-мастера Reverse Engineer Wizard.

4. Из списка Installed Visio drivers (Инсталлированные драйверы Visio) выберите драйвер Microsoft SQL Server.

5. Затем нужно определить источник данных, который позволит получить доступ к базе данных Novelty. Для этого щелкните на кнопке New.

6. На экране появится диалоговое окно Create New Data Source (Создать новый источник данных) с предложением указать тип создаваемого источника данных.

Выберите источник данных System Data Source и щелкните на кнопке Next. 

РИС. 1.8. Основное окно программы Visio: слева показан шаблон, а справа – область рисования. Элементы схемы создаются с помощью перетаскивания элементов шаблона в область рисования

7. В следующем окне снова предлагается выбрать драйвер базы данных. Прокрутите список драйверов и выберите SQL Server. Щелкните на кнопке Next, a затем на кнопке Finish.

8. На экране появится новое диалоговое окно Create a New Data Source to SQL Server (Создать новый источник данных для SQL Server) с предложением указать источник данных. Введите имя базы данных Novelty в поле Name, а затем в списке с надписью Which SQL Server do you want to connect to? (К какому серверу SQL Server нужно присоединиться?) выберите После этого щелкните на кнопке Next.

9. Укажите режим аутентификации на сервере SQL Server. (Более подробно этот вопрос рассматривается в главе 3, "Знакомство с SQL Server Затем щелкните на кнопке Next.

10. В следующем диалоговом окне установите флажок Change the default database to: (Заменить используемую по умолчанию базу данных:) и выберите в списке базу данных Novelty. Щелкните на кнопке Next, а затем на кнопке Finish.

 11. В последнем диалоговом окне ODBC Microsoft SQL Server Setup (Установки параметров драйвера ODBC Microsoft SQL Server) можно протестировать соединение с базой данных с помощью известных параметров соединения. Щелкните на кнопке Test Data Source (Проверка источника данных), чтобы убедиться в работоспособности соединения. После успешной проверки соединения щелкните на кнопке OK.

12. После этого источник данных Novelty будет автоматически выбран и представлен в диалоговом окне программы-мастера Reverse Engineer Wizard. Дважды щелкните на кнопке Next, чтобы пропустить экран для выбора типов объекта.

13. На следующем экране выберите таблицы tblCustomer и tblOrder для выполнения реинжиниринга. Затем щелкните на кнопке Finish. После этого программа Visio самостоятельно создаст схему вашей базы данных, включая отношение междуопределенными ранее таблицами tblCustomer и tblOrder (рис. 1.9).

РИС. 1.9. Схема, созданная с помощью программы-мастера Reverse Engineer Wizard, с двумя таблицами базы данных Novelty и отношениями между ними

В результате такого трудоемкого и рутинного процесса программа-мастер Reverse Engineer Wizard устраняет необходимость использования отдельной программы-мастера для создания источника данных ODBC – устаревшей технологии компании Microsoft, предназначенной для обеспечения взаимодействия приложений с реляционными базами данных. (Более подробно технология ODBC описывалась в прежнем издании книги, но она не очень широко используется в среде Visual Studio .NET, а потому эта тема опущена в данном издании.)

Важной особенностью технологии ODBC является то, что после создания именованного источника данных ODBC его не нужно создавать повторно. Для следующих попыток доступа к базе данных Novelty используется уже созданный источник данных ODBC.

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

1. В окне Entity Relationship (Отношения между объектами) в левой части окна программы Visio щелкните на компоненте Entity (Объект) и перетащите его в область рисования. При этом будет создан новый объект (таблица), который по умолчанию называется Table 1.

2. Щелкните правой кнопкой мыши на созданном объекте и выберите в контекстном меню команду Database Properties (Свойства базы данных). На экране появится страница свойств базы данных Database Properties.

3. Введите новое имя таблицы tblRegion в текстовом поле Physical name (Физическое имя).

4. В списке Categories (Категории) страницы свойств базы данных Database Properties щелкните на категории Columns (Поля) и создайте три поля в сетке с определением таблицы, как показано на рис. 1.10. Обратите внимание, что для длины поля типа char или varchar нужно выбрать поле и щелкнуть на кнопке Edit (Редактировать) с правой стороны страницы свойств.

После выполнения этих действий схема базы данных будет выглядеть, как показано на рис. 1.10.

НА ЗАМЕТКУ

Здесь продемонстрирован очень простой способ создания схемы базы данных. Учтите, что в программе Visio есть много других более сложных специализированных шаблонов для создания схем базы данных.

Между таблицами tblRegion и tblCustomer существует отношение на основе связи между их полями State. Для отражения этого отношения в схеме нужно использовать компонент Relationship так, как описано ниже. 

РИС. 1.10. ERD-диаграмма с определением новой таблицы tblRegion

1. В окне Entity Relationship (Отношения между объектами) в левой части окна программы Visio щелкните на компоненте Relationship и перетащите его в область рисования. Он представляет собой линию со стрелкой и с зелеными квадратиками (метка-манипулятор) на концах линии.

2. Щелкните и перетащите одну из зеленых меток на таблицу tblRegion. При этом цвет метки станет красным, что означает незавершенность выполняемых действий с данным отношением.

3. Щелкните и перетащите другую зеленую метку на таблицу tblCustomer.

4. В странице свойств в нижней части окна Visio выберите поля State в обеих таблицах, а затем щелкните на кнопке Associate (Связать). Теперь ERD-диаграмма будет выглядеть, как показано на рис. 1.11. Обратите внимание, что кнопка между двумя списками полей из таблиц tblRegion и tblCustomer либо будет неактивной, либо будет содержать надпись Disconnect (Разорвать) или Associate (Связать). Например при выборе по одному полю в каждом списке эта кнопка будет иметь надпись Associate.

Рис. 1.11. ERD-диаграмма с отображением отношения между таблицами tblCustomer и tbIOrder

После создания таблицы в схеме базы данных можно использовать программу Visio для создания таблицы в базе данных. Для этого нужно выбрать команду меню Database→Update (База данных→Обновить). На экране появится диалоговое окно программы-мастера Database Update Wizard с предложением выполнить обновление. Для обновления базы данных можно создать сценарий на языке определения данных (Data Definition Language — DDL), который внесет все необходимые изменения в базу данных. Этот способ позволяет задокументировать все вносимые изменения и использовать их для репликации. (Более подробно DDL рассматривается в главе 2, "Запросы и команды на языке SQL".) Для обновления базы данных программа Visio может просто внести их в базу данных без создания сценария на DDL. Программа-мастер Database Update Wizard позволяет использовать любой из этих вариантов либо оба вместе.

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

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

Теперь между таблицами tblOrder и tblOrderItem существует отношение типа один-ко-многим, как показано на рис. 1.12.

Полностью схему всей базы данных Novelty можно скопировать в виде файла для программы Visio с Web-страницы этой книги на Web-сервере Издательского дома "Вильяме" по адресу: www.williamspublishng.com.

НА ЗАМЕТКУ

Не следует путать процесс создания схемы базы данных с процессом создания программного обеспечения. В большинстве компаний по созданию программного обеспечения используется методология, которая регламентирует решаемые бизнес-задачи, внешний вид программного обеспечения и способ его создания. Их нужно учитывать при разработке базы данных.

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

РИС. 1.12. Схема базы данных с отношениями между четырьмя таблицами

Полями, создающими отношение, являются первичный ключ (представленный выше в этой главе) и внешний (foreign) ключ. Внешний ключ — это ключ в связанной таблице, который хранит копию первичного ключа из основной таблицы.

Предположим, у вас есть таблицы с характеристиками отделов и сотрудников компании. Отношение между отделом и группой сотрудников можно определить типом один-ко-многим. Каждому отделу присваивается собственный идентификационный номер (ID), и каждый сотрудник имеет свой ID. Но, чтобы указать, в каком отделе работает каждый сотрудник, необходимо сделать копию номера ID отдела в каждой записи, содержащей данные о сотруднике. Итак, чтобы идентифицировать каждого сотрудника как члена некоторого отдела, в таблице Employees (Сотрудники) должно быть предусмотрено поле (именуемое, допустим, Department ID) для хранения ID отдела, в котором работает данный сотрудник. Поле Department ID в таблице Employees служит внешним ключом таблицы Employees, поскольку хранит копию первичного ключа таблицы Departments (Отделы).

Благодаря отношению процессор баз данных "знает", какие две таблицы участвуют в этом отношении и какой внешний ключ связан с первичным ключом. Для прежнего процессора Jet базы данных Access явное объявление отношений не обязательно, но это в ваших же интересах, поскольку при таком объявлении упрощается задача выборки данных из записей двух или нескольких связанных таблиц (подробнее об этом в главе 2, "Запросы и команды на языке SQL"). Отсутствие такого объявления – один из основных недостатков технологии Jet, который можно устранить с помощью переноса унаследованных приложений на основе технологии Jet на платформу ADO.NET. Помимо соответствия связанных записей в отдельных таблицах, отношение определяется для того, чтобы воспользоваться преимуществами ссылочной целостности, под которой понимают свойство процессора базы данных, обеспечивающее непротиворечивость информации, хранимой в многотабличной базе данных. Когда ссылочная целостность имеет место в базе данных, то процессор баз данных препятствует удалению записи в случае, если в базе данных существуют другие записи, связанные с ней.

После того как вы определите отношение в базе данных, это определение сохраняется до тех пор, пока вы не удалите его. Отношения можно создавать графически, используя инструменты Visual Studio .NET, SQL Enterprise Manager, Visio, или с помощью сценариев на языке DDL.

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

Допустим, у вас есть таблицы tblCustomer и tblOrder. Эти две таблицы связаны через общее поле ID.

Предполагается, что сначала вы регистрируете клиентов в таблице tblCustomer, а затем создаете записи с информацией о заказах в таблице tblOrder. Но что произойдет, если запустить процесс, удаляющий запись с данными о клиенте, который оформил заказы, зарегистрированные в таблице tblOrder? А если создать заказ, для которого не существует действительного значения поля CustomerID? Любой заказ без значения поля CustomerID не будет отгружен, поскольку адрес отгрузки представляет собой функцию от записи в таблице tblCustomer. Когда данные в связанных таблицах страдают от такого рода проблемы, их называют несогласованными или противоречивыми.

Поскольку очень важно, чтобы база данных не стала противоречивой, во многих процессорах баз данных (включая SQL Server) предусмотрен способ определения формальных отношений между таблицами. При формальном определении отношения между двумя таблицами процессор баз данных отслеживает это отношение и препятствует выполнению любой операции, которая "покушается" на ссылочную целостность.

Ссылочная целостность обеспечивается путем генерирования ошибок при выполнении действия, которое могло бы оставить данные в противоречивом состоянии. Например, в базе данных с активизированной ссылочной целостностью при попытке создать заказ, содержащий идентификационный номер (ID) клиента, которого на самом деле не существует, вы получите сообщение об ошибке и "подозрительный" заказ не будет создан.

Для проверки отношения между таблицами tblCustomer и tblOrder попробуем использовать окно Server Explorer среды Visual Studio .NET. Для этого выполните перечисленные ниже действия.

1. Откройте схему базы данных Novelty с двумя таблицами- tblCustomer и tblOrder. Обратите внимание на то, что эта схема содержит и другие таблицы, но в данном случае нас интересует отношение между этими таблицами.

2. Щелкните правой кнопкой мыши на линии отношения между двумя этими таблицами и из контекстного меню выберите команду Property Pages.

3. После появления на экране страницы свойств данного отношения выберите вкладку Relationships, в которой указаны поле ID таблицы tblCustomer, поле CustomerID таблицы tblOrder и ограничения ссылочной целостности в нижней части.

НА ЗАМЕТКУ

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

4. Установите флажок Enforce Relationship for INSERTS and UPDATES (Применять каскадное обновление и удаление), а затем щелкните на кнопке Close.

5. Для сохранения внесенных изменений выберите команду File→Save Relationships.

Для проверки заданного ограничения выполните перечисленные ниже действия.

1. В окне Server Explorer щелкните правой кнопкой мыши на таблице tblOrder и выберите из контекстного меню команду Retrieve Data from Table.

2. Введите заказ для клиента идентификатором которого на самом деле нет в таблице с данными о клиентах.

3. Перейдите в другую строку для автоматического сохранения введенного заказа.

В результате на экране появится диалоговое окно с предупреждением: INSERT statement conflicted with COLUMN FOREIGN KEY constraint ' FK_tblOrder_tblCustomer'. Conflict occurred in database 'Novelty', table 'tblCustomer', column 'ID'. The statement has been terminated. (Команда INSERT конфликтует с ОГРАНИЧЕНИЕМ ПО ВНЕШНЕМУ КЛЮЧУ 'FK_tblOrder_tblCustomer'. Конфликт произошел в базе данных 'Novelty', таблице 'tblCustomer', поле 'ID'. Выполнение команды прекращено.)

4. Щелкните на кнопке OK в окне с предупреждением и отмените команду вставки новой записи с помощью клавиши <Esc>.

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

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

Каскадные обновления и каскадные удаления – весьма полезные свойства процессора баз данных SQL Server. И вот почему.

• Каскадные обновления. При изменении значения первичного ключа таблицы связанные данные во внешних ключах, относящихся к этой таблице, также изменяются, отражая изменения в первичном ключе. Следовательно, если вы измените идентификатор ID клиента Хокки Марта (Hockey Mart) в таблице tblCustomer с 48 на 72, то значение поля CustomerID всех заказов, сгенерированных этим Хокки Мартом в таблице tblOrder, автоматически изменится с 48 на 72. В рабочем приложении редко приходится изменять значения ключа (основная концепция заключается в том, что ключ должен быть уникальным и неизменным), но если это все-таки приходится делать, то все каскадные обновления этого ключа во внешних ключах будут выполнены автоматически.

• Каскадные удаления. При удалении записи в таблице все записи, связанные с этой записью в соответствующих таблицах, автоматически удаляются. Следовательно, если вы удалите запись для Хокки Марта в таблице tblCustomer, все записи в таблице tblOrder для клиента Хокки Марта автоматически удаляются.

НА ЗАМЕТКУ

Устанавливая отношения, выполняющие каскадные обновления и удаления в базе данных, следует проявлять определенную осторожность. При недостаточной бдительности можно допустить удаление (или обновление) большего объема данных, чем ожидалось. Некоторые разработчики базы данных вообще отказываются от каскадного обновления и удаления, предпочитая явное управление ссылочной целостностью данных среди связанных таблиц. Однако, более внимательно изучив особенности каскадного обновления и удаления, можно убедиться в том, что они довольно легко программируются.

Каскадные обновления и удаления работают только в том случае, если вы установили отношение между двумя таблицами. Если вы всегда создаете таблицы с первичным ключом типа AutoNumber (Счетчик), (или первичными ключами типа AutoIncrement в терминах SQL Server), то каскадные удаления для вас окажутся более полезными, чем каскадные обновления, поскольку вы не в силах изменить значение поля типа AutoNumber или поля AutoIncrement (т.е. нет обновлений – нечего и тиражировать).

Для проверки возможностей каскадного удаления с помощью окна Server Explorer выполните перечисленные ниже действия.

1. Убедитесь в том, что между таблицами tblCustomer и tblOrder задано отношение с каскадным удалением. (Для проверки или указания этого ограничения воспользуйтесь схемой базы данных.)

2. Создайте запись о новом клиенте, щелкнув правой кнопкой мыши на таблице tblCustomer узла Tables в окне Server Explorer, выбрав в контекстном меню команду Retrieve Data from Table и введя необходимые данные. Запомните идентификатор ID, присвоенный процессором базы данных новому клиенту, потому что он потребуется для создания заказов данного клиента. Пусть эта таблица остается открытой, потому что она нам еще понадобится чуть позже.

3. Откройте таблицу tblOrder и создайте 2-3 заказа для нового клиента. Для этого укажите в поле CustomerID идентификатор ID, присвоенный процессором базы данных новому клиенту. Пусть эта таблица также остается открытой.

4. Вернитесь к таблице tblCustomer и попытайтесь удалить запись с данными этого клиента, щелкнув правой кнопкой мыши на левом конце записи и выбрав из контекстного меню команду Delete.

5. После этого на экране появится диалоговое окно с предупреждением и просьбой подтвердить удаление данных. Щелкните на кнопке Yes.

6. Вернитесь к таблице tblOrder, и вы обнаружите, что заказы этого клиента не удалены. Что произошло? На самом деле они удалены, но дают устаревшее представление данных. Для его обновления нужно выбрать команду меню Query→Run (Запрос1→Запуск). После этого вид таблицы будет обновлен и связанные заказы данного клиента будут удалены благодаря параметрам каскадного удаления.

Нормализация — это тесно связанное с отношениями понятие, которое означает устранение противоречий и повышение эффективности базы данных.

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

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

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

НА ЗАМЕТКУ

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

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

Эта структура первоначально может показаться рациональной, однако посмотрим, что произойдет, если кто-нибудь постарается ввести данные в приложение, основанное на этой таблице.

Если бы вы вводили обычную информацию о клиенте - имя, адрес и т.д., то после ввода названия штата вам бы пришлось задуматься, чтобы определить регион проживания данного клиента. Где же находится этот Арканзас – на западе или на юге? Где находится клиент с Виргинских островов? Если существует большая вероятность ошибки, то такого рода решения не стоит оставлять в руках операторов, занимающихся вводом данных, даже несмотря на их высокую квалификацию. Если же полагаться только на человеческую память, то рано или поздно ваши данные станут противоречивыми. А чтобы защитить данные от противоречивости, и следует обращаться к нормализации.

Вместо того чтобы при регистрации каждого нового клиента возлагать процесс принятия решения на операторов ввода, лучше хранить информацию, связанную с регионами, в отдельной таблице. Эту таблицу можно было бы назвать tblRegion; структура ее совсем проста.

Данные в этой таблице выглядели бы следующим образом: 

В этой усовершенствованной версии структуры базы данных для выборки информации о регионе вам придется выполнить двухтабличный запрос с объединением двух таблиц – tblCustomer и tblRegion, причем из одной таблицы вы получите информацию о штате, а из другой – о регионе (на основании информации о штате). В объединениях сопоставляются записи, имеющие общие поля, в отдельных таблицах. (Более подробно объединения описываются в главе 2, "Запросы и команды на языке SQL".) Хранение информации о регионах в отдельной таблице имеет ряд преимуществ.

• Если вы решили выделить новый регион на основе существующего, то для отражения рождения нового региона проще изменить всего несколько записей в таблице tblRegion, чем тысячи записей в таблице tblCustomer.

• Если вы расширите свой бизнес за пределы 50 штатов, то для отражения изменений в бизнесе достаточно опять-таки добавить новый регион. Для этого вам понадобится внести в таблицу tblRegion всего по одной записи для каждой новой области, и эта новая запись немедленно станет доступной для всей системы.

• Если обнаружится необходимость использования принципов регионального деления в других задачах, решаемых на основе этой базы данных (например, для обозначения того, что офис по продажам, расположенный в определенном штате, обслуживает определенный регион), то вы могли бы с успехом использовать таблицу tblRegion без модификаций.

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

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

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

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

Выражение отношения один-ко-многим почти такое же простое для понимания (но гораздо более гибкое), как выражение отношения один-к-одному, поэтому сразу же переходим к следующему разделу.

Гораздо чаще, чем отношения типа один-к-одному, в базах данных используются отношения типа один-ко-многим, в которых каждая запись таблицы связана с одной или несколькими записями в другой таблице (или вообще не связана ни с какими записями). В созданной ранее схеме базы данных между клиентами и заказами задано отношение один-ко-многим. Каждый клиент может иметь один или несколько заказов (или вообще не иметь заказов), поэтому между таблицами tblCustomers и tblOrder существует отношение один-ко-многим.

Напомним, что для реализации такого отношения в базе данных копируется первичный ключ из таблицы на стороне "один" в таблицу на стороне "многие". В пользовательском интерфейсе для ввода данных этот тип отношения обычно имеет вид формы с основной (master) и подчиненной (slave) частями, в которой одна основная запись отображается со своими подчиненными записями в отдельной части формы. В пользовательском интерфейсе первичный ключ из одной таблицы обычно связывает ся с внешним ключом из связанной таблицы с помощью списка или поля со списком.

Отношение типа многие-ко-многим по сравнению с отношением один-ко-многим идет еще дальше. В качестве классического примера отношения типа многие-ко-многим можно привести отношение между студентами и классами. Каждый студент может иметь много классов, а каждый класс – много студентов. (Конечно же, возможны варианты, когда класс будет состоять из одного студента или в нем вовсе не будет ни одного учащегося, а также вполне возможно для студента иметь только один класс или ни одного.)

В данном бизнес-примере отношение задается между заказами и позициями заказа, т.е. каждый заказ может содержать несколько позиций, а каждая позиция может присутствовать в нескольких заказах.

Чтобы установить отношение многие-ко-многим, необходимо иметь три таблицы: две для хранения реальных данных и третью (именуемую соединительной) для хранения отношения между двумя первыми таблицами. Таблица соединения обычно состоит только из двух внешних ключей – по одному из каждой связанной таблицы, хотя иногда в таблице соединения полезно использовать собственное поле с идентификаторами для предоставления доступа к записям таблицы с помощью программных средств.

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

РИС. 1.13. В этой группе таблиц, участвующих в отношении многие-ко-многим, tbIOrderItem является таблицей соединения

Разработчики предыдущих версий Visual Basic первыми предложили концепцию связывания данных, согласно которой связанный с данными объект или элемент управления данными (data control) позволяет программистам с минимальными усилиями создавать простые, связанные с данными пользовательские интерфейсы. В Visual Basic .NET эта концепция также поддерживается, а многие недостатки прежней версии устранены.

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

На платформе .NET операциями подключения к базе данных и извлечения данных управляет автоматически созданный код, что позволяет добиться ряда преимуществ.

1. Автоматически созданный код, в отличие от абстрактного элемента управления данными, можно просматривать, поэтому он позволяет в большей степени контролировать способы доступа к данным.

2. Изучая автоматически созданный код, программист может познакомиться с классами платформы .NET, предназначенными для доступа к данным, что особенно полезно для тех, кто не имеет опыта работы на платформе .NET.

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

В приведенных ранее примерах создана база данных, которая вполне подходит для ознакомления с основными принципами создания связанного с данными пользовательского интерфейса. В следующих разделах демонстрируются способы создания связанных с базой данных приложений на основе Windows Forms.

Нет ничего проще, чем создать приложение на основе Windows Forms. И в этом заявлении нет никакого преувеличения; более того, если вас интересует лишь просмотр содержимого базы данных, вам вообще не придется писать ни единой строки кода. Весь процесс состоит из двух этапов: подключение к базе данных и связывание последнего пользовательского интерфейса с источником данных, генерированным Visual Studio .NET. Для этого выполните перечисленные ниже действия.

1. В Visual Studio .NET создайте новый проект на основе Windows Forms и откройте новую форму Form1.

2. В окне Server Explorer найдите созданную ранее таблицу tblCustomer и перетащите ее из окна Server Explorer в форму Form1.

3. После этого в нижней части окна с формой Form1 появятся объекты SqlConnection1 и SqlDataAdapter1.

Для извлечения и отображения данных используются три объекта: объект SqlConnection1 создает подключение к базе данных, объект-адаптер SqlDataAdapter1 извлекает данные, а объект DataSet сохраняет данные, извлеченные адаптером SqlDataAdapter1. Для создания объекта DataSet выполните следующее.

 1. Выберите команду меню Data→Generate Dataset (Данные1→Генерация набора данных), и на экране появится диалоговое окно Generate Dataset.

2. Воспользуйтесь всеми заданными по умолчанию параметрами и щелкните на кнопке OK. В результате будет создан новый объект DataSet11, который будет располагаться в нижней части окна под формой Form1 возле объектов SqlConnection1 иSqlDataAdapter1.

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

1. Откройте панель элементов управления Toolbox с помощью команды меню View→Toolbox (Просмотр→Панель инструментов управления), перейдите во вкладку Windows Forms и найдите элемент управления DataGrid (Сетка данных). Перетащите его в форму Form1, и в ней появится экземпляр DataGrid1 объекта DataGrid.

2. Свяжите этот элемент управления с источником данных. Для этого с помощью команды меню View→Properties Window (Просмотр1→Окно свойств) откройте окно свойств Properties и выберите для свойства DataSource (Источник данных) сетки DataGrid1 источник данных DataSet11. Затем выберите для свойства DataMember (Элемент данных) сетки DataGrid1 таблицу tblCustomer.

3. Наконец, создайте код извлечения данных из базы данных и вставки их в сетку DataGrid1. Для этого дважды щелкните на форме, и в окне просмотра кода автоматически появится процедура Form1_Load. Введите в ней следующий код:

Private Sub Form1_Load(ByVal sender As System.Object , _

 ByVal e As System.EventArgs) Handles MyBase.Load

 SqlDataAdapter1.Fill(DataSet11)

End Sub

4. Запустите полученное приложение с помощью команды меню Debug→Start (Отладка→Запуск), и в окне приложения будут отображены данные из таблицы tblCustomer.

Здесь следует отметить одну особенность данного приложения. Все внесенные в нем изменения данных не будут отражены и сохранены в базе данных. Для их сохранения нужно создать дополнительный код вызова метода объекта DataAdapter. Эта тема рассматривается далее, в разделе об обновлении записей.

В предыдущем примере показан простейший способ связывания данных на основе извлечения всей таблицы и отображения ее в элементе управления DataGrid. А как отобразить только одну запись? Для этого потребуется использовать элементы управления TextBox и Button, а также создать дополнительный код.

Чтобы создать приложение для просмотра данных по одной записи из таблицы tblCustomer, выполните ряд действий.

 1. В Visual Studio .NET создайте новый проект на основе Windows Forms и откройте новую форму Form1. Создайте в ней два текстовых поля, txtFirstName и txtLastName, на основе элемента управления TextBox.

2. Создайте объекты SqlConnection, SqlDataAdapter и DataSet для извлечения данных о клиентах из таблицы tblCustomer. (Необходимые для этого действия аналогичны действиям из предыдущего примера.) Как и прежде, не забудьте вызвать метод Fill объекта SqlDataAdapter в коде для инициализации объекта DataSet. (В данном примере объект DataSet имеет имя DsCustomer1. - Прим. ред.)

3. Теперь нужно создать связь между двумя текстовыми полями (txtFirstName и txtLastName) и соответствующими полями в базе данных. Для этого щелкните на текстовом поле txtFirstName и в группе свойств Data выберите подгруппу свойств (DataBindings). Это свойство содержит несколько свойств, которые следует установить для связывания данных таблицы с текстовым полем.

4. Выберите поле FirstName таблицы tblCustomer для свойства Text текстового поля txtFirstName. Для этого щелкните в правой части поля со списком возле свойства Text. Выберите набор данных DsCustomer1, таблицу tblCustomer и поле FirstName, как показано на рис. 1.14.

РИС. 1.14. Создание связи между данными из поля базы, данных и текстовым полем с помощью свойств (DataBindings)

5. Аналогично свяжите текстовое поле txtLastName с полем LastName таблицы tblCustomer.

6. Запустите приложение, в текстовых полях которого будут отображены имя и фамилия первого клиента.

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

Даже в таком ограниченном примере очевидны преимущества способов связывания данных на платформе .NET: они более гибки, чем аналогичные способы в Visual Basic 6. Например, упомянутая гибкость достигается за счет способности управлять процессом связывания с помощью кода.

Попробуем теперь создать код для перехода от одной записи к другой с помощью перечисленных ниже действий.

1. Создайте две кнопки, btnNext и btnPrevious, для перехода к следующей и предыдущей записям.

2. Дважды щелкните на кнопке btnNext и в автоматически появившемся окне редактирования кода с определением процедуры btnNext_Click вставьте следующий код:

Private Sub btnNext_Click(ByVal sender As System.Object, _

 ByVal e As System.EventArgs) Handles btnNext.Click

 Me.BindingContext(DsCustomer1, "tblCustomer").Position += 1

End Sub

3. Дважды щелкните на кнопке btnPrevious и в автоматически появившемся окне редактирования кода с определением процедуры btnPrevious_Click вставьте код

Private Sub btnPrevious_Click(ByVal sender As System.Object, _

 ByVal e As System.EventArgs) Handles btnPrevious.Click

 Me.BindingContext(DsCustomer1, "tblCustomer").Position -= 1

End Sub

4. Снова запустите приложение и убедитесь в том, что с помощью созданных кнопок можно переходить к следующей и предыдущей записям. (Учтите, что эта программа будет работать только при наличии нескольких записей в таблице.)

Объект BindingContext предоставляет средства организации перехода к другим записям в приложении для работы с данными. При создании таких приложений в предыдущих версиях Visual Basic для организации переходов к другим записям требовалось использовать элемент управления Data. На платформе .NET выделен, специальный объект BindingContext, который отвечает за связывание данных. (Иными словами, выделение небольшого специализированного объекта из более крупного общего объекта позволяет распределить специализированные функции среди нескольких объектов меньшего размера.) В объектно-ориентированном программировании разработчик стремится создавать специализированные объекты, чтобы упростить структуру программы и сделать ее более гибкой.

Таким образом, при создании приложения, рассчитанного на работу с базами данных, для составления запросов, обновления данных, связывания элементов управления пользовательского интерфейса с данными и перехода к полям таблицы не рекомендуется использовать один громоздкий объект Data. Вместо него в Windows Forms и ADO.NET предусмотрено несколько отдельных специализированных объектов. Выделение функций доступа к данным – ключевое достоинство платформы .NET Framework (этот вопрос подробно рассматривается в следующих главах).

Объект BindingContext является членом семейства объектов Windows Forms (а точнее, членом пространства имен System.Windows.Forms платформы .NET Framework) и содержит множество полезных свойств и методов. Например, объект BindingContext можно использовать для определения количества записей в источнике данных так, как описано ниже.

1. Создайте ярлык lblDataStatus с помощью элемента управления Label с пустой строкой в свойстве Text.

2. В коде формы создайте подпрограмму ShowDataStatus с указанным ниже кодом, которая будет отображать текущее расположение записи и общее количество записей в ярлыке lblDataStatus.

Private Sub ShowDataStatus()

 With Me.bindingContext(DsCustomer1, "tblCustomer")

  lblDataStatus. Text = "Record " +  s.Position + 1 & " of " & .Count

 End With

End Sub

3. Поместите вызов этой подпрограммы ShowDataStatus в подпрограммы обработки событий загрузки формы (Forml_Load) и щелчков мыши на обеих кнопках (btnNext_Click и btnPrevious_Click). Это позволит отображать обновленную информацию о текущем количестве записей и текущей записи при загрузке формы и после каждого перемещения к другой записи. Учтите, что отсчет текущего номера записи (свойство Position объекта DataBindings) начинается с нуля (как и во всех коллекциях на платформе.NET). Поэтому для получения реального номера записи следует прибавить к нему 1.

4. Запустите приложение и попробуйте перейти к разным записям таблицы. Тогда в ярлыке будет отображено общее количество записей в таблице и номер текущей записи.

С помощью Windows Forms связывание данных можно организовать программно. Это позволяет добиться более высокой гибкости в ситуациях, когда расположение полей неизвестно во время создания приложения либо требуется явно выразить связь между элементами управления и полями другим способом, чем предлагается в интегрированной среде разработки.

Чтобы организовать связь с элементами управления пользовательского интерфейса, следует создать метод Add объекта DataBindings элемента управления Windows Forms. В листинге 1.1 показан типичный способ создания связи с данными в приложении для работы с базами данных.

Private Sub Form1_Load (ByVal sender As System.Object, ByVal e As _

 System.EventArgs) Handles MyBase.Load

 txtFirstName.DataBindings.Clear()

 txtLastName.DataBindings.Clear()

 txtFirstName.DataBindings.Add("Text", DsCustomer1, "tblCustomer.LastName")

 txtLastName.DataBindings.Add("Text", DsCustomer1, "tblCustomer.LastName")

 sqlAdapterl.Fill(DsCustomer1)

 ShowDataStatus()

End Sub

(Убедитесь в том, что для свойства ConnectionString объекта SqlConnection1 задана верная строка подключения с используемым вами сервером SQL Server. Дело в том, что в коде этого примера, который можно скопировать по адресу: http://www.williamspublishing.com указана строка подключения к серверу SQL Server, установленному на компьютере ROCKO автора книги. – Прим. ред.)

Обратите внимание, что вызовы метода Clear элементов управления коллекции DataBindings не обязательно создавать в разрабатываемом приложении. Они нужны в этом случае, потому что связь с данными ранее задана с помощью окна Properties.

Метод Add коллекции DataBindings принимает три параметра: свойство элемента управления, с которым связываются данные; объект источника данных (обычно, но не обязательно объект DataSet), ссылка на член источника данных, который предоставляет данные. После запуска приложения с приведенным выше кодом для метода Load в поле с именем клиента будет отображена его фамилия, а в поле с фамилией – его имя.

Элементом управления, взаимодействующим с данными (data-aware control), может быть любой элемент управления, имеющий свойство-коллекцию DataBindings. С помощью этого свойства можно ссылаться на любой тип данных, включая реляционные источник данных.

Свойство DataBindings соединяет элемент управления пользовательского интерфейса с элементом управления данными (т.е. именно так происходит связывание пользовательского интерфейса с базой данных). Поэтому говорят, что элемент управления пользовательского интерфейса связан с базой данных через элемент управления данными.

В предыдущих версиях Visual Basic с источником данных можно было связать относительно небольшое количество элементов управления пользовательского интерфейса. Возможности манипулирования связанными с данными элементами управления были довольно ограниченными: пользователь мог связать их с теми источниками данных, для которых существует провайдер данных ADO. Для взаимодействующих с данными элементов управления разработчику приходилось создавать рутинный код большого размера для выполнения вручную всех операций связывания данных. На платформе.NET практически каждый элемент управления Windows Forms может быть связан с данными, включая сложные элементы управления, например Tree View. Более того, разработчик не ограничен только реляционными источниками данных или известными среде Visual Studio .NET или ADO.NET. Любой объект, реализующий интерфейс IList, может быть связан с данными, включая наборы данных DataSet и более сложные конструкции, например массивы и коллекции.

До сих пор в приведенных ранее примерах нам удавалось только извлекать и просматривать данные. А изменять данные можно было только в элементах пользовательского интерфейса, но их нельзя было сохранить (зафиксировать) в базе данных.

Интуитивно понятно, что изменения в связанном с данными элементе управления пользовательского интерфейса должны автоматически сохраняться в базе данных. Именно так работают различные связанные с данными элементы управления пользовательского интерфейса в прежних версиях Visual Basic. Почему же в Windows Forms на платформе.NET связывание с данными организовано иначе?

Принудительная фиксация обновлений в источнике данных с помощью дополнительной строки кода продиктована требованиями гибкости и более высокой производительности. Рассмотрим принцип работы объекта DataSet на платформе .NET.

На рис. 1.15 показана схема взаимосвязи между формой, объектом DataSet и базой данных в приложении на основе Windows Forms.

РИС. 1.15. Схема взаимосвязи между связанной формой, объектом DataSet и базой данных

В созданном ранее приложении все данные в исходном состоянии находятся в базе данных. Затем они извлекаются и сохраняются в памяти в объекте DataSet. Форма содержит элементы управления, связанные с полями таблицы в объекте DataSet. Форма обнаруживает появление новых данных и автоматически отображает содержимое полей в связанных с данными элементах управления.

В связанном с данными приложении изменение содержимого связанного с данными элемента управления влияет только на объект DataSet, т.е. изменение содержимого текстового поля приводит к изменению содержимого записи в таблице, которая находится в объекте DataSet. Но изменение объекта DataSet не копируется в базу данных, а сохраняется до тех пор, пока не поступит явное указание скопировать их в базу данных (с помощью метода Update набора данных DataSet). Хотя явное включение этой инструкции может показаться излишним (ведь в прежних версиях Visual Basic этого делать было не нужно), но на самом деле оно позволяет добиться более высокой производительности. Дело в том, что в таком случае приложению не нужно постоянно поддерживать соединение с базой данных во время редактирования данных пользователем.

В листинге 1.2 показан пример модифицированных обработчиков событий, которые позволяют редактировать данные в созданном ранее приложении.

Private Sub btnNext_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles bfnNext.Click

 Me.BindingContext(DsCustomer1, "tbICustomer").Position += 1

 SqlDataAdapter1.Update(DsCustomer1)

 ShowDataStatus()

End Sub

Private Sub btnPrevious_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnPrevious.Click

 Me.BindingContext(DsCustomerl, "tblCustomer").Position -= 1

 SqlDataAdapter1.Update(DsCustomer1)

 ShowDataStatus()

End Sub

Конечно, обновлять каждую запись при перемещении пользователя к другим записям совсем не обязательно. Поскольку разработчик может контролировать способ обновления объекта DataSet, можно было бы организовать обновление внесенных изменений с помощью специальной кнопки или команды меню Save. Можно также отложить фиксацию обновлений до окончания редактирования группы строк, т.е. использовать пакетное обновление. ВADO.NET для пакетного обновления не нужно создавать какой-либо иной специализированный код, потому что оно выполняется автоматически объектами DataSet (который сохраняет данные в памяти) и SqlDataAdapter (который отвечает за выполнение необходимых команд управления базой данных для гарантированного корректного представления, вставки, обновления и удаления данных). Более подробно связь между этими объектами описывается в главах 5, "ADO.NET: объект DataSet", и 6, "ADO.NET: объект DataAdapter".

Для создания новой записи в связанном с данными приложении на основе Windows Forms нужно использовать метод AddNew объекта BindingContext. При выполнении этого метода любые связанные с данными элементы управления очищаются для ввода новых данных. После ввода новых данных они фиксируются в базе данных с помощью метода Update объекта DataAdapter (как в предыдущем примере).

Для создания новых записей в связанном с данными приложении выполните перечисленные ниже действия.

1. Создайте в форме новую кнопку с именем btnNew и укажите значение New (Ввести новые данные) для ее свойства Text.

2. Щелкните дважды на кнопке и введите приведенный ниже код обработки события щелчка на этой кнопке.

Private Sub btnNew_Click(ByVal sender As System.Object, _

 ByVal e As System.EventArgs) Handles btnNew.Click

 Me.BindingContext(DsCustomer1, "tblCustomer").AddNew()

 txtFirstName.Focus()

 ShowDataStatus()

End Sub

3. Запустите приложение и щелкните на кнопке New. После очистки текстового поля пользователь сможет ввести в форме новую запись. Для сохранения новой записи нужно перейти к другой записи с помощью кнопок Next или Previous.

Учтите, что кнопки Next или Previous фиксируют обновления объекта DataSet, поэтому в данном примере не нужно использовать явные инструкции обновления объекта DataSet после создания новой записи. В данном случае достаточно просто перейти к другой записи. Но если пользователь закроет приложение до фиксации новых данных в базе данных (либо неявно с помощью перехода к другой записи, либо явно с помощью метода Update объекта DataAdapter), то новые данные будут утрачены.

Кроме того, пользователю обычно предоставляют возможность отмены внесенных изменений с помощью метода CancelCurrentEdit объекта BindingContext.

Для удаления записей из связанной с данными формы на основе Windows Forms нужно использовать метод RemoveAt объекта BindingContext. Этот метод принимает один параметр – индекс удаляемой записи. Для организации удаления текущей записи нужно использовать свойство Position в качестве параметра метода RemoveAt объекта BindingContext, как показано в листинге 1.3.

Private Sub btnDelete_Click(ByVal sender As System.Object, _

 ByVal e As System.EventArgs) Handles btnDelete.Click

 If MsgBox("Whoa bubba, you sure?", MsgBoxStyle.YesNo, "Delete record") = MsgBoxResult.Yes Then

  With Me.BindingContext(DsCustomer1, "tblCustomer")

   RemoveAt(.Position)

  End With

 End If

End Sub

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

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

В программировании баз данных проверка введенных данных (validation) гарантирует, что эти данные отвечают правилам, определенным при проектировании приложения. Эти правила называются правилами проверки данных (validation rules). Один из способов проверки данных при программировании приложения на основе Windows Forms состоит в написании кода для события RowUpdating объекта DataAdapter. Событие RowUpdating возникает как раз перед обновлением записи, а событие Row-Updated — сразу после обновления записи. Размещая код проверки введенных данных в событие RowUpdating, можно быть уверенным в том, что будут обрабатываться любые изменения данных в любой части приложения.

Ключевым фактором эффективного использования события RowUpdating является использование свойств и методов аргумента события, который представлен в виде экземпляра объекта System.Data.SqlClient.SqlClient.SqlRowUpdatingEventArgs.

Кроме проверки команды обновления записи (с помощью свойства Command объекта), можно проинформировать адаптер данных DataAdapter об отказе от обновления и откате внесенных изменений. В листинге 1.4 этот подход иллюстрирует рассмотренный ранее пример приложения для просмотра данных.

Private Sub SqlDataAdapter1_RowUpdating(ByVal sender As Object, _

 ByVal e As System.Data.SqlClient.SqlRowUpdatingEventArgs) _

 Handles SqlDataAdapter1.RowUpdating

 If e.Row.Item("FirstName") = "" Or e.Row.Item("LastName") = "" Then

  MsgBox("Change not saved; customer must have a first and last name.")

  e.Status = UpdateStatus.SkipCurrentRow

  e.Row.RejectChanges()

 End If

End Sub

Передача значения UpdateStatus.SkipCurrentRow свойству Status аргумента события позволяет сообщить адаптеру данных о прекращении операции, т.е. отмене обновления данных, потому что оно не прошло проверку. Но недостаточно просто прекратить выполнение операции, потому что в этом случае пользователь получит пустое текстовое поле (и пустое поле в объекте DataSet). Для решения этой проблемы следует вызвать метод RejectChanges объекта Row, который содержится в аргументе события. Он обновит содержимое пользовательского интерфейса и сообщит объекту DataSet о том, что больше не нужно согласовывать эту строку с базой данных. После этого можно продолжать редактирование данных, не беспокоясь об их безопасности.

Помимо проверки данных во время ввода информации, следует знать о том, что можно также выполнять проверку и на уровне процессора баз данных. Такая проверка обычно более надежна, поскольку применяется независимо от причины изменения данных. При этом вам не нужно заботиться о реализации правил проверки введенных данных в каждом приложении, которое получает доступ к какой-нибудь таблице. Однако проверка введенных данных на уровне процессора баз данных отличается меньшей гибкостью, поскольку его практически невозможно переопределить, и часто имеет примитивную форму (обычно ограничивается тем, что не допускает ввод в поля пустых значений). Кроме того, проверку введенных данных на уровне процессора баз данных можно выполнять только на уровне поля, и вы не сможете сделать так, чтобы правила проверки введенных данных, реализуемые процессором баз данных, были основаны на сравнении значений двух полей (если только проверка не реализована на основе ограничения первичный/внешний ключ или реализована в серверной процедуре в виде триггера).

Контроль на уровне процессора баз данных является функцией схемы базы данных. Предположим, вы хотите быть уверены в том, что ни одна запись о клиенте не будет введена в таблицу tblCustomer без указания его имени и фамилии. Тогда установите правило проверки введенных данных на уровне процессора баз данных, выполнив перечисленные ниже действия.

1. В окне Server Explorer среды Visual Studio .NET откройте схему таблицы tblCustomer.

2. В столбце Allow Nulls (Допускаются неопределенные значения) снимите флажки FirstName и LastName.

3. Сохраните схему таблицы tblCustomer с помощью команды меню File→Save tblCustomer.

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

Эта глава посвящена основам баз данных в целом, а также простейшим способам соединения приложений Visual Basic .NET для работы сданными, хранящимися в базе данных SQL Server. Следует учитывать, что правильно составленная схема базы данных может значительно повысить производительность и практичность приложения. Нормализация, ссылочная целостность и индексирование могут оказаться весьма эффективными для достижения этих целей. Однако помните, что чрезмерное индексирование может привести к обратному эффекту и замедлить работу приложения. В следующих главах приводятся примеры бизнес-ситуаций, в которых следует учитывать эти особенности.

Существует ли в Visual Studio .NET элемент управления Data, который в Visual Basic 6 можно было успешно использовать для быстрого создания прототипов данных?

Нет. Все функции элемента управления Data, который использовался в Visual Basic 6 и более старых версиях, теперь распределены среди разных объектов данных. Например, соединение с базой данных теперь создается с помощью отдельного объекта SqlConnection, операции извлечения, обновления и удаления данных — с помощью объектов BindingContext и DataAdapter, а операции перемещения по записям — с помощью объекта BindingContext. В отличие от прежних объектов для работы с данными, новые объекты не имеют никакого визуального представления во время выполнения, что позволяет разработчику создавать практически любые виды пользовательского интерфейса для работы с данными.

Можно ли первичный ключ составить из нескольких полей?

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