|
«Genway - больше, чем
семья»
|
«Moederevo»
|
«MyHeritage»
|
|
Приятный дизайн
|
да
|
да
|
да
|
|
Интуитивно понятный
интерфейс
|
нет
|
да
|
да
|
|
Графический редактор
|
да
|
да
|
да
|
|
Контроль приватности данных
|
нет
|
нет
|
да
|
|
Возможность импорта и
экспорта данных
|
нет
|
нет
|
нет
|
|
Возможность печати дерева
|
нет
|
да
|
да
|
Подводя итог проведенному анализу существующих в настоящее время веб-сервисов
для построения генеалогических деревьев можно сказать, что одним из крупнейших
в сети интернет генеалогическим ресурсом является сервис «MyHeritage».
Существенным недостатком данного сервиса является ограниченные возможности в
бесплатном режиме (ограниченное количество родственников в дереве, ограниченное
количество доступного места для хранения мультимедийных данных). Ни один из
рассмотренных ресурсов не поддерживает импорт и экспорт данных, то есть не
предоставляет пользователю возможности сохранить свои наработки вне сервиса.
Создаваемый сервис разрабатывается с целью устранения найденных
недостатков, не забывая про имеющиеся достоинства перечисленных сервисов.
1.4
Выбранные программные средства
Для реализации сервиса основным языком разработки выбран язык Python (см.
[6]).
Язык Python - это стабильный и распространённый высокоуровневый язык
программирования с акцентом на производительность разработчика и читаемость
кода; язык общего назначения с широким спектром возможного применения, выразительным
синтаксисом и приемлемой производительностью. Недостаток языка - относительно
невысокая скорость выполнения программ - компенсируется уменьшением времени
разработки программы. В среднем, программа, написанная на Python, в 2-4 раза
компактнее, чем её аналог на C++ или Java.
В качестве каркаса приложения выбран фреймворк Django (см. [7]). Django
(Джанго) - свободный фреймворк для веб-приложений на языке Python.
Для хранения данных проекта решено использовать два типа СУБД:
реляционную и нереляционную базы данных (см. [8]). Такой выбор основан на
необходимости хранения разнородных данных. Реляционная база данных хранит
данные, удобно представимые в табличном виде: данные о пользователях, данные о
географическом расположении пользователей, о правах доступа, о мультимедийных
данных. Для хранения данных о генеалогических деревьях используется
документо-ориентированная база данных.
1.4.1
Выбор реляционной базы данных
В качестве реляционных баз данных рассматривались две наиболее популярные
реляционные базы данных с открытым исходным кодом: MySQL и PostgreSQL.
Каждая база имеет свои особенности и отличия. Если необходимо быстрое
хранилище для простых запросов с минимальной настройкой, лучше выбирать MySQL.
Если необходимо надежное хранилище для большого объема данных с возможностью
расширения, репликации, полностью соответствующее современным стандартам языка
SQL (см. [9]), рекомендуется использовать PostgreSQL.хорошо использовать для
простых запросов с отключенными транзакциями, в то время как PostgreSQL может
поддерживать более серьезную нагрузку и сложные запросы параллельно с записью в
базу данных. Ниша, которую занимает PostgreSQL, более широкая, и потенциал у
PostgreSQL выше. Ниша MySQL скромнее, MySQL оправдывает себя как хранилище для
некритичных по нагрузке и производительности баз данных.
Основное преимущество PostgreSQL - безопасное и защищённое хранилище
данных. В качестве полнофункциональной, свободной реляционной БД (RDBMS),
PostgreSQL обладает многими характеристиками, спроектированными для поддержки
критически-важных приложений с большим потоком транзакций.
В силу всего вышеперечисленного, в качестве реляционной базы данных
решено использовать PostgreSQL (см. [10]).
1.4.2
Выбор нереляционной базы данных
В качестве нереляционной базы данных выбрана база CouchDB (см. [11]).
Основные характеристики этой базы:
- данные сохраняются не в строках и колонках, а в виде
JSON-подобных документов, моделью которых является не таблицы, а деревья;
- целостность базы данных обеспечивается исключительно на уровне
отдельных записей (но не на уровне связей между ними);
- для построения индексов и выполнения запросов используются
функции представления;
- функции-валидаторы, функции-представления, функции-фильтры
сохраняются в текстовом виде в самой базе данных;
- каждой базе данных в системе CouchDB соответствует
единственное В-дерево; каждое B-дерево хранится в виде отдельного файла на
диске;
- поддерживается вертикальная масштабируемость, что означает
поддержку как огромных кластеров, так и портативных устройств.
Для манипуляций с данными используется JavaScript -
объектно-ориентированный скриптовый язык программирования (см. [12]).
2.Описание базы данных
2.1
Реляционная база данных
Спроектирована реляционная база данных, состоящая из десяти таблиц (см.
[13]).
2.1.1
Концептуальная схема базы данных
Концептуальная схема базы данных, отображающая взаимосвязи между
таблицами, представлена на рис. 2.1.:
Рис. 2.1. Концептуальная схема базы данных
2.1.2
Описание назначения таблиц
Приведем описание таблиц:
- user - таблица хранит данные о пользователях (табл. 2.1.);
- region - таблица с названиями регионов (пример: Новосибирская
область) (табл. 2.2.);
- region_area - таблица с названиями районов региона, пример:
Коченевский район (Новосибирская область, Коченевский район) (табл. 2.3.);
- city - таблица с названиями городов/сел/поселков,
принадлежащих району региона, пример: с. Прокудское (Новосибирская область,
Коченевский район, с. Прокудское) (табл. 2.4.);
- city_area - таблица с названиями районов города, пример:
Ленинский (Новосибирск, Ленинский район) (табл. 2.5.);
- media - таблица для хранения информации о мультимедийных
данных (табл. 2.6.);
- photo - таблица для связи пользователей и фотографий, на
которых они отмечены (табл. 2.7.);
- privilege - таблица для хранения информации о правах
пользователей на генеалогические деревья других пользователей (табл. 2.8.);
- album - таблица для хранения информации о альбомах,
предназначенных для хранения фотографий (табл. 2.9.);
- media_to_album - таблица для хранения связей между
фотографиями и альбомами (табл. 2.10.).
С описанием структур перечисленных выше таблиц можно ознакомиться в
Приложении А.
2.2
Нереляционная база данных
2.2.1
Описание структуры документов
Нереляционная база данных будет хранить документы следующего вида:
tree = {
families: [
FAMILY_0,
...,
FAMILY_N,
],
peoples: [
PEOPLE_0,
...,
PEOPLE_N,
],
owner_id: int,
create_date: date,
update_date: date,
revision: string,
},
где для упрощения представления вынесем отдельно описание FAMILY_K и PEOPLE_K:
- FAMILY_K = {"id": int,
"hasbent": int, "wife": int, "children": list,
"parent_families": list, "child_families": list}
- PEOPLE_K = {"id": int,
"lastname": string, "name": string, "patronymic":
string, "sex": string, "birthday": date,
"deathdate": date, "parent_families": list,
"self_families": list}
2.2.2
Описание назначения полей в документе
В документе будет храниться следующая информация о дереве:
- "owner_id":
совпадает с id пользователя - создателя дерева;
- "create_date":
содержит информацию о дате создания дерева;
- "update_date":
содержит информацию о дате последнего изменения дерева;
- "revision":
хранит идентификатор текущей ревизии;
- "families":
коллекция семей, участвующих в дереве;
- "peoples":
коллекция персон, участвующих в дереве.
Описание FAMILY_K:
- "id": хранит id семьи;
- "hasbent":
хранит id персоны, которая является мужем
семьи;
- "wife":
хранит id персоны, которая является женой
семьи;
- "children":
хранит список, состоящий из id
персон, являющихся детьми семьи;
- "parent_families": хранит список, состоящий из id семей, являющихся родительскими по
отношению к мужу и жене семьи;
- "child_families": хранит список, состоящий из id семей, которые были образованы
детьми семьи.
Описание PEOPLE_K:
- "id": хранит id персоны;
- "lastname": хранит фамилию персоны;
- "name": хранит имя персоны;
- "patronymic": хранит отчество персоны;
- "sex":
хранит пол персоны;
- "birthday": хранит дату рождения персоны;
- "deathdate": хранит дату смерти персоны;
- "parent_families": хранит список, состоящий из id семей, являющихся родительскими по
отношению к персоне;
- "self_families ": хранит список, состоящий из id семей, которые были образованы
персоной.
3.Описание реализации работы с данными
3.1
Структура классов для манипуляции с данными
Для манипуляции с данными используются следующие классы:
а) class User (login, password, firstname, lastname,
patronymic, phone, email, sex, birthday, deathday, city_id, city_area_id,
address, registration_date, update_data, ip_info) - используется для записи данных в таблицу 'user';
б) class Region (title) - используется для записи данных в таблицу
'region';
в) class RegionArea (title, region_id) - используется для записи
данных в таблицу 'region_area';
г) class City (title, region_area_id) - используется для записи
данных в таблицу 'city';
д) class CityArea (title, city_id) - используется для записи данных
в таблицу 'city_area';
е) class Media (type, title, path, owner_id) - используется для записи данных в таблицу
'media';
ж) class Photo (media_id, user_id, rectangle) - используется для
записи данных в таблицу 'photo';
з) class Privilege (document_id, owner_id, user_id,
privilege) - используется для записи данных в таблицу 'privilege';
и) class Album (owner_id, avatar_id, title, create_date,
update_date) - используется для записи данных в таблицу 'album';
к) class MediaToAlbum (album_id, media_id) - используется для записи данных в таблицу 'media_to_album';
л) class DatabaseConnection(address, user, password) - используется для установки соединения с нереляционной базой данных;
м) DatabaseManager(connection, db_name) - используется для создания
запросов к нереляционной базе данных.
3.2
Разграничение прав доступа к данным
Для решения задач проекта необходимо реализовать две системы прав
доступа. Первая система прав доступа будет отвечать за разграничение прав
доступа к ресурсам сервиса, а вторая - за разграничение доступа к
пользовательским данным.
.2.1 Система прав
доступа к ресурсам сервиса
Существуют три роли пользователей:
а) незарегистрированные пользователи;
б) зарегистрированные пользователи;
в) администраторы.
Незарегистрированные пользователи имеют доступ к:
- главной странице,
- странице регистрации,
- страницам пользователей, разрешивших полный доступ к своим
данным.
Зарегистрированные пользователи имеют доступ к:
- главной странице,
- странице регистрации,
- страницам пользователей, разрешивших полный доступ к своим
данным,
- страницам пользователей, разрешивших доступ к своим данным
этому пользователю.
Администраторы имеют доступ как к вышеперечисленным данным, так и к
интерфейсу администратора.
3.2.2 Система прав
доступа к пользовательским данным
Система прав доступа к пользовательским данным базируется на трех
операциях:
а) отсутствие доступа;
б) доступ на чтение;
в) доступ на запись.
Права доступа могут быть назначены пользователю или группе пользователей.
При этом права, назначенные пользователю, имеют более высокий приоритет.
3.3
Вычисление степеней родства
Степени родства между персонами в одном генеалогическом дереве должны
определяться в двух случаях:
а) определение кровности родства между двумя персонами в одном
генеалогическом дереве;
б) определение в дереве всех персон с заданным типом родственной
связи для некоторой выбранной персоны.
Задача определения кровного или некровного родства между двумя персонами
в дереве была решена поиском пути, в котором все родственники между этими
персонами являются кровными друг другу. Если такой путь существует, то
родственники являются кровными. Если такой путь отсутствует, родство является
некровным.
Определение в одном дереве всех персон с заданным типом родственной связи
для некоторой выбранной персоны реализуется по набору существующих названий
отношений между родственниками. Для этого разработан набор терминов родственных
связей, с которым можно ознакомиться в Приложении Б. Выбрав некоторую персону в
генеалогическом дереве и тип родственной связи из данного набора, можно
получить всех персон в этом дереве, которые связаны с выбранной персоной
выбранным типом родственного отношения. Например, для любой персоны дерева
можно получить всех братьев или всех бабушек этой персоны.
Заключение
В результате проделанной работы полностью реализован запланированный
объём работы, включающий в себя реализацию системы хранения данных проекта,
реализацию системы разграничения прав доступа к ресурсам сервиса и реализацию
возможности определения родства между персонами генеалогического дерева.
Разработанный сервис имеет практическую ценность для работы с
генеалогическими деревьями в веб-среде.
Для достижения поставленной цели проделаны следующие виды работ:
- исследована предметная область;
- найдены и исследованы существующие аналоги;
- составлены общие и функциональные требования;
- исследованы возможные средства разработки для решения
поставленной задачи;
- выбраны и изучены средства разработки: объектно-реляционная СУБД
PostgreSQL, документо-ориентированная СУБД CouchDB, язык программирования Python, фреймворк Django, язык программирования JavaScript;
- разработана и реализована архитектура реляционной базы
данных;
- разработана и реализована архитектура нереляционной базы
данных;
- разработан и реализован интерфейс для доступа к хранимым
данным;
- разработана и реализована система разграничения прав доступа
для разных групп пользователей;
- разработано и реализовано вычисление степеней родства между
двумя персонами в генеалогическом дереве;
- проведена отладка и тестирование разработанного сервиса.
Направлениями будущей деятельности являются разработка методов для
определения возможного родства между зарегистрированными пользователями и
определения названий родственных связей между любыми двумя выбранными персонами
в одном генеалогическом дереве, а также более углубленное исследование вопроса
безопасности данного сервиса с разработкой методов обеспечения защищенности
системы.
Литература
1) Ф. Харари. Теория графов = Graph
Theory / пер. с англ. В. Козырев. - М.: Либроком, 2009. - 302 с.;
2) Кочевых, Сергей Владимирович.
Методическое пособие по проведению генеалогических разысканий. Основы
генеалогической культуры. -
СПб.: 2006. - 80 с.;
3) Genway - больше, чем семья:
[Электрон. Ресурс]. - http://www.genway.ru [30.05.12];
4) Moederevo.com: [Электрон. Ресурс]. -
http://moederevo.com [30.05.12];
5) MyHeritage.com: [Электрон. Ресурс]. -
http://www.myheritage.com [30.05.12];
6) Дэвид М. Бизли. Python. Подробный справочник, 4-е издание.
- пер. с англ. А. Киселёв. -
СПб.: Символ-Плюс, 2010. - 864
с.;
7) А. Головатый. Django. Подробное руководство = The Definitive Guide to Django / пер. с англ. А. Киселев. - СПб.: Символ-Плюс, 2010.
- 560 с.;
8) В.Ю. Пирогов. Информационные системы
и базы данных. Организация и проектирование. - СПб.: ХВ-Петербург, 2009. - 528
с.;
9) Кевин Е. Кляйн. SQL. Справочник = In a Nutshell: A Desktop Quick Reference / пер. с англ. А. Слинкин, Е. Демьянов. - СПб.: Символ-Плюс, 2010. - 656 с.;
10)Gregory Smith. PostgreSQL 9.0 High Performance. - Packt
Publishing, 2010. - 468 с.;
11)J. Chris Anderson. CouchDB: The Definitive Guide . - O'Reilly
Media, 2010. - 250 c.;
12)Дэвид Флэнаган. JavaScript. Подробное руководство = JavaScript: The
Definitive Guide / пер. с англ. А. Киселев. - 5-е изд. - СПб.:
Символ-Плюс, 2009. - 992 с.;
13)Джен Л.
Харрингтон. Проектирование реляционных баз данных = Relational Database Design
/ пер. с англ. И. Дранишников. - М.: Лори, 2006. - 230 с.
Приложения
Приложение
А
(справочное)
Структура
таблиц реляционной базы данных
Таблица А.1.Таблица «user»
|
Атрибут
|
Характеристики атрибута
|
Комментарий
|
|
id
|
integer UNSIGNED
NOT NULL AUTO_INCREMENT
|
Первичный ключ таблицы
|
|
login
|
varchar(50) NOT NULL
|
Логин пользователя
|
|
password
|
varchar(50) NOT NULL
|
Пароль
пользователя
|
|
firstname
|
varchar(50) NOT NULL
|
Имя пользователя
|
|
lastname
|
varchar(50) NOT NULL
|
Фамилия пользователя
|
|
patronymic
|
varchar(50) NULL
|
Отчество
пользователя
|
|
phone
|
varchar(20) NULL
|
Телефон пользователя
|
|
email
|
varchar(75) NULL
|
Электронный адрес пользователя
|
|
sex
|
varchar(1) NOT NULL
|
Пол пользователя
|
|
birthday
|
date NULL
|
Дата рождения пользователя
|
|
deathdate
|
date NULL
|
Дата смерти пользователя
|
|
city_id
|
integer NULL
|
Внешний ключ таблицы;
совпадает с городом проживания пользователя
|
|
city_area_id
|
integer NULL
|
Внешний ключ таблицы;
совпадает с id района города, в котором проживает пользователь
|
|
address
|
varchar(100) NULL
|
Адрес
пользователя
|
|
registration_date
|
date NOT NULL
|
Дата регистрации
|
|
update_data
|
date NOT NULL
|
Дата последнего изменения
учетной записи
|
|
ipInfo
|
integer NOT NULL
|
Информация о ip-адресе, с
которого пользователь последний раз посещал сервис
|
Таблица А.2.Таблица «region»
|
Атрибут
|
Характеристики атрибута
|
Комментарий
|
|
id
|
integer UNSIGNED
NOT NULL AUTO_INCREMENT
|
Первичный ключ таблицы
|
|
title
|
varchar(30) NOT NULL
|
Название региона
|
Таблица А.3. Таблица «region_area»
|
Атрибут
|
Комментарий
|
|
id
|
integer UNSIGNED
NOT NULL AUTO_INCREMENT
|
Первичный ключ таблицы
|
|
title
|
varchar(60) NOT NULL
|
Название района
региона
|
|
region_id
|
integer NOT NULL
|
Внешний ключ таблицы;
совпадает с id региона
|
Таблица А.4. Таблиц «city»
|
Атрибут
|
Характеристики атрибута
|
Комментарий
|
|
id
|
integer UNSIGNED
NOT NULL AUTO_INCREMENT
|
Первичный ключ таблицы
|
|
title
|
varchar(60) NOT NULL
|
Название города,
принадлежащего району региона
|
|
region_area_id
|
integer NOT NULL
|
Внешний ключ таблицы;
совпадает с id районом региона
|
Таблица А.5. Таблиц
«city_area»
|
Атрибут
|
Характеристики атрибута
|
Комментарий
|
|
id
|
integer UNSIGNED
NOT NULL AUTO_INCREMENT
|
Первичный ключ таблицы
|
|
title
|
varchar(60) NOT NULL
|
Название района
города
|
|
city_id
|
integer NOT NULL
|
Внешний ключ таблицы;
совпадает с id города
|
Таблица А.6.Таблица «media»
|
Атрибут
|
Характеристики атрибута
|
Комментарий
|
|
id
|
integer UNSIGNED
NOT NULL AUTO_INCREMENT
|
Первичный ключ таблицы
|
|
type
|
varchar(15) NOT NULL
|
Тип медиа-файла
|
|
title
|
varchar(100) NOT NULL
|
Название
медиа-файла
|
|
path
|
varchar(200) NOT NULL
|
Путь к расположению
медиа-файла
|
|
owner_id
|
integer NOT NULL
|
Внешний ключ таблицы;
совпадает с id пользователя - создателя медиа-файла
|
Таблица А.7. Таблица «photo»
|
Атрибут
|
Характеристики атрибута
|
Комментарий
|
|
id
|
integer UNSIGNED
NOT NULL AUTO_INCREMENT
|
Первичный ключ таблицы
|
|
media_id
|
integer NOT NULL
|
Внешний ключ таблицы; совпадает
с id фотографии
|
|
user_id
|
integer NOT NULL
|
Внешний ключ таблицы;
совпадает с id пользователя, отмеченного на фотографии
|
|
rectangle
|
varchar(20) NOT NULL
|
Границы отмеченной области
на фотографии
|
Таблица А.8. Таблица
«privilege»
|
Атрибут
|
Характеристики атрибута
|
Комментарий
|
|
id
|
integer UNSIGNED
NOT NULL AUTO_INCREMENT
|
Первичный ключ таблицы
|
|
document_id
|
varchar(40) NOT NULL
|
Cовпадает с id документа,
на который распространяются права
|
|
owner_id
|
integer NOT NULL
|
Внешний ключ таблицы;
совпадает с id пользователя-создателя документа
|
|
user_id
|
integer NOT NULL
|
Внешний ключ таблицы;
совпадает с id пользователя, которому предоставляются права
|
|
privilege
|
varchar(3) NOT NULL
|
Определяет тип прав
("r"-чтение, "w"-запись, "c"-копирование)
|
Таблица А.9.Таблица «album»
|
Атрибут
|
Характеристики атрибута
|
Комментарий
|
|
id
|
integer UNSIGNED
NOT NULL AUTO_INCREMENT
|
Первичный ключ таблицы
|
|
owner_id
|
integer NOT NULL
|
Внешний ключ таблицы;
совпадает с id пользователя-создателя альбома
|
|
avatar_id
|
integer NOT NULL
|
Внешний ключ таблицы;
совпадает с id фотографии, являющейся обложкой альбома
|
|
title
|
varchar(100) NOT NULL
|
Название альбома
|
|
create_date
|
date NOT NULL
|
Дата создания альбома
|
|
update_date
|
date NOT NULL
|
Дата последнего изменения
альбома
|
Таблица А.10. Таблиц «media_to_album»
|
Атрибут
|
Характеристики атрибута
|
Комментарий
|
|
id
|
integer UNSIGNED
NOT NULL AUTO_INCREMENT
|
Первичный ключ таблицы
|
|
album_id
|
integer NOT NULL
|
Внешний ключ таблицы;
совпадает с id альбома
|
|
media_id
|
integer NOT NULL
|
Внешний ключ таблицы;
совпадает с id фотографии
|
Приложение Б
(справочное)
Термины
родственных связей
Отношения по крови:
Бабушка - мать отца или матери; жена дедушки.
Брат родной - сын одних родителей.
Брат двоюродный - сын сестры или брата отца или матери, то есть сын дяди
или тети
Внук - сын дочери, сына; а также сыновья племянника или племянницы.
Внучка - дочь сына, дочери; а также дочери племянника или племянницы.
Дедушка - отец матери или отца; муж бабушки.
Дочь - лицо женского пола по отношению к своим родителям.
Дядя - брат отца или матери; муж тети.
Мать - лицо женского пола по отношению к своим детям.
Отец - лицо мужского пола по отношению к своим детям.
Племянник - сын брата или сестры.
Племянница - дочь брата или сестры.
Сестра родная - дочь одних родителей.
Сестра двоюродная - сестры или брата отца или матери, то есть дочь дяди
или тети
Сын - лицо мужского пола по отношению к своим родителям.
Тетя - сестра отца или матери, жена дяди.
Отношения по браку:
Братаниха - жена двоюродного брата.
Братова - жена брата.
Деверь - брат мужа.
Жена - замужняя женщина по отношению к мужу.
Золовка - сестра мужа.
Зять - муж дочери, сестры, золовки.
Муж - женатый мужчина по отношению к жене.
Невестка - жена сына, брата, деверя, шурина. Другими словами, это женщина
по отношению к семье мужа: его матери (свекрови), братьям (деверям) и сёстрам
(золовкам), жёнам братьев (сношенницам) и мужьям сестёр.
Сват, сватья - родители супругов и их родственники по отношению друг к
другу.
Свекор - отец мужа.
Свекровь - мать мужа.
Свояки - лица, женатые на двух сестрах.
Свояки двоюродные - лица, женатые на двоюродных сестрах.
Сноха - жена сына по отношению к его отцу.
Сношенница - жена деверя, жены двух братьев по отношению друг к другу.
Тесть - отец жены.
Теща - мать жены.
Шурин - родной брат жены.
Термины неродственных отношений:
Дочь названая - приемная дочь, воспитанница.
Мать названная - мать приемному сыну или приемной дочери, воспитаннику.
Мачеха - другая жена отца, неродная мать.
Отец названый - отец приемному сыну или приемной дочери, воспитаннику.
Отчим - другой муж матери, неродной отец.
Падчерица - дочь от другого брака по отношению к неродному родителю.
Пасынок - сын неродной одному из супругов.
Сводный брат - братья от разных родителей по отношению друг к другу.
Сводная сестра - сестры от разных родителей по отношению друг к другу
Сын названый - приемная дочь, воспитанница.