82
В результате анализа требований пользователя и структур данных, опи-
сывающих деятельность, обработка документооборота, определены как сущ-
ности следующие объекты:
Исполнители (Код_исполнителя – первичный ключ)
Музыка (Код_музики – первичный ключ)
Жанры (Код_жанра – первичный ключ)
Плейлисты (Код_плейлиста – первичный ключ)
Радисостанции (Код_радиостанции – первичный ключ)
Первичный вариант концептуальной модели данных предметной обла-
сти представляем в виде диаграммы «сущностей-связей» (ER-диаграммы),
разработанной в программе yEd, показано на рисунке 2.17
При этом минимальная информация, изображаемая на диаграмме,
должна содержать следующие пять элементов данных:
сущности, изображаемые в виде прямоугольников произвольного раз-
мера;
ключи сущностей, изображаемые в виде подчеркнутых надписей ря-
дом с прямоугольником с любой стороны;
связи, изображаемые в виде ромбов произвольного размера и соеди-
ненных прямыми линиями с соответствующими сущностями, эти линии могут
быть произвольного наклона и, по возможности, без пересечений;
степень участия в связи для каждой сущности, изображаемая в виде
числа или буквы около соответствующего прямоугольника-сущности и линии
связи;
полнота участия в связи для каждой сущности, изображаемая в виде
точки перед символом-степенью участия, при этом наличие точки означает
полное участие в связи данной сущности, т.е. значение обязательный.
Каких-либо строгих правил для изображения диаграммы ER-типов не
существует. В различных коммерческих системах (CASE средствах) проекти-
рования БД используется и другая нотация для изображения ER-диаграмм,
83
наиболее известными из них являются нотация «куриных лапок» и нотация
стандарта IDEF1X. Однако, для обсуждения результатов проектирования с бу-
дущими пользователями БД удобнее всего представить диаграмму ER-типов в
нотации, предложенной впервые П. Ченом, т.е. в виде прямоугольников и ром-
бов.
В процессе документооборота сущности взаимодействуют друг с дру-
гом. В концептуальной модели взаимодействие между сущностями выража-
ется с помощью связей, основными из которых являются следующие. [14]
В связи Музыка - Плейлист (М: М) независимо от класса принадлежно-
сти сущностей формируются три отношения, два отношения соответству-ют
связываемым сущностям и их ключи являются первичными ключами этих от-
ношений. Третье отношение является связным между первыми двумя, а его
ключ объединяет ключевые атрибуты связываемых отношений [15]. Связь
изображена на рисунке 2.10
Рисунок 2.10 – Сущность связь (музыка и плейлист)
В связи Исполнитель - Музыка (1: М) класс принадлежности сущности
Музыка будет обязательным. Согласно правилу 3, первичный ключ сущности
на стороне 1 добавляется как атрибут в таблицу для сущности на стороне М, и
служит внешним ключом. И строится 2 таблицы.
Рисунок 2.11 – Сущность связь (исполнитель и музыка)
84
В связи Музыка - Жанры (1: М) класс принадлежности сущности Жанры
будет обязательным. Согласно правилу 3, первичный ключ сущности на сто-
роне 1 добавляется как атрибут в таблицу для сущности на стороне М, и слу-
жит внешним ключом. И строится 2 таблицы.
Рисунок 2.12 – Сущность связь (музыка и жанры)
В связи Плейлисты - Радиостанция (1: М) класс принадлежности сущно-
сти Радиостанция будет обязательным. Согласно правилу 3, первичный ключ
сущности на стороне 1 добавляется как атрибут в таблицу для сущности на
стороне М, и служит внешним ключом. И строится 2 таблицы.
Рисунок 2.13 – Сущность связь (плейлист и радиостанция)
85
Рисунок 2.14 – ERD-модель
Логическая модель. Разработка логической модели базы данных.
После того, как концептуальная модель одобрена, можно перейти к
этапу логического проектирования БД. При этом исходными данными для
проектирования являются диаграмма ER-типов концептуальной модели пред-
метной области и логическая модель данных, используемая для реализации
будущей БД и поддерживаемая какой-либо коммерческой СУБД.
В качестве логической модели данных выбираем реляционную модель
Кодда, как наиболее распространенную в большинстве современных СУБД.
Теперь следует преобразовать концептуальную модель в соответствии с тре-
бованиями реляционной модели данных.
Таким образом, формально этап логического проектирования БД может
в проекте отсутствовать, но при этом следует иметь в виду, что при выполне-
нии преобразования диаграммы ER-типов в схему БД с помощью выше изло-
женных правил 1-8, мы, фактически и выполняем логическое проектирование
БД с использованием реляционной логической модели данных. И в любом слу-
чае получаем логическую модель, в которой все объекты представлены как
сущности (сильные или слабые) и связи один ко многим и один к одному
(сильные или слабые).
86
Еще одним ограничением реляционной модели данных является требо-
вание нормализации всех сущностей-отношений. Это требование часто назы-
вают первой нормальной формой (1НФ). Оно заключается в том, чтобы все
атрибуты в БД были атомарными с точки зрения СУБД. Атомарность означает
неделимость каждого значения данных на многие значения, например не до-
пускается иметь в БД атрибутов, представляющих собой списки значений
(множественные значения), как-то: номера телефонов, оценки, дни работы и
т.д. Не допускается иметь в БД и атрибуты составные, например адрес, вклю-
чающий город, улицу, дом, квартиру при условии, что в процессе использова-
ния БД потребуется обращение к какой-либо части этого адреса.
Во всех этих случаях требуется на этапе логического проектирования
обязательно провести нормализацию каждого отношения, т.е. привести его к
1НФ.
На следующем шаге проектирования необходимо оценить полученные
отношения с точки зрения нормальных форм более высокого порядка. Причем,
из пяти нормальных форм, известных в настоящее время 2НФ, 3НФ. НФБК,
4НФ и 5НФ, на практике, как правило, бывает вполне достаточно обеспечить
третью нормальную форму или НФБК (усиленную 3НФ). В крайнем случае,
можно вообще не заниматься вопросами приведения БД к той или иной НФ,
но при этом надо помнить о том, что надежность проекта будет тем ниже, чем
сложнее БД и чем большие требования предъявляются к целостности данных.
Чтобы провести проверку на уровень нормализации БД, необходимо:
разместить все атрибуты во всех полученных сущностях-отношениях
(слабых и сильных);
выявить в каждом отношении потенциальные ключи;
выявить все функциональные зависимости (ФЗ) между атрибутами в
каждом отношении;
сопоставить потенциальные ключи с детерминантами ФЗ (их левыми
частями);
87
если какой-либо детерминант отношения не совпадает ни с одним по-
тенциальным ключом этого же отношения, то данное отношение не находится
в той или иной НФ и его требуется нормализовать в соответствии с теорией
нормальных форм [16].
В результате приведения БД в ту или иную НФ, как правило, появляются
дополнительные отношения, которые следует добавить в логическую модель.
Таким образом, получается окончательный вариант логической модели
БД, ER диаграмма которой представлена на рисунке 2.15.
88
Рисунок 2.15 – Логическая модель
89
Разработка физической модели базы данных. На третьем этапе проекта,
опираясь на логическую модель БД, полученную на предыдущем этапе.
На основе схемы базы данных, а именно, используя значения потенци-
альных и внешних ключей отношений, напишем скрипты создание таблиц
[17].
Физическая модель, изображено на рисунке 2.16.
Рисунок 2.16 – Физическая модель
2.3.3 Структурная схема пакета (дерево вызова процедур и про-
грамм)
Схема графических форм разрабатываемой программы предоставлена
на рисунке 2.17.
Рисунок 2.17 – Схема графических форм
90
В таблице 2.11 содержится описание всех модулей структурной схемы
паке-тов.
Таблица 2.11 – Описание всех модулей структурной схемы
Наименование мо-
дуля
Функционал формы
Форма «Главная»
Через главную форму осуществляется переход по
следующим формам: создание плейлиста, добавле-
ние трека или жанра, просмотр плейлистов, удалить
трек или плейлист.
Форма «Добавление
плейлиста»
Форма генерации плейлиста.
Форма «Добавления
трека или жанра»
Форма на добавления трека или жанра.
Форма «Просмотр
плейлистов»
Форма просмотра информации по плейлистам.
Форма «Удаление
трека или плейлиста»
Форма на удаление трека или плейлиста.
2.3.4 Описание программных модулей
Для извлечения или отправки данных в базу данных была выбрана про-
граммная платформа «Entity Framework».
Entity Framework был впервые выпущен в 2008 году, основным сред-
ством взаимодействия Microsoft между приложениями .NET и реляционными
базами данных. Entity Framework - это Object Relational Mapper (ORM), кото-
рый представляет собой тип инструмента, который упрощает сопоставление
91
между объектами в вашем программном обеспечении и таблицами и столб-
цами реляционной базы данных.
Entity Framework (EF) - это среда ORM с открытым исходным кодом для
ADO.NET, которая является частью .NET Framework.
ORM заботится о создании соединений с базой данных и выполнении
команд, а также о получении результатов запроса и автоматической материа-
лизации этих результатов как объектов вашего приложения.
ORM также помогает отслеживать изменения в этих объектах, и при по-
лучении инструкции он также сохраняет эти изменения обратно в базу данных
для вас.
Entity Framework - это ORM, и ORM направлены на повышение произ-
водительности труда разработчика за счет сокращения избыточной задачи со-
хранения данных, используемых в приложениях.
Entity Framework может генерировать необходимые команды базы
данных для чтения или записи данных в базу данных и выполнять их для вас.
Если вы запрашиваете, вы можете выразить свои запросы к объектам
вашего домена, используя LINQ для сущностей.
Entity Framework выполнит соответствующий запрос в базе данных, а
затем материализует результаты в экземпляры ваших доменных объектов для
работы в вашем приложении.
На рынке есть и другие ORM, такие как NHibernate и LLBLGen
Pro. Большинство ORM обычно отображают типы доменов непосредственно в
схему базы данных.