Файл: РАЗРАБОТКА САЙТА КОНСАЛТИНГОВОЙ КОМПАНИИ В СФЕРЕ ИНФОРМАЦИОННЫХ ТЕХНОЛОНИЙ ООО «Геоаналитика».pdf

Создание нового типа

Если вдруг так случится, что обширного списка типов данных Постгреса вам окажется недостаточно, вы можете использовать команду CREATE TYPE, чтобы создать новые типы данных, такие как составной, перечисляемый, диапазон и базовый. Рассмотрим пример создания и отправки запросов нового составного типа:
 

-- создаем новый составной тип "wine"

CREATE TYPE wine AS (

wine_vineyard varchar(50),

wine_type varchar(50),

wine_year int

);

-- создаем таблицу, которая использует составной тип "wine"

CREATE TABLE pairings (

menu_entree varchar(50),

wine_pairing wine

);

-- вставляем данные в таблицу при помощи выражения ROW

INSERT INTO pairings VALUES

('Lobster Tail',ROW('Stag''s Leap','Chardonnay', 2012)),

('Elk Medallions',ROW('Rombauer','Cabernet Sauvignon',2012));

/*

выборка из таблицы с использованием имени колонки

(используйте скобки, отделяемые точкой от имени поля

в составном типе)

*/

SELECT (wine_pairing).wine_vineyard, (wine_pairing).wine_type

FROM pairings

WHERE menu_entree = 'Elk Medallions';

Поскольку они не являются объектно-реляционными, MySQL, MariaDB и Firebird не предоставляют такую мощную функциональность.
 

2.1.2 Размеры данных

PostgreSQL может обрабатывать много данных. Текущие опубликованные ограничения перечислены ниже:

В Compose [прим. пер.: организация, в которой трудится автор оригинальной статьи] мы автоматически масштабируем вашу инсталляцию, чтобы вам не приходилось волноваться о росте количества данных. Но, как известно любому администратору баз данных, стоит с опаской относиться к слишком большим и неограниченным возможностям. Мы советуем руководствоваться здравым смыслом при создании таблиц и добавлении индексов.

Для сравнения, MySQL и MariaDB печально известны ограничением размера строк в 65 535 байт. Firebird также предлагает всего лишь 64Кб в качестве максимального размера строки. Обычно объём данных ограничивается максимальным размером файлов операционной системы. Поскольку PostgreSQL умеет хранить табличные данные в множестве файлов меньшего размера, он может обойти это ограничение. Но стоит отметить, что слишком большое количество файлов может негативно сказаться на производительности. MySQL и MariaDB поддерживают большее количество столбцов в таблице (до 4,096 в зависимости от типа данных) и большие индивидуальные размеры таблицы, чем PostgreSQL, но необходимость превысить существующие ограничения Постгреса возникает лишь в крайне редких случаях.
 

2.1.3 Целостность данных

Постгрес стремится соответствовать стандарту ANSI-SQL:2008, отвечает требованиям ACID (атомарность, согласованность, изолированность и надежность) и известен своей ссылочной и транзакционной целостностью. Первичные ключи, ограничивающие и каскадные внешние ключи, уникальные ограничения, ограничения NOT NULL, проверочные ограничения и другие функции обеспечения целостности данных дают уверенность, что только корректные данные будут сохранены.

MySQL и MariaDB больше работают на то, чтобы соответствовать стандарту SQL с движками таблиц InnoDB/XtraDB. Теперь они предлагают опцию STRICT с использованием режимов SQL, которая устанавливает проверки корректности используемых данных. Несмотря на это, в зависимости от того, какой режим вы используете, недостоверные и даже урезанные без вашего ведома данные могут быть вставлены или созданы при обновлении. Ни одна из этих баз данных сейчас не поддерживает CHECK ограничения. Кроме того, у них существует множество особенностей в отношении ограничений ссылочной целостности по внешним ключам. В дополнение к вышесказанному, целостность данных может существенно пострадать в зависимости от выбранного движка хранения. MySQL (и fork MariaDB) не делают секрета из того, что променяли целостность и соответствие стандартам на скорость и эффективность.
 

2.1.4 Подводя итоги

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

Если вам кажется, что PostgreSQL не соответствует вашим потребностям, или вы предпочитаете “стрелять от бедра”, тогда вам стоит обратить внимание на NoSQL базы данных, которые мы предлагаем в Compose, или подумать о других SQL базах данных, которые мы упоминали. У каждой из них есть свои преимущества. Compose твёрдо уверен, что очень важно выбрать правильную базу данных для конкретной задачи… иногда это означает, что нужно выбрать несколько баз данных!

2.2 АРХИТЕКТУРА ПРИЛОЖЕНИЯ

Основное дело приложений изображено на рисунке 1

Рисунок 1 – Архитектура приложения

