Разработка реляционной базы данных для товарищества собственников жилья «Электрон» | Статья в журнале «Молодой ученый»

Отправьте статью сегодня! Журнал выйдет 4 мая, печатный экземпляр отправим 8 мая.

Опубликовать статью в журнале

Авторы: ,

Рубрика: Технические науки

Опубликовано в Молодой учёный №18 (122) сентябрь-2 2016 г.

Дата публикации: 12.09.2016

Статья просмотрена: 1304 раза

Библиографическое описание:

Горшков, Е. А. Разработка реляционной базы данных для товарищества собственников жилья «Электрон» / Е. А. Горшков, Н. С. Колыбелкина. — Текст : непосредственный // Молодой ученый. — 2016. — № 18 (122). — С. 72-75. — URL: https://moluch.ru/archive/122/33719/ (дата обращения: 25.04.2024).



Жилищно-коммунальное хозяйство — одна из наиболее социально ответственных отраслей экономики. Но это не говорит о ее благополучии. Десятилетия консервативного существования этой сферы достаточно сильно отпечатались на ее общем состоянии. Пришедшие на этот рынок менеджеры столкнулись с массой проблем. Одна из них — полное отсутствие объективной информации о реальном положении дел. Ее сбор, обработка и анализ возможны только путем внедрения автоматизированных средств учета и контроля. Это необходимая, но масштабная работа, требующая не только времени и сил, но и весомых денежных вливаний. Государственная же программа реформирования жилищно-коммунального хозяйства страны не предусматривает финансирование этого направления. Поэтому многие управляющие компании (УК) страны и нашего региона решают данный вопрос на локальном уровне. Одним из таких решений является проектирование и создание реляционных баз данных, обеспечивающих информационные потребности УК и в частности товариществ собственников жилья (ТСЖ). Одной из таких перспективных разработок является созданная база данных ТСЖ «Электрон».

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

Созданная база данных предназначена для узкого круга пользователей — глав ТСЖ.

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

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

Так же требуются данные о проживающих в квартирах — это, прежде всего, код гражданина и код квартиры, дата прописки и выписки, а также информация, снимают ли эту квартиру, или же в ней проживают собственники (рис. 1).

Данные о владении квартирами доступны лишь узкому кругу пользователей, главам ТСЖ и самим владельцам — код гражданина, код квартиры, размер доли обладателя квартиры и само основание правообладания.

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

Рис. 1ER-диаграмма для БД «ТСЖ «Электрон»»

В качестве инструментального средства разработки реляционной базы данных «ТСЖ «Электрон»» выбрано MSAccess, как наиболее полно удовлетворяющее требованиям Заказчика.

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

Логическое описание таблицы «Гражданин» включает: «Код гр» — числовое поле объемом 4 байта; «Фамилия», «Имя», «Отчество» и «Контактные данные» — 4 текстовых поля объемом до 255 знаков каждый; «Дата рождения» — поле Дата/время объемом 8 байт и «Примечания» — поле MEMO объемом до 65 535 знаков. На одно поле необходимо:

Предполагается максимальное количество 300 граждан, следовательно, для хранения данных одной таблицы необходимо 19 Мбайт.

Логическое описание таблицы «Владение» включает: 4 числовых поля — «Код владения», «Код квартиры», «Код гр», «Размер доли» объемом каждый по 4 байта. На одно поле необходимо:

Предполагается максимальное количество 300 полей данных, следовательно, для хранения данных одной таблицы необходимо 80 Кбайт.

Логическое описание таблицы «Квартира» составляют: 4 числовых поля — «Код квартиры», «№ дома», «№ квартиры», «Общая площадь» объемом каждый 4 байта, а также 2 логических поля — «Газовый счетчик» и «Счетчик воды» объемом по 2 байта каждый.

На одно поле необходимо:

Предполагается максимальное количество 150 квартир, следовательно, для хранения данных одной таблицы необходимо 3000 байт.

Логическое описание таблицы «Проживание» включает: 3 числовых поля — «Код проживания», «Код квартиры», «Код гр» объемом по 4 байта каждый, 2 поля Дата/время — «Дата прописки», «Дата выписки» объемом по 8 байт каждый, а также логическое поле «Снятие» объемом в 2 байта. На одно поле необходимо:

