23 Продолжение таблицы 4.3.

4.4 Диаграмма "сущность-связь"

Все, ранее определенные сущности преобразованы в набор из 11 реляционных таблиц. Так сущность. Пользовать расширяется таблицами: сотрудник, студент и преподаватель. Сущность Литература расширяется таблицами: журнал, методические указания, с учетом статистики использования литературы и участия книг в обмене с другими университетами.

Каждая таблица содержит первичный ключ. Для обеспечения ссылочной целостности используются внешние ключи.

Полученная схема данных представлена в виде ER-диаграммы (диаграммы сущность-связь) (рис. 4.1).

Рисунок 4.1 - ER-диаграмма модели данных задачи "Учет фонда библиотеки"

5. Описание полученных таблиц и связей

В схеме данных присутствуют такие таблицы:

1) Polzovatel, содержит сведенья о пользователе библиотеки. Таблица состоит из атрибутов: Familiya (Фамилия), Imya (Имя), Otchestvo (Отчество), Data_rogd (дата рождения), Login (логин для входа в систему), Password (пароль для входа систему).

2) Student, содержит Spec (специальность), Fakultet (факультет), Gruppa (группа), Roles_id (уникальный идентификатор роли, внешний ключ), Polzovatel_id (уникальный идентификатор пользователя, внешний ключ). Данная таблица связана с таблицей Polzovatel связью типа "является" и имеет отношение 1: 1.

3) Prepodavtel, содержит сведенья о преподавателе. Таблица состоит из таких атрибутов: Kafedra (кафедра к которой относиться преподаватель), Zvanie (звание,) Uch step (ученая степень), Roles_id (уникальный идентификатор роли, внешний ключ), PolzovateMd (уникальный идентификатор пользователя, внешний ключ).

Данная таблица связана с таблицей Polzovatel связью типа "является" и имеет отношение 1:1.

4) Sotrudnik, содержит сведенья о сотруднике библиотеки. Таблица состоит из атрибутов: Otdel (отдел в котором работает сотрудник библиотеки), Dolgnost (должность сотрудника), Roles_id (уникальный идентификатор роли, внешний ключ), PolzovateMd (уникальный идентификатор пользователя, внешний ключ). Данная таблица связана с таблицей Polzovatel связью типа "является" и имеет отношение 1: 1.

5) Roles, представляет набор возможных ролей пользователей системы. Таблица имеет атрибуты: Admin (определяет, имеет ли пользователь максимальный набор прав по доступу к системе; право утверждать изменения), Prepodavatel (определяет набор прав для преподавателя), Student (определяет набор прав для студента), Roles_id (уникальный идентификатор роли, внешний ключ), Polzovatel_id (уникальный идентификатор пользователя, внешний ключ). Данная таблица связана с таблицами Prepodavatel, Student, Sotmdnik связью типа "принадлежит" и имеет отношение 1:М.

Literatura, содержит сведенья о литературе. Таблица имеет атрибуты Avtor (название авторов книги), Nazvanie название книги), God (год издания), Kod_knigi (уникальный код - идентификатор книги), Tematika (информация о тематике книги), Stranicy (количество страниц книги). Literatura_id (уникальный идентификатор книги, внешний ключ).

Metod, содержит информацию о методических указаниях. Таблица имеет набор атрибутов: Kafedra (название кафедры к которой относиться методические указания), VUZ (название ВУЗа, издавшего методические указания), Disciplina (дисциплина, на которую "направлено" данное методическое указание), Metod_id (уникальный идентификатор методического указания, внешний ключ), Literaturaid (уникальный идентификатор книги, внешний ключ).

Gurnal, содержит информацию о журналах. Таблица включает в себя такие атрибуты: Gurnal_id (уникальн ый идентификатор журнала, внешний ключ), NomerJVypuska (информация о номере выпуска), Mesyac (месяц издания), Literatura_id (уникальный идентификатор книги, внешний ключ).

Statistica, содержит информацию о статистике использования литературы пользователями библиотеки. Таблица содержит такие атрибуты: Count (используется для фиксации частоты использования литературы), Statistikaid (уникальный идентификатор статистики, внешний ключ), Primary_kurs (информация о курсе что наиболее часто использует данную литературу), Primary_month (фиксирует максимальный спрос на издание в году), Literatura_id (уникальный идентификатор книги, внешний ключ).10) Formular содержит сведения о взятой литературе. Таблица содержит атрибуты: Formular id (уникальный идентификатор формуляра, внешний ключ), Data vydachi (дата выдачи книги), Na srok (на какой срок выдана книга), Реnуа (пеня), Sostoyanie knigi (состояние книги (сдана / не сдана), Literatura id (уникальный идентификатор книги, внешний ключ), Polzovatel id (уникальный идентификатор пользователя, внешний ключ).

11) Podrazdelenie содержит название раздела литературы и количество книг в нем. Таблица содержит атрибуты: Podrazdelenie id (уникальный идентификатор подразделения, внешний ключ) Nazvanie otdela (название раздела литературы), Kolichestvo (количество книг в разделе), Literatura_id (уникальный идентификатор книги, внешний ключ).

6. Разработка объектно-ориентированной модели

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

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

Учитывая все приведенные условия, была разработана ООМД, диаграмма классов, которая представлена на рисунке 6.1.

Рисунок 6.1 - Диаграмма классов объектно-ориентированной модели данных задачи "Учет фонда библиотеки"

