Джеффри Мак-Манус - Обработка баз данных на Visual Basic®.NET

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

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

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

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