Предполагается максимальное количество 300 полей данных, следовательно, для хранения данных одной таблицы необходимо 9000 байт.

Логическое описание таблицы «Собрания» включает: числовое поле — «Код собрания» объемом 4 байта, «Дата проведения» — поле Дата/время объемом 8 байт, «Комментарии» — Поле МЕМО объемом до 65 535 знаков, текстовое поле — «Место проведения» объемом до 255 знаков, а также «Протокол собрания» — поле вложение объемом до 2 Гб.

На одно поле необходимо:

Предполагается максимальное количество 50 собраний, следовательно, для хранения данных одной таблицы необходимо 100 Гбайт.

Логическое описание таблицы «Список участников собрания» включает: 2 числовых поля «Код собрания» и «Код гр» объемом по 4 байта каждый, а также логическое поле «Присутствие» объемом 2 байта. На одно поле необходимо:

Предполагается максимальное количество 300 участников, следовательно, для хранения данных одной таблицы необходимо 3000 байт.

Для избежание избыточности данных, в базе создаются связи между таблицами, которые отображаются в схеме данных. Схема данных БД представлена на рис. 2.

Рис. 2 Схема БД «ТСЖ «Электрон»

В качестве примера реализации интерфейса ввода/вывода данных в данной БД приведены: «Главная форма» базы данных «ТСЖ «Электрон»», которая представляет собой навигационную форму, которая позволяет свободно перемещаться между своими вкладками (рис.3); а также «Форма работы с отчетами» (рис.4).

Рис. 3. Главная форма БД «ТСЖ «Электрон»

Рис. 4. Форма работы с отчетами

Запросы являются основным инструментов поиска, обновления и выборки данных из таблиц. Access в соответствии с концепцией реляционных баз данных для выполнения запросов использует язык структурированных запросов SQL (Structured Query Language). С помощью инструкций языка SQL реализуется любой запрос в Access. В разработанной базе данных «ТСЖ «Электрон»» было создано 5 запросов: Вес голоса, Присутствующие на собрании, Выборка по данным «Свердлова 27», Выборка по данным «Свердлова 29», Запрос для отчета.

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

Поэтому разработанная база данных «ТСЖ «Электрон»» является перспективным решением информационной потребности жилищно-коммунальной службы, что подтверждается ее успешным внедрением и эксплуатацией Заказчиком на локальном уровне

Литература:

  1. Токарев А. Н. Проектирование реляционных баз данных. (Методические указания к выполнению курсовой работы). // БФ РАНХ и ГС, Балаково, 2012.
  2. Марков, А. С. Базы данных. Введение в теорию и методологию: учебник // М.: Финансы и статистика, 2015.
  3. Информационно-аналитический портал [Электронный ресурс]: URL: http: // citforum.ru/ (дата обращения 18.05.2016г.)
  4. Информационно-справочный портал [Электронный ресурс]: URL: http: // accesshelp.ru/ (дата обращения 04.05.2016г.)
  5. Информационно-справочный портал [Электронный ресурс]: URL: http: // support.office.com (дата обращения 04.05.2016г.)
  6. Информационно-аналитический портал [Электронный ресурс]: URL: http: // compress.ru/ (дата обращения 19.05.2016г.)
  7. Информационно-новостной портал [Электронный ресурс]: URL: http: // fb.ru // (дата обращения 19.05.2016г.)
  8. Информационно-образовательный интернет-портал [Электронный ресурс]: URL: http: // www.intuit.ru/ (дата обращения 17.05.2016г.)
  9. Информационно-образовательный интернет-портал [Электронный ресурс]: URL: http: // ru.wikipedia.org (дата обращения 02.05.2016г.)
Основные термины (генерируются автоматически): хранение данных, байт, логическое описание таблицы, SQL, пол, данные, Дата, квартира, объем, поле.


Похожие статьи

Технологии обработки больших данных | Статья в журнале...

Оказалось, это не объёмы хранимых данных, точнее не только объемы.

