БД “Бухгалтерия” имеет возможности ведения учета:
- сотрудников;
- договоров;
- поощрений;
- взысканий;
- выставлять счет.
Причем, имеется возможность:
- редактирования данных (добавления, изменения, удаления ) в строках или кортежах таблиц;
- поиска информации по созданным таблицам;
- получения интересующей информации по определенным полям посредством написания запросов.
Функциональная структура системы представляет собой набор диаграмм потоков данных (далее - ДПД), которые описывают смысл операций и ограничений (Рис. 1). ДПД отражает функциональные зависимости значений, вычисляемых в системе, включая входные значения, выходные значения и внутренние хранилища данных. ДПД - это граф, на котором показано движение значений данных от их источников через преобразующие их процессы к их потребителям в других объектах. ДПД содержит процессы, которые преобразуют данные. Потоки данных, которые переносят данные. Активные объекты, которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные.
Рис. 1. Функциональная структура БД “Бухгалтерия”
Процесс преобразует значения данных. Процессы самого нижнего уровня представляют собой функции без побочных эффектов. Процесс может иметь побочные эффекты, если он содержит нефункциональные компоненты, такие как хранилища данных или внешние объекты.
Поток данных соединяет выход объекта (или процесса) со входом другого объекта (или процесса). Он представляет промежуточные данные вычислений. Поток данных изображается в виде стрелки между производителем и потребителем данных, помеченной именами соответствующих данных; примеры стрелок, изображающих потоки данных, представлены на рисунке ДПД.
Хранилище данных - это пассивный объект в составе ДПД, в котором данные сохраняются для последующего доступа. Хранилище данных допускает доступ к хранимым в нем данным в порядке, отличном от того, в котором они были туда помещены. Агрегатные хранилища данных, как например, списки и таблицы, обеспечивают доступ к данным в порядке их поступления, либо по ключам (Рис. 2).
Рис. 2. Диаграмма потоков данных БД “Бухгалтерия”
В результате детального анализа предметной области, изучения функциональной структуры и построения схемы потоков данных были выделены объекты (Рис. 3).
Рис.3. Объекты изучения функциональной структуры
Конструирование базы данных связано в конечном итоге с построением ее логической структуры, а именно: взаимосвязанных нормализованных реляционных таблиц, для формирования которых используется система управления базами данных (СУБД).
Однако основой для построения логической структуры является концептуальное моделирование, т.е. переход от описания реального мира к модели этого мира. Синтез концептуальной модели производится при помощи ряда методик. Одной из наиболее популярных семантических моделей данных является модель “Сущность-Связь” или “Объект-Отношение” (Рис. 4).
При построении модели сущность-связь на начальном этапе каждый информационный объект заменяем сущностью, при этом каждое свойство объекта становится атрибутом сущности.
Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности.
Рис. 4. Концептуальная модель БД “Бухгалтерия”
Построение концептуальной модели заключается в выделении объектов и установлении между ними связей. Список объектов для предметной области “Бухгалтерия” будет выглядеть так: сотрудник, должность, договор, личные данные, график работы, счет, поощрения, взыскания. Каждый из этих объектов обладает собственными свойствами.
По концептуальной модели необходимо построить логическую модель (Рис. 5). При этом атрибуты добавляются, в сущности, соответственно связям, показанным на концептуальной модели.
Рис. 5. Логическая модель БД “Бухгалтерия”
Для реализации базы данных была выбрана СУБД Oracle 11g . Это объясняется следующими возможностями данной СУБД:
- Поддержка языка SQL, который достаточно прост в обращении и позволяет без особых затрат времени извлекать любую информацию из базы данных;
- Real Application Cluster (RAC) обеспечивает работу одного экземпляра базы данных на нескольких узлах grid, позволяя управлять нагрузкой и гибко масштабировать систему в случае необходимости;
- Automatic Storage Management (ASM) позволяет автоматически распределять данные между имеющимися ресурсами систем хранения данных, что повышает отказоустойчивость системы и снижает общую стоимость владения (TCO);
- Производительность. Oracle Database 11g позволяет автоматически управлять уровнями сервиса и тиражировать эталонные конфигурации в рамках всей сети;
- Простые средства разработки. Новый инструмент разработки приложений HTML DB позволяет простым пользователям создавать эффективные приложения для работы с базами данных в короткие сроки;
- Самоуправление. Специальные механизмы Oracle Database 11g позволяют самостоятельно перераспределять нагрузку на систему, оптимизировать и корректировать SQL-запросы, выявлять и прогнозировать ошибки;
- Большие базы данных. Максимальный размер экземпляра базы данных Oracle может достигать 8 байт;
- Недорогие серверные системы. Oracle Database 11g может использовать недорогие однопроцессорные компьютеры или модульные системы из “серверов-лезвий”;
- Обеспечение транзакционной целостности, связана с организацией одновременного доступа значительного количества пользователей к данным размещенным на физическом носителе. Доступ производится в процессе выполнения транзакций представляющей собой логическую связь последовательных запросов и операций манипулирования данных;
- Буферирование. На обработку первого запроса уходит больше времени, чем на все последующие запросы это характеризуется тем, что их повторное использование позволяет исключить физический ввод данных с дискового устройства и уменьшает время выполнения запроса, ограничение объема буфера приводит к перманентному вытеснению из него раннее считанных блоков.
Ряд вышеперечисленных возможностей, выделяет СУБД Oracle 11g как наиболее подходящую для реализации базы данных по предоставляемым возможностям.
ЗАКЛЮЧЕНИЕ
В ходе работы была рассмотрена общая характеристика Смоленского филиала РЭУ им. Г.В. Плеханова. Помимо этого, также был проведён анализ, как деятельности самого учреждения, так и функционирование финансово-экономического отдела. Непосредственно были разобраны и составлены модели баз данных указанного отдела.
На основе выделенных информационных объектов и их атрибутов построена концептуальная и логическая модель, т.е. проведено проектирование баз данных: концептуальное и логическое.
Достигнутые основные цели проектирования баз данных. Это:
1. Обеспечение хранения в БД всей необходимой информации.
2. Обеспечение возможности получения данных по всем необходимым запросам.
3. Сокращение избыточности и дублирования данных.
4. Обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.
Таким образом, можно сделать вывод, что, функционирование внутри финансово-экономического отдела, так и деятельность данного отдела в целом играет немаловажную роль в организации Смоленского филиала РЭУ им. Г.В. Плеханова. Обосновывается это тем, что текущий отдел отвечает за всю финансовую деятельность организации.