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

Глава 2 • Сущности и взаимоотношения данных 27
$frWM*e! Рис. 2.11 может показаться вам сложным.
Поверните вертикальные символы на 90", и вам будет легче прочитать взаимоотношения.
Поскольку составные сущности создаются главным образом для указания взаимоотношений, установленных между двумя другими сущностями, они должны быть связаны с обеими своими родительскими сущностями. Именно поэтому взаимоотношение между каждой составной сущностью на рис. 2.11 и ее родителями обязательно.
Взаимоотношения и бизнес-правила
Во многих случаях проектирование базы данных в такой же мере является искусством, как и наукой. Какую структуру конкретного предприятия считать правильной, зависит исключительно от применяемых бизнес-правил; что подходит для одной организации, может оказаться неприемлемым для другой.
Предположим, что создается база данных для предприятия розничной торговли, в состав которого входит несколько магазинов. Одним из аспектов, учитываемых при моделировании базы данных, является перечень служащих. Перед его составлением нужно ответить на вопрос по поводу типа взаимоотношения между служащим и магазином. Служащий работает всегда только в одном магазине, и тогда это взаимоотношение "один-ко-многим", или же распределяет свое рабочее время между несколькими магазинами, и, следовательно, имеет место взаимоотношение "многие-ко-многим"? Это вопрос не правильности или неправильности структуры базы данных, а принципов ведения деловой деятельности.
Итак, вывод: независимо от уровня владения методами проектирования нельзя построить хорошую базу данных, если взаимоотношения, обрисованные в ней, не являются точным отражением взаимоотношений, существующих в среде базы данных.
Моделирование данных и поток данных
Одной из самых распространенных ошибок, совершаемых теми, кто начинает моделирование данных, является неумение четко разделить модели данных и потоки Данных. Поток данных (data flow) описывает процесс обработки данных в организации: кто работает с данными, где они хранятся и что с ними происходит. Модель Данных (data model), напротив, описывает внутренние, логические взаимоотношения ежду данными безотносительно к тому, кто именно работает с данными или какие операции над ними выполняются.
(ХЛ Потоки данных часто документируются в виде диаграмм потоков данных v г-диаграмм — data flow diagrams). Например, на рис. 2.12 показана диаграмма Потоков данных верхнего уровня для Lasers Only. Квадраты представляют людей, Работающих с данными, а окружности — процессы (processes) — то, что с данными
28
Часть первая • Теория
Customer
Main database
Employee
Рис. 2.12. Диаграмма потоков данных верхнего уровня для Lasers Only
происходит. Область, где данные хранятся (хранилище данных — data store), изображена в виде двух параллельных линий, в этом примере ограничивающих фразу Main Database (главная база данных). Стрелки на линиях показывают способ передачи данных из одной области в другую.
Customer
Т store in validate in
Main database
Employee
Рис. 2.13. Развитие процесса Take order, изображенного на рис. 2.12
2 • Сущности и взаимоотношения данных
29
Customer
с\ле/3.1.1.2Ч\* [ Validate ) \ number/
if existing ч-^ customer
"Л Main database
РИС. 2.14. Развитие процесса Get customer information, изображенного на рис. 2.13
Для более детального представления потоков диаграммы часто разбиваются на элементы. На рис. 2.13 показано развитие процесса Take order (принять заказ), изображенного на рис. 2.12. Теперь можно видеть, что процесс принятия заказа состоит из двух основных этапов: получения информации о клиенте (Get customer information) и получения сведений о заказанных товарах (Get items ordered).
Каждый из процессов рис. 2.13 можно развить и далее, показав дополнительные подробности (см. рис 2.14 и 2.15). В итоге диаграммы будут детализированы практически до такой степени, что разработчик приложения сможет составить алгоритм прикладной программы.
Какое место во всем этом занимают база данных и ее ER-диаграмма? Вся Wv-диаграмма скрыта внутри Main Database. На практике большинство инструментальных средств CASE позволяет связать ER-диаграмму с представлением базы Данных на DF-диаграмме. Затем можно дважды щелкнуть клавишей мыши на пред-авлении базы данных, в результате чего появится ER-диаграмма.
tbwtbhribgi Подробнее об использовании инструментальных средств CASE рассказывается в главе У.
30
Часть первая • Теория
Рис. 2.15. Развитие процесса Get items ordered, изображенного на рис. 2.13
Приведем несколько общих положений, связанных с разделением потоков данных и моделей данных: v .
¦ Поток данных показывает тех, кто использует данные или работает с ними. Модель данных этого не предоставляет.
¦ Поток данных показывает метод сбора данных (людей или другие источники, откуда поступает информация). В модели данных этого нет.
¦ Поток данных показывает операции, выполняемые над данными (процессы, посредством которых данные преобразуются). Модель данных не отображает этого.
¦ Модель данных показывает взаимосвязанные сущности данных. Поток данных этого не предоставляет.
¦ Модель данных показывает атрибуты, характеризующие сущности данныХ' В потоке данных этого нет.
fjiaea 2 • Сущности и взаимоотношения данных
31
Таким образом, основным выводом является следующий: в модели данных с0держится информация о данных, хранящихся в базе (о сущностях, атрибутах ¦I о взаимоотношениях сущностей). Если данные о некоторой сущности не предполагается хранить в базе данных, эта сущность не должна быть частью базы данных. Так, хотя на диаграмме потоков данных в Lasers Only показан служащий Lasers Only, работающий с основным объемом данных, сведения о служащих храниться в базе данных не будут. Поэтому на ER-диаграмме нет сущности служащих.
ш
Схемы
Завершенная диаграмма взаимоотношений сущностей представляет общий логический план базы данных и называется схемой (schema). С помощью схемы персонал, отвечающий за сопровождение базы данных, может анализировать ее структуру. Однако пользователи (как интерактивные пользователи, так и прикладные программы) имеют возможность работать только с частью логической схемы. Причем логическая схема и представления данных, применяемые пользователями, отличаются от вида информации, в котором она хранится физически.