Логическое проектирование (Logical Design) — описание структуры решения и взаимодействия составляющих его компонентов с точки зрения группы разработчиков проекта. Цель логического проектирования — учет требований проектной группы. Результат этого этапа — набор бизнес-объектов (объекты предметной области) с соответствующими сервисами (функции объектов), атрибутами (свойства объектов) и взаимосвязями; детальный проект пользовательского интерфейса и логическая модель базы данных (без привязки к конкретной СУБД, платформе...).
Физическое проектирование (Physical Design) — описание компонентов, сервисов и технологий, выбранных для получения решения. Цель этого этапа — анализ логического проекта с учетом ограничений, накладываемых существующими технологиями, включая соображения сложности реализации и производительности продукта. Результат физического проектирования — спецификации компонентов программной системы и взаимосвязей между ними, проект пользовательского интерфейса для выбранной платформы и физическая модель базы данных (с привязкой к конкретной СУБД).
Фаза реализации (Development), по другой терминологии фаза конструирования, программирования или собственно разработки. Результатом этой фазы является законченная версия программного продукта, готовая к внешнему тестированию. Иногда в эту фазу включают этап внешнего тестирования и внедрения программного продукта, иногда эти работы выделяют в отдельную фазу ЖЦ ПО.
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
небольшую команду программистов (от 2 до 10 человек);
короткий, но тщательно проработанный производственный график разработки версии программного продукта (от 2 до 6 мес.);
повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, и его версии передаются на эксплуатацию, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Следует отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. В частности, не подходят для разработки по методологии RAD приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые версии наверняка не будут полностью работоспособны, что в данном случае исключается.
В таком процессе разработки особую роль играют CASE-средства проектирования и реализации программных систем (Computer Aided Software Engineering). Эти средства не просто облегчают разработку моделей, документирование процесса в целом и подготовку документации по программному обеспечению. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены ранее. Каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация. Применение единой среды хранения информации о проекте позволяет сохранять информацию о проекте при переходах с этапа на этап и от версии к версии.
Информационное моделирование процессов предметной области и применение потоковых диаграмм.
Языки потоковых диаграмм, которые мы рассмотрим в этом разделе курса, акцентируют внимание на действиях-процессах, но с точки зрения приема-передачи-хранения-преобразования информации, т.е. откуда (или от кого) действия принимают информацию, куда (или кому) ее передают и как (посредством чего и кого) они преобразуют информацию. Иначе говоря, эти языки информационного моделирования процессов акцентируют внимание на информационных связях между дейстиями-процессами, а не на связях по управлению (порядком выполнения).
В таких языках используются различные виды графовых (сетевых) представлений.
Двудольный ориентированный граф: два типа вершин - хранилища данных и процессы (обработки данных), ориентированные ребра - потоки данных (DataFlow), которые показывают из каких хранилищ процессы берут входные данные, и в какие хранилища посылают результаты своей работы.
Простой ориентированный граф: вершины - процессы, ориентированные ребра - потоки данных. Такое представление показывает – «кто (процесс) на кого (процесс) работает и что (поток данных) при этом получает и передает».
Представление, двойственное предыдущему: вершины - данные, ориентированные ребра – процессы (потоки работ-преобразований, WorkFlow), использующие входные данные и создающие выходные. Представления этого вида заметно больше, чем предыдущие, акцентируют внимание на данных, поэтому их можно трактовать и как модели данных.
Конкретные языки информационного моделирования, естественно, содержат и другие средства - в частности, внешние объекты - конечные пользователи и другие объекты, обменивающиеся данными с информационной системой; средства декомпозиции сложных данных и процессов...
ПОТОКОВЫЕ ОПЕРАЦИОННЫЕ ДИАГРАММЫ С ХРАНИЛИЩАМИ (DFD - Data Flow Diagramming).
Базовые элементы языка.
Д
Имя действия (глагол)
ействие (процесс)
Имя потока (существительное)
 
