Социальная сеть

Размещено на http://www.allbest.ru/

Оглавление

Введение

Глава 1. Описание задачи в предметной области

1.1 Назначение системы

1.2 Описание аналогов

1.2.1 Учебный портал ECONOMIST Факультета Экономики Российского Университета Дружбы Народов

1.3 Постановка задачи

Глава 2. Разработка функциональной модели системы

2.1 Методологии моделирования предметной области

2.2 Операционные диаграммы автоматизируемых процессов

2.2.1 Композиционная диаграмма системы

2.2.2 Диаграмма функциональной декомпозиции

2.2.3 Диаграмма декомпозиции функции «определение уровня доступа в систему»

2.2.4 Диаграмма декомпозиции функции «редактирование профиля студента»

На рисунке 8 изображена диаграмма декомпозиции функции «редактирование профиля студента»

2.2.5 Диаграмма декомпозиции функции «управление профилем преподавателя»

2.2.6 Диаграмма функционального блока «сообщества»

Глава 3. Разработка базы данных системы

3.1 Инфологическое проектирование. Определение предметной области

3.2 Логическое проектирование реляционной БД

3.2.1 Преобразование ER-диаграммы в схему базы данных

3.2.2 Составление реляционных отношений

3.2.3 Нормализация полученных отношений

3.2.4 Определение дополнительных ограничений целостности

3.2.5 Описание групп пользователей и прав доступа

3.3 Выбор СУБД

3.3.1 Microsoft SQL Server

3.3.2 Oracle

3.3.3 PostgreSQL

3.3.4 MySQL

3.3.5 Сравнительный анализ рассматриваемых СУБД

3.4 Реализация проекта базы данных

Глава 4. Разработка алгоритмов работы системы

4.1 Схемы переходов между страницами

4.2 Разработка алгоритмов

4.2.1 Алгоритм входа в систему

4.2.2 Алгоритм регистрации первого этапа

4.2.3 Алгоритм регистрации второго этапа

4.2.4 Алгоритм РМ «Администратор»

4.2.5 Алгоритм РМ «Управляющий»

4.2.6 Алгоритм РМ «Обычный пользователь»

4.2.7 Алгоритм РМ «Преподаватель»

4.2.8 Алгоритм РМ «Студент»

4.3 Выбор средства реализации

4.4 Описание структур кода. Особенности программирования на Grails

Заключение

Список литературы

Приложение



Введение

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

В прогрессивной тенденции развития современного информационного общества важную роль занимают такие интернет проекты как социальные сети. Социальная сеть - это особый вид интернет ресурсов, на которых люди могут размещать информацию о себе, общаться друг с другом и обмениваться различными данными. С развитием технологий Web 2.0 социальные сети обрели осязаемую основу в виде порталов и веб-сервисов.

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

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

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

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



Глава 1. Описание задачи в предметной области

моделирование декомпозиция диаграмма пользователь

1.1 Назначение системы

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

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

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

Такую структуру можно было бы организовать и на уже существующих открытых сервисах, таких как livejournal.com или vkontakte.ru, но такой способ является слишком трудоёмким и не сможет охватить полностью все требования к студенческому порталу. Поэтому необходимо разработать автоматизированную систему, настроенную именно под учебный процесс. Это повысит удобство сопровождения этого процесса, позволит ускорить обмен информации между студентами и преподавателями и повысит качество получаемых студентами знаний.

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

1.2 Описание аналогов

1.2.1 Учебный портал ECONOMIST Факультета Экономики Российского Университета Дружбы Народов

Адрес портала: http://economist.rudn.ru/

На рисунке 1 представлена главная страница учебного портала студентов экономического факультета университета РУДН. Портал позволяет регистрироваться. Имеется и раздел со свободным доступом, который несет общую познавательную информацию о факультете.

Главная страница интереса не представляет, так как станицы статичны, состоят из HTML (от англ. HyperText Markup Language -- «язык разметки гипертекста») кода с подключением CSS (англ. Cascading Style Sheets -- каскадные таблицы стилей) стилей и JavaScript -- прототипно-ориентированный сценарный язык программирования. Возможность создания страниц без динамических данных достаточно просто реализована в CMS Sapid (англ. Content management system и XML Sapiens Demonstrator -- система управления контентом немодульного типа, написанная на языке PHP).

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

