10.Стадии и этапы разработки базы данных.

Этапы разработки баз данных
Как отмечалось выше, база данных является одним из основных компонентов любой информационной системы, поэтому при её проектировании преследуются те же цели, что и при проектировании автоматизированной системы управления (АСУ) предприятием, а этапы и стадии её создания практически совпадают с работами по созданию АСУ. При разработке базы данных принято выделять следующие этапы, при помощи которых осуществляется переход от предметной области к её конкретной реализации:
• изучение предметной области;
• разработка моделей предметной области;
• разработка логической модели данных;
• разработка физической модели данных;
• разработка собственно базы данных.
Изучение предметной области заключается в выявлении существенных процессов и факторов, оказывающих определяющее влияние на достижение целей внедрения информационной системы.
Модель предметной области – это записанные знания об объектах реального мира, которыми необходимо управлять наиболее рациональным образом. Эти знания могут быть представлены как в чисто текстовом виде, так и с использованием методологий структурного функционального моделирования - SADT, IDEF0, IDEF3, методологий и стандартов описания состава, структуры и взаимосвязей используемой в деятельности предприятия информации – IDEF1, DFD и соответствующих инструментальных case-средств – BPWin, AIO WIN, ProCap, ProSim, SmartER.
Логическая модель данных описывает понятия предметной области и их взаимосвязи и является прототипом будущей базы данных. Логическая модель разрабатывается в терминах информационных понятий, но без какой-либо ориентации на конкретную СУБД. Наиболее широко используемым средством разработки логических моделей баз данных являются диаграммы «сущность-связь» - Entity-Relationship (ER-диаграммы). Следует заметить, что логическая модель данных, представленная ER-диаграммами, в принципе, может быть преобразована как в реляционную модель данных, так и в иерархическую, сетевую, постреляционную.
Физическая модель данных строится на базе логической модели и описывает данные уже средствами конкретной СУБД. Отношения, разработанные на стадии логического моделирования, преобразуются в таблицы, атрибуты в столбцы, домены в типы данных, принятых в выбранной конкретной СУБД. На этапах логического и физического моделирования, как правило, используется стандарт IDEF1X и case-средства ERWin или SmartER. Указанные инструментальные средства проектирования поддерживают несколько десятков наиболее популярных СУБД. Результатом физического моделирования является генерация программного кода базы данных на соответствующем выбранной СУБД диалекте структурированного языка запросов SQL.
Несмотря на постоянно совершенствуемые возможности case-средств по автоматической генерации кода баз данных, детальное её проектирование все-таки остается работой и заботой человека. Case-средства помогают создать прототип базы данных, на котором строится её рабочая версия. Поскольку практически любая база данных кроме таблиц содержит дополнительный программный код в виде триггеров и хранимых процедур, которые пишутся на процедурных расширениях языка SQL или универсальном языке программирования, то полностью автоматизировать её создание из логической модели пока не представляется возможным, а может быть и нужным.
Хранимые процедуры, основным назначением которых является реализация бизнес процессов предметной области, – это процедуры и функции, хранящиеся непосредственно в базе данных в откомпилированном виде, которые могут запускаться непосредственно пользователем или прикладными программами, работающими с базой данных.
Триггеры – это хранимые процедуры, связанные с некоторыми событиями, происходящими во время работы базы данных. В качестве таких событий обычно выступают операции вставки, обновления и удаления строк таблиц. Если в базе данных определен некоторый триггер, то он запускается автоматически всегда при возникновении события. Важным является то, что пользователи не могут обойти триггер, независимо от того, кто из них и каким образом инициировал запускающее его событие. Основным назначением триггеров является автоматическая поддержка целостности базы данных, но они могут использоваться и для реализации достаточно сложных ограничений, накладываемых предметной областью, например, с операцией вставки нового товара в накладную может быть связан триггер, который проверяет наличие необходимого товара на складе и выполняет другие необходимые действия.