Студент, атрибутами которого являться Специальность, Факультет и Группа имеет два метода addStudent (), editStudent (), позволяющие добавлять студентов вносить изменения. Данный класс является классом - наследником класса Пользователь.

Преподаватель, наследует свойства и методы класса - родителя - Пользователь. Имеет свойства: Кафедра, Звание, Ученая степень, Должность. Реализует методы: addPrepodavatel (), editPrepodavatel ().

Роли - класс со свойствами помогающими определить набор выполняемых функций пользователя. Реализует методы: setRole (), deleteRole ().

Сотрудник, наследует свойства и методы класса Пользователь и имеет свои собственные методы addSotrudnik (), editSotrudnik (), позволяющие редактировать и добавлять сотрудников. Имеет свойства: Отдел, Должность.

Пользователь, свойствами которого являются: Фамилия, Имя, Отчество, Дата рождения, Логин и Пароль, имеет методы getPolzoavtel (), setPolzovatel, delPolzovatel (), editPolzovatel (), позволяющие извлекать информацию о пользователе, добавлять информацию, удалять и редактировать.

Литература, свойствами которого являются: Автор, Название, Год, Код книги, Тематика и Страницы, имеет методы getBook (), editBook (), addBook (), countBook (), checkBook (), delBook (). Методы позволяют добавлять информацию о книге, редактировать удалять, проверять на непригодность к дальнейшему использованию, подсчета книг.

Методические указания, наследует свойства и методы класса Литература. Имеет собственные свойства: Кафедра, ВУЗ, Дисциплина. Реализует методы: добавления и редактирования.

Журнал, наследует свойства и методы класса Литература. Имеет собственные свойства: Номер выпуска и Месяц выпуска. Реализует методы добавления и редактирования.

Статистика. Имеет свойства: Подсчет, Основной курс и Основной месяц. Реализует методы позволяющие определять месяц с наибольшей частотой использования книги (getPrimaryMonthQ), курс, на котором чаще всего используется литература (getPrimaryKurs ()), а так же определять коэффициент частоты использования книги (getCount ()).

Формуляр. Является классом, реализующим методы проверки пени (checkPenya ()) и заполнения формуляра (fillFormular). Имеет свойства: Дата выдачи, На срок, Пеня, Состояние книги.

Подразделение. Является классом, реализующим метод получения сведений о количестве книг в данном разделе (getKolichestvo ()). Имеет свойства: Название отдела, Количество.

7. Сравнение объектно-ориентированной модели и ER-модели

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

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

Еще один крупный недостаток реляционных баз данных это высокая трудоемкость манипулирования информацией и изменения связей.

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

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

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

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

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

В РСУБД связи управляются пользователем, создающим внешние ключи. Затем для обнаружения связей динамически во время выполнения система просматривает две (или больше) таблицы, сравнивая внешние ключи до достижения соответствия. Этот процесс, называемый объединением (j°^m) > является слабой стороной реляционной технологии. Более двух или трех уровней объединений сигнал, чтобы искать лучшее решение. В ООСУБД пользователь просто объявляет связь, и СУБД автоматически генерирует методы управления, динамически создавая, удаляя и пересекая связи. Ссылки при этом прямые, нет необходимости в просмотре и сравнении или даже поиске индекса, который может сильно сказаться на производительности. Таким образом, применение объектной модели предпочтительнее для баз данных с большим количеством сложных связей [5].

В отличие от реляционных, ООСУБД полностью поддерживают объектно-ориентированные языки программирования.

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

И, наконец, ООСУБД подходят для организации распределенных вычислений.

Одна из основных проблем ООМД - отсутствие в ней стандартного универсального метода доступа к данным.

Поэтому система указателей в ООСУБД сложна; ООСУБД рассматриваются как возврат к устаревшим системам указателей, которые использовались в иерархических и сетевых моделях и на сегодняшний день устарели.

Не в пользу ООМД говорит и высокую стоимость изучения ООСУБД и недостаточную совместимость между различными ООСУБД, затрудняющую переход с одного программного обеспечения на другое.

Несмотря на рассмотренные недостатки реляционных баз данных, они обладают рядом достоинств:

разделение таблиц разными программами;

развернутый "код возврата" при ошибках;

высокая скорость обработки запросов;

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

Выводы

В данной работе в рамках информационного обеспечения задачи "Учет фонда библиотеки" АИС "Библиотека", была разработана схема данных на основе реляционной и объектно-ориентированной моделей данных. Так же в данной работе был проведен сравнительный анализ реляционного и объектно-ориентированного подхода к моделированию данных.

В результате анализы было определено явные преимущества использования реляционного подхода при разработке данной системы. Учитывая недостаточную надежность ООСУБД и отсутствие единых стандартов между ООСУБД было принято решение об использовании РСУБД при решении задачи учета фонда библиотеки.

Перечень ссылок

1. Томас М. Конноли, Каролин Е. Бегг Базы данных. Проектирование, реализация, сопровождение. Теория и практика. - Москва-Санкт-Петербург - Киев: 2001. - 1111с.

2. Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление. - СПб.: БХВ-Петербург, 2004. - 1040 с.

3. Мюллер Р. Базы данных и UML. Проектирование - М.: Лори, 2002. - 476 с.

4. Т. Карпова. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2001. - 304 с: ил.

5. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений. - СПб.: КОРОНА принт, 2000. - 416 с.

Размещено на Allbest.ru