Рисунок 1 - Главная страница «Учебного портала ECONOMIST Факультета Экономики Российского Университета Дружбы Народов» до Авторизации

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

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

Рисунок 2 -Главная страница «Учебного портала ECONOMIST Факультета Экономики Российского Университета Дружбы Народов» после Авторизации

Рисунок 3 -Страница Объявлений «Учебного портала ECONOMIST Факультета Экономики Российского Университета Дружбы Народов».

Студенты РУДН могут зайти на страницу каждой дисциплины, присутствующей в его курсе обучения (рисунок 3). Здесь они могут узнать программу курса, домашние задания, рейтинги студентов, посмотреть список преподавателей и скачать учебные материалы.

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

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

Рисунок 4 - Форум «Учебного портала ECONOMIST Факультета Экономики Российского Университета Дружбы Народов

На портале РУДН присутствует студенческий форум, на нем есть раздел для гостей (рисунок 4). В остальных разделах гости могут только просматривать темы. Добавлять и комментировать темы могут только зарегистрированные пользователи.

Имеется фотогалерея факультета, где зарегистрированные пользователи могут выкладывать фотографии.

1.3 Постановка задачи

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

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

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

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

- Login (Логин - имя для аутентификации);

- Password (Пароль - секретный ключ для аутентификации, идёт в паре с Login);

- Email (Адрес почтового ящика - используется для смены пароля и для подтверждения регистрации);

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

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

Каждый студент в процессе учебы может получать рейтинг. Рейтинг - целая величина, отображающая уровень знаний студента. Начислять единицы рейтинга может преподаватель за успешно выполненные задачи. Каждый зарегистрированный пользователь может редактировать свой профиль. «Управляющие» и «администраторы» могут редактировать и удалять профили любых пользователей.

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

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

- Создание и управление профилями пользователей;

- Создание и управление сообществами.

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

- РМ «Преподаватель»;

- РМ «Студент»;

- РМ «Обычный пользователь»;

- РМ «Управляющий»;

- РМ «Администратор».

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

1. РМ "Преподаватель":

- Аутентификация;

- Редактирование личной страницы;

- Действия над сообществами (вступить, покинуть, создать, редактировать);

- Публикация тем (постов) и комментариев в сообществах;

- Присуждение рейтинга студентам.

2. РМ "Студент":

- Аутентификация;

- Редактирование личной страницы;

- Действия над сообществами (вступить, покинуть, создать, редактировать);

- Публикация тем (постов) и комментариев в сообществах.

3. РМ "Обычный пользователь":

- Аутентификация;

- Редактирование личной страницы;

- Действия над сообществами (вступить, покинуть);

- Публикация тем (постов) и комментариев в сообществах.

4. РМ "Управляющий":

- Аутентификация;

- Редактирование личных страниц пользователей;

- Действия над сообществами (вступить, покинуть, создать, редактировать, удалить);

- Публикация тем (постов) и комментариев в сообществах;

- Управление рейтингом пользователей.

5. РМ "Администратор":

- Аутентификация;

- Редактирование личных страниц пользователей ;

- Действия над сообществами (вступить, покинуть, создать, редактировать, удалить);

- Публикация тем (постов) и комментариев в сообществах;

- Управление рейтингом пользователей.



Глава 2. Разработка функциональной модели системы

2.1 Методологии моделирования предметной области

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

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

Для отображения структурного аспекта моделей предметных областей в основном используются графические методы, которые должны гарантировать представление информации о компонентах системы. Главное требование к графическим методам документирования -- простота. Графические методы должны обеспечивать возможность структурной декомпозиции спецификаций системы с максимальной степенью детализации и согласований описаний на смежных уровнях декомпозиции. IDEF0 (Function Modeling -- методология функционального моделирования и графическая нотация) является наиболее распространенным стандартом построения таких моделей.

С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков -- в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы» [1].

История IDEF0

«Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique).Несколько лет назад в России небольшим тиражом вышла одноименная книга, посвященная описанию основных принципов построения SADT-диаграмм. Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках “аналитик-специалист”. Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменения, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом По Стандартам и Технологиям США (NIST)» [2].