12. Нормализация таблиц при проектировании баз данных. Нормальные формы (1НФ, 2НФ, 3НФ, НФБК).
Реляционная база данных содержит как структурную, так и семантическую информацию. Структура базы данных определяется числом и видом включенных в нее отношений, и связями типа "один ко многим", существующими между кортежами этих отношений. Семантическая часть описывает множество функциональных зависимостей, существующих между атрибутами этих отношений. Дадим определение функциональной зависимости - Если даны два атрибута X и Y некоторого отношения, то говорят, что Y функционально зависит от X, если в любой момент времени каждому значению X соответствует ровно одно значение Y.
Функциональная зависимость обозначается X -> Y. Отметим, что X и Y могут представлять собой не только единичные атрибуты, но и группы, составленные из нескольких атрибутов одного отношения.
Можно сказать, что функциональные зависимости представляют собой связи типа "один ко многим", существующие внутри отношения.
Некоторые функциональные зависимости могут быть нежелательны.
Избыточная функциональная зависимость - зависимость, заключающая в себе такую информацию, которая может быть получена на основе других зависимостей, имеющихся в базе данных.
Корректной считается такая схема базы данных, в которой отсутствуют избыточные функциональные зависимости. В противном случае приходится прибегать к процедуре декомпозиции (разложения) имеющегося множества отношений. При этом порождаемое множество содержит большее число отношений, которые являются проекциями отношений исходного множества. Обратимый пошаговый процесс замены данной совокупности отношений другой схемой с устранением избыточных функциональных зависимостей называется нормализацией.
Условие обратимости требует, чтобы декомпозиция сохраняла эквивалентность схем при замене одной схемы на другую, т.е. в результирующих отношениях:
• не должны появляться ранее отсутствовавшие кортежи;
• на отношениях новой схемы должно выполняться исходное множество функциональных зависимостей.
1NF - первая нормальная форма.
Для обсуждения первой нормальной формы необходимо дать два определения:
Простой атрибут - атрибут, значения которого атомарны (неделимы).
Сложный атрибут - получается соединением нескольких атомарных атрибутов, которые могут быть определены на одном или разных доменах. (его также называют вектор или агрегат данных).
Теперь можно дать
Определение первой нормальной формы: отношение находится в 1NF если значения всех его атрибутов атомарны.
В базе данных отдела кадров предприятия необходимо хранить сведения о служащих, которые можно попытаться представить в отношении
СЛУЖАЩИЙ(НОМЕР_СЛУЖАЩЕГО, ИМЯ, ДАТА_РОЖДЕНИЯ, ИСТОРИЯ_РАБОТЫ, ДЕТИ).
Из внимательного рассмотрения этого отношения следует, что атрибуты "история_работы" и "дети" являются сложными, более того, атрибут "история_работы"  включает еще один сложный атрибут "история_зарплаты".
Данные агрегаты выглядят следующим образом:
  •  ИСТОРИЯ_РАБОТЫ (ДАТА_ПРИЕМА, НАЗВАНИЕ, ИСТОРИЯ_ЗАРПЛАТЫ),
