"Проектирование реляционных баз данных." - читать интересную книгу автора (Джен Л. Харрингтон)

Street
City, State Zip
Phone
? Item shipped?
Item number | j title f~~---------------------~~-----------' " I
Price f ~— -~~ ' ~"
'¦• 1.1. Форма для ввода данных, используемая в Lasers Only для почтовых заказов
Order date:
I
\
4
Часть первая • Теория
Когда в магазин поступает новый диск, служащий просматривает базу данных в поисках всех лиц, заказавших этот диск, затем печатает упаковочный лист (бланк) и помечает знаком X флажок Item shipped? (Товар отправлен?).
На первый взгляд кажется, что программное обеспечение Lasers Only просто, понятно и должно работать замечательно. Так оно вначале и было, но спустя год или два возникли серьезные проблемы.
Ненужное дублирование данных и согласование данных
В базе данных Lasers Only значительный объем занимают повторяющиеся данные:
¦ Имя, фамилия, адрес и номер телефона клиента дублируются для каждого заказываемого им товара.
¦ Название товара дублируется каждый раз при его заказе.
Дублируемая подобным образом информация должна быть идентична по всей базе данных. Другими словами, в каждом заказе конкретного клиента должны фигурировать и печататься абсолютно одинаково одни и те же имя, фамилия, адрес и номер телефона. В каждом заказе одного из дисков название диска должно быть в точности таким же и напечатано точно так же, как и его названия во всех других заказах. Нужно, чтобы повторяющиеся данные были согласованы по всей базе данных.
С ростом базы данных все сложнее обеспечивать согласование подобного рода. Большая часть программ для баз данных, ориентированных на ведение бизнес-приложений, чувствительна к состоянию регистра символов, т. е. в таких программах буквы верхнего и нижнего регистров рассматриваются в качестве разных символов. К тому же никто не сможет гарантировать абсолютно безошибочного ввода данных. Разница в регистре буквы (прописная или строчная) или даже пропуск буквы может привести к тому, что программное обеспечение базы данных будет считать два значения различными.
Когда служащий Lasers Only ищет всех лиц, заказавших конкретный диск, программное обеспечение базы данных выбирает только те заказы, которые в точности соответствуют введенному названию. Предположим, что запланировано появление фильма "Summer Days". В некоторых заказах его название введено корректно. "Summer Days". В ряде же других оно указано как "summer days" или даже как "Sumer Days". В результате при поиске тех, кому нужно отправить этот фильм, заказь с "summer days" и "Sumer Days" выбраны не будут. Эти клиенты не получат свои заказы, что вызовет их недовольство и, скорее всего, приведет к снижению объемо торговой деятельности.
Применяемое в настоящее время программное обеспечение Lasers Only не мо гарантировать согласованного ввода повторяющихся данных. Существуют два ре ния этой проблемы. Первое — устранить максимально возможный объем дублиру мых данных (как вы увидите, удалить их все или невозможно, или нежелательн
А
Глава 1 • Введение
5
Второе — разработать некий алгоритм проверки корректного ввода тех данных, кото-owe должны дублироваться. В грамотно спроектированной базе данных реализуются оба этих решения.
нужное дублирование данных, помимо всего прочего, приводит к излишнему расходованию дискового пространства. Однако с учетом того, что сегодня дисковая память относительно недорога, это не является веским доводом для избавления от избыточных данных.
Проблемы с вводом данных
В Lasers Only каталог выходящих вскоре дисков готовился вручную. Каждый месяц, когда от оптовиков поступали уведомления о новинках, специальный служащий выполнял операцию "вырезания и вставки", формируя 16-страничный буклет, который размножался и рассылался по почте клиентам. Однако в 1995 г. Стоун поняла, что это очень неудобно, и решила, что намного лучше создавать каталог из базы данных.
Почему бы не создать специальную программу, генерирующую полный каталог на основе получаемого из базы данных перечня новых дисков? В результате выяснилось, что это невозможно по двум причинам.
Во-первых, в текущей базе данных не содержится вся информация, необходимая для создания каталога, в частности, отсутствует обзор содержимого диска. Эту проблему можно было бы устранить, добавив нужную информацию к текущей базе данных. Однако, если при этом компании необходимо подытоживать каждый заказ, то обостряется проблема с излишним дублированием данных. Если сводка будет создаваться только однажды, то как узнать, в каком из заказов она содержится?
Во-вторых, и это гораздо важнее, невозможно ввести данные о диске, который не заказан. В Lasers Only нельзя ввести информации о диске до тех пор, пока он не будет заказан хотя бы однажды. Никто не сможег'получить генерируемый компьютером каталог и узнать о том, что диск доступен для заказа, если кто-нибудь не разместит эту информацию в базе данных.
МянтЯМНФ! Эта проблема более известна как "аномалия ввода" (см. ниже).
Проблемы с удалением данных
В Lasers Only существуют также проблемы с удалением данных. Предположим, клиент заказывает только один товар. После обработки заказа выпуск этого товара {«останавливается производителем. Следовательно, из базы данных Lasers Only **но удалить лишь все ссылки на товар, поскольку он больше недоступен.
6
Часть первая • Теория
При удалении заказов, содержащих этот товар, информация обо всех клиентах, заказавших только данный товар, также удаляется. Для такого клиента в базе данных не остается сведений ни о каких других заказах. Lasers Only не сможет посылать ему каталоги и поэтому потеряет шанс получить от него новые заказы.
Эта проблема более известна как "аномалия удаления" (см. ниже).
Смысловая значимость идентификаторов
В базе данных Lasers Only существует еще одна серьезная проблема: номера клиентов. Часто возникает желание придать идентификатору определенный смысл, что, как правило, полезно,— но до тех пор, пока значения, на которых основан идентификатор, не изменяются.
Рассмотрим ситуацию, когда клиент Lasers Only меняет место жительства. Личный номер клиента при этом должен измениться. В результате для одного клиента в одной и той же базе данных будут существовать заказы с разными номерами.
Если клиент звонит и запрашивает перечень всех заказанных товаров, служащий, отвечающий на телефонный звонок, первым делом интересуется номером данного клиента. Клиент, естественно, сообщает текущее значение, т. е. все то, что было заказано под старым номером, во время поиска будет пропущено. Тогда клиент может сделать еще один заказ, и в результате ему направят два экземпляра одного и того же товара. После этого у Lasers Only появится еще один недовольный клиент, которому придется отсылать обратно дубликат и с кредитной карты которого соответствующая сумма будет снята два раза.
Содержание книги
Эта книга поможет вам избежать тех проблем, о которых рассказывалось выше. В грамотно спроектированной базе данных существуют специальные процедуры для устранения избыточности данных, для согласования данных, для ввода необходимых данных без обязательного ввода "лишней" информации и для удаления данных без случайной потери той информации, которую нужно сохранить.
В главе 2 обсуждаются основы проектирования базы данных: определение логических взаимоотношений данных в той среде, где будет работать база данных, без обращения к программному обеспечению, которое будет применяться. В главе 3 рассматриваются модели данных — формальные способы отображения взаимоотношении данных на программное обеспечение баз данных. В общих чертах объясняется, что значит для базы данных быть реляционной. В главах с 4 по 7 исследуются характеристики реляционной модели данных, и наконец, в главе 8 рассказывается о использовании SQL (стандартного языка взаимодействия с реляционными базами

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