Основные элементы IDEF0

«Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:

Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы.

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

1) Верхняя сторона имеет значение “Управление” (Control);

2) Левая сторона имеет значение “Вход” (Input);

3) Правая сторона имеет значение “Выход” (Output);

4) Нижняя сторона имеет значение “Механизм” (Mechanism).

Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

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

Моделирование процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. Для моделирования процессов разрабатываемой автоматизированной системы будет использоваться case-средство BPwin, которое поддерживает методологию функционального моделирования (IDEF0)» [3] . 

2.2 Операционные диаграммы автоматизируемых процессов

2.2.1 Композиционная диаграмма системы

На рисунке 5 изображена композиционная диаграмма системы.

Рисунок 5 - Композиционная диаграмма системы

2.2.2 Диаграмма функциональной декомпозиции

На рисунке 6 изображена диаграмма функциональной декомпозиции.

Рисунок 6 - диаграмма функциональной декомпозиции

2.2.3 Диаграмма декомпозиции функции «определение уровня доступа в систему»

На рисунке 7 изображена диаграмма декомпозиции функции «определение уровня доступа в систему».



Рисунок 7 - Диаграмма декомпозиции фукнции «определения уровня доступа в систему»

2.2.4 Диаграмма декомпозиции функции «редактирование профиля студента»

На рисунке 8 изображена диаграмма декомпозиции функции «редактирование профиля студента».

Рисунок 8 - Диаграмма декомпозиции функции «редактирование профиля студента»

2.2.5 Диаграмма декомпозиции функции «управление профилем преподавателя»

На рисунке 9 изображена диаграмма декомпозиции функции «управление профилем преподавателя».



Рисунок 9 - Диаграмма декомпозиции функции «управление профилем преподавателя»

2.2.6 Диаграмма функционального блока «сообщества»

На рисунке 10 изображена диаграмма функционального блока «сообщества».

Рисунок 10 - Диаграмма функционального блока «сообщества»



Глава 3. Разработка базы данных системы

3.1 Инфологическое проектирование. Определение предметной области

«Проектирование базы данных (БД) - одна из наиболее сложных и ответственных задач, связанных с созданием автоматизированных систем. Взаимодействие конечных пользователей с БД обычно осуществляется с помощью интерфейсного приложения, входящего в состав автоматизированной системы.

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

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

Существуют разные подходы к инфологическому проектированию. Основные из них это:

Функциональный подход к проектированию БД.

Этот метод реализует принцип "от задач" и применяется в том случае, когда известны функции некоторой группы лиц и/или комплекса задач, для обслуживания информационных потребностей которых создаётся рассматриваемая БД.

Предметный подход к проектированию БД.

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

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

Метод "сущность-связь" (Entity-Relation, ER-method) был разработан в 1976 г. П.Ченом (Chen P.P.). Он является комбинацией двух предыдущих и обладает достоинствами обоих.

ER-метод является наиболее распространённым методом проектирования БД, поэтому именно этот метод используется в данной дипломной работе» [4].

Для создания ER-модели необходимо выделить сущности предметной области:

1. Университет:

название

аббревиатура

контактная информация

описание

2. Факультет:

название

аббревиатура

контактная информация

описание

3. Кафедра:

название

аббревиатура

контактная информация

описание

4. Группа:

название

аббревиатура

контактная информация

описание

5. Сообщество:

название

описание

тип

6. Профиль сообщества:

участники

посты

7. Пост:

наименование

содержание

комментарии

8. Комментарий:

содержание

пост-родитель

9. Пользователь:

логин

пароль

электронная почта

контакты

роль

ФИО

дата рождения

группа

кафедра

направление деятельности

10. Профиль пользователя:

личная информация (о себе)

рейтинг

фото

11. Студент:

ФИО

номер группы

дата рождения

логин

пароль

электронная почта

контакты

12. Преподаватель:

ФИО

направление деятельности

дата рождения

логин

пароль

электронная почта

контакты

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

- Каждый преподаватель принадлежит к определенному учебному заведению, факультету, кафедре.

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

- В каждом учебном заведении может быть несколько факультетов.

- На каждом факультете может числиться несколько кафедр.

- На каждой кафедре может числиться несколько групп.

