Кириллов В.В., Громов Г.Ю. - Введение в реляционные базы данных. Литература для вузов isbn 9785941577705 в книге рассматриваются основные понятия баз данных и систем управления ими
 Скачать 11.62 Mb.
|
|
Глава 10. Введение в проектирование Глава 11. Нормализация Глава 12. Пример проектирования базы данных "LIBRARY" Глава 10 Введение в проектирование 10.1. Цели проектирования Только небольшие организации могут обобществить данные в одной полно- стью интегрированной базе данных. Чаще всего администратор баз данных (даже если это группа лиц) практически не в состоянии охватить и осмыслить все информационные требования сотрудников организации (т. е. будущих пользователей системы). Поэтому информационные системы больших орга- низаций содержат множество баз данных, нередко распределенных между несколькими взаимосвязанными компьютерами различных подразделений. (Так в больших городах создается не одна, а несколько овощных баз, распо- ложенных в разных районах.) Отдельные базы данных могут объединять все данные, необходимые для ре- шения одной или нескольких прикладных задач, или данные, относящиеся к какой-либо предметной области (например, финансам, учебному процессу, кулинарии и т. п.). Первые обычно называют прикладными базами данных, а вторые — предметными базами данных (соотносящимся с предметами ор- ганизации, а не с ее информационными приложениями). Первые можно срав- нить с базами материально-технического снабжения или отдыха, а вторые — с овощными и обувными базами. Предметные базы данных позволяют обеспечить поддержку любых текущих и будущих приложений, поскольку набор их элементов данных включает на- боры элементов данных прикладных баз данных. Вследствие этого предмет- ные базы данных создают основу для обработки неформализованных, изме- няющихся и неизвестных запросов и приложений (приложений, для которых невозможно заранее определить требования к данным). Такая гибкость и приспосабливаемость позволяет создавать на основе предметных баз данных достаточно стабильные информационные системы, т. е. системы, в которых Часть IV. Основы проектирования баз данных 196 большинство изменений можно осуществить без вынужденного переписыва- ния старых приложений. Основывая же проектирование баз данных на текущих и предвидимых при- ложениях, можно существенно ускорить создание высокоэффективной ин- формационной системы, т. е. системы, структура которой учитывает наибо- лее часто встречающиеся пути доступа к данным. Поэтому прикладное проектирование до сих пор привлекает некоторых разработчиков. Однако по мере роста числа приложений таких информационных систем быстро увели- чивается число прикладных баз данных, резко возрастает уровень дублиро- вания данных и повышается стоимость их ведения. Таким образом, каждый из рассмотренных подходов к проектированию воз- действует на результаты проектирования в разных направлениях. Желание достичь и гибкости, и эффективности привело к формированию методологии проектирования, использующей как предметный, так и прикладной подходы. В общем случае предметный подход используется для построения первона- чальной информационной структуры, а прикладной — для ее совершенство- вания с целью повышения эффективности обработки данных. При проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей (сотрудников организации). Сбор данных начинается с изучения сущностей организации и процессов, использующих эти сущности. Сущности группи- руются по "сходству" (частоте их использования для выполнения тех или иных действий) и по количеству ассоциативных связей между ними (само- лет — пассажир, преподаватель — дисциплина, студент — сессия и т. д.). Сущности или группы сущностей, обладающие наибольшим сходством и (или) с наибольшей частотой ассоциативных связей, объединяются в пред- метные базы данных. (Нередко сущности объединяются в предметные базы данных без использования формальных методик — по "здравому смыслу".) Для проектирования и ведения каждой предметной базы данных (нескольких баз данных) назначается администратор базы данных, который далее занима- ется детальным проектированием базы. Далее будут рассматриваться вопросы, связанные с проектированием отдель- ных реляционных предметных баз данных. Основная цель проектирования базы данных — это сокращение избыточно- сти хранимых данных, а следовательно, экономия объема используемой па- мяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хране- ния в разных местах сведений об одном и том же объекте. Так называемый Глава 10. Введение в проектирование 197 "чистый" проект базы данных ("каждый факт в одном месте") можно создать, используя методологию нормализации отношений. И хотя нормализация должна использоваться на завершающей проверочной стадии проектирова- ния базы данных, мы начнем обсуждение вопросов проектирования с рас- смотрения причин, которые заставили Кодда создать основы теории норма- лизации. Прежде чем приступить к подробному изложению, сделаем несколько пред- варительных замечаний. Следует заметить, что речь здесь пойдет о логическом (или концептуальном) проектировании, а не о разработке физического проекта. Это вовсе не значит, что физическое проектирование не имеет большого значения. Наоборот, соз- дание физического проекта играет очень важную роль. Тем не менее, необ- ходимо сделать следующие оговорки. Физическое проектирование может рассматриваться как отдельный по- следующий этап. Иначе говоря, для "правильного" проектирования базы данных, прежде всего, необходимо создать ее приемлемый логический (т. е. реляционный) проект и лишь затем в качестве отдельного этапа раз- работки выполнить отображение этого логического проекта на опреде- ленные физические структуры, поддерживаемые конкретной СУБД. Дру- гими словами, как отмечалось ранее, физический проект создается на базе логического проекта и никак иначе. Физическое проектирование по определению является зависимым от спе- цифики конкретной целевой СУБД. Логический проект, наоборот, совер- шенно независим от СУБД, и для его реализации могут использоваться некоторые строгие теоретические принципы. К сожалению, на практике часто случается так, что решения, принятые в про- цессе физической реализации проекта, могут оказывать существенное обрат- ное влияние на его логический уровень. Иначе говоря, может потребоваться выполнить нескольких итераций цикла "логическое проектирование — физи- ческое проектирование" и пойти на определенные компромиссы. Тем не ме- нее, изложение материала в этой части ведется исходя из того, что предвари- тельно необходимо создать логический проект без учета особенностей его будущей физической реализации (например, без учета требований к опреде- ленному уровню производительности). После всего сказанного следует подчеркнуть, что проектирование базы дан- ных еще во многом продолжает оставаться скорее искусством, чем наукой. Конечно, существуют некоторые научные принципы такого проектирования, которые будут изложены в следующих главах. Однако при проектировании Часть IV. Основы проектирования баз данных 198 базы данных возникает множество других проблем, которые не всегда можно решить, руководствуясь этими правилами. Следует отметить некоторые допущения, используемые в дальнейшем изло- жении. Проектирование базы данных заключается не только в создании правиль- ной структуры данных. Еще одной и, вероятно, более важной задачей яв- ляется обеспечение целостности данных. Далее в большинстве случаев проектирование рассматривается независимо от приложения.Иначе говоря, интерес представляют сами данные, а не то, как они будут использоваться.Независимость от приложения в этом смысле желательна по той простой причине, что в момент проектирования базы данных обычно еще неизвестны все возможные способы использо- вания ее данных. Таким образом, необходимо, чтобы созданный проект был стабильным, т. е. оставался работоспособным даже при возникнове- нии в приложениях новых (т. е. неизвестных на момент создания исходно- го макета) требований к данным. Следуя этим допущениям, можно ска- зать, что здесь обсуждается создание концептуальной схемы,т. е. абстрактного логического проекта, не зависящего от аппаратного обеспе- чения, операционной системы, целевой СУБД, языка программирования, требований пользователей и т. д. 10.2. Универсальное отношение Предположим, что проектирование базы данных "COOK" (табл. 3.1—3.10) начинается с выявления атрибутов и подбора данных, образец которых (часть блюд изготовленных и реализованных 15/05/1989 г.) показан в табл. 10.1. (Отметим, что в табл. 10.1 добавлен столбец СТРАНА , отсутствующий в табл. 3.4.) Этот вариант таблицы "COOK" не является отношением, так как большинст- во ее строк содержат множественные значения. Для придания таким данным формы отношения необходимо реконструировать таблицу. Наиболее просто это сделать с помощью простого процесса вставки, результат которого пока- зан в табл. 10.2. Однако такое преобразование приводит к возникновению большого объема избыточных данных. Таблица 10.1. Основные данные, необходимые для создания базы данных "COOK" БЛЮДО ВИД ОСНОВА ВЫХОД ПРОДУКТ ПОСТАВЩИК СТАТУС СТРАНА ГОРОД АДРЕС ЦЕНА ------------- ------- ------ ------ -------- --------- ---------- ------- --------- -------------- ---- Бастурма Горячее Мясо 300,0 Говядина ПОРТОС кооператив Латвия Резекне Садовая,27 3,60 Зелень СЫТНЫЙ рынок Россия Ленинград Сытнинская,3 3,00 Лук УРОЖАЙ коопторг Россия Луга Песчаная,19 0,50 Масло ОГУРЕЧИК ферма Литва Паневежис Укмерге,15 4,00 Помидоры СЫТНЫЙ рынок Россия Ленинград Сытнинская,3 1,50 Салат мясной Закуска Мясо 200,0 Говядина ПОРТОС кооператив Латвия Резекне Садовая,27 3,60 Зелень ШУШАРЫ совхоз Россия Пушкин Новая, 17 2,50 Майонез ТУЛЬСКИЙ универсам Россия Ленинград Тульский,5 2,04 Помидоры СЫТНЫЙ рынок Россия Ленинград Сытнинская,3 1,50 Яйца КОРЮШКА кооператив Эстония Йыхви Нарвское ш.,64 2,00 Суп харчо Суп Мясо 500,0 Говядина ОГУРЕЧИК ферма Латвия Паневежис Укмерге,15 4,20 Зелень ШУШАРЫ совхоз Россия Пушкин Новая, 17 2,50 Лук ЛЕТО агрофирма Россия Ленинград Пулковская,8 0,70 Масло ОГУРЕЧИК ферма Литва Паневежис Укмерге,15 4,00 Помидоры СЫТНЫЙ рынок Россия Ленинград Сытнинская,3 1,50 Рис ТУЛЬСКИЙ универсам Россия Ленинград Тульский,5 0,88 Сырники Горячее Молоко 220,0 Мука УРОЖАЙ коопторг Россия Луга Песчаная,19 0,50 Сахар УРОЖАЙ коопторг Россия Луга Песчаная,19 1,00 Сметана ОГУРЕЧИК ферма Литва Паневежис Укмерге,15 2,20 Творог ОГУРЕЧИК ферма Литва Паневежис Укмерге,15 1,00 Яйца ПОРТОС кооператив Латвия Резекне Садовая,27 1,80 Кофе черный Напиток Кофе 100,0 Кофе ТУЛЬСКИЙ универсам Россия Ленинград Тульский,5 4,50 Таблица 10.2. Универсальное отношение COOK БЛЮДО ВИД ОСНОВА ВЫХОД ПРОДУКТ ПОСТАВЩИК СТАТУС СТРАНА ГОРОД АДРЕС ЦЕНА ------------- ------- ------ ------ -------- --------- ---------- ------- --------- -------------- ---- Бастурма Горячее Мясо 300,0 Говядина ПОРТОС кооператив Латвия Резекне Садовая,27 3,60 Бастурма Горячее Мясо 300,0 Зелень СЫТНЫЙ рынок Россия Ленинград Сытнинская,3 3,00 Бастурма Горячее Мясо 300,0 Лук УРОЖАЙ коопторг Россия Луга Песчаная,19 0,50 Бастурма Горячее Мясо 300,0 Масло ОГУРЕЧИК ферма Литва Паневежис Укмерге,15 4,00 Бастурма Горячее Мясо 300,0 Помидоры СЫТНЫЙ рынок Россия Ленинград Сытнинская,3 1,50 Салат мясной Закуска Мясо 200,0 Говядина ПОРТОС кооператив Латвия Резекне Садовая,27 3,60 Салат мясной Закуска Мясо 200,0 Зелень ШУШАРЫ совхоз Россия Пушкин Новая, 17 2,50 Салат мясной Закуска Мясо 200,0 Майонез ТУЛЬСКИЙ универсам Россия Ленинград Тульский,5 2,04 Салат мясной Закуска Мясо 200,0 Помидоры СЫТНЫЙ рынок Россия Ленинград Сытнинская,3 1,50 Салат мясной Закуска Мясо 200,0 Яйца КОРЮШКА кооператив Эстония Йыхви Нарвское ш.,64 2,00 Суп харчо Суп Мясо 500,0 Говядина ОГУРЕЧИК ферма Литва Паневежис Укмерге,15 4,20 Суп харчо Суп Мясо 500,0 Зелень ШУШАРЫ совхоз Россия Пушкин Новая, 17 2,50 Суп харчо Суп Мясо 500,0 Лук ЛЕТО агрофирма Россия Ленинград Пулковская,8 0,70 Суп харчо Суп Мясо 500,0 Масло ОГУРЕЧИК ферма Литва Паневежис Укмерге,15 4,00 Суп харчо Суп Мясо 500,0 Помидоры СЫТНЫЙ рынок Россия Ленинград Сытнинская,3 1,50 Суп харчо Суп Мясо 500,0 Рис ТУЛЬСКИЙ универсам Россия Ленинград Тульский,5 0,88 Сырники Горячее Молоко 220,0 Мука УРОЖАЙ коопторг Россия Луга Песчаная,19 0,50 Сырники Горячее Молоко 220,0 Сахар УРОЖАЙ коопторг Россия Луга Песчаная,19 1,00 Сырники Горячее Молоко 220,0 Сметана ОГУРЕЧИК ферма Литва Паневежис Укмерге,15 2,20 Сырники Горячее Молоко 220,0 Творог ОГУРЕЧИК ферма Литва Паневежис Укмерге,15 1,00 Сырники Горячее Молоко 220,0 Яйца ПОРТОС кооператив Латвия Резекне Садовая,27 1,80 Кофе черный Напиток Кофе 100,0 Кофе ТУЛЬСКИЙ универсам Россия Ленинград Тульский,5 4,50 Глава 10. Введение в проектирование 201 Таблица 10.2 представляет собой экземпляр корректного отношения. Его назы- вают универсальным отношением проектируемой базы данных. В одно уни- версальное отношение включаются все представляющие интерес атрибуты, и оно может содержать все данные, которые предполагается размещать в базе данных в будущем. Для малых баз данных (включающих не более 15 атрибу- тов) универсальное отношение может использоваться в качестве отправной точки при проектировании базы данных. 10.3. Почему проект базы данных может быть плохим? Начинающий проектировщик будет использовать универсальное отношение COOK (табл. 10.2) в качестве завершенной базы данных (естественно после дополнения этого отношения рядом столбцов, которые были из него изъяты для уменьшения ширины таблицы). Действительно, зачем разбивать отноше- ние COOK на несколько более мелких отношений (см. например, табл. 3.1— 3.10), если оно заключает в себе все данные? А разбивать надо потому, что при использовании универсального отношения возникает несколько проблем. Избыточность. Данные практически всех столбцов многократно повто- ряются. Повторяются и некоторые наборы данных: Блюдо — Вид — Осно- ва — Выход , Поставщик — Статус — Страна — Город — Адрес — Цена Нежелательно и повторение рецептов (не показанных в табл. 10.2), неко- торые из них намного больше рецепта "Лобио" (см. рис. 2.7). И уж совсем плохо, что все данные о блюде (включая рецепт) повторяются каждый раз, когда это блюдо включается в меню. Потенциальная противоречивость (аномалии обновления).Вследствие избыточности можно обновить адрес поставщика в одной строке, оставляя его неизменным в других. Если поставщик кофе сообщил о своем переез- де по другому адресу, и была обновлена строка с продуктом кофе, то у поставщика Тульский появляется два адреса, один из которых не актуа- лен. Следовательно, при обновлениях необходимо просматривать всю таблицу для нахождения и изменения всех подходящих строк. Аномалии включения. В базе данных не может быть записан новый по- ставщик (Няринга, Литва, Вильнюс), если поставляемый им продукт (Огурцы) не используется ни в одном блюде. Можно, конечно, поместить неопределенные значения в столбцы Блюдо , Вид , Основа и Выход для этого Часть IV. Основы проектирования баз данных 202 поставщика. Но если появится блюдо, в котором используется этот про- дукт, не забудем ли мы удалить строку с неопределенными значениями? По аналогичным причинам нельзя ввести и новый продукт (например, Баклажаны), который предлагает существующий поставщик (например, Сытный). А как ввести новое блюдо, если в нем используется новый продукт (Крабы)? БЛЮДА БЛЮДО ВИД ОСНОВА ВЫХОД ----------- ------- ------ ----- Суп харчо Суп Мясо 500,0 Бастурма Горячее Мясо 300,0 Кофе черный Напиток Кофе 100,0 РЕЦЕПТЫ БЛЮДО РЕЦЕПТ ----------- ---------------------- Суп харчо Грудинку говядины наре Бастурма Мясо нарезать кубиками Кофе черный Кофеварку или кастрюлю ПРОДУКТЫ ПРОДУКТ БЕЛКИ ЖИРЫ УГЛЕВ -------- ------ ------ ------ Говядина 189,0 124,0 0,0 Лук 17,0 0,0 95,0 Масло 60,0 825,0 90,0 Помидоры 6,0 0,0 42,0 Зелень 9,0 0,0 20,0 Рис 70,0 6,0 773,0 Кофе 127,0 36,0 9,0 СОСТАВ БЛЮДО ПРОДУКТ ВЕС --------- -------- --- Суп харчо Говядина 80 Суп харчо Лук 30 Суп харчо Масло 15 Суп харчо Зелень 15 Суп харчо Помидоры 25 Суп харчо Рис 35 Бастурма Говядина 180 ПОСТАВЩИКИ ПОСТАВЩИК СТАТУС СТРАНА ГОРОД АДРЕС --------- --------- ------- --------- ------------ ОГУРЕЧИК ферма Литва Паневежис Укмерге,15 УРОЖАЙ коопторг Россия Луга Песчаная,19 ШУШАРЫ совхоз Россия Пушкин Новая, 17 СЫТНЫЙ рынок Россия Ленинград Сытнинская,3 ТУЛЬСКИЙ универсам Россия Ленинград Тульский,5 ПОСТАВКИ ПРОДУКТ ПОСТАВЩИК ЦЕНА К_ВО ДАТА -------- --------- ---- ---- ---------- Говядина ОГУРЕЧИК 4,20 70 10.05.1989 Лук УРОЖАЙ 0,50 130 14.05.1989 Масло ОГУРЕЧИК 4,00 250 10.05.1989 Рис ТУЛЬСКИЙ 0,88 150 09.05.1989 Помидоры СЫТНЫЙ 1,50 50 14.05.1989 Зелень СЫТНЫЙ 3,00 10 10.05.1989 Зелень ШУШАРЫ 2,50 20 14.05.1989 Кофе ТУЛЬСКИЙ 4,50 50 09.05.1989 Рис. 10.1. Преобразование универсального отношения COOK (первый вариант) Глава 10. Введение в проектирование 203 Аномалии удаления. Обратная проблема возникает при необходимости удаления всех продуктов, поставляемых данным поставщиком, или всех блюд, использующих эти продукты. При таких удалениях будут утрачены сведения о таком поставщике. Многие проблемы этого примера исчезнут, если выделить в отдельные таб- лицы сведения о блюдах, рецептах, продуктах и их поставщиках, а также создать связующие таблицы Состав и Поставки (рис. 10.1). Включение. Простым добавлением строк ( Поставщики ; Няринга, Вильнюс ) и ( Поставки ; Огурцы, Няринга, Вильнюс, 0,50, 40 ) можно ввести информа- цию о новом поставщике. Аналогично можно ввести данные о новом продук- те ( Продукты ; Баклажаны, 240 ) и ( Поставки ; Баклажаны, Полесье, Украина, Киев, 50 ). Удаление. Удаление сведений о некоторых поставках или блюдах не приво- дит к потере сведений о поставщиках. Обновление. В таблицах с рис. 10.1 все еще много повторяющихся дан- ных, находящихся в связующих таблицах ( Состав и Поставки ). Следова- тельно, в данном варианте базы данных сохранилась потенциальная проти- воречивость: для изменения названия поставщика с Урожай на Полесье придется изменять не только строку таблицы Поставщики , но и множество строк таблицы Поставки . При этом не исключено, что в базе данных будут одновременно храниться: Полесье, Палесье, Няринга, Няренга и другие ва- рианты названий. Кроме того, повторяющиеся текстовые данные (такие как название блюда "Рулет из телячьей грудинки с сосисками и гарниром из разноцветного пюре" или продукта "Колбаса московская сырокопченая") существенно увеличива- ют объем хранимых данных. Для исключения ссылок на длинные текстовые значения последние обычно нумеруют: нумеруют блюда в больших кулинарных книгах, товары (продук- ты) в каталогах и т. д. Воспользуемся этим приемом (использованием сурро- гатных ключей — см. разд. 2.4) для исключения избыточного дублирования данных и появления ошибок при копировании длинных текстовых значений (рис. 10.2). Теперь при изменении названия поставщика Урожай на Полесье исправляется единственное значение в таблице Поставщики . И даже если оно вводится с ошибкой (Палесье), то это не может повлиять на связь между по- ставщиками и продуктами (в связующей таблице Поставки используются но- мера поставщиков и продуктов, а не их названия). Часть IV. Основы проектирования баз данных 204 БЛЮДА БЛ БЛЮДО ВИД ОСНОВА ВЫХОД -- ----------- ------- ------ ------ 1 Суп харчо Суп Мясо 500,0 2 Бастурма Горячее Мясо 300,0 3 Кофе черный Напиток Кофе 100,0 РЕЦЕПТЫ БЛ РЕЦЕПТ -- ----------------------- 1 Грудинку говядины нарез 2 Мясо нарезать кубиками 3 Кофеварку или кастрюлю ПРОДУКТЫ ПР ПРОДУКТ БЕЛКИ ЖИРЫ УГЛЕВ -- -------- ------ ------ ------ 1 Говядина 189,0 124,0 0,0 2 Лук 17,0 0,0 95,0 3 Масло 60,0 825,0 90,0 4 Помидоры 6,0 0,0 42,0 5 Зелень 9,0 0,0 20,0 6 Рис 70,0 6,0 773,0 7 Кофе 127,0 36,0 9,0 СОСТАВ БЛ ПР ВЕС -- -- --- 1 1 80 1 2 30 1 3 15 1 5 15 1 4 25 1 6 35 2 1 180 ПОСТАВЩИКИ ПС ПОСТАВЩИК СТАТУС СТРАНА ГОРОД АДРЕС -- --------- --------- ------- --------- ------------ 1 ОГУРЕЧИК ферма Литва Паневежис Укмерге,15 2 УРОЖАЙ коопторг Россия Луга Песчаная,19 3 ШУШАРЫ совхоз Россия Пушкин Новая, 17 4 СЫТНЫЙ рынок Россия Ленинград Сытнинская,3 5 ТУЛЬСКИЙ универсам Россия Ленинград Тульский,5 ПОСТАВКИ ПР ПС ЦЕНА К_ВО ДАТА -- -- ---- ---- ---------- 1 1 4,20 70 10.05.1989 2 2 0,50 130 14.05.1989 3 1 4,00 250 10.05.1989 6 5 0,88 150 09.05.1989 4 4 1,50 50 14.05.1989 5 4 3,00 10 10.05.1989 5 3 2,50 20 14.05.1989 7 5 4,50 50 09.05.1989 Рис. 10.2. Преобразование универсального отношения COOK (второй вариант) 10.4. Процедура проектирования Как уже отмечалось в разд. 1.3, проект базы данных должен начинаться с выбора предметной области (той части реального мира, данные о которой надо отразить в базе данных) и выявления требований к ней отдельных поль- зователей (сотрудников организации, для которых создается база данных). Глава 10. Введение в проектирование 205 Проектирование обычно поручается человеку (группе лиц) — администра- тору данных (АД). Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей и (или) анализа их технических заданий, и свои представления о данных, которые могут потре- боваться в будущих приложениях, АД сначала создает обобщенное нефор- мальное описание создаваемой базы данных. Это выполненное с использова- нием текста (на естественном языке), образцов входных и выходных документов, математических формул, таблиц, графики и других средств, по- нятных потенциальным пользователям и всем людям, работающим над про- ектированием базы данных, и есть концептуальная модель данных, которую часто называют логической или информационно-логической (инфологиче- ской) моделью (см. главу 2). Такая человеко-ориентированная модель полностью независима от физиче- ских параметров среды хранения данных и от той СУБД, которая будет ис- пользоваться для построения и ведения базы данных. В конце концов, этой средой может быть память человека, а не ЭВМ. Поэтому концептуальная мо- дель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторых определений, чтобы эта мо- дель продолжала отражать предметную область. 10.4.1. Этапы проектирования базы данных Основная цель проектирования базы данных — это сокращение избыточно- сти хранимых данных, а следовательно, экономия объема используемой па- мяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хране- ния в разных местах сведений об одном и том же объекте. Так называемый, "чистый" проект базы данных ("Каждый факт в одном месте") можно соз- дать, используя при тестировании проекта методологию нормализации от- ношений (см. главу 11). Начинать же создание "чистого" проекта необходи- мо, "забыв" об обеспечении просьб и пожеланий будущих пользователей, включая разработчиков и администраторов приложений, которые, как прави- ло, хотят, чтобы база данных содержала таблицы с теми или иными резуль- тирующими данными, т. е. многочисленными дубликатами. Их просьбы бу- дут в дальнейшем учтены на этапах оптимизации базы данных (см. главу 16) и проектирования приложений (см. часть VI). Процесс проектирования состоит из трех основных этапов: 1. На основе информации, полученной при анализе, необходимо создать подробное описание предметной области, обращая особое внимание на требования к данным. Часть IV. Основы проектирования баз данных 206 2. Построить инфологическую модель базы данных — обобщенное, не привя- занное к каким-либо компьютерам и СУБД, описание предметной области (наборы данных, их типов, длин, связей и т. п.). 3. Выбрать СУБД, под управлением которой должна функционировать база данных, и создать даталогическую (табличную) модельбазы данных — инфологическую модель, переведенную на язык выбранной СУБД. В литературе по проектированию информационных систем (основой которых являются базы данных) обычно подробно рассматриваются различные под- ходы к организации проектирования и отмечается, что проектирование, как правило, не имеет четко выраженного начала и окончания и часто продолжа- ется на этапах тестирования и реализации. Это иллюстрируется различными моделями жизненного цикла (рис. 10.3) и подробным обсуждением их досто- инств и недостатков. Также описывается целый ряд стандартов, регламентирующих жизненный цикл, а в некоторых случаях и процессы разработки. Значительный вклад в теорию проектирования и разработки информацион- ных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию организационного планирования (Business System Planning, BSP). Метод структурирования информации с использованием матриц пе- ресечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информационных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в IT-проектах, но и проектах по реинжинирингу бизнес- процессов, изменению организационной структуры. Важнейшие шаги про- цесса BSP, их последовательность (получить поддержку высшего руково- дства, определить процессы предприятия, определить классы данных, про- вести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике. Среди наиболее известных стандартов можно выделить: ГОСТ 34.601-90 — распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте со- держится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют кас- кадной модели жизненного цикла. ISO/IEC 12207:1995 — стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного программного обеспече- ния. Стандарт не содержит описания фаз, стадий и этапов. Глава 10. Введение в проектирование 207 а б в Рис. 10.3. Модели жизненного цикла: а — каскадная; б — поэтапная (водопад); в — спиральная Часть IV. Основы проектирования баз данных 208 Custom Development Method (методика Oracle) по разработке прикладных информационных систем — технологический материал, детализирован- ный до уровня заготовок проектных документов, рассчитанных на исполь- зование в проектах с применением Oracle. Применяется CDM для клас- сической модели жизненного цикла (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов. Rational Unified Process (RUP) предлагает итеративную модель разра- ботки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в ре- зультате которых выпускается версия для внутреннего или внешнего ис- пользования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии систе- мы. Если после этого работа над проектом не прекращается, то получен- ный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP — это создание и сопровождение моделей на базе UML (Unified Modeling Language — унифицированный язык моделиро- вания). Microsoft Solution Framework (MSF) сходна с RUP, также включает четыре фазы (анализ, проектирование, разработка, стабилизация), является итера- ционной, предполагает использование объектно-ориентированного моде- лирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений. Extreme Programming (XP). Экстремальное программирование (самая но- вая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация ме- жду заказчиком и исполнителем в течение всего проекта по разработке информационной системы, а разработка ведется с использованием после- довательно дорабатываемых прототипов. В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы жизненного цикла делятся на три группы: основные процессы — приобретение, поставка, разработка, эксплуатация, сопровождение; вспомогательные процессы — документирование, управление конфигура- цией, обеспечение качества, разрешение проблем, аудит, аттестация, со- вместная оценка, верификация; организационные процессы — создание инфраструктуры, управление, обучение, усовершенствование. Глава 10. Введение в проектирование 209 Ограничимся в данной главе этим кратким обзором методологий проектиро- вания, перенесем описание процесса проектирования даталогической модели в разд. 11.4 и приведем здесь лишь некоторые принципы проверки качества и полноты инфологической модели. Качество сущностей. Основной гарантией качества сущности является ответ на вопрос, действительно ли объект является сущностью, то есть важным объектом или явлением, информация о котором должна храниться в базе данных. Список проверочных вопросов для сущности: 1. Отражает ли имя сущности суть данного объекта? 2. Нет ли пересечения с другими сущностями? 3. Имеются ли хотя бы два атрибута? 4. Всего атрибутов не более восьми? 5. Есть ли синонимы/омонимы данной сущности? 6. Сущность определена полностью? 7. Есть ли уникальный идентификатор? 8. Имеется ли хотя бы одна связь? 9. Существует ли хотя бы одна функция по созданию, поиску, корректиров- ке, удалению, архивированию и использованию значения сущности? 10. Ведется ли история изменений? 11. Имеет ли место соответствие принципам нормализации данных? 12. Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем? 13. Не имеет ли сущность слишком общий смысл? 14. Достаточен ли уровень обобщения, воплощенный в ней? Качество атрибутов. Следует выяснить, а действительно ли это атрибуты, то есть описывают ли они тем или иным образом данную сущность. Список проверочных вопросов для атрибута: 1. Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства? 2. Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)? 3. Имеет ли атрибут только одно значение в каждый момент времени? 4. Отсутствуют ли повторяющиеся значения (или группы)? Часть IV. Основы проектирования баз данных 210 5. Описаны ли формат, длина, допустимые значения, алгоритм получения и т. п.? 6. Не может ли этот атрибут быть пропущенной сущностью, которая приго- дилась бы для другой прикладной системы (уже существующей или предполагаемой)? 7. Не может ли он быть пропущенной связью? 8. Нет ли где-нибудь ссылки на атрибут как на "особенность проекта", ко- торая при переходе на прикладной уровень должна исчезнуть? 9. Есть ли необходимость в истории изменений? 10. Зависит ли его значение только от данной сущности? 11. Если значение атрибута является обязательным, всегда ли оно известно? 12. Зависит ли его значение только от какой-то части уникального иденти- фикатора? 13. Зависит ли его значение от значений некоторых атрибутов, не включен- ных в уникальный идентификатор? Качество связи. Нужно выяснить, отражают ли связи действительно важные отношения, наблюдаемые между сущностями. Список проверочных вопросов для связи: 1. Имеется ли ее описание для каждой участвующей стороны, точно ли оно отражает содержание связи и вписывается ли в принятый синтаксис? 2. Участвуют ли в ней только две стороны? 3. Не является ли связь переносимой? 4. Заданы ли степень связи и обязательность для каждой стороны? 5. Допустима ли конструкция связи? 6. Не относится ли конструкция связи к редко используемым? 7. Не является ли она избыточной? 8. Не изменяется ли она с течением времени? 9. Если связь обязательная, всегда ли она отражает отношение к сущности, представляющей противоположную сторону? |