Имя хранилища (существительное)
В нешний объект
Группируя более простые действия и данные в более сложные, мы получаем возможность отвлечься (абстрагироваться) от внутренних деталей и сконцентрировать внимание на взаимосвязях между этими сложными действиями и данными. А при необходимости, мы можем сконцентрировать внимание на одном сложном действии или данном, рассмотрев его детализацию (конкретизацию), и отвлечься от внешней для него среды.
Группировка (композиция) и разгруппировка (декомпозиция) действий (процессов) представляется многоуровневыми потоковыми диаграммами, сложное действие представляется (прямоугольником) как единое целое в одной диаграмме и как набор взаимосвязанных действий в детализирующей диаграмме.
Группировка (композиция) и разгруппировка (декомпозиция) потоков представляется как их слияние и разветвление соответственно.
ЗАДАЧА о хозяине, его собаке и его друге.
PROGRAM Pp; VAR S0,Sk,Vh,Vd,Vs:REAL;
S,t:REAL; k:INTEGER; C:CHAR;
BEGIN READ(S0,Sk,Vh,Vd,Vs); S:=S0; C:='Х'; k:=0;
WHILE S>=Sk DO
BEGIN IF C='Х' THEN BEGIN C:='Д'; t:=S/(Vs+Vd) END
ELSE BEGIN C:='Х'; t:=S/(Vs+Vh) END;
S:=S-t*(Vh+Vd); k:=k+1 END;
WRITE(k) END.
ПРИМЕР Потоковой операционной диаграммы с хранилищами для задачи о бегающей собаке.
Типы потоков и действий. Реальные действия (процессы) и связывающие их потоки могут иметь специфические особенности, которые желательно отобразить в информационной модели. Для этих целей в языках потоковых диаграмм обычно имеются дополнительные средства.
Потоки можно классифицировать на:
чисто информационные, их особенность состоит в том, что при разветвлении информация может дублироваться и поступать по всем ветвям (например, информация о наличии финансовых средств может поступить от одного источника нескольким адресатам);
материальные, их особенность состоит в том, что при разветвлении содержимое потока не дублируется, а реально распределяется по ветвям (например, исходящие из одного источника финансовые средства поступят нескольким адресатам не в общей сумме, а в соответствующих долях);
управляющие (изображены в вышеприведенном примере пунктирными стрелками, причем связывают действия напрямую – без выделения соответствующего хранилища данных), их особенность состоит в том, что информация такого потока имеет директивный характер, она неким образом ограничивает или предписывает условия выполнения действия.
В языке могут быть специальные элементы, которые используются в точках разветвления и слияния потоков, и позволяют фиксировать различия в семантике различных видов разветвления и слияния.
Аналогично можно классифицировать (и соответственно по-разному обозначать) действия (процессы):
действия приема, передачи и преобразования потоков;
управляющие действия, имеющие специфический директивный характер (в вышеприведенном примере к таким отнесены «действия проверки условия», изображенные пунктирными прямоугольниками).
Пример [9] модели деятельности условного предприятия «ТОРГОВАЯ СИСТЕМА». TGS.doc (DBLEC\TGS.BP1)
Заказчиком на разработку программной системы является некая организация, занимающаяся оптовой торговлей сельхозпродуктами. В представленной концептуальной модели еще не проведена «граница автоматизации» – из общего набора бизнес-процессов не выделены процессы, выполняемые непосредственно программной системой или с помощью нее.
ВЕРБАЛЬНОЕ ОПИСАНИЕ. «ТОРГОВАЯ СИСТЕМА» предназначена для обслуживания клиентов оптового рынка.
Организация заключает договора с поставщиками сельхозпродуктов о приеме и сбыте поставленного товара за соответствующие комиссионные.
Партии товаров от поставщиков доставляют транспортные агентства. Прием оформляется соответствующим документом – накладная о приеме партии товара.
Покупатели после переговоров с торговыми агентами (сотрудниками организации) принимают решение о приобретении товаров. Продажа оформляется соответствующим документом – квитанция о продаже товара. Грузчики (сотрудники организации) получают инструкции об отгрузке товаров со склада.
Ведется учет цен и количества отпускаемых товаров и их комплектации (от каких поставщиков в каком количестве), а также учет комиссионных по сделкам с поставщиками...
Управляющий запрашивает сведения о ходе продаж, выполнении договоров с поставщиками...
См. также о языке SADT/IDEF0-диаграмм DB2LSADT.doc
Информационное моделирование данных предметной области (*).
Рассмотрим одно из хранилищ данных ранее рассмотренного примера «ТОРГОВАЯ СИСТЕМА».
ХРАНИЛИЩЕ ДАННЫХ «Накладные о приеме товаров».
Содержательной единицей хранения является некий документ о партии товара, поставленного неким поставщиком, и сбыте этого товара нашей торговой организацией. В процессе сбыта этот документ пополняется, а по окончании информация этого документа предоставляется поставщику в виде отчета «Об итогах завершающего анализа» по этой партии товаров.
ПОСТАВЩИК: Джон Харрис ЛТД
АДРЕС: НКГР Лондон СВ8
|
ПОЛУЧАТЕЛЬ:
|
ДАТА ПРИЕМА:
14 июля 1980
|
N НАКЛАДНОЙ:
978
|
ДАТА ПРОДАЖИ:
25 июля 1980
|
НОМЕР СЧЕТА:
195 015
|
N КОНТЕЙНЕРА:
аааааааааа
|
N АВТОМАШИНЫ:
ббббббббббб
|
СПОСОБ ХРАНЕНИЯ:
вввввввв
|
ПОЛУЧЕНО
|
ПРОДАНО
|
МАРКИРОВКА
|
К-ВО
|
ВЕС
|
К-ВО
|
ЦЕНА
|
СТОИМОСТЬ
|
НАИМЕНОВАНИЕ ТОВАРА: Персики «Красный Дикси» А
|
XXX
|
50
|
|
40
|
1.00
|
40.00
|
|
|
|
10
|
1.05
|
10.50
|
НАИМЕНОВАНИЕ ТОВАРА: Персики «Красный Дикси» Б
|
YYY
|
481
|
|
100
|
0.75
|
75.00
|
|
|
|
150
|
0.77
|
115.50
|
|
|
|
200
|
0.80
|
160.00
|
|
|
|
31
|
0.85
|
25.35
|
|
ИТОГО:
|
427.35
|
СБОРЫ
|
ВСЕГО
СБОРЫ:
|
200.19
|
ЗА ХРАНЕНИЕ
|
КОМИССИОННЫЕ
|
ПРОЧИЕ
|
8.55
|
42.74
|
148.90
|
|
ЧИСТЫМИ:
|
227.16
|
Нормализация баз данных и функциональные зависимости.
СТРУКТУРА ХРАНИЛИЩА ДАННЫХ «Накладные о приеме товаров».
За основу возьмем структуру вышеприведенного документа.
В итоге мы имеем глубоко структурированное представление хранилища данных.
Это представление обладает рядом положительных качеств.
Данные предметной области сгруппированы в набор содержательных документов, к компонентам документов применимы традиционные средства доступа (языка Паскаль).
По такому представлению легко подготовить отчет поставщику об итогах сделки по партии товаров.
Но с другой стороны, это представление имеет и много недостатков.
Иерархический принцип группировки предполагает некую определенную точку зрения, в данном случае - «чьи товары надо продать». Но данные предназначены для многоцелевого использования. Если на это представление посмотреть с точки зрения «какие товары имеются для продажи», то возникает много вопросов... Решить задачи такого типа конечно можно, но при выбранном способе группировки проблематично воспользоваться, например упорядоченностью по видам имеющихся товаров...
Кроме внутренней структуры хранилищ данных (обычно) имеется внешняя структура взаимосвязей между данными из разных хранилищ. Описывать структуру взаимосвязей между сложно структурированными данными довольно трудно. Поэтому уже на уровне спецификаций задач будет оставаться много недоговоренного... с соответствующими последствиями...
ПЕРВАЯ НОРМАЛЬНАЯ ФОРМА. В реляционной модели баз данных рассматриваются только файлы в (первой) нормальной форме - «плоские файлы», точнее таблицы-отношения. Поля таких файлов должны иметь базовый неструктурный тип.
Устранение повторяющихся (внутренних) группировок (приведение к нормальной форме) проводится (многократной) декомпозицией исходного файла на два, связанных по уникальному ключу исходного файла.
   
