Сопоставьте записи для Джона Леверлинга (летчика с идентификационным номером ID 25100) в старой таблице Pilots и в новой таблице Pilot Certifications (Допуски пилотов). Основное преимущество новой связывающей таблицы в том, что теперь можно связывать любое количество сертификатов с одним летчиком. Задавать определенные типы запросов стало также намного легче. Например, можно определить, какие летчики имеют допуск к полетам на самолете Боинг-747, или извлечь список допусков для конкретного летчика. Можно также отсортировать данные в любом требуемом порядке без каких-либо неблагоприятных последствий.

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

Настройка таблиц

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

Что а имени тебе моем? (Чость второй)

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

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

Описывает ли имя предмет таблицы точно, понятно и однозначно? Когда имя таблицы туманно и неоднозначно, то можно поспорить, что таблица представляет более одного предмета. Имя Данные - это хороший пример туманного имени таблицы. Трудно точно определить, что представляет эта таблица, если нет на руках ее oпиtaния. Допустим, таблица появляется в базе данных агентства развлечений.

При тщательном ознакомлении с ней обнаружится, что в ней содержатся данные о встречах с клиентами и данные о продаже билетов на постоянных эстрадных артистов. Эта таблица явно представляет два предмета. В таком случае разделите таблицу на две и присвойте каждой из них соответствующее имя, например Client Meetings (Встречи с клиентами) и Entertainer Schedules (График выступлений эстрадных исполнителей).

Содержит ли имя слова, которые обозначают физические характеристики? Избегайте использования таких слов, как файл , запись и таблица , в именах таблиц, поскольку они вносят неразбериху. Таблица, в имени которой имеется слово такого типа, с очень большой вероятностью может представлять более чем один предмет. Рассмотрим имя Employee Record (Записи о сотрудниках). На первый взгляд, в связи с таким именем не могут возникнуть какие-то проблемы. Но когда вы задумаетесь о том, что должна включать запись о сотруднике, то поймете, что проблемы весьма вероятны. Имя содержит слово, которое потенциально представляет три предмета: служаищх, отделы и платежные ведомости. Учитывая это, разделите исходную таблицу (Employee Record) на три новые таблицы, по одной для каждого из предметов.

Используете ли вы акронимы или сокращения в качестве имени таблицы? Если да - измените имя немедленно! Сокращения редко могут четко описать предмет таблицы, а акронимы обычно трудно расшифровать. Пусть база данных вашей компании включает таблицу с именем SC. Как же узцать, что представляет таблица, если не знать значения, скрывающегося за этими буквами? Суть в том, что вы не сможете легко установить предмет таблицы. Более того, может оказаться, что таблица означает разное для разных отделов компании (вот это действительно ужасно!) Группа людей в отделе кадров думает, что оно обозначает Steering Committees (Руководящие комитеты); персонал из отдела информационных систем полагает, что это System Configurations (Конфигурации системы); сотрудники отдела безопасности считают, что оно обозначает SecurityCodes (Коды безопасности). Этот пример отчетливо показывает, почему следует избегать использования сокращений и акронимов в именах таблиц.

Используете ли вы имя, которое явно или неявно идентифицирует более одного предмета? Это одна из наиболее обычных ощибок, которую можно сделать, присваивая имена таблицам, и ее относительно легко распознать. Такой тип имени обычно содержит слова and (и) или or (или) и такие символы, как обратная наклонная черта (\), дефис (-) или амперсанд (&). Типичные примеры: Facility\Building (Здания\Строения) и Department or Branch (Отдел или Отделение). Когда таблице

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

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

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

Усоввршвнствононив структуры

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

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