Этап 1. Инфологическое проектирование

Инфологический подход не предоставляет формальныхспособов моделирования реальности, однако он закладывает основы методологиипроектирования БД.

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

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

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

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

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

1. Имя отношениявыделяется курсивом и подчеркиванием и пишется прописными буквами,например: СОТРУДНИКИ.

2. Имя атрибутаотношения выделяется курсивом и подчеркиванием и пишется с большой буквы,например: Оклад.

3. Ключевые атрибутыотношения выделяются полужирным шрифтом, например: Табельныйномер.

4. Имя связи междуотношениями выделяется курсивом и подчеркиванием и пишется строчными буквами,например: работает.

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

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

Для каждой сущности определяются атрибуты, которыеделятся на два типа: идентифицирующие и описательные. Идентифицирующие атрибуты входят в состав ключа (или ключей) и позволяютоднозначно распознавать экземпляры сущности. Первичный ключ базовой сущности неможет содержать неопределённые значения атрибутов (null). Первичный ключ долженвключать в свой состав минимально необходимое для идентификации количествоатрибутов. Описательные атрибуты заключают в себе свойства сущности,интересующие пользователей.

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

Обязательно предложите в инфологической моделисоставные атрибуты (с неопределенным числом элементов). Это гарантируеткачественное выполнение этапа «Логическое проектирование».

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

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

· объединение вединое целое фрагментарных представлений о различных свойствах одного и того жеобъекта;

· введение абстрактныхпонятий, удобных для решения задач системы, установление их связи с болееконкретными понятиями модели;

· образованиеклассов и подклассов подобных объектов (например, класс "изделие" иподклассы типов изделий, производимых на предприятии).

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

1. Идентичность. Два или более элементов моделиидентичны, если они имеют одинаковое семантическое значение.

2. Агрегация. Позволяет рассматривать связьмежду элементами как новый элемент. Например, связь экзамен междусущностями СТУДЕНТ, ДИСЦИПЛИНА, ПРЕПОДАВАТЕЛЬ может быть представлена агрегированной сущностью ЭКЗАМЕН сатрибутами Название дисциплины, Фамилия преподавателя, Фамилия студента, Оценка.

3. Обобщение. Позволяет образовыватьмногоуровневую иерархию обобщений.

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

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

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

Один авторможет написать несколько книг, и, в то же время, одна книга может быть написананесколькими авторами. Следовательно, "книга" и "автор" вданном случае выступают как различные сущности, объединяемые связью N: M. Длятого, чтобы определить класс принадлежности сущностей в связи, отметим, чтокниг без авторов не бывает, как и авторов без книг. Значит, каждая сущностьдолжна иметь обязательный класс принадлежности (кардинальность связи(1,N) 1,N)).

Точно так жеодин издатель может издавать сразу несколько книг, но каждая конкретная книгаиздается только в одном месте. Следовательно, мы должны ввести сущность"издатель", ассоциируемую с "книгой" связью типа 1: N. Т.к.каждая книга кем-то издана, класс принадлежности сущности "издатель"в данной связи будет (1,1), но в то же время мы допускаем хранение сведений обиздательствах, чьих книг в нашей базе данных пока нет. Соответственно, класспринадлежности сущности "книга" в этой связи (0,N).

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

Те жерассуждения можно повторить и для характеристики "год издания". Ее мытоже оставим в списке атрибутов "книги".

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

Что касаетсявсех возможных авторов, то нас интересует только одна их харакетристика - имя.Поэтому, сущность "автор" имеет только один атрибут"имя_автора", который и является ключом.

С сущностью "издатель"дел обстоит несколько сложнее. Практически все крупные издательства имеютсейчас собственные web-страницы, которые могут содержать информацию полезнуюдля пользователей проектируемой базы данных. Поэтому, нужно рассматреть двехарактеристики этого объекта: "имя_издателя" и "URL"(uniform resource locator - универсальный указатель ресурсов, с помощьюкоторого в Internet определяется путь к web - странице). Ясно, что каждыйиздатель имеет уникальное имя и уникальный url, но прежде чем внести их в списокатрибутов, вспомним, что наша база данных должна также содержать ссылки и надругие Internet-ресурсы. Возможно, при дальнейшем анализе возникнетнеобходимость во введении отдельной сущности "URL". Поэтому"имя_издателя" внесем в список атрибутов сущности"издатель", а "URL" будем считать атрибутом отдельнойсущности "web - страница", ассоциируемой с "издателем"связью (1,1) 1,1).

Теперь насталапора занятся объектом "ресурс Internet". Его мы можем описать спомощью понятий "имя ресурса", "url", "автор".Внимательно рассмотрев связи этих понятий с описываемым объектом, можно прийтик заключению, что "имя_ресурса" и "url" однозначно с нимсвязаны, т.е. являются атрибутами. В то же время, "автор" являетсяотдельной сущностью (один ресурс может иметь много авторов, и один автор можетбыть создателем многих web - страниц). Т.к. мы уже ранее вввели сущность"автор" просто определим характеристики ее связи с сущностью"Internet-ресурс". Из сказанного выше следует, что эти сущности объединяютсясвязью n: m, в то же время, автор какой-либо книги может не иметь собственнойweb - страницы, а авторы некоторых Internet ресурсов не указывают своих имен(т.е. можно формально сказать, что эти ресурсы не имеют авторов).Следовательно, класс принадлежности обеих сущностей будет необязательным.

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

Сущность"автор" имеет обязательный класс принадлежности в связи с сущностью"книга". Это означает, что мы не сможем добавить в базу данныхсведения о человеке, который создал собственный web - сайт, но не написал ниодной книги. Для того, что бы устранить это ограничение изменим класспринадлежности сущности "книга" в рассматриваемой связи"автор" - "книга" на необязательный.

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

Готовая модель"сущность-связь" представлена на следующем рисунке:

 

На этапе анализа ПО также необходимо решить следующиезадачи:

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

2. Выделить группы пользователей системы. Каждаягруппа выполняет определённые задачи и обладает разными правами доступа ксистеме.

3. Создать внешнюю спецификацию тех функций(процессов), которые эта система будет выполнять. Например, для той жебиблиотечной системы это задачи поиска книг (по определённым критериям),выдачи/приёма книг, определение списка должников и т.д.

Этап 2. Определениетребований к операционной обстановке

На этом этапе производится оценка требований квычислительным ресурсам, необходимым для функционирования системы, выбор типа иконфигурации ЭВМ, типа и версии операционной системы.

Выбор зависит от таких следующих показателей:

· примерный объёмданных в БД;

· динамика ростаобъёма данных;

· характер запросовк данным (извлечение и обновление отдельных записей, групп записей, обработкаотдельных отношений или соединение отношений);

· интенсивностьзапросов к данным по типам запросов;

· требования квремени отклика системы по типам запросов.