Такое хранение данных еще называют noSQL базы данных.

Основные термины (генерируются автоматически): данные, SQL, обычный компьютер, личная информация, язык запросов, ETL...

Таблица данных для SQL

Попробуем рассмотреть разницу SQL — NoSQL БД. Для данных SQL характерно требование ACID (Atomicity, Consistency, Isolation, Durability — атомарность, непротиворечивость

При реляционном хранении потребуется описание дополнительных полей или таблиц.

BigData: анализ больших данных сегодня | Статья в журнале...

Библиографическое описание

Основные термины (генерируются автоматически): данные, SQL, HANA, SAP, IBM, объем информации, баз данных, информация, использование данных, текущий момент.

Методы выполнения запросов к хранилищу данных в Hadoop...

Первое из этих свойств — это возможность управлять огромным объёмом данных.

Это новое качество данных потребовало нового подхода к их хранению и обработке.

В этой статье не рассмотрена операция соединения таблиц (аналог оператора JOIN в SQL).

Сравнение производительности ORM-библиотек как критерия...

Библиографическое описание

Использование реляционной базы данных для хранения

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

Выбор SQL Server для медицинского учреждения

объем хранимой информации; серверную операционную систему; безопасность хранения информации.

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

Организация доступа к реляционной базе данных на основе...

Класс представляет собой объявленный программистом составной тип данных, имеющий в составе поля данных и методы [2].

Библиотека не только решает задачу связи классов Java с таблицами базы данных (и типов данных Java с типами данных SQL), но и также...

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

Библиографическое описание

Основные термины (генерируются автоматически): OLAP, SQL, данные, MOLAP, интеллектуальный анализ данных, OLTP, таблица измерений, хранилище данных, автоматизированная сортировочная, куб.

Классификация и тестирование производительности способов...

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

Метаданные таблицы – это ее имя (Name), описание (Description) и флаг (TempTableFlag) того, что

Например, когда один тип хранилища лучше подходит для данных малого объема, а...

Похожие статьи

Технологии обработки больших данных | Статья в журнале...

Оказалось, это не объёмы хранимых данных, точнее не только объемы.

Такое хранение данных еще называют noSQL базы данных.

Основные термины (генерируются автоматически): данные, SQL, обычный компьютер, личная информация, язык запросов, ETL...

Таблица данных для SQL

Попробуем рассмотреть разницу SQL — NoSQL БД. Для данных SQL характерно требование ACID (Atomicity, Consistency, Isolation, Durability — атомарность, непротиворечивость

При реляционном хранении потребуется описание дополнительных полей или таблиц.

BigData: анализ больших данных сегодня | Статья в журнале...

Библиографическое описание

Основные термины (генерируются автоматически): данные, SQL, HANA, SAP, IBM, объем информации, баз данных, информация, использование данных, текущий момент.

Методы выполнения запросов к хранилищу данных в Hadoop...

Первое из этих свойств — это возможность управлять огромным объёмом данных.

Это новое качество данных потребовало нового подхода к их хранению и обработке.

В этой статье не рассмотрена операция соединения таблиц (аналог оператора JOIN в SQL).

Сравнение производительности ORM-библиотек как критерия...

Библиографическое описание

Использование реляционной базы данных для хранения

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

Выбор SQL Server для медицинского учреждения

объем хранимой информации; серверную операционную систему; безопасность хранения информации.

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

Организация доступа к реляционной базе данных на основе...

Класс представляет собой объявленный программистом составной тип данных, имеющий в составе поля данных и методы [2].

Библиотека не только решает задачу связи классов Java с таблицами базы данных (и типов данных Java с типами данных SQL), но и также...

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

Библиографическое описание

Основные термины (генерируются автоматически): OLAP, SQL, данные, MOLAP, интеллектуальный анализ данных, OLTP, таблица измерений, хранилище данных, автоматизированная сортировочная, куб.

Классификация и тестирование производительности способов...

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

Метаданные таблицы – это ее имя (Name), описание (Description) и флаг (TempTableFlag) того, что

Например, когда один тип хранилища лучше подходит для данных малого объема, а...

Задать вопрос