ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ КАТАЛОГА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Для этого осуществляются следующие мероприятия:

• обследование предметной области, изучение ее информационной структуры
• выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами
• моделирование и интеграция всех представлений

Для создания схем концептуальной модели привлекаются специалисты ПО, не владеющие специальной терминологией обработки данных. Поэтому предпочтение надо отдавать простым, понятным, легко читаемым способам отображения объектов ПО я их взаимосвязей на схеме, возможно с использованием естественного языка.

Для представления концептуальной модели используют различные методы и модели, например, модель "сущность" - "атрибут" - "связь",которая описывает ПО в виде UML-диаграмм. UML-диаграммы - понятны, легко читаемы даже не специалистами и в тоже время достаточно формализованы и широко распространены.

     В нотации языка  UML определены следующие виды  канонических диаграмм:

• вариантов использования (use case diagram)
• классов (class diagram)
• кооперации (collaboration diagram)
• последовательности (sequence diagram)
• состояний (statechart diagram)
• деятельности (activity diagram)
• компонентов (component diagram)
• развертывания (deployment diagram)

 

Диаграмма вариантов использования (Use Case Diagram) представляет собой наиболее общую концептуальную модель сложной системы, которая является исходной для построения всех остальных диаграмм.

Визуальное моделирование в UML можно  представить как некоторый процесс  поуровневого спуска от наиболее общей  и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (Use Case Diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.

Разработка диаграммы вариантов использования преследует следующие цели:

1. определение общих границ и контекста моделируемой предметной области на начальных этапах проектирования системы.
2. формулирование общих требований к функциональному поведению проектируемой системы.
3. разработка исходной концептуальной модели системы для ее последующей детализации в форме логических и физических моделей.

Суть данной диаграммы состоит  в следующем, проектируемая система  представляется в виде множества  сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. На рисунке 1 представлена диаграмма вариантов использования, при помощи которой разработана основная концепция разрабатываемой информационной системы.

 

 

Рисунок 1 – Диаграмма  вариантов использования пользовательской части

 

 

 

Рисунок 2 – Диаграмма вариантов использования администраторской части

 

Диаграмма классов (Class Diagram), по своей сути, логическая модель, отражающая статические аспекты структурного построения сложной системы.

Диаграмма классов предназначена для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. При этом диаграмма классов может содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры классификаторов, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы, т. е. графическое представление таких структурных взаимосвязей логической модели системы, которые не зависят от времени.

 

 

Рисунок 2 – Диаграмма классов

 

Остальные диаграммы в данной предметной области можно не рассматривать.

 

 

2.4 Логическое проектирование  БД

 

 

Логическое проектирование основано на модели логического уровня и представляет собой описание и построение схем связей между элементами данных безотносительно к их содержанию и среде хранения.

Логическая структура БД получается преобразованием концептуальной схемы в логическую схему (модель), ориентированную на выбранную СУБД.

Применительно к наиболее распространенной реляционной модели данных общий подход преобразования концептуальной схемы в логическую состоит в том, что каждую сущность, являющуюся представителем множества однотипных объектов, задают схемой отдельного отношения (таблицы), а атрибуты сущности образуют столбцы таблицы. Первичный ключ сущности образует исходный первичный ключ таблицы, который в дальнейшем может быть изменен.

Проектирование логической структуры  БД должно решать задачи выбора наиболее эффективной структуры данных, обеспечения  быстрого доступа к данным. исключения дублирования данных, обеспечения целостности данных таким образом, чтобы при изменении одних объектов автоматически происходило соответствующее изменение связанных с ними объектов.

При неправильно спроектированной схеме БД могут возникнуть аномалии модификации данных. Они обусловлены отсутствием средств явного представления типов множественных связей между объектами ПО и неразвитостью средств описания ограничений целостности на уровне модели данных. Для решения подобных проблем проводится нормализация отношений, предложенная Э.Ф.Коддом в рамках реляционной модели данных.

 

 

Нормализация

 

 

Целью нормализации является исключение избыточности данных, которая является причиной ошибок при вводе и нерационального использования дискового пространства компьютера

Нормализация представляет собой  процесс последовательного приведения логической структуры базы данных к требуемому уровню нормальной формы. Существует шесть нормальных форм (НФ): первая НФ (1НФ), вторая НФ (2НФ). третья НФ (ЗНФ), нормальная форма Бойса-Кодда (БКНФ), четвертая НФ (4НФ), пятая НФ (5НФ). Каждая следующая нормальная форма должна удовлетворять требованиям предыдущей формы и некоторым дополнительным условиям. Ограничимся рассмотрением первых трех НФ, поскольку при практическом проектировании баз данных остальные НФ используются в редких случаях.

 

 

2.4.1 Первая нормальная форма

 

 

Таблица находится в 1 НФ, если она  удовлетворяет следующим требованиям:

а) не содержит полей с несколькими значениями;