- К каждой кафедре могут быть прикреплены несколько преподавателей.

- В каждой группе числится несколько студентов.

ER-диаграмма предметной области представлена на рисунке 11.

Рисунок 11 - ER-диаграмма предметной области

3.2 Логическое проектирование реляционной БД

«На этапе логического проектирования инфологическая модель ПО, представленная в виде ER-диаграммы, преобразуется в логическую (концептуальную схему БД). Результатом выполнения этапа логического проектирования являются схемы БД концептуального и внешнего уровней архитектуры, составленные на языке определения данных (DDL, Data Definition Language) выбранной СУБД (Система управления базами данных)»

3.2.1 Преобразование ER-диаграммы в схему базы данных

На рисунке 12 представлена схема реляционной базы данных, полученная из ER-диаграммы.



Рисунок 12 - Схема реляционной базы данных

3.2.2 Составление реляционных отношений

Таблица 1 - Схема отношения УЧЕБНОЕ ОТДЕЛЕНИЕ (STUDYING DIVISION)

Содержание поля	Имя поля	Тип, длина	Примечания
Название	sd_name	С(80)	обязательное поле
Аббревиатура	sd_short_name	C(8)	обязательное поле
Контактная информация	sd_contact_info	C(40)	необязательное многозначное поле
Описание	sd_describe	C(300)	необязательное поле
Учебное отделение_id	sd_id	N(4)	суррогатный первичный ключ

Таблица 2 - Схема отношения СООБЩЕСТВО (COMMUNITY)

Содержание поля	Имя поля	Тип, длина	Примечания
Название	c_name	С(80)	обязательное поле
Описание	c_describe	C(300)	обязательное поле
Тип	c_type	C(16)	обязательное поле
Учебное отделение_id	c_division	N(4)	внешний ключ (к STUDYING DIVISION)
Сообщество_id	c_id	N(6)	суррогатный первичный ключ

Таблица 3 - Схема отношения ПРОФИЛЬ СООБЩЕСТВА (COMMUNITY PROFILE)

Содержание поля	Имя поля	Тип, длина	Примечания
Участники	cp_member	С(80)	обязательное поле
Сообщество_id	cp_id	N(6)	внешний ключ (к COMMUNITY)



Таблица 4 - Схема отношения ПОСТ (POST)

Содержание поля	Имя поля	Тип, длина	Примечания
Наименование	p_name	С(80)	обязательное поле
Содержание	p_content	C(300)	обязательное поле
Комментарии_id	p_comment	N(6)	внешний ключ (к COMMENT)
Участник сообщества_id	p_member	N(6)	внешний ключ (к MEMBER OF COMMUNITY)
Сообщество_id	p_id	N(6)	внешний ключ (к COMMUNITY)
Пост_id	p_id	N(6)	суррогатный первичный ключ

Таблица 5 - Схема отношения КОММЕНТАРИЙ (COMMENT)

Содержание поля	Имя поля	Тип, длина	Примечания
Содержание	com_content	С(200)	обязательное поле
Пост_id	com_post	N(6)	внешний ключ (к POST)
Комментарий_id	com_id	N(6)	суррогатный первичный ключ

Таблица 6 - Схема отношения ПОЛЬЗОВАТЕЛЬ (USER)

Содержание поля	Имя поля	Тип, длина	Примечания
Логин	u_login	С(20)	обязательное уникальное поле
Пароль	u_password	C(16)	обязательное поле
Электронная почта	u_e-mail	C(40)	обязательное уникальное поле
Контакты	u_conacts	C(300)	необязательное многозначное поле
Роль	u_role	C(30)	обязательное поле
ФИО	u_fio	C(70)	обязательное поле
Дата рождения	u_birthday	N(8)	необязательное поле
Группа	u_group	N(4)	необязательное поле
Кафедра	u_department	N(4)	необязательное поле
Направление деятельности	u_work	C(20)	необязательное поле
Пользователь_id	u_id	N(6)	суррогатный первичный ключ

Таблица 7 - Схема отношения УЧАСТНИК СООБЩЕСТВА

Содержание поля	Имя поля	Тип, длина	Примечания
Пользователь_id	mc_user	N(6)	внешний ключ (к USER)
Cообщество_id	mc_community	N(6)	внешний ключ (к COMMUNITY)

