ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 29.11.2023
Просмотров: 39
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Введение
База данных – представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).
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 Обоснование СУБД. Даталогическая модель БД
СУБД представляет собой комплекс инструментальных средств, программных и языковых, реализующих централизованное управление БД и обеспечивающих доступ к данным (изменения, добавления, удаления, резервного копирования и т.д.), роль которых как единого средства хранения, обработки и доступа к большим объемам информации постоянно возрастает. Быстрое развитие потребностей применений БД выдвигает новые требования к СУБД: естественные и эффективные представления в БД разнообразных отношений между объектами предметных областей (например, пространственно-временных с обеспечением визуализации данных.