•  ИСТОРИЯ_ЗАРПЛАТЫ (ДАТА_НАЗНАЧЕНИЯ, ЗАРПЛАТА),
•  ДЕТИ (ИМЯ_РЕБЕНКА, ГОД_РОЖДЕНИЯ).
Их связь представлена на рис. 1.
Рис.1. Исходное отношение.
Для приведения исходного отношения СЛУЖАЩИЙ к первой нормальной форме необходимо декомпозировать его на четыре отношения, так как это показано на следующем рисунке:
Рис.2. Нормализованное множество отношений.
Здесь первичный ключ каждого отношения выделен синей рамкой, названия внешних ключей набраны шрифтом синего цвета. Напомним, что именно внешние ключи служат для представления функциональных зависимостей, существующих в исходном отношении. Эти функциональные зависимости обозначены линиями со стрелками.
Алгоритм нормализации описан Е.Ф.Коддом следующим образом:
• Начиная с отношения, находящегося на верху дерева (рис. 1.), берется его первичный ключ, и каждое непосредственно подчиненное отношение расширяется путем вставки домена или комбинации доменов этого первичного ключа.
• Первичный Ключ каждого расширенного таким образом отношения состоит из Первичного Ключа, который был у этого отношения до расширения и добавленного Первичного Ключа родительского отношения.
• После этого из родительского отношения вычеркиваются все непростые домены, удаляется верхний узел дерева, и эта же процедура повторяется для каждого из оставшихся поддеревьев.
2NF - вторая нормальная форма.
Очень часто первичный ключ отношения включает несколько атрибутов (в таком случае его называют составным) - см., например, отношение ДЕТИ, показанное на рис. 2. При этом вводится понятие полной функциональной зависимости.
Определение: неключевой атрибут функционально полно зависит от составного ключа если он функционально зависит от всего ключа в целом, но не находится в функциональной зависимости от какого-либо из входящих в него атрибутов.
Пример:
Пусть имеется отношение ПОСТАВКИ (N_ПОСТАВЩИКА, ТОВАР,  ЦЕНА).
Поставщик может поставлять различные товары, а один и тот же товар может поставляться разными поставщиками. Тогда ключ отношения - "N_поставщика + товар". Пусть все поставщики поставляют товар по одной и той же цене. Тогда имеем следующие функциональные зависимости:
• N_поставщика, товар -> цена
• товар -> цена
Неполная функциональная зависимость атрибута "цена" от ключа приводит к следующей аномалии: при изменении цены товара необходим полный просмотр отношения для того, чтобы изменить все записи о его поставщиках. Данная аномалия является следствием того факта, что в одной структуре данных объединены два семантических факта. Следующее разложение дает отношения во 2НФ:
• ПОСТАВКИ (N_ПОСТАВЩИКА, ТОВАР)
• ЦЕНА_ТОВАРА (ТОВАР, ЦЕНА)
Определение второй нормальной формы:
Отношение находится во 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально полно зависит от ключа.
3NF - третья нормальная форма.
Перед обсуждением третьей нормальной формы необходимо ввести понятие транзитивной функциональной зависимости.
Пусть X, Y, Z - три атрибута некоторого отношения. При этом X --> Y и Y --> Z, но обратное соответствие отсутствует, т.е. Z -/-> Y и Y -/-> X. Тогда  Z транзитивно зависит от X.
Пусть имеется отношение ХРАНЕНИЕ (ФИРМА, СКЛАД, ОБЪЕМ), которое содержит информацию о фирмах, получающих товары со складов, и объемах этих складов. Ключевой атрибут - "фирма". Если каждая фирма может получать товар только с одного склада, то в данном отношении имеются следующие функциональные зависимости:
• фирма -> склад
• склад -> объем
При этом возникают аномалии:
• если в данный момент ни одна фирма не получает товар со склада, то в базу данных нельзя ввести данные о его объеме (т.к. не определен ключевой атрибут)
• если объем склада изменяется, необходим просмотр всего отношения и изменение кортежей для всех фирм, связанных с данным складом.
Для устранения этих аномалий необходимо декомпозировать исходное отношение на два:
• ХРАНЕНИЕ (ФИРМА, СКЛАД)
• ОБЪЕМ_СКЛАДА (СКЛАД, ОБЪЕМ)
Определение третьей нормальной формы:
Отношение находится в 3НФ, если оно находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.
BCNF - нормальная форма Бойса-Кодда.
Эта нормальная форма вводит дополнительное ограничение по сравнению с 3НФ. Определение нормальной формы Бойса-Кодда:
Отношение находится в BCNF, если оно находится во 3НФ и в ней отсутствуют зависимости атрибутов первичного ключа от неключевых атрибутов.
Ситуация, когда отношение будет находится в 3NF, но не в BCNF, возникает при условии, что отношение имеет два (или более) возможных ключа, которые являются составными и имеют общий атрибут. Заметим, что на практике такая ситуация встречается достаточно редко, для всех прочих отношений 3NF и BCNF эквивалентны

14. Архитектура клиент-сервер. Распределенные базы данных.
Архитектура клиент-сервер - архитектура распределенной вычислительной системы, в которой приложение делится на клиентский и серверный процессы.
Модель "сервер базы данных" - архитектура вычислительной сети типа "клиент-сервер", в которой пользовательский интерфейс и логика приложений сосредоточены на машине-клиенте, а информационные функции (функции СУБД) - на сервере. Обычно клиентский процесс посылает запрос серверу на языке SQL.
Распределенная база данных - совокупность баз данных, физически распределенная по взаимосвязанным ресурсам вычислительной сети и доступная для совместного использования.
Распределенная база данных - территориально распределенная совокупность локальных баз данных, объединенных согласованными принципами организации, комплектования и эксплуатации, а также каналами связи, и доступная для совместного использования.
(Чтоб понятнее был принцип: Распределенная система - система из нескольких взаимосвязанных компьютеров, способная решать единую прикладную задачу.
Назначение и принцип работы распределенной базы данных
Когда у предприятия есть удаленные филиалы, возникает необходимость в синхронизации данных между ними и главным офисом. Естественно, что в основной базе предприятия должны отображаться любые изменения касательно филиалов. Такую синхронизацию можно осуществлять при помощи механизмов распределенной базы данных.
В главном офисе создаются начальные образы базы (для каждого филиала - свой образ) и передаются в филиалы, где их загружают. При этом задаются настройки обмена, по которым будет происходить синхронизация между каждой из периферийных (подчиненных) баз и главной базой.
Структура предприятия может быть такова, что у филиалов, подчиненных главному офису, могут быть свои удаленные подразделения. Тогда для них производят процедуру аналогичную той, что была совершена при настройке филиалов, подчиненных напрямую главной базе.
Таким образом, можно подытожить, что в распределенной базе формируются древообразные связи. Например, на предприятии главному офису подчинено два филиала, причем у первого филиала есть два удаленных подразделения, а у второго - три подразделения. Получается, что основной базе подчинено две периферийных базы. Первой периферийной базе, в свою очередь, подчинено еще две базы, а второй периферийной - три. То есть можно представить связи в такой распределенной базе следующим образом:

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