Таблица 8 - Схема отношения ПРОФИЛЬ ПОЛЬЗОВАТЕЛЯ (USER PROFILE)

Содержание поля	Имя поля	Тип, длина	Примечания
Личная информация	up_info	С(300)	необязательное поле
Рейтинг	up_rating	N(3)	необязательное поле
Фото	up_foto	C(20)	необязательное поле
Пользователь_id	up_user	N(6)	внешний ключ (к USER)

Таблица 9 - Схема отношения ДИСЦИПЛИНА (DISCIPLINE)

Содержание поля	Имя поля	Тип, длина	Примечания
Название	dis_name	С(20)	обязательное поле
Дисциплина_id	dis_id	N(5)	суррогатный первичный ключ

Таблица 10 - Схема отношения ПРЕПОДАВАТЕЛЬ ДИСЦИПЛИНЫ (TEACHER DISCIPLINE)

Содержание поля	Имя поля	Тип, длина	Примечания
Дисциплина_id	td_discipline	N(5)	внешний ключ (к DISCIPLINE)
Преподаватель_id	td_teacher	N(6)	внешний ключ (к USER)

Таблица 11 - Схема отношения ЧЛЕН УЧЕБНОГО ОТДЕЛЕНИЯ (SD_MEMBER)

Содержание поля	Имя поля	Тип, длина	Примечания
Учебное отделение_id	sdm_division	N(4)	внешний ключ (к STUDYING DIVISION)
Пользователь_id	sdm_user	N(4)	внешний ключ (к USER )

«После составления концептуальной (логической) схемы БД необходимо проверить её на отсутствие аномалий модификации данных. Эти аномалии обусловлены ограниченностью структуры РМД (Реляционная модель данных). Различают три вида аномалий: аномалии обновления, удаления и добавления. Аномалия обновления может возникнуть в том случае, когда информация дублируется. Другие аномалии возникают тогда, когда две и более сущности объединены в одно отношение.

В рамках реляционной модели данных Э.Ф. Коддом был разработан аппарат нормализации отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме. Нормализация схемы отношения выполняется путём декомпозиции схемы» [4].

3.2.3 Нормализация полученных отношений

Таблица 12 - Схема отношения УЧЕБНОЕ ОТДЕЛЕНИЕ

Содержание поля	Имя поля	Тип, длина	Примечания
Аббревиатура	sd_short_name	C(8)	обязательное поле
Описание	sd_describe	C(300)	необязательное поле
Название	sd_name	С(80)	обязательное поле
Учебное отделение_id	sd_id	N(4)	суррогатный первичный ключ

Таблица 13 - Схема отношения КОНТАКТЫ (CONTACTS)

Содержание поля	Имя поля	Тип, длина	Примечания
Контактная информация	cont_contact_info	C(40)	необязательное многозначное поле
Учебное отделение_id	cont_division	N(4)	внешний ключ (к STUDYING DIVISION)

Таблица 14 - Схема отношения СООБЩЕСТВО (COMMUNITY)

Содержание поля	Имя поля	Тип, длина	Примечания
Название	c_name	С(80)	обязательное поле
Описание	c_describe	C(300)	обязательное поле
Тип	c_type	C(16)	обязательное поле
Учебное отделение_id	c_division	N(4)	внешний ключ (к STUDYING DIVISION)
Сообщество_id	c_id	N(6)	суррогатный первичный ключ

Таблица 15 - Схема отношения ПРОФИЛЬ СООБЩЕСТВА(COMMUNITY PROFILE)

Содержание поля	Имя поля	Тип, длина	Примечания
Участники	cp_member	С(80)	обязательное поле
Сообщество_id	cp_id	N(6)	внешний ключ (к COMMUNITY)

Таблица 16 - Схема отношения ПОСТ (POST)

Содержание поля	Имя поля	Тип, длина	Примечания
Наименование	p_name	С(80)	обязательное поле
Содержание	p_content	C(300)	обязательное поле
Комментарии_id	p_comment	N(6)	внешний ключ (к COMMENT)
Участник сообщества_id	p_member	N(6)	внешний ключ (к MEMBER OF COMMUNITY)
Сообщество_id	p_c_id	N(6)	внешний ключ (к COMMUNITY)
Пост_id	p_id	N(6)	суррогатный первичный ключ

