Проектирование и реализация базы данных системы
Зарегистрируйся в два клика и получи неограниченный доступ к материалам,а также
промокод
на новый заказ в Автор24. Это бесплатно.
Построение базы данных для информационной системы начинается с анализа предметной области, в ходе которого выделяются основные сущности. После определения основных сущностей строится концептуальная схема предметной области [9-10], отображающая взаимодействие выделенных сущностей.
Концептуальная схема для исследуемой предметной области показана на рисунке 3.
В исследуемой предметной области выделены следующие сущности:
Платеж – оплата налога определенного вида компанией или физлицом.
Плательщик – физическое или юридическое лицо, оплачивающее налоги на недвижимость, транспорт, деятельность и т.д.
Вид налога – категория, к которой относится налог.
Период – время, за которое физическому или юридическому лицу необходимо оплатить налог.
Далее на основе полученной концептуальной схемы строится логическая модель базы данных. Перед построением логической модели необходимо определить модель данных для будущей базы.
Для реализации базы данных выбрана реляционная модель данных. Так как при использовании реляционной модели данные хранятся в двумерных таблицах (реляционных отношениях) с фиксированной структурой [11-12]
Зарегистрируйся, чтобы продолжить изучение работы
. Таблицы связываются между собой для обеспечения доступа ко всем хранимым данным. За счет связей обеспечивается быстрый доступ к хранимой информации.
Логическая модель базы данных представлена на рисунке 4.
Для обеспечения целостности хранимых данных необходимо провести нормализацию до третьей нормальной формы [6-8]. Построенные реляционные отношения находятся в первой нормальной форме (1НФ) [7, 11], так как значения всех атрибутов являются атомарными. Отношения соответствуют второй нормальной форме, так как они находятся в 1НФ и все неключевые атрибуты неприводимо зависят от ключевого атрибута. Отношения находятся в третьей нормальной форме (3НФ), так как они находятся в 2НФ и отсутствуют транзитивные зависимости между неключевыми атрибутами.
На основе логической модели строится физическая модель базы данных с использованием выбранной реляционной СУБД. На рисунке 5 показана физическая модель базы данных, построенная с помощью MS Sql Server и MS Sql Server Management studio.
При построении физической модели добавлена таблица Users, содержащая данные о пользователях информационной системы по учету налоговых платежей.
Характеристики атрибутов представлены в таблицах 1-5.
Таблица 1 – Periods
Название Тип данных Описание
Id
int
Идентификатор периода, первичный ключ
Title
nvarchar(40) Название периода
Таблица 2 – Pays
Название Тип данных Описание
Id
int
Идентификатор платежа, первичный ключ
PDate
datetime
Дата проведения платежа
Total
float
Сумма платежа
Payer_Id
int
Номер плательщика, внешний ключ
Period_Id
int
Номер периода, внешний ключ
TaxType_Id
int
Номер вида налога, внешний ключ
Account
nvarchar(20) Номер счета плательщика, внешний ключ
Таблица 3 – Payers
Название Тип данных Описание
Id
int
Идентификатор плательщика, первичный ключ
PType
nvarchar(40) Тип плательщика (физическое лицо, юридическое лицо)
Title
nvarchar(255) Название организации (для юридических лиц)
Lasname
nvarchar(80) Фамилия плательщика (физлица или представителя организации)
Name
nvarchar(80) Имя плательщика
Patronymic
nvarchar(80) Отчество плательщика
Phone
nvarchar(20) Номер телефона плательщика (организации)
Таблица 4 – TaxTypes
Название Тип данных Описание
Id
int
Идентификатор вида, первичный ключ
Title
nvarchar(80) Название вида налога
Таблица 5 – Users
Название Тип данных Описание
Id
int
Идентификатор пользователя, первичный ключ
Login
nvarchar(40) Логин пользователя
Pass
nvarchar(40) Пароль от учетной записи пользователя
Таблица Pays связана с таблицей Periods связью типа «многие-к-одному»: за один период может быть совершено несколько платежей, каждый платеж относится только к одному периоду.
Таблица Pays связана с таблицей Payers связью типа «многие-к-одному»: каждый плательщик может совершить несколько платежей, каждый платеж относится только к одному плательщику.
Таблица Pays связана с таблицей TaxTypes связью типа «многие-к-одному»: к одному виду налога может относиться несколько платежей, каждый платеж относится только к одному виду налога.
50% курсовой работы недоступно для прочтения
Закажи написание курсовой работы по выбранной теме всего за пару кликов. Персональная работа в кратчайшее время!