При устранении повторяющихся группировок потребуются дополнительные поля («N строки накладной») для ключей межтабличных связей. Для надежной идентификации поставщиков, товаров и удержаний введем соответствующие коды. Вычислимые поля («итого», «всего сборы», «чистыми», «стоимость») исключим. Первичные ключи таблиц подчеркнуты.
В итоге мы получили нормализованную базу данных – многотабличную с межтабличными связями.
Такую БД всегда можно свести к нормализованной однотабличной (универсальная таблица-отношение) - соединением по ключу межтабличной связи, даже если эта связь типа «многие ко многим»:
SELECT КлючА, АтрибутыА, АтрибутыВ
FROM ТаблицаА, ТаблицаВ WHERE КлючА = КлючВ
Взаимосвязи между данными отражают семантику базы данных, унаследованную от предметной области. Поэтому в проектировании БД особое внимание уделяется выбору способа представления зависимостей между данными. Известно, что неудачный выбор может создавать впоследствии трудности при обновлении данных - аномалии.
Аномалии обновления данных. Рассмотрим эти трудности на примере таблицы «Партии товара».
Аномалия вставки (insert).
Пусть в таблице уже имеются накладные по некоторым еще не завершенным сделкам с данным поставщиком, и надо добавить новую накладную в связи с заключением новой сделки с этим поставщиком.
Поставщики в БД идентифицируются кодом, но при добавлении накладной надо ввести и его реквизиты – наименование, адрес. Кроме того, придется провести проверку. Если в других накладных этого поставщика указаны другие значения этих реквизитов, то впоследствии могут быть недоразумения. Например, в списке различных наименований окажется больше организаций, чем в списке различных (по коду) поставщиков(*).
Пусть имеются сведения о потенциальном поставщике, с которым пока не заключались сделки, но хотелось бы хранить информацию о нем.
В нашей БД можно хранить информацию о таком поставщике, только добавив частично заполненную накладную о фиктивной (пустой) сделке с этим поставщиком. Такие фиктивные сделки тоже впоследствии либо будут вызывать недоразумения в учете сделок, либо будут создавать дополнительные трудности в обработке (их придется «обходить»).
Аномалия удаления (delete). Если с поставщиком заключена единственная сделка, и по каким-то причинам необходимо удалить соответствующую накладную, то будет потеряна информация о наименовании и адресе этого поставщика. Либо, как и в предыдущем случае придется оформлять фиктивную сделку.
Аномалия обновления (update). Если изменился адрес поставщика, то соответствующее изменение придется внести в каждую накладную по сделкам с этим поставщиком.
Причины аномалий исследуются в теории и методологии проектирования БД. Получены результаты об устранении некоторых видов аномалий приведением базы данных к более сильным нормальным формам, чем первая.
ВТОРАЯ НОРМАЛЬНАЯ ФОРМА. Значения неключевых полей должны зависеть от всего ключа в целом, а не от его части.
Уникальным ключом новой таблицы УДЕРЖАНИЯ является пара (N накладной, Код удержания), но поле «Наименование удержания» зависит от части ключа - поля «Код удержания». Можно привести примеры аномалий, используя «код и наименование удержания», аналогично «коду и наименованию поставщика» в вышеприведенных примерах.
Разложим эту таблицу на две.
ТРЕТЬЯ НОРМАЛЬНАЯ ФОРМА. В таблице «ПАРТИИ ТОВАРА» поля «Наименование и адрес поставщика» зависят от поля «Код поставщика», а «Код поставщика» в свою очередь зависит от ключа «N накладной». С другой стороны, поля «Наименование и адрес поставщика» однозначно определяются напрямую по ключу «N накладной». Такая ситуация называется транзитивной зависимостью. В третьей нормальной форме не должно быть транзитивных зависимостей. Отметим, что аналогичная ситуация в таблице «СТРОКИ НАКЛАДНЫХ» для полей «Код товара» и «Наименование товара».
Разложим каждую из этих таблиц на две.
Отметим, что ранее рассмотренные для таблицы «ПАРТИИ ТОВАРОВ» примеры аномалий уже не проявляются в новой БД.
(Упрощенная) ER-диаграмма новой базы данных «Накладные о приеме товаров».
ER/IDEF1X-диаграмма БД «Накладные о приеме товаров».
(DBLEC\TGS.ER1)
Введение в основы теории функциональных зависимостей.
Пусть R – реляционное (конечное) отношение с атрибутами A = (X1,...Y1,...Z1,...). X,Y A.
R удовлетворяет функциональной зависимости XY :
проекция [X,Y](R) является функциональным отношением типа XY, т.е. не содержит пары строк с одинаковыми значениями атрибутов X («аргумент функции»), но разными значениями атрибутов Y («значение функции»). Будем использовать также терминологию: f-зависимость, Y функционально (однозначно) зависит от X, X функционально (однозначно) определяет Y, X – посылка (детерминант) f-зависимости, Y – заключение.
Пусть F – множество f-зависимостей.
F = XY (F влечет f-зависимость XY): для любого R, если R удовлетворяет каждой f-зависимости из F, то R удовлетворяет f-зависимости XY. F - (соответствующее) замыкание F, т.е. множество всех f-зависимостей XY, таких что F влечет f-зависимость XY.
Аксиомы Армстронга (точнее, исчисление выводимости для f-зависимостей).
F1. Рефлексивность (аксиома): XX
F2. Пополнение (правило вывода): XY
XZY
F6. Псевдотранзитивность (правило вывода): XY YZW
XZW
Производные правила вывода (их обоснование можно получить из предыдущих):
F3. Аддитивность: XY XZ
XYZ
F4. Проективность: XYZ
XY
F5. Транзитивность (~ F6 при пустом Z): XY YW
XW
F - XY (из F выводима f-зависимость XY): имеется вывод XY из набора зависимостей F (как аксиом) и аксиом рефлексивности по правилам вывода Армстронга.
Теорема о полноте. F = XY F - XY
Таким образом, F - транзитивное замыкание F, построенные по отношению «влечет» и по отношению «выводимости», совпадают.
NB. Доказуемость в исчислении выводимости для f-зависимостей равносильна доказуемости в - фрагменте интуиционистской (конструктивной) логики высказываний.
З адача проверки (XYF) имеет вычислительную сложность по времени – O(n), где n – длина кода, представляющего (XY;F).
Как уже отмечалось выше, взаимосвязи между данными отражают семантику базы данных, унаследованную от предметной области. Фактически для проектировщика и администратора БД основной интерес представляют не конкретные взаимосвязи между конкретными данными конкретного текущего состояния БД, а именно зависимости между атрибутами, причем те, которые должны сохраняться, по крайней мере в периоде между реструктуризациями БД (изменениями в метаданных).
Поэтому точнее, семантику БД фиксирует именно F, множество зависимостей, которое определяется не по конкретному текущему наполнению конкретной БД, а (априорно) определяется проектировщиком БД, исходя из смысла предметной области («что, будем считать, должно сохранятся в процессе преобразований БД»).
Однако базовые зависимости F влекут свои последствия, из чего проистекает практический интерес к F и далее к понятиям «выводимость и сложность вывода».
Может возникнуть недоумение – база данных состоит из нескольких взаимосвязанных таблиц, а все вышеприведенные определения даны применительно к одному отношению R. Поэтому напомним, что выше было оговорено, что многотабличная реляционная БД теоретически сводима к однотабличной, а практически... приведенные определения чисто технически обобщаются и на многотабличные БД.
X – возможный ключ отношения R: X является уникальным ключом (но возможно не выделенным в качестве первичного ключа). Неключевой атрибут – атрибут, не входящий в состав ни одного из возможных ключей.
R находится во второй нормальной форме: R находится в первой нормальной форме, и нет неключевых атрибутов, зависящих от части какого-либо (составного) возможного ключа.
Пусть (X,Y) – возможный ключ отношения R, но поля B1,... зависят от X (части возможного ключа), т.е. XB1,... Тогда R = [X,B1,...](R) * [X,Y,C1,...](R), где C1,... – остальные атрибуты отношения R. Это разложение отношения R на два отношения [X,B1,...](R) и [X,Y,C1,...](R) устраняет (внутритабличную) зависимость XB1,... от части ключа. Причем естественное соединение этих двух отношений точно совпадает с исходным отношением. Такое разложение называется декомпозицией без потерь.
     ПРИМЕР.
