Автор: Пользователь скрыл имя, 02 Ноября 2012 в 17:03, курсовая работа
В настоящее время все большую актуальность приобретает использование при разработке приложений реляционных баз данных. Это связано с тем, что современные информационные системы имеют дело с большими объемами информации.
Введение………………………………………………………...………………
Задание на проектирование…………………..………………………....
Разработка структуры БД………………….…………………..………..
2.1 Описание предметной области………..………………………....
2.2 Анализ информационных потоков………………..……………..
2.3 Создание инфологической модели ………………………..…….
2.3.1 Процедура нормализации сущностей……………………...
2.4 Создание даталогической модели……………………..…………
2.5 Выбор технических и программных средств реализации БД и клиентского приложения………………………………………………..
Создание базы данных……………………………………………...…...
3.1 Описание структуры БД ………………………………………....
3.2 Описание свойств таблиц БД…………………………………….
3.3 Описание связей между таблицами БД и условий целостности данных………..……………………………………………………
3.4 Описание хранимых процедур…………………………………...
Создание пользовательского интерфейса информационной системы……………..................................................................................
4.1 Пользовательское меню …………………………………………
4.2 Формы как средство добавления, удаления, просмотра, изменений данных в БД…………………………………..……..
4.3 Формирование запросов к базе данных………………….……...
4.4 Формирование отчетов……….…………………………………..
4.5 Справочная система…………………….………………………...
Заключение……………………………………………………………………...
Литература………………………………………………………………………
Приложения……………………………………………………………………..
Таблица 5 – Инфологическая модель таблицы «Движение»
Имя сущности |
Движение |
Тип сущности |
Ассоциация | |
Имя атрибута |
Свойства атрибута | |||
Ключевой/ описательный |
Составной/ простой |
Однозначный/ многозначный |
Основной/ Производный | |
Дата |
Описательный |
Составной |
Однозначный |
Основной |
Код кассира |
Внешний Ключ |
Простой |
Однозначный |
Основной |
Признак операции |
Описательный |
Составной |
Однозначный |
Основной |
Код бухгалтерского счета |
Внешний Ключ |
Простой |
Однозначный |
Основной |
Тип операции |
Описательный |
Составной |
Однозначный |
Основной |
Код сотрудника |
Внешний Ключ |
Простой |
Однозначный |
Основной |
Сумма |
Описательный |
Простой |
Однозначный |
Основной |
Код документа |
Внешний Ключ |
Простой |
Однозначный |
Основной |
Номер документа |
Описательный |
Простой |
Однозначный |
Основной |
Таблица 6 – Инфологическая модель таблицы «Остатки»
Имя сущности |
Остатки |
Тип сущности |
Обозначение | |
Имя атрибута |
Свойства атрибута | |||
Ключевой/ описательный |
Составной/ простой |
Однозначный/ многозначный |
Основной/ Производный | |
Код кассира |
Внешний Ключ |
Простой |
Однозначный |
Основной |
Дата |
Описательный |
Составной |
Однозначный |
Основной |
Остаток на начало дня |
Описательный |
Простой |
Однозначный |
Основной |
Сумма прихода |
Описательный |
Простой |
Однозначный |
Основной |
Сумма расхода |
Описательный |
Простой |
Однозначный |
Основной |
Таблица 7 – Инфологическая модель таблицы «Банки»
Имя сущности |
Банки |
Тип сущности |
Стержень | |
Имя атрибута |
Свойства атрибута | |||
Ключевой/ описательный |
Составной/ простой |
Однозначный/ многозначный |
Основной/ Производный | |
Код банка |
Первичный ключ |
Простой |
Однозначный |
Основной |
Наименование банка |
Описательный |
Составной |
Однозначный |
Основной |
Таблица 8 – Инфологическая модель таблицы «Подразделения»
Имя сущности |
Подразделения |
Тип сущности |
Обозначение | ||
Имя атрибута |
Свойства атрибута | ||||
Ключевой/ описательный |
Составной/ простой |
Однозначный/ многозначный |
Основной/ производный | ||
Код подразделения |
Первичный ключ |
Простой |
Однозначный |
Основной | |
Наименование |
Описательный |
Составной |
Однозначный |
Основной | |
Код сотрудника_ начальника подразделения |
Внешний Ключ |
Составной |
Однозначный |
Основной | |
Инфологическая модель базы данных на языке «Таблицы - связи» представлена на первом графическом листе. На рисунке 1 Приложения изображена инфологическая модель базы данных на языке ER-диаграмм.
Кассиры Движение Остатки
(стержень) (ассоциация) (
Бухгалтерские счета
(стержень)
Документы
(стержень)
Подотчетные лица Подразделения
(ассоциация) (обозначение)
Банки
(стержень)
Рис. 2.1. Инфологическая модель базы данных "Кассовые операции", построенная с помощью языка "Таблицы-связи"
Рис. 2.2. Инфологическая модель базы данных "Кассовые операции", построенная с помощью языка ER-диаграмм
2.3.1 Процедура нормализации сущностей
Проблема проектирования реляционной базы данных состоит в обоснованном принятии решений о том,
При неправильно спроектированной схеме БД могут возникнуть аномалии выполнения операций включения, удаления и модификации данных.
При классическом подходе весь процесс проектирования производится в терминах реляционной модели данных методом последовательных приближений к удовлетворительному набору схем отношений.
Нормализация – пошаговый обратимый процесс композиций или декомпозиций исходных отношений, обладающих лучшими свойствами при включении, изменении, удалении данных, назначении им ключей по определенным правилам и выявлении всех функциональных зависимостей.
В теории реляционных баз данных обычно выделяется 5 нормальных форм и нормальная форма Бойса-Кодда. Каждая из таблиц базы данных может находиться в одной или нескольких нормальных формах.
В таблице 9 отражено, в каких нормальных формах находятся таблицы базы данных «Кассовые операции».
Таблица 9 – Нормализация таблиц базы данных «Кассовые операции»
Название таблицы |
Нормальная форма |
Кассиры |
Таблица находится в 1NF, т.к. атрибуты отношения определены на простых типах данных и ключевое поле не может иметь null-значений. Таблица находится во 2NF, т.к. она удовлетворяет определению первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. Таблица находится в 3NF, т.к. она удовлетворяет определению второй нормальной формы и ни одно из ее неключевых полей не зависит функционально от любого другого неключевого поля. |
Бухгалтерские счета |
Таблица находится в 1NF, т.к. атрибуты отношения определены на простых типах данных и ключевое поле не может иметь null-значений. Таблица находится во 2NF, т.к. она удовлетворяет определению первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. Таблица находится в 3NF, т.к. она удовлетворяет определению второй нормальной формы и ни одно из ее неключевых полей не зависит функционально от любого другого неключевого поля. |
Документы |
Таблица находится в 1NF, т.к. атрибуты отношения определены на простых типах данных и ключевое поле не может иметь null-значений. Таблица находится во 2NF, т.к. она удовлетворяет определению первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. Таблица находится в 3NF, т.к. она удовлетворяет определению второй нормальной формы и ни одно из ее неключевых полей не зависит функционально от любого другого неключевого поля. |
Банки |
Таблица находится в 1NF, т.к. атрибуты отношения определены на простых типах данных и ключевое поле не может иметь null-значений. Таблица находится во 2NF, т.к. она удовлетворяет определению первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. Таблица находится в 3NF, т.к. она удовлетворяет определению второй нормальной формы и ни одно из ее неключевых полей не зависит функционально от любого другого неключевого поля. |
Подотчетные лица |
Таблица находится в 1NF, т.к. атрибуты отношения определены на простых типах данных и ключевое поле не может иметь null-значений. Таблица находится во 2NF, т.к. она удовлетворяет определению первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. Таблица находится в 3NF, т.к. она удовлетворяет определению второй нормальной формы и ни одно из ее неключевых полей не зависит функционально от любого другого неключевого поля. |
Движение |
Таблица находится в 1NF, т.к. атрибуты отношения определены на простых типах данных и ключевое поле не может иметь null-значений. Таблица находится во 2NF, т.к. она удовлетворяет определению первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. |
Остатки |
Таблица находится в 1NF, т.к. атрибуты отношения определены на простых типах данных и ключевое поле не может иметь null-значений. Таблица находится во 2NF, т.к. она удовлетворяет определению первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. Таблица находится в 3NF, т.к. она удовлетворяет определению второй нормальной формы и ни одно из ее неключевых полей не зависит функционально от любого другого неключевого поля. |
Подразделения |
Таблица находится в 1NF, т.к. атрибуты отношения определены на простых типах данных и ключевое поле не может иметь null-значений. Таблица находится в 3NF, т.к. она удовлетворяет определению второй нормальной формы и ни одно из ее неключевых полей не зависит функционально от любого другого неключевого поля. |
2.4 Создание датологической модели
Второй этап проектирования базы данных называется логическим проектированием базы данных.
Логическое проектирование заключается в преобразовании концептуальной модели данных в логическую модель данных и ее описание с учетом выбранного типа СУБД. То есть на этом этапе уже должно быть известно, какая СУБД будет использоваться в качестве целевой – реляционная, сетевая, иерархическая или объектно-ориентированная. Но все остальные характеристики выбранной СУБД, например, любые особенности физической организации ее структур хранения данных и построения индексов не принимаются еще во внимание.
Под даталогической моделью понимается модель, отражающая логические взаимосвязи между элементами данных без относительного их содержания и физической организации.
Описание сущностей предметной области для даталогической модели базы данных «Кассовые операции» приведено в таблицах 10 – 17.
Таблица 10 -НАЗВАНИЕ
Имя сущности |
Kassiri | ||||||
Имя атрибута |
Тип данных |
Дли на |
Ключевое поле (да/нет, если да, то указать первичный или внешний) |
Индексированное поле (да/нет, если да, то указать тип индекса) |
Обязательное поле (да/нет) |
Ограничение домена (условие на значение) |
Значение по умолчанию |
Kod_kas |
smallint |
2 |
Да, первичный |
Да, простой |
Да |
N>0 |
|
FIO_kas |
varchar |
50 |
Нет |
Нет |
Да |
s<=50 |
|
Таблица 11
Имя сущности |
Doc | ||||||
Имя атрибута |
Тип данных |
Дли на |
Ключевое поле (да/нет, если да, то указать первичный или внешний) |
Индексированное поле (да/нет, если да, то указать тип индекса) |
Обязательное поле (да/нет) |
Ограничение домена (условие на значение) |
Значение по умолчанию |
Kod_doc |
smallint |
2 |
Да, первичный |
Да, простой |
Да |
N>0 |
|
Naim_doc |
varchar |
50 |
Нет |
Нет |
Да |
s<=50 |
|
Таблица 12
Имя сущности |
Podotch_lic | ||||||
Имя атрибута |
Тип данных |
Дли на |
Ключевое поле (да/нет, если да, то указать первичный или внешний) |
Индексированное поле (да/нет, если да, то указать тип индекса) |
Обязательное поле (да/нет) |
Ограничение домена (условие на значение) |
Значение по умолчанию |
Kod_sotr |
smallint |
2 |
Да, первичный |
Да, простой |
Да |
N>0 |
|
FIO_sotr |
varchar |
50 |
Нет |
Нет |
Да |
s<=50 |
|
Lic_sch |
char |
10 |
Нет |
Да |
Да |
||
Kod_banka |
smallint |
2 |
Да, вторичный |
Нет |
Да |
N>0 |
|
Kod_podr |
smallint |
2 |
Да, вторичный |
Нет |
Да |
N>0 |
|
Таблица 13
Имя сущности |
Buh_scheta | ||||||
Имя атрибута |
Тип данных |
Дли на |
Ключевое поле (да/нет, если да, то указать первичный или внешний) |
Индексированное поле (да/нет, если да, то указать тип индекса) |
Обязательное поле (да/нет) |
Ограничение домена (условие на значение) |
Значение по умолчанию |
Kod_sch |
smallint |
2 |
Да, первичный |
Да, простой |
Да |
N>0 |
|
Naim_sch |
varchar |
50 |
Нет |
Нет |
Да |
s<=50 |
|