б) ключевое поле не имеет пустот.

 

Первым требованием обеспечивается атомарность полей, т.е. каждое поле таблицы должно иметь только одно значение в каждой строке данных. Иногда неатомарное поле может быть представлено несколькими полями повторяющейся группы, которая также запрещена в 1НФ. В процессе нормализации, необходимо повторяющиеся значения в полях превратить в повторяющиеся строки в других таблицах, а повторяющиеся группы в отдельные таблицы.

Вторым требованием через определение  первичного ключа обеспечивается уникальность записей таблицы. Как правило, в 1НФ первичный ключ является составным.

Рассмотрим процесс приведения к 1 НФ на примере Рис1. представлен список таблиц проектируемой базы данных.

По определению логическая модель является отображением концептуальной модели, в частности диаграммы  классов. В данном случае исходными данными будут являться три таблицы (Рис1.), выделенные при построении концептуальной модели. Проанализируем их в соответствии с требованиями.

 

Программы:

 

Название

Автор

Категория

Лицензия

Язык

Размер

Стоимость

Версия

Ссылка

ОС

Сайт автора

 

Скриншоты:

 

Название

Бинарный файл

 

Администраторы:

 

Логин

Пароль

Тип

 

 

В таблице "Программы" не все поля удовлетворяют требованиям 1НФ. В частности поле "ОС" содержит список операционных систем, а значит не является атомарным и его надо выделить в отдельную таблицу БД.

 

Название

ОС

 

Поля "Автор", "Категория", "Лицензия", "Язык", "Размер", "Стоимость", "Версия",  "Сайт" являются атомарными.

Таким образом, мы получили таблицы без полей с несколькими значениями, таким образом первое требование 1 НФ выполнено. Чтобы обеспечить второе требование необходимо определить первичные ключи в каждой таблице.

Для таблицы "Программы" первичным ключом будет составной ключ из полей "Название", "Автор" которое будет определять другие не ключевые поля.

В результате все таблицы  не имеют пустот, таким образом, мы завершили процесс приведения к 1НФ.

 

 

2.4.2 Вторая нормальная форма

 

 

Таблица находится во 2НФ, если она  удовлетворяет следующим требованиям:

- таблица должна быть приведена к 1НФ;

- поля, которые зависят только от части первичного ключа должны быть выделены в состав отдельных таблиц;

- все таблицы должны быть связаны между собой.

 

Поскольку на данном этапе первичный  ключ является составным необходимо, части таблицы, зависящие от полей  этого первичного ключа выделить в состав отдельных таблиц, с условием взаимосвязей сущностей.

 

ИД_автора

Автор

Сайт

 

ИД_программы

ИД_автора

Категория

Лицензия

Размер

Стоимость

Версия

Ссылка

 

При анализе предметной области  мы выяснили, что авторы могут редактировать  свои программы, и поэтому нам  необходимо соединить таблицу "Авторы" с таблицей "Администраторы".

 

ИД_автора

Автор

Сайт

Логин

Пароль

Тип

 

 

Создадим новую сущность "Категории" и добавим в неё атрибуты: "ИД_категории" и "Название". При формулировке системного анализа одним из требований было построение иерархической структуры каталога программ, поэтому для этой цели нам нужно создать дополнительный атрибут "ИД_родителя", который будет хранить ссылку на родительский элемент каталога, и таким образом можно создавать иерархию любой вложенности.

 

 

ИД_категории

Название

ИД_родителя

ИД_программы

ИД_автора

ИД_категории

Лицензия

Размер

Стоимость

Версия

Ссылка

 

 

 

 

 

 

 

 

 

 

В таблице "Программы" существует также избыточное поле "Лицензия", которое будет повторяться у некоторого количества записей, поэтому данное поле следует вынести в отдельную сущность.

 

 

ИД_лицензии

Название

ИД_программы

ИД_автора

ИД_категории

ИД_лицензии

Размер

Стоимость

Версия

Ссылка

 

 

 

 

 

 

 

 

 

 

В таблице "Скриншоты" нужно убрать атрибут "Название" и вместо него ввести ключевое поле "ID_картинки". Для связи таблиц "Программы" и "Скриншоты" по связи один-ко-многим следует создать дополнительный атрибут "ID_программы".