Файл: Проектирование БД для учета домашних финансов.pdf

Для способа нормализации имеются концепции и методы, разработанные Коддом (Codd). Он определил три типа нормализованных схем, называемых первой, второй и третьей нормальной формой.

Согласно Кодду каждая нормализованная схема (схема без повторяющихся групп) автоматически определяется в первой нормальной форме (1НФ), свободно от того, насколько сложен ее ключ и какая взаимосвязь существует между ее элементами. По определению схема определяется во второй нормальной форме (2НФ), если все её ключевые атрибуты целиком зависят от ключа. Схема определяется в третьей нормальной форме (3НФ), если она находится во 2НФ, и ни какой не ключевой атрибут не зависит от другого не ключевого атрибута.

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

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

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

1.3. Проектирование логической структуры базы данных.

Сущность - объект любой природы данные, о котором хранятся в отношении (таблице, в которой содержатся данные).

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

1. ДОХОД-содержит информацию о сумме поступленияденежных средствам, даты поступления, аванс или зарплата, категории поступления

2. РАСХОД – содержит информацию о сумме расходов денежных средств, дата расхода, категория расходов и т.д.

3. ДОХОД, Категория – содержит о категории поступления денежных средств: алименты, детское пособие, денежные переводы, дивиденды, зарплата, НДФЛ, пенсия.

4. ДОХОДЫ, Подкатегория -содержит информацию о перечисленных денежных средствах ( аванс, зарплата, премия)

5. РАСХОД, Категория – содержит информацию о статьях расхода ( быт.техника, выдача денег родителям, канцтовары, ком. Услуги, продукты, транспорт и т.д.)

---

6. РАСХОДЫ, Подкатегория – содержит информацию о том, когда кто производил расход (мать, отец)

7. УЧЕТ – содержит информацию о поступлении денежных средств и их расходование.

Перечисленные ранее сущности заключают в себе различные атрибуты. Атрибут – свойство сущности (заголовок столбца таблицы).

Ниже приведем название атрибутов вышеуказанных сущностей:

ДОХОД (Код или номер по пункту, дата дохода, сумма дохода, название, категория, подкатегория).

РАСХОД (Код или номер по пункту, дата расхода, сумма расхода, название, категория, подкатегория).

ДОХОД, Категория (Категория)

ДОХОДЫ, Подкатегория(Подкатегория)

РАСХОД, Категория (Категория)

РАСХОДЫ, Подкатегория (Подкатегория)

УЧЕТ (Сумма)

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

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

Проблема представления семантики от начала времен работы с базами банных интересовала разработчиков, и в 70-х годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном(McLeon) в 1981 году, функциональную модель данных Шипмана(Shipman), также созданную в 1981 году, модель "сущность—связь", предложенную Ченом(Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящее время именно модель Чена "сущность—связь", или "EntityRelationship", стала фактическим стандартом при инфологическом моделировании баз данных.

Модель «сущность-связь» называют также «ER-моделью» (essence-сущность, relation-связь). [11. стр. 147].

Припроектирование БД информацию чаще всего размещают в нескольких таблицах. Таблицы при этом связываютс семантикой информации. В реляционной СУБД для указания связей в таблице производят операции их связывания. Рассмотрим наиболее часто встречаемые бинарные связи:

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

2. Связь 1:М может быть в случае, когда одной записи основной таблицы соответствует несколько записей дополнительной таблицы.

---

3. Связь М:1 может быть тогда, когда нескольким записям основной таблицы ставится в соответствии одна запись дополнительной.

4. Связь М:М возникает в том случае когда нескольким записям основной таблицы соответствует несколько записей дополнительной. В реляционной БД связь М:М реализуется через дополнительные таблицы.

Реляционная модель баз данных была предложена сотрудником фирмы IBM Э. Кодом в начале семидесятых годов. Будучи математиком, он предлагал использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность и Декартово произведение). Он обнаружил, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известных в математике как отношения.

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

Реляционная БД представляет собой информацию об объекте, показанную в виде двумерного массива - таблицы объеденных определенными связями.

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

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

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

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

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

Для атрибута табель рабочего времени ключом будет являться две сущности, номер сотрудника и период, то есть ключ будет составным.

• 2 Проектирование физической структуры базы данных.

---

Проектирование информационных систем, включающих в себя базы данных, осуществляется на физическом и логическом уровнях. Решение проблем проектирования на физическом уровне во многом зависит от используемой СУБД (система управления базами данных – комплекс языковых и программных средств, предназначенных для создания, ведения, и совместного ведения БД многими пользователями), зачастую автоматизировано и скрыто от пользователя. В ряде случаев пользователю предоставляется возможность настройки отдельных параметров системы, которая не составляет большой проблемы. [11. стр.123]

Рассмотрим соотношения нашей БД подробнее.

Таблица 1 – Доход

Название	Тип данных	Тип поля
Код	Счетчик	Ключевое
Дата	Дата/Время
Доход	Денежный
Название	Текстовый
Категории	Текстовый
Подкатегория	Текстовый

Таблица 2 – Доход, Категория

Наименование	Тип данных	Тип поля
Категория	Текстовый

Таблица 3 – Доход, Подкатегория

Наименование	Тип данных	Тип поля
Подкатегория	Текстовый

Таблица 4 – Расходы

Название	Тип данных	Тип поля
Код	Счетчик	Ключевое
Дата	Дата/Время
Расход	Денежный
Название	Текстовый
Категории	Текстовый
Подкатегория	Текстовый

Таблица 5 – Расход, Категория

Наименование	Тип данных	Тип поля
Категория	Текстовый

Таблица 6 – Расход, Подкатегория

Наименование	Тип данных	Тип поля
Подкатегория	Текстовый

Таблица 7 – Учет

---

Наименование	Тип данных	Тип поля
Сумма	Денежный

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

Все запросы делятся на две группы: запросы-выборки, запросы-действия.

Запросы-выборки осуществляют выборку данных из таблиц в соответствии с заданными условиями.

Запросы-действия позволяют модифицировать данные в таблицах: удалять, обновлять, добавлять записи.

В данной БДпредставлены следующие запросы:

1. Доходы – сколько и какие доходы поступили на определенную дату. Сумму доходов и название необходимо вводить в ручную с клавиатуры. Остальные критерии можно выбирать из всплывающего окна.

2. Доход категории –как к вам поступили доходы, например алименты, зарплата, пенсия или денежные переводы.

3. Доход Подкатегория– в данном запросе мы видим поступление зарплаты в виде аванса, премии или зарплаты.

4. Расходы – какие расходы прошли на конкретную дату. Сумму расходов и название необходимо вводить вручную с клавиатуры.

5. Расходы Категория – мы видим информацию по какой категории прошли траты, например: расходы на продукты, на медицину, коммун. Услуги и т.д.

6. Расходы Подкатегория – кто произвел расход жена или муж.

7. УЧЕТ - поиск необходимой информации по доходам и расходам.

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

Форма предоставляет возможности для:

1. Ввода и просмотра информации базы данных

2. Изменения данных

3. Печати

4. Создания сообщений.

В данной БД представлены следующие формы:

1. Доходы

2. Расходы

3. Категория расходов

4. Категория доходов

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

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

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

---