Обеспечение надежности структуры бозы донных

Мы определяем облик зданий, которые мы строим:

впоследствии они определяют наш облик .

- Сэр Уинстон Черчилль

Вопросы, россмотриАоемые а донной глопе:

Почему это ГЛ060 помещено здесь Зочем нужно хорошо продумонноя структуро остройко полей Ностройко тоблиц Устоновко и испровление связей Все ли это? /1тоги

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

Почему это глово помещено здесь

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

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

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

Зачем нужна хорошо продуманная структура

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

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

Теперь вернемся к первоочередным задачам формирования ваших структур: займемся полями.

Настройка полей

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

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

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

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

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

Является ли имя поля однозначным? Поле с именем PhoneNumber (Телефонный номер) может очень легкб ввести в заблуждение. Что это за номер телефона? Домашний? Рабочий? Мобильный? Давайте привыкать к точности. Если требуется записать каждый из этих типов номеров телефонов, создайте поля HomePhone, WorkPhone и CellPhone.

Для того чтобы сделать имена полей более четкими и однозначными, позаботьтесь о том, чтобы не использовать одни и те же имена в нескольких таблицах. Предположим, что имеются три таблицы с именами Customers, Vendors и Employees. Нет сомнений, что в каждой из этих таблиц будут поля City и State и что эти поля будут одинаково называться во всех трех таблицах. Это не будет представлять собой проблему до тех пор, пока вы не обратитесь к одному конкретному полю. Но как можно будет различить, скажем, поле City в таблице Vendors, поле City в таблице Customers и поле City в таблице Employees? Ответ прост: добавьте короткий префикс к каждому имени поля. Например, используйте имя VendCity в таблице Vendors, CustCity в таблице Customers и EmpCity в таблице Employees. Теперь можно легко сделать понятную ссылку на ка>кдое из этих полей. (Этот метод можно использовать для любого группового поля, например FirstName, LastName и Address.)

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

Используется ли в качестве имени поля акроним или сокращение? Если да, то замените его! Сокращение бывает трудно расшифровать и можно неверно понять. Представьте себе поле с именем CAD SW. Извольте догадаться, что это значит! Используйте сокращения как можно реже и обрабатывайте их внимательно. Применяйте их только в том случае, если они дополняют или расширяют имя поля положительным образом. Сокращение не должно отвлекать от смысла имени поля.