Таблица 17 - Схема отношения КОММЕНТАРИЙ (COMMENT)

Содержание поля	Имя поля	Тип, длина	Примечания
Содержание	com_content	С(200)	обязательное поле
Пост_id	com_post	N(6)	внешний ключ (к POST)
Комментарий_id	com_id	N(6)	суррогатный первичный ключ

Таблица 18 - Схема отношения ПОЛЬЗОВАТЕЛЬ (USER)

Содержание поля	Имя поля	Тип, длина	Примечания
Пароль	u_password	C(16)	обязательное поле
Логин	u_login	С(20)	обязательное уникальное поле
Электронная почта	u_e_mail	C(40)	обязательное уникальное поле
Роль	u_role	C(30)	обязательное поле
ФИО	u_fio	C(70)	обязательное поле
Дата рождения	u_birthday	N(8)	необязательное поле
Группа	u_group	N(4)	необязательное поле
Кафедра	u_department	N(4)	необязательное поле
Направление деятельности	u_work	C(20)	необязательное поле
Пользователь_id	u_id	N(6)	суррогатный первичный ключ

Таблица 19 - Схема отношения КОНТАКТЫ ПОЛЬЗОВАТЕЛЯ (USER CONTACTS)

Содержание поля	Имя поля	Тип, длина	Примечания
Контакты	uc_conacts	C(300)	необязательное многозначное поле
Пользователь_id	uc_user	N(6)	внешний ключ (к USER)



Таблица 20 - Схема отношения УЧАСТНИК СООБЩЕСТВА (MEMBER OF COMMUNITY)

Содержание поля	Имя поля	Тип, длина	Примечания
Пользователь_id	mc_user	N(6)	внешний ключ (к USER)
Сообщество_id	mc_community	N(6)	внешний ключ (к COMMUNITY)
Участ_сообщ_id	mc_id	N(6)	суррогатный первичный ключ

Таблица 21 - Схема отношения ПРОФИЛЬ ПОЛЬЗОВАТЕЛЯ (USER PROFILE)

Содержание поля	Имя поля	Тип, длина	Примечания
Личная информация	up_info	С(300)	необязательное поле
Настроение (статус)	up_status	C(20)	необязательное поле
Фото	up_foto	C(20)	необязательное поле
Пользователь_id	up_id	N(6)	внешний ключ (к USER)

Таблица 22 - Схема отношения РЕЙТИНГ ПОЛЬЗОВАТЕЛЯ (USER RATING)

Содержание поля	Имя поля	Тип, длина	Примечания
Рейтинг	upr_rating	N(3)	необязательное поле
Пользователь_id	upr_user	N(6)	внешний ключ (к USER PROFILE)

Таблица 23 - Схема отношения ДИСЦИПЛИНА (DISCIPLINE)

Содержание поля	Имя поля	Тип, длина	Примечания
Название	dis_name	С(20)	обязательное поле
Учебный курс_id	dis_course	N(5)	внешний ключ (к TRAINING COURSE)
Дисциплина_id	dis_id	N(5)	суррогатный первичный ключ

Таблица 24 - Схема отношения ПРЕПОДАВАТЕЛЬ ДИСЦИПЛИНЫ (TEACHER DISCIPLINE)

Содержание поля	Имя поля	Тип, длина	Примечания
Дисциплина_id	td_discipline	N(5)	внешний ключ (к DISCIPLINE)
Преподаватель_id	td_teacher	N(6)	внешний ключ (к USER)

Таблица 25 - Схема отношения ЧЛЕН УЧЕБНОГО ОТДЕЛЕНИЯ (SD_MEMBER)

Содержание поля	Имя поля	Тип, длина	Примечания
Учебное отделение_id	sdm_division	N(4)	внешний ключ (к STUDYING DIVISION)
Пользователь_id	sdm_user	N(4)	внешний ключ (к USER )

3.2.4 Определение дополнительных ограничений целостности

1. Атрибут ТИП отношения СООБЩЕСТВО может принимать одно из следующих значений "научное", "университет","факультет", "кафедра", "группа", "по интересам".