B
|
X
|
Y
|
C
|
N группы
|
N зачетки
|
Наименование экзамена
|
Оценка
|
...
|
...
|
...
|
...
|
Для этой таблицы нетрудно привести (аналогичные ранее приведенным) примеры аномалий. Рекомендованная декомпозиция (без потерь) дает две таблицы:
B
|
X
|
|
X
|
Y
|
C
|
N группы
|
N зачетки
|
|
N зачетки
|
Наименование экзамена
|
Оценка
|
...
|
...
|
|
...
|
...
|
...
|
Z транзитивно зависит от X (в отношении R): имеется такой Y, что XY и YZ, где XYZ и не верно: YX.
R находится в третьей нормальной форме: R находится во второй нормальной форме, и нет неключевых атрибутов, транзитивно зависящих от какого-либо возможного ключа.
Пусть X – возможный ключ отношения R, XY и YZ (т.е. Z транзитивно зависит от X), W – остальные атрибуты отношения R. Тогда R = [Y,Z](R) * [X,Y,W](R). Это разложение отношения R на два отношения [Y,Z](R) и [X,Y,W](R) устраняет (внутритабличную) транзитивную зависимость XZ. Причем декомпозицией без потерь.
     ПРИМЕР.
W
|
X
|
Y
|
Z
|
Сумма оценок по всем экзаменам
|
N зачетки
|
Группа
|
Количество экзаменов в текущей сессии
|
...
|
...
|
...
|
...
|
Для этой таблицы нетрудно привести (аналогичные ранее приведенным) примеры аномалий. Рекомендованная декомпозиция (без потерь) дает две таблицы:
W
|
X
|
Y
|
|
Y
|
Z
|
Сумма оценок по всем экзаменам
|
N зачетки
|
Группа
|
|
Группа
|
Количество экзаменов в текущей сессии
|
...
|
...
|
...
|
|
...
|
...
|
Функциональные зависимости и проектирование базы данных.
Пусть имеется некий предварительный проект БД. Сначала сведем многотабличную БД к универсальной таблице.
Определение f-зависимостей дано для одной таблицы, но зависимости имеются и межтабличные.
Пусть зафиксировано множество F функциональных зависимостей. Построим его замыкание F.
В явном виде F может и не содержать «плохих» зависимостей. Но аномалии могут быть, если «плохие» зависимости выводимы из F.
зависимости от части возможных ключей, т.е. приводим БД ко 2-й нормальной форме,
транзитивные зависимости, т.е. приводим БД к 3-й нормальной форме.
Приведение 3-й нормальной форме не гарантирует устранения всех аномалий.
Известны и изучены другие виды «плохих» функциональных зависимостей. Для устранения соответствующих аномалий предложены алгоритмы приведения БД к соответствующим более сильным нормальным формам.
Известны и изучены зависимости более общего вида, нефункциональные.
Аномалии не следует трактовать как ошибки или парадоксы. Скорее это проявление объективно существующих проблем представления предметной области. Устранение аномалий тоже не следует понимать как полное устранение проблем. Скорее это перегруппировка проблем, «перевод их в другую плоскость».
Вернемся к примеру устранения транзитивной зависимости. Пусть T – исходная таблица, а T1,T2 – полученные в результате декомпозиции.
В исходной таблице T были f-зависимости: T.NзачеткиT.Группа; T.ГруппаT.Количество; T.NзачеткиT.Количество.
В базе данных с таблицами T1,T2 остались: T1.NзачеткиT1.Группа; T2.ГруппаT2.Количество; межтабличная связь T1.Группа=T2.Группа и межтабличная зависимость T1.NзачеткиT2.Количество.
Транзитивная зависимость устранена не в абсолютном смысле, а лишь «разведена» через межтабличную связь. Смысл понятия «декомпозиция без потерь» и состоит в сохранении всех исходных зависимостей.
Устранение аномалий, связанных с устраненной транзитивной зависимостью, породило другие проблемы: теперь труднее решать задачу «По номеру зачетки вычислить средний балл студента в текущей сессии», появилась новая задача – контроль ссылочной целостности T1.Группа=T2.Группа.
Однако для решения этих проблем имеются типовые схемы и средства: операция «естественное соединение», средства определения межтабличных связей и соответствующего контроля ссылочной целостности.
В целом, принято считать хорошим правилом проектирования базы данных:
Сначала проанализировать имеющиеся проблемы, для этого привести БД к достаточно сильной нормальной форме.
На сегодняшний день имеются CASE-средства, которые по заданному описанию БД и базовому набору зависимостей автоматически строят описание соответствующей БД, приведенной к затребованной нормальной форме.
В конечном счете, только разработчик модели данных предметной области несет ответственность за проистекающие из нее трудности на последующих этапах разработки. Поэтому ему и принимать решение – какие из выявленных проблем решать за счет нормализации, а какие – частными методами, возможно более эффективными в конкретных условиях конкретной предметной области.
Поэтому вполне возможно, что будет принято решение о частичной денормализации ранее полученного представления базы данных.
Как было отмечено выше, зависимости между атрибутами фиксируют семантику предметной области.
Когда разработчик знакомится с новой предметной областью, не столь очевиден и однозначен ответ на вопрос – что следует считать объектами этой предметной области. В первую очередь выявляются скорее списки атрибутов и зависимости между ними. Разговоры с пользователями – специалистами предметной области обычно происходят в терминах – какие документы имеются, каковы реквизиты этих документов, как они связаны между собой и как по одним реквизитам одних документов рассчитать значения других(*). Некие объекты в названиях реквизитов документов конечно присутствуют, но...
ПРИМЕР(**). Ставится задача спроектировать БД для секретаря некой игровой лиги небольшого городка.
Речь идет об индивидуальном виде игр (в книге – игра в кегли), в которой каждый игрок набирает личные очки. Команде засчитывается победа в игре с командой соперников, если ее игроки суммарно набрали больше очков, чем игроки команды соперников. Далее очки команды вычисляются по результатам серии из трех игр с командой соперников.
На каждую неделю каждой команде требуется назначить игровую площадку, на которой она проведет три игры. Соперники играют на смежных площадках.
Секретарю понадобятся фамилии, телефонные номера и адреса всех игроков лиги.
Секретарю необходимо знать состав игроков каждой из команд и фамилию капитана.
Для каждого игрока надо знать его результативность на начало сезона и набранные им очки в каждой из трех игр каждой еженедельной серии текущего сезона.
Эта информация необходима для расчета очков команд и определения соответствующего из положения в турнирной таблице. Кроме того, эта информация используется при распределении индивидуальных призов игрокам по результатам сезона.
В результате обсуждений с секретарем был подготовлен список атрибутов универсальной таблицы и набор функциональных зависимостей. При этом многие атрибуты первоначального списка были вычеркнуты, т.к. было установлено, что они вычислимы. Например, вычислимой оказалась вся информация о командных результатах.
NКоманды: номер, однозначно идентифицирующий
команду.
НКоманды: наименование, однозначно идентифицирующее
команду.
ФИОИгрока: ФИО, однозначно идентифицирующее игрока.
NПлощадки: номер, однозначно идентифицирующий
игровую площадку.
ФИОКапитана: ФИО, однозначно идентифицирующее не только
игрока – капитана команды, но и команду.
Телефон: номер телефона игрока, несколько
игроков могут иметь один и тот же телефон.
Улица: улица, на которой проживает игрок.
NНедели: порядковый номер недели в сезоне.
Рез0: результативность игрока на начало сезона.
ОИгры1: число набранных игроком очков
в 1-й игре недели.
ОИгры2: аналогично... во 2-й игре недели.
ОИгры3: ... в 3-й игре недели.
(ФИОИгрока,NНедели) – единственный возможный ключ.
НКомандыNКоманды
НКомандыФИОКапитана
ФИОКапитанаNКоманды
ФИОИгрокаNКоманды,Улица,Телефон,Рез0
ФИОИгрока,NНеделиОИгры1,ОИгры2,ОИгры3,NПлощадки
NПлощадки,NНеделиNКоманды
NКоманды,NНеделиNПлощадки
В диаграмме f-зависимостей: штрих-стрелками отмечены зависимости от части возможного ключа, белой стрелкой – транзитивная зависимость от возможного ключа.
ФИОИгрока,NНеделиNПлощадки является транзитивной зависимостью:
ФИОИгрока,NНеделиNКоманды,NНедели
и NКоманды,NНеделиNПлощадки.
Замыкание базового набора f-зависимостей содержит и другие транзитивные зависимости, например:
ФИОИгрока,NНеделиNКоманды,
т.к. ФИОИгрока,NНеделиNПлощадки,NНедели
и NПлощадки,NНеделиNКоманды.
Устраним сначала транзитивную зависимость ФИОИгрока,NНеделиNПлощадки:
R1(ФИОИгрока,NНедели,NКоманды,НКоманды,ФИОКапитана,
Телефон,Улица,Рез0,ОИгры1,ОИгры2,ОИгры3)
R2(NКоманды,NНедели,NПлощадки)
Теперь в R1 устраним оставшуюся зависимость от части первичного ключа:
R11(ФИОИгрока,NКоманды,НКоманды,ФИОКапитана,
Телефон,Улица,Рез0)
R12(ФИОИгрока,NНедели,ОИгры1,ОИгры2,ОИгры3)
Теперь в R11 устраним транзитивную зависимость ФИОИгрокаНКоманды,ФИОКапитана, которая была в исходной универсальной таблице, но для R11 она к тому же стала зависимостью от первичного ключа.
R111(ФИОИгрока,NКоманды,Телефон,Улица,Рез0)
R112(NКоманды,НКоманды,ФИОКапитана)
В итоге получили базу данных с 4-мя таблицами. Соответствующая ER/IDEF1X-диаграмма (DBLEC\LIGA.ER1):
Модель данных «сущность-связь» и применение ER-диаграмм.
|
