Курсовая Базы Данных. Курсовая работа по базам данных Проектирование и создание базы данных предметной области Пояснительная записка
 Скачать 0.88 Mb.
|
1 2  Министерство образования и науки Российской Федерации ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «ОРЕНБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ» Факультет математики информационных технологий Кафедра программного обеспечения и вычислительной техники автоматизированных систем КУРСОВАЯ РАБОТА по базам данных Проектирование и создание базы данных предметной области Пояснительная записка ОГУ 09.03.01. 3618. 059 ПЗ Руководитель доцент каф. ПОВТАС канд. техн. наук
«____» __________ 20___г. Студент группы 16ИВТ(ба)ОП-2
«____» __________ 20___г. Оренбург 2018 Аннотация Данная работа посвящена теме «разработка и создание базы данных предметной области». В работе используются построения диаграмм моделей и процессов, использованные для проектирования и создания базы данных. Описывается диаграммы IDEF0, IDEF3, DFD, основные принципы проектирования базы данных, а также приложения Windows Forms. В работе приводятся результаты работы программы, приведенные выше диаграммы. Работа содержит 29 листов,19 рисунков, 1 приложение, 13 таблиц. Содержание Введение……………………...………………………………………....………………….5 1. Анализ информационных потоков предметной области……………………………...6 1.1. Разработка модели IDEF0 исследуемого процесса………………………………….6 1.2. Разработка модели IDEF3 операций (работ) процесса………………………………7 1.3. Разработка модели DFD автоматизации исследуемого процесса…………………..8 2. Выбор и обоснование технологии проектирования базы данных…………………..10 3. Техническое проектирование………………………………………………………….12 3.1. Описание объектов базы данных……………………………………………………12 3.2. Инфологическая модель данных…………………………………………………….16 3.3. Даталогическая модель данных……………………………………………………..16 3.4. Обоснование СУБД. Физическая модель данных………………………………….17 3.5. Разработка запросов на выборку, изменение, обновление и удаление данных….18 3.6. Разработка процедур по защите данных (обеспечение целостности БД)…………19 4. Интерфейсы взаимодействия с БД…………………………………………………....22 Заключение………………………………………………………………………………..24 Список использованных источников……………………………………………………25 Приложение А…………………………………………………………………………….26 Приложение Б……………………………………………………………………………..29 ВведениеБаза данных – представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ). Microsoft SQL Server – система управления реляционными базами данных (РСУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка. Целью данной курсовой работы являются проектирование и разработка базы данных и приложения для работы с ней. База данных и приложение должны обеспечить возможность учета заявок центра службы занятости. Для достижения поставленной цели должны быть решены следующие задачи: 1 Изучение предметной области, с целью анализа информационных потоков. 2 Построение диаграмм IDEF0, IDEF3, DFD с целью систематизации данных, полученных в процессе анализа предметной области. 3 Проектирование базы данных средствами SQL Server. 4 Создание графического приложения средствами MS Visual Studio и установление связей с базой данных для обеспечения комфортной работы. 1 Анализ информационных потоков данных Разработка модели IDEF0 исследуемого процесса. Для построения функциональной модели обычно используется методология IDEF0. Данная методология предназначена для представления функций системы и требований анализа к системам. В IDEF0 реализованы идеи системного анализа, под которыми понимают исследования, берущие начало с общего обзора системы, а затем происходит ее детализация в виде иерархической структуры с фиксированным числом уровней. Результатом детализации являются функциональные составляющие, для каждой составляющей дается полное описание, исследуются информационные потоки и формируется структура данных. Эта методология позволяет получить наглядное представление бизнес-процессов и выявить недостатки системы. В нотации IDEF0 основными элементами диаграмм являются функциональные блоки и дуги, которые представляются соответственно прямоугольниками и стрелками. Все дуги и функциональные блоки должны быть поименованы. Дуги представляют собой информацию, в которой блоки нуждаются или ее производят. Каждый блок имеет свой номер, который размещается обычно в нижнем правом углу. В методологии IDEF0 функциональный блок, который на самом верхнем уровне иерархии представляет систему в качестве единого блока (контекстная диаграмма), детализируется на другой диаграмме с помощью нескольких блоков, соединенных между собой интерфейсными дугами. Эти блоки представляют основные подфункции единого исходного модуля. Каждый из этих подмодулей может быть декомпозирован подобным образом для более детального представления. Количество уровней иерархии не ограничивается, процесс декомпозиции блоков заканчивается тогда, когда каждый из модулей самого нижнего уровня декомпозиции может быть реализован в проектируемой системе одним программным модулем. Результат применения методологии IDEF0 – функциональная модель, которая состоит из диаграмм, фрагментов текста и глоссария, имеющих ссылки друг на друга.  Рисунок 1 – Контекстная диаграмма методологии IDEF0.  Рисунок 2 – IDEF0 – диаграмма первого уровня декомпозиции Разработка модели IDEF3 операций (работ) процесса На более низких уровнях иерархии можно использовать применение методологий IDEF3 и DFD для создания диаграмм в составе единой модели. Основными признаками для применения методологии IDEF3 является наличие логики в описании процессов, для применения методологии DFD – наличие хранилищ для промежуточного хранения данных. Нотация IDEF3 является второй важнейшей категорией после IDEF0 и ориентирована на описание логики взаимодействия информационных потоков. Особенно удобно применять IDEF3 на нижних уровнях иерархии функциональных моделей при описании работ, выполняемых в подразделениях и на рабочих местах. Центральным компонентом модели является единица работы, близкая по смыслу к работе IDEF0.  Рисунок 3 – IDEF3 – диаграмма сценария «Прием заявок в центре» Разработка модели DFD автоматизации исследуемого процесса Диаграммы потоков данных применяются для документирования механизма передачи и обработки информации в проектируемой системе, они удобны для наглядного изображения текущей работы системы документооборота организации. Обычно DFD служит в качестве дополнения IDEF0-модели. Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота.  Рисунок 4 – диаграмма потоков данных В базе данных хранятся следующие данные: организация (Код, Название, Краткое название Адрес, Контактные телефоны, электронный адрес) предоставляет услуги по трудоустройству. Организацией ведется банк данных о существующих вакансиях. По каждой вакансии поддерживается следующая информация: - предприятие (Код, Название, Краткое название Адрес, Контактные телефоны, электронный адрес); - название вакансии (должность); - требования к соискателю: пол, возраст (Верхняя граница, Нижняя граница), образование (высшее, среднее, не имеет значение и т.п.), знание определенных видов деятельности (выбор из перечня - знание электронного документооборота, определенных прикладных программ и т.п.), коммуникабельность (да, нет); - обязанности (выбор из перечня – заключение договоров, распространение агитационного материала, работа с клиентами и т.п.); - предполагаемая оплата (Нижняя граница, Верхняя граница), единицы измерения оплаты - рубли; - оформление трудовой книжки (да, нет); - наличие социального пакета (да, нет); - срок начала открытия вакансии; - срок закрытия вакансии (вакансия занята). Выбор и обоснование технологии проектирования базы данных Основными подходами к проектированию систем БД являются восходящий метод и нисходящий метод проектирования. Суть первого способа заключается в структурном проектировании снизу—вверх. В данном процессе на основе описания частей осуществляется попытка получения целого, адекватно отображающего предметную область. При использовании восходящего подхода на первом этапе происходит выявление свойств объектов (атрибутов сущностей) предметной области. Проводится анализ связей между свойствами, на основании которого свойства объединяются в таблицы (реляционные отношения). Восходящий метод проектирования применяют в распределенных БД при интеграции спроектированных локальных баз данных. Для проектирования сложных БД преимущественно применяется нисходящий подход. При таком подходе работа начинается с подготовки моделей данных, содержащих несколько высокоуровневых сущностей и связей. После этого производятся нисходящие уточнения низкоуровневых сущностей, связей и атрибутов, относящихся к ним. Нисходящий подход используется в концепции метода проектирования «сущность-связь». В основе метода лежат три элемента: сущность, атрибут, связь. Работа начинается с выявления сущностей и связей между ними. Процесс построения баз данных методом «сущность-связь» включает в себя три этапа: концептуальное, логическое и физическое проектирование [1]. Концептуальное проектирование БД – это процесс, результатом которого является создание модели имеющейся информации. Модель строится вне зависимости от любых физических аспектов ее представления. Такая модель данных формируется на основе информации, определенной в перечне требований пользователей. Особенности физической реализации (тип СУБД, язык программирования, тип вычислительной платформы и т.д.) на данном этапе не учитываются. На этапе логического проектирования БД происходит выбор модели организации данных, на основе которой создается модель используемой информации. Далее в концептуальную модель вносятся изменения и дополнения, и происходит преобразование в логическую модель данных. Созданная модель должна учитывать особенности организации данных в целевой СУБД (например, реляционная модель). На данном этапе должна быть определена целевая СУБД (реляционная, сетевая, иерархическая или объектно-ориентированная), так как построение логической модели происходит с учетом выбранной модели организации данных. С помощью метода нормализации происходит проверка правильности модели. Нормализация исключает избыточность данных, которая может привести к различным аномалиям в процессе обновления данных. Поддержка всех транзакций, которые необходимы пользователям, также должна обеспечиваться логической моделью. Физическое проектирование БД – это процесс, включающий в себя определение способов реализации и разработку описания конкретной реализации БД. В ходе данной стадии проектирования создается набор реляционных таблиц, определяется организация файлов и способы доступа к ним, а также анализируются ограничения целостности и разрабатываются средства защиты проектируемой БД. В данной работе применяется нисходящий подход. 3 Техническое проектирование 3.1 Описание объектов БД Таблица является базовой структурой реляционной базы данных, которая состоит из строк и столбцов с данными. Представление – это поименованная динамически поддерживаемая СУБД выборка данных из одной или нескольких таблиц. Описание проектируемых таблиц представлено далее (Таблицы 1-11). Диаграмма связей представлена на рисунке 5. Таблица 1 – Реляционная таблица Адрес
Таблица 2 – Реляционная таблица Организация
Таблица 3 – Реляционная таблица Образование
Таблица 4 – Реляционная таблица Абитуриент
Таблица 5 – Реляционная таблица Список курсов абитуриентов
Таблица 6 – Реляционная таблица Курсы
Таблица 7 – Реляционная таблица Документ
Таблица 8 – Реляционная таблица Контроль
Таблица 9 – Реляционная таблица Темы
Таблица 10 – Реляционная таблица тип_НП
Таблица 11 - Реляционная таблица тип_улицы
Таблица 12 - Реляционная таблица улица
Таблица 13 - Реляционная таблица НП
3.2 Инфологическая модель БД Информационно-логическая модель предметной области отражает предметную область в виде совокупности информационных объектов и их структурных связей. В данном проекте инфологическая модель отражает совокупность объектов центра службы занятости и их структурных связей.  Рисунок 5 – инфологическая модель БД. 3.2 Даталогическая модель БД Даталогическая модель данных - это описание, создаваемое проектировщиком по инфологической модели данных на языке описания данных конкретной СУБД.  Рисунок 6 – даталогическая модель данных. 3.4 Обоснование СУБД. Физическая модель данных. В данном курсовом проекте для разработки СУБД применяется MS SQL Server. Характеристика данной СУБД представлена в таблице 13. Таблица 13 – характеристика СУБД
 Продолжение таблицы 13. Физическая модель – логическая модель базы данных, выраженная в терминах языка описания данных конкретной СУБД. Физическая модель базы данных содержит все детали, необходимые конкретной СУБД для создания базы: наименования таблиц и столбцов, типы данных, определения первичных и внешних ключей и т.п. Физическая модель строится на основе логической с учетом ограничений, накладываемых возможностями выбранной СУБД. Физическая модель данной БД описана выше. 3.5 Разработка запросов В данном проекте были реализованы следующие запросы: на заданную дату список предприятий, имеющих вакансии по заданной должности  Рисунок 8 – SQL запрос на вывод вакансий.   Рисунок 9 – результат выполнения запроса название должности, на которую за заданный период было предложено максимальное количество вакансий;  Рисунок 10 – SQL запрос на вывод должности   Рисунок 11 – результат выполнения запроса на заданную дату список предприятий, предлагающих вакансии, не требующих образования.  Рисунок 12 – SQL запрос на вывод вакансий без образования.   Рисунок 13 – результат выполнения запроса 3.6 Разработка процедур по защите данных (обеспечение целостности БД) Це́лостность ба́зы да́нных (database integrity) — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint). Главное средство обеспечение доменной целостности в SQL Server - это ограничение CHECK. Оно может быть определено при создании таблицы или добавлено позднее при помощи команды ALTER TABLE. В данной базе данных целостность обеспечивается путем добавления в таблицы таких ограничений, как внешний ключ. Ограничения FOREIGN KEY был добавлены в следующие таблицы: Вакансии, соискатель, список вакансий соискателей и организация. Помимо ограничений, защита данных осуществляется при помощи ролей бд. Роль представляет собой именованных набор прав и привилегий на объект БД, в системе имеется два типа ролей: Администратор БД и Пользователь, настройки ролей представлены на рисунках 14 и 15 соответственно.  Рисунок 14 - Роль Администратор БД  Рисунок 15 - Роль Пользователь 4 Интерфейсы взаимодействия с БД Для взаимодействия с БД было разработано приложение в среде MS Visual studio 2017. В приложении возможно просматривать таблицы БД, а также реализовывать запросы, описанные выше.  Рисунок 16 – Главная форма  Рисунок 17 – выбор таблицы для просмотра  Рисунок 18 – просмотр выбранной таблицы. Для реализации запросов необходимо нажать на кнопку «Запросы», расположенную на этой же форме. В результате появится новое окно с полями для условий отбора.  Рисунок 19 – форма «Запросы» Результат выполнения запросов представлен выше. Код программы см. Приложение А. 1 2 |