2. Атрибут ПАРОЛЬ отношения ПОЛЬЗОВАТЕЛЬ должен включать в себя минимум 6 знаков.

3. Атрибут РОЛЬ отношения ПОЛЬЗОВАТЕЛЬ может принимать одно из следующих значений "преподаватель", "студент", "обычный пользователь" , "управляющий", "администратор".

4. Атрибут РЕЙТИНГ отношения РЕЙТИНГ ПОЛЬЗОВАТЕЛЯ не должен превышать значения "100".

Все эти ограничения выполняются программно.

Окончательная схема базы данных представлена на рисунке 13.



Рисунок 13 - Окончательная схема базы данных автоматизированной системы

3.2.5 Описание групп пользователей и прав доступа

S - чтение данных (select); I - добавление данных (insert); U - модификация данных (update); D - удаление данных(delete).

Таблица 26 - Описание групп пользователей и прав доступа

Таблицы	Группы пользователей (роли)
	Администратор	Руководитель учебного заведения	Обычный пользователь	Преподаватель	Студент
сообщество	SUID	SIUD	S	SIUD	SIUD
пост	SUID	SIUD	SIUD	SIUD	SIUD
комментарий	SUID	SIUD	SIUD	SIUD	SIUD
профиль сообщества	SUID	S	S	S	S
учебное отделение	SUID	S	S	S	S
название	SUID	S	S	S	S
контакты	SUID	S	S	S	S
член учебного отделения	SUID	S	S	S	S
пользователь	SUID	S	S	S	S
участник сообщества	SUID	S	S	S	S
почта пользователя	SUID
логин пользователя	SUID
контакты пользователя	SUID	S	S	S	S
рейтинг пользователя	SUID	S	S	S	S
профиль пользователя	SUID	S	S	S	S
дисциплина	SUID	S		S	S

3.3 Выбор СУБД

«Выбор СУБД является одним из важнейших моментов в разработке проекта БД, так как он принципиальным образом влияет на весь процесс проектирования БД и реализации системы.

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

тип модели данных, которую поддерживает данная СУБД, адекватность модели данных структуре рассматриваемой предметной области;

характеристики производительности СУБД;

запас функциональных возможностей для дальнейшего развития системы;

степень оснащенности СУБД инструментарием для персонала администрирования данными;

удобство и надежность СУБД в эксплуатации;

стоимость СУБД и дополнительного программного обеспечения» [5].

На сегодня известно большое число различных серверов баз данных SQL (англ. Structured Query Language -- «язык структурированных запросов»). Рассмотрим более подробно следующие четыре ведущих серверных СУБД -Microsoft SQL Server, Oracle, PostgreSQL и MySQL, проведем их сравнение и выберем одну из них.

3.3.1 Microsoft SQL Server

«Система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов -- Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия» [6].

3.3.2 Oracle

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

ORACLE удовлетворяет промышленно принятым стандартам по языку доступа к данным, операционным системам, интерфейсам с пользователем и сетевым протоколам. Работает под Sun Solaris, Linux, Windows и других операционных систем» [7].

3.3.3 PostgreSQL

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

Существует в реализациях для множества UNIX-like платформ, включая AIX, различные BSD-системы, HP-UX, IRIX, Linux, Mac OSX, Solaris/OpenSolaris, Tru64,

QNX, а также для Windows.

PostgreSQL базируется на языке SQL и поддерживает многие из возможностей стандарта SQL:2003 (ISO/IEC 9075)

Имеет BSD лицензию, существует так же коммерческая лицензия (которая предполагает техническую поддержку).

Поддерживает транзакции, подзапросы, триггеры, представления, внешние ключи, пользовательские типы и их наследование. Поддержка языка запросов PL/pgSQL, который очень похож на PL/SQL Oracle» [8].

3.3.4 MySQL

«СУБД MySQL является одной из самых известных, надежных и быстрых из всего семейства существующих СУБД. Исходные коды скомпилированы под множество платформ.

Разработку и поддержку MySQL осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой Sun Microsystems, которая ранее приобрела шведскую компанию MySQL AB. Продукт распространяется как под GNU General Public License, так и под собственной коммерческой лицензией.

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