БД курсовая. 1 Анализ информационных потоков данных
 Скачать 0.93 Mb.
|
1 2  ВведениеБаза данных – представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ). 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 Анализ информационных потоков данных  Рисунок 1 – Контекстная диаграмма методологии IDEF0.  Рисунок 2 – IDEF0 – диаграмма первого уровня декомпозиции Разработка модели DFD автоматизации исследуемого процесса Диаграммы потоков данных применяются для документирования механизма передачи и обработки информации в проектируемой системе, они удобны для наглядного изображения текущей работы системы документооборота организации. Обычно DFD служит в качестве дополнения IDEF0-модели. Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота.  Рисунок 4 – диаграмма потоков данных В базе данных хранятся следующие данные: организация (Код, Название, Краткое название Адрес, Контактные телефоны, электронный адрес) предоставляет услуги по трудоустройству. Организацией ведется банк данных о существующих вакансиях. По каждой вакансии поддерживается следующая информация: - предприятие (Код, Название, Краткое название Адрес, Контактные телефоны, электронный адрес); - название вакансии (должность); - требования к соискателю: пол, возраст (Верхняя граница, Нижняя граница), образование (высшее, среднее, не имеет значение и т.п.), знание определенных видов деятельности (выбор из перечня - знание электронного документооборота, определенных прикладных программ и т.п.), коммуникабельность (да, нет); - обязанности (выбор из перечня – заключение договоров, распространение агитационного материала, работа с клиентами и т.п.); - предполагаемая оплата (Нижняя граница, Верхняя граница), единицы измерения оплаты - рубли; - оформление трудовой книжки (да, нет); - наличие социального пакета (да, нет); - срок начала открытия вакансии; - срок закрытия вакансии (вакансия занята). Выбор и обоснование технологии проектирования базы данных Основными подходами к проектированию систем БД являются восходящий метод и нисходящий метод проектирования. Суть первого способа заключается в структурном проектировании снизу—вверх. В данном процессе на основе описания частей осуществляется попытка получения целого, адекватно отображающего предметную область. При использовании восходящего подхода на первом этапе происходит выявление свойств объектов (атрибутов сущностей) предметной области. Проводится анализ связей между свойствами, на основании которого свойства объединяются в таблицы (реляционные отношения). Восходящий метод проектирования применяют в распределенных БД при интеграции спроектированных локальных баз данных. Для проектирования сложных БД преимущественно применяется нисходящий подход. При таком подходе работа начинается с подготовки моделей данных, содержащих несколько высокоуровневых сущностей и связей. После этого производятся нисходящие уточнения низкоуровневых сущностей, связей и атрибутов, относящихся к ним. Нисходящий подход используется в концепции метода проектирования «сущность-связь». В основе метода лежат три элемента: сущность, атрибут, связь. Работа начинается с выявления сущностей и связей между ними. Процесс построения баз данных методом «сущность-связь» включает в себя три этапа: концептуальное, логическое и физическое проектирование [1]. Концептуальное проектирование БД – это процесс, результатом которого является создание модели имеющейся информации. Модель строится вне зависимости от любых физических аспектов ее представления. Такая модель данных формируется на основе информации, определенной в перечне требований пользователей. Особенности физической реализации (тип СУБД, язык программирования, тип вычислительной платформы и т.д.) на данном этапе не учитываются. На этапе логического проектирования БД происходит выбор модели организации данных, на основе которой создается модель используемой информации. Далее в концептуальную модель вносятся изменения и дополнения, и происходит преобразование в логическую модель данных. Созданная модель должна учитывать особенности организации данных в целевой СУБД (например, реляционная модель). На данном этапе должна быть определена целевая СУБД (реляционная, сетевая, иерархическая или объектно-ориентированная), так как построение логической модели происходит с учетом выбранной модели организации данных. С помощью метода нормализации происходит проверка правильности модели. Нормализация исключает избыточность данных, которая может привести к различным аномалиям в процессе обновления данных. Поддержка всех транзакций, которые необходимы пользователям, также должна обеспечиваться логической моделью. Физическое проектирование БД – это процесс, включающий в себя определение способов реализации и разработку описания конкретной реализации БД. В ходе данной стадии проектирования создается набор реляционных таблиц, определяется организация файлов и способы доступа к ним, а также анализируются ограничения целостности и разрабатываются средства защиты проектируемой БД. В данной работе применяется нисходящий подход. 3 Техническое проектирование База данных предназначена для компании, занимающейся трудоустройством. Основной задачей базы данных является отслеживание финансовой стороны работы по трудоустройству. Деятельность бюро организована следующим образом: компания готова искать работников для различных работодателей и вакансии для ищущих работу специалистов различного профиля. При обращении клиента-работодателя его стандартные данные (название, вид деятельности, адрес, телефон) фиксируются в базе данных. При обращении клиента-соискателя его стандартные данные (фамилия, имя, отчество, квалификация, профессия, иные данные) также фиксируются в базе данных. По каждому факту удовлетворения интересов обоих сторон составляется документ. В документе указывается соискатель, работодатель, должность и комиссионные. В базе фиксируется не только сделка, но и хранится информация по открытым вакансиям. Кроме того, для автоматического поиска вариантов необходимо вести справочник «Виды деятельности». По смыслу задачи к базе данных возможны следующие запросы: Какую вакансию получил соискатель с заданной фамилией; Какой вид деятельности предлагает работодатель; Какую квалификацию имеет соискатель; Какие должности включают в себя открытые вакансии; Исходя из поставленных задач, разработана концептуальная модель данных, которая включает в себя следующие объекты: Работодатели; Соискатели; Сделки; Открытые вакансии; Вид деятельности; Объект Соискатели связан с объектом Сделки соотношением один ко многим, объект Сделки связан с объектом Открытые вакансии соотношением один ко одному, объект Открытые вакансии связан с объектом Работодатели соотношением многие к одному, объект работодатели связан с объектом Вид деятельности соотношением многие к одному.  Рисунок 5 - Схема БД «По трудоустройству» 3.1 Описание объектов БД Исходя из концептуальной модели была создана реляционная модель. В неё входят следующие объекты: Виды деятельности; Открытые вакансии; Работодатели; Сделки; Соискатели. CREATE TABLE Вид деятельности ( Код вид деятельности INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, Вид деятельности VARCHAR (20) NOT NULL,(Код вид деятельности) ); TABLE Соискатели ( Код соискателя INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, Код вид деятельности INTEGER UNSIGNED NOT NULL, Фамилия VARCHAR (20) NULL, Имя VARCHAR (20) NULL, Отчество VARCHAR (20) NULL, Квалификация VARCHAR (45) NULL, Иные данные VARCHAR (255) NULL, Предполагаемый размер заработной платы NUMERIC NULL, KEY (Код соискателя),Соискатели_FKIndex1(Код вид деятельности),KEY(Код вид деятельности)Вид деятельности(Код вид деятельности) ON DELETE NO ACTIONUPDATE NO ACTION ); TABLE Работодатели ( Код работодателя INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, Код вид деятельности INTEGER UNSIGNED NOT NULL, Название VARCHAR (45) NULL, Адрес VARCHAR (45) NULL, Телефон VARCHAR (20) NULL,KEY(Код работодателя), Работодатели_FKIndex1(Код вид деятельности),KEY(Код вид деятельности)Вид деятельности(Код вид деятельности) ON DELETE NO ACTIONUPDATE NO ACTION ); TABLE Открытые вакансии ( Код вакансий INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, Код работодателя INTEGER UNSIGNED NOT NULL, Должность VARCHAR (20) NULL, KEY (Код вакансий), Открытые вакансии_FKIndex1(Код работодателя), FOREIGN KEY (Код работодателя) REFERENCES Работодатели (Код работодателя) ON DELETE NO ACTIONUPDATE NO ACTION ); TABLE Сделки ( Код сделки INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, Код вакансий INTEGER UNSIGNED NOT NULL, Код соискателя INTEGER UNSIGNED NOT NULL, Комиссионные NUMERIC NULL, KEY (Код сделки), Сделки_FKIndex1(Код соискателя), INDEX Сделки_FKIndex 2(Код вакансий), FOREIGN KEY (Код соискателя) REFERENCES Соискатели (Код соискателя) ON DELETE NO ACTIONUPDATE NO ACTION, KEY (Код вакансий) Открытые вакансии (Код вакансий) DELETE NO ACTIONUPDATE NO ACTION); 3.2 Инфологическая модель БД Информационно-логическая модель предметной области отражает предметную область в виде совокупности информационных объектов и их структурных связей. В данном проекте инфологическая модель отражает совокупность объектов центра службы занятости и их структурных связей.  Рисунок 5 – инфологическая модель БД. 3.3 Обоснование СУБД. Даталогическая модель БД СУБД представляет собой комплекс инструментальных средств, программных и языковых, реализующих централизованное управление БД и обеспечивающих доступ к данным (изменения, добавления, удаления, резервного копирования и т.д.), роль которых как единого средства хранения, обработки и доступа к большим объемам информации постоянно возрастает. Быстрое развитие потребностей применений БД выдвигает новые требования к СУБД: естественные и эффективные представления в БД разнообразных отношений между объектами предметных областей (например, пространственно-временных с обеспечением визуализации данных. В данном курсовом проекте для разработки СУБД применяется MS SQL Server. Характеристика данной СУБД представлена в таблице 13. Таблица 13 – сравнение СУБД  В данном курсовом проекте для разработки СУБД применяется MS SQL Server. Характеристика данной СУБД представлена в таблице 14. Таблица 14 – характеристика СУБД
Даталогическая модель данных - это описание, создаваемое проектировщиком по инфологической модели данных на языке описания данных конкретной СУБД.  Рисунок 6 – даталогическая модель данных. 3.4 Физическая модель данных. Физическая модель – логическая модель базы данных, выраженная в терминах языка описания данных конкретной СУБД. Физическая модель базы данных содержит все детали, необходимые конкретной СУБД для создания базы: наименования таблиц и столбцов, типы данных, определения первичных и внешних ключей и т.п. Физическая модель строится на основе логической с учетом ограничений, накладываемых возможностями выбранной СУБД. Таблица является базовой структурой реляционной базы данных, которая состоит из строк и столбцов с данными. Представление – это поименованная динамически поддерживаемая СУБД выборка данных из одной или нескольких таблиц. Описание проектируемых таблиц представлено далее (Таблицы 1-13). Таблица 1 – Реляционная таблица Адрес
Таблица 2 – Реляционная таблица Организация
Таблица 3 – Реляционная таблица Образование
Таблица 4 – Реляционная таблица Абитуриент
Таблица 5 – Реляционная таблица Список курсов абитуриентов
Таблица 6 – Реляционная таблица Курсы
Таблица 7 – Реляционная таблица Документ
Таблица 8 – Реляционная таблица Контроль
Таблица 9 – Реляционная таблица Темы
Таблица 10 – Реляционная таблица тип_НП
Таблица 11 - Реляционная таблица тип_улицы
Таблица 12 - Реляционная таблица улица
Таблица 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 |