Где приложение – это папка с файлами, реализующими логику одного раздела.

На рисунке 2 мы видим раскрытый раздел управления данными

Рисунок 2 – Архитектура приложения по управлению данными

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

Рисунок 3 – Архитектура статических файлов приложения

ЧАСТЬ 3. Архитектура приложения

3.1 Создание БД

Все данные приложения хранятся в базе данных, база данных представляет собой набор из таблиц, а таблица – набор столбцов, хранящих значение.

На рисунке 4 изображен перечень используемый таблиц.

Рисунок 4 – Перечень таблиц приложения

Таблица создается путем ввода SQL запроса.

CREATE TABLE public.auth_user

(

id integer NOT NULL DEFAULT nextval('auth_user_id_seq'::regclass),

password character varying(128) NOT NULL,

last_login timestamp with time zone,

is_superuser boolean NOT NULL,

username character varying(150) NOT NULL,

first_name character varying(30) NOT NULL,

last_name character varying(30) NOT NULL,

email character varying(254) NOT NULL,

is_staff boolean NOT NULL,

is_active boolean NOT NULL,

date_joined timestamp with time zone NOT NULL,

CONSTRAINT auth_user_pkey PRIMARY KEY (id),

CONSTRAINT auth_user_username_key UNIQUE (username)

)

CREATE TABLE public.map_viewer_project

(

id integer NOT NULL DEFAULT nextval('map_viewer_project_id_seq'::regclass),

name character varying(255) NOT NULL,

public boolean NOT NULL,

slug character varying(255) NOT NULL,

extent geometry(Polygon,3857),

preview character varying(100),

type character varying(1) NOT NULL,

cartometry_permission character varying(1),

dashboard_permission character varying(1),

tabviewer_download_permission character varying(1),

parameters text NOT NULL,

default_basemap_id integer,

owner_id integer,

diagram_permission character varying(1),

CONSTRAINT map_viewer_project_pkey PRIMARY KEY (id),

CONSTRAINT map_viewer_project_default_basemap_id_4fc3b3f2_fk_map_viewe FOREIGN KEY (default_basemap_id)

REFERENCES public.map_viewer_basemap (id) MATCH SIMPLE

ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED,

CONSTRAINT map_viewer_project_owner_id_e90851c7_fk_auth_user_id FOREIGN KEY (owner_id)

REFERENCES public.auth_user (id) MATCH SIMPLE

ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED,

CONSTRAINT map_viewer_project_slug_key UNIQUE (slug)

)

CREATE TABLE public.munobr

(

ogc_fid integer NOT NULL DEFAULT nextval('munobr_ogc_fid_seq'::regclass),

ogr_fid double precision,

namemo character varying,

descr character varying,

fcode double precision,

id double precision,

wkb_geometry geometry(MultiPolygon,3857),

CONSTRAINT munobr_pkey PRIMARY KEY (ogc_fid)

)

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

3.2 Интерфейс приложения

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

Модель клиентской части отображена на рисунке 5.

Рисунок 5 – Модель пользовательской части приложения

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

Модель административной части отображена на рисунке 6.

Рисунок 6 – Модель административной части приложения

ЧАСТЬ 4. Инструкция пользователя

4.1 Инструкция пользователя

Для осуществления доступа к приложения необходимо пройти авторизацию.

На рисунке 7 отображено окно авторизации.

Рисунок 7 – Авторизация

Для перехода к разделу «Управления данными», в котором мы можем загружать новые данные для их визуализации, необходимо навести курсов мыши на кнопку «Проекты», в выпадающем списке выбрать «Управление данными». На рисунке 8 отображен раздел загрузки данных.

Рисунок 8 – Раздел загрузки данных

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

На рисунке 9 изображен функционал настройки цвета загруженных данных.

Рисунок 9 – Окно выбора цвета слоя

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

На рисунке 10 мы видим информацию по области отделенной коричневым цветом.

Рисунок 10 – Информация по выделенной области

4.2 Инструкция администратора

Для входа в панель администрирования необходимо ввести логин пароль пользователя наделенного правами администратора.

На рисунке 11 изображено окно для входа в панель администратора.

Рисунок 11 – Окно для входа в панель администратора

После успешной авторизации мы увидим панель администратора, изображенную на рисунке 12.

Рисунок 12 – Панель администратора

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

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

Рисунок 13 – Панель работы с пользователями

По такой же аналогии система позволяет администрировать и другие разделы.

Заключение

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

Данная работа включает в себя описание архитектуры сайта оператора и его файловой структуры.

Реализован набор таблиц БД, статические файлы интерфейса и файлы для работы серверной части приложения. БД находится в третьей нормальной форме (3НФ), что говорит о том, что таблицы связаны по ключу и зависят друг от друга только ключевыми полями.

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