Размещено на http://www.allbest.ru/

Уральский институт экономики, управления и права

Курсовая работа

По базе данных

Тема: Проектирование реляционной базы данных на примере предметной области "Работники школы"

Студентка:

Группа:

Специальность: «Прикладная информатика в экономики»

Преподаватель: Татьяна

Нижний Тагил

2011 год



Содержание

Введение

Глава 1. Теоретические основы проектирования БД.

1.1 Модели данных

1.2 Этапы проектирования БД

1.3 Нормализация реляционных БД

Глава 2. Разработка реляционной базы данных для предметной области «Работники школы».

2.1 Постановка задачи

2.2 Описание БД на языке ER-диаграмм и на языке инфологического моделирования

2.3 Схема данных

2.4 Таблицы

2.5 Запросы

2.6 Формы

2.7 Отчеты

Заключение

Литература



Введение:

Использование баз данных (БД) в настоящее время является неотъемлемой частью функционирования большинства предприятий и деловой деятельности программиста. В связи с этим все большую актуальность приобретает освоение студентами основных принципов построения и эффективного применения соответствующих технологий и программных продуктов - систем управления базами данных (СУБД).

В данной работе в качестве предметной области рассматриваются работники школы: учителя, охрана, обслуживающий персонал.

Целью данной курсовой работы является разработка базы данных «Работники школы» средствами Microsoft Access.

Задачи курсовой работы:

1. Исследовать предметную область;

2. Спроектировать базу данных;

3. Создать формы для работы с базой;

В курсовой работе будет представлена работа с формами, запросами и отчетами в разработке инфологической модели.



Глава 1. Теоретические основы проектирования БД.

1.1 . Модели данных

Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь".

Инфологическая модель должна быть отображена в компьютеро-ориентированную даталогическую модель, "понятную" СУБД. В процессе развития теории и практического использования баз данных, а также средств вычислительной техники создавались СУБД, поддерживающие различные даталогические модели. Сначала стали использовать иерархические даталогические модели. Простота организации, наличие заранее заданных связей между сущностями, сходство с физическими моделями данных позволяли добиваться приемлемой производительности иерархических СУБД на медленных ЭВМ с весьма ограниченными объемами памяти. Но, если данные не имели древовидной структуры, то возникала масса сложностей при построении иерархической модели и желании добиться

нужной производительности. Сетевые модели также создавались для мало ресурсных ЭВМ. Это достаточно сложные структуры, состоящие из "наборов" - поименованных двухуровневых деревьев. "Наборы" соединяются с помощью "записей-связок", образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество "маленьких хитростей", позволяющих увеличить производительность СУБД, но существенно усложнивших последние. Прикладной программист должен знать массу терминов,

изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Один из разработчиков операционной системы UNIX сказал "Сетевая база - это самый верный способ потерять данные". Сложность практического использования иерархических и сетевых СУБД заставляла искать иные способы представления данных. В конце 60-х годов появились СУБД на основе инвертированных файлов, отличающиеся простотой организации и

наличием весьма удобных языков манипулирования данными. Однако такие СУБД обладают рядом ограничений на количество файлов для хранения данных, количество связей между ними, длину записи и количество ее полей.

Физическая организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для поднастройки модели под конкретную БД. Разнообразие способов корректировки физических моделей современных промышленных СУБД не позволяет рассмотреть их в этом разделе.

1.2. Этапы проектирования БД

Создание и внедрение в практику современных информационных систем автоматизированных баз данных выдвигает новые задачи проектирования, которые невозможно решать традиционными приемами и методами. Большое внимание необходимо уделять вопросам проектирования баз данных. От того, насколько успешно будет спроектирована база данных, зависит эффективность функционирования системы в целом, ее жизнеспособность и возможность расширения и дальнейшего развития. Поэтому вопрос проектирования баз данных выделяют как отдельное, самостоятельное направление работ при разработке информационных систем.

Проектирование баз данных -- это итерационный, многоэтапный процесс принятия обоснованных решений в процессе анализа информационной модели предметной области, требований к данным со стороны прикладных программистов и пользователей, синтеза логических и физических структур данных, анализа и обоснования выбора программных и аппаратных средств. Этапы проектирования баз данных связаны с многоуровневой организацией данных. Рассматривая вопрос проектирования баз данных, будем придерживаться такого многоуровневого представления данных: внешнего, инфологического, логического (даталогического) и внутреннего.

Такое представление уровней данных не единственное. Существуют и другие варианты многоуровневого представления данных. Так, в соответствии с предложениями исследовательской группы по системам управления данными Американского национального института стандартов ANSI/X3/SPARC, а также CODASYL (Conference on Data Systems Languages), как правило, выделяется три уровня представления данных:

· внешний уровень (с точки зрения конечного пользователя и прикладного программиста),

· концептуальный уровень (с точки зрения СУБД),

· внутренний уровень (с точки зрения системного программиста).

В соответствии с этой концепцией внешний уровень это часть (подмножество) концептуальной модели, необходимая для реализации какого-либо запроса или прикладной программы. То есть, если концептуальная модель выступает как схема, поддерживаемая конкретной СУБД, то внешний уровень -- это некоторая совокупность подсхем, необходимых для реализации конкретной прикладной программы или запроса пользователя.

Существует также другая точка зрения, в соответствии с которой под внешним уровнем понимают более общие понятия, связанные с изучением и анализом информационных потоков предметной области и их структуризацией. Некоторые авторы вводят вспомогательный уровень (промежуточный между внешним и даталогическим уровнями), который называется инфологическим. Он может выступать как самостоятельный или быть составной частью внешнего уровня.

Такая концепция более целесообразна с точки зрения понимания процесса проектирования БД. Поэтому будем рассматривать инфологический уровень как самостоятельный уровень представления данных. Внешний уровень в этом случае выступает как отдельный этап проектирования, на котором изучается все внемашинное информационное обеспечение, то есть формы документирования и представления данных, а также внешняя среда, в которой будет функционировать банк данных с точки зрения методов фиксации, сбора и передачи информации в базу данных.

При проектировании БД на внешнем уровне необходимо изучить функционирование объекта управления, для которого проектируется БД, всю первичную и выходную документацию с точки зрения определения того, какие именно данные необходимо сохранять в базе данных. Внешний уровень это, как правило, словесное описание входных и выходных сообщений, а также данных, которые целесообразно сохранять в БД. Описание внешнего уровня не исключает наличия элементов дублирования, избыточности и несогласованности данных. Поэтому для устранения этих аномалий и противоречий внешнего описания данных выполняется инфологическое проектирование.

Инфологическая модель является средством структуризации предметной области и понимания концепции семантики данных. Инфологическую модель можно рассматривать в основном как средство документирования и структурирования формы представления информационных потребностей, которая обеспечивает непротиворечивое общение пользователей и разработчиков системы.

Все внешние представления интегрируются на инфологическом уровне, где формируется инфологическая (каноническая) модель данных, которая не является простой суммой внешних представлений данных.

Инфологический уровень представляет собой информационно-логическую модель (ИЛМ) предметной области, из которой исключена избыточность данных и отображены информационные особенности объекта управление без учета особенностей и специфики конкретной СУБД. То есть инфологическое представление данных ориентированно преимущественно на человека, который проектирует или использует базу данных.

Логический (концептуальный) уровень построен с учетом специфики и особенностей конкретной СУБД. Этот уровень представления данных ориентирован больше на компьютерную обработку и на программистов, которые занимаются ее разработкой. На этом уровне формируется концептуальная модель данных, то есть специальным способом структурированная модель предметной области, которая отвечает особенностям и ограничениям выбранной СУБД. Модель логического уровня, поддерживаемую средствами конкретной СУБД, называют еще даталогической.

Инфологическая и даталогическая модели, которые отображают модель одной предметной области, зависимы между собой. Инфологическая модель может легко трансформироваться в даталогическую модель.

Внутренний уровень связан с физическим размещением данных в памяти ЭВМ. На этом уровне формируется физическая модель БД, которая включает структуры сохранения данных в памяти ЭВМ, в т.ч. описание форматов записей, порядок их логического или физического приведения в порядок, размещение по типам устройств, а также характеристики и пути доступа к данным. От параметров физической модели зависят такие характеристики функционирования БД: объем памяти и время реакции системы. Физические параметры БД можно изменять в процессе ее эксплуатации с целью повышения эффективности функционирование системы. Изменение физических параметров не предопределяет необходимости изменения инфологической и даталогической моделей. Схема взаимосвязи уровней представления данных в БД изображена на рис.1.1. В соответствии с этими уровнями проектируется БД. Проектирование БД-- этосложный и трудоемкий процесс, который требует привлечения многих высококвалифицированных специалистов. От того, насколько квалифицированно спроектирована БД, зависят производительность информационной системы и полнота обеспечения функциональных потребностей пользователей и прикладных программ. Неудачно спроектированная БД может усложнить процесс разработки

прикладного программного обеспечения, обусловить необходимость использования более сложной логики, которая, в свою очередь, увеличит время реакции системы, а в дальнейшем может привести к необходимости перепроектирования логической модели БД. Реструктуризация или внесение изменений в логическую модель БД это очень нежелательный процесс, поскольку он является причиной необходимости модификации или даже перепрограммирование отдельных задач. Все работы, которые выполняются на каждом этапе проектирования, должны интегрироваться со словарем данных. Каждый этап проектирования рассматривается как определенная последовательность итеративных процедур, в результате, которых формируется определенная модель БД.



Рис. 1.1. Схема взаимосвязи уровней представление данных в БД

Внешний уровень -- подготовительный этап инфологического проектирования.

Целью проектирования на внешнем уровне является разработка внемашинного информационного обеспечения, которое включает систему входной (первичной) документации, характеризующую определенную предметную область, систему классификации и кодирования технико-экономической информации, а также перечень соответствующих выходных сообщений, которые нужно формировать с помощью БнД.

Существуют два подхода к проектированию баз данных на внешнем уровне: «от предметной области» и «от запроса». Подход «от предметной области» состоит в том, что формируется внешнее информационное обеспечение всей предметной области без учета потребностей пользователей и прикладных программ. Иногда этот подход называют еще объектным или непроцессным.

При подходе «от запроса» основным источником информации о предметной области есть изучение запросов пользователей и потребностей прикладных программ. Этот подход также называется процессным или функциональным. При таком подходе БД проектируется для выполнения текущих задач управления без учета возможности расширение системы и возникновение новых задач управление. Преимущество подхода «от предметной области» это его объективность, системность при отображении ПО и стойкость информационной модели, возможность реализации большого количества прикладных программ и запросов, в том числе незапланированных при создании БД. Недостатком этого подхода является значительный объем работ, которые необходимо выполнить при определении информации, подлежащей хранению в БД, что, соответственно, усложняет и увеличивает срок разработки проекта.

Функциональный подход ориентирован на реализацию текущих требований пользователей и прикладных программ без учета перспектив развития системы. При его использовании могут возникнуть сложности в агрегации требований разных пользователей и прикладных программ. Тем не менее, при таком подходе значительно уменьшается трудоемкость проектирования, и поэтому возможно создать систему с высокими эксплуатационными характеристиками. Однако взятый в отдельности любой из этих методов не может дать достаточно информации для проектирования рациональной структуры БД. Поэтому при проектировании БД целесообразно совместно использовать эти два подхода. Если схематично представить процесс проектирования БД на внешнем уровне, то он состоит из таких работ.

1. Определение функциональных задач предметной области, которые подлежат автоматизированному решению. Поскольку основной целью создания БД есть обеспечение информацией функций обработки данных, то, прежде всего, необходимо изучить все функции предметной области (объекта управления), для которой разрабатывается база данных, и проанализировать их особенности. Функции и функциональные особенности объекта управление необходимо изучать в неразрывной связи с изучением функциональных требований к данным со стороны будущих пользователей информационной системы. Изучение и анализ предусматривают выявление информационных потребностей и определения информационных потоков. Эти работы можно выполнять обследованием предметной области и анкетированием ее сотрудников. Результатом такого изучения может быть перечень функциональных задач, которые должны решаться автоматизированным способом с использованием БД.

2. Изучение и анализ оперативных первичных документов. Изучив функции и определив перечень функциональных задач, которые подлежат автоматизированному решению, переходят к изучению оперативных документов, которые используются на входе каждой задачи или их комплекса. Изучив и проанализировав все оперативные документы (как внешние, так и внутренние), которые используются на входе каждой задачи, определяют, какие реквизиты этих документов нужно сохранять в БД.

3. Изучение нормативно-справочных документов. На третьем шаге изучают и анализируют всю нормативно-справочную документацию. К такой документации принадлежат различные классификаторы, сметы, договоры, нормативы, законодательные акты по налоговой политике, плановая документация и т.п. Распределение и отдельный анализ оперативной и нормативно-справочной информации обусловлены технологически. В базы данных различаются технологии создания и ведения файлов условно-постоянной информации, размещенной в нормативно-справочной документации, и файлов оперативной информации.

4. Изучение процессов преобразования входных сообщений в выходные.

Прежде всего, изучаются все выходные сообщения, которые выдаются на печать или на экран и сохраняются в виде выходных массивов на МД. Это необходимо для того, чтобы определить, которые из атрибутов входных сообщений нужно сохранять в БД для получения выходных сообщений. Кроме того, на этом этапе определяются те показатели, которые получают во время решения задачи в результате выполнения определенных вычислений. По каждому расчетному показателю следует определить алгоритм его формирования и убедиться в том, что этот показатель можно получить на основе атрибутов оперативной и нормативно-справочной информации, которые были определены на втором и третьем шагах. Если определенных данных не хватает для полного выполнения расчетов, необходимо возвратиться назад, провести дополнительное исследование и

определить, где и каким способом можно получить атрибуты, которых не хватает. Кроме того, нужно определиться, какие из расчетных показателей целесообразно сохранять в БД. Показатели, полученные расчетным путем, как правило, в БД не сохраняются. Исключением являются случаи, когда расчетный показатель нужно использовать для решения других задач или для данной задачи, но в следующие календарные периоды.

При проведении проектных работ на внешнем уровне надо учитывать то, что для выполнения определенных функций в БД необходимо сохранять дополнительные данные, которые не отображены в документах (данные календаря, статистические данные и т.п.). Обобщенная схема процесса изучения документов и данных при проектировании на внешнем уровне изображена на рис.1.2.



Рис.1.2. Обобщенная схема процесса проектирование на внешнем уровне

Такое изучение необходимо провести по каждой функциональной задаче или их комплексу, которые будут решаться с помощью БД.

Результатом проектирования на внешнем уровне будет перечень атрибутов (реквизитов) оперативной и условно-постоянной информации, которые необходимо хранить в БД, с указанием источников их получения и формы представления.

Однако этот перечень не исключает возможности существования в нем збыточности, дублирования, несогласованности и других недостатков. Поэтому на этом процесс не заканчивается, а осуществляется переход к этапу инфологического проектирования.

1.3. Нормализация реляционных баз данных

При наличии определенных зависимостей между атрибутами таблиц и дублированием данных в таблицах выделяют шесть нормальных форм: первая, вторая, третья, усиленная третья (НФБК), четвертая, пятая. Процесс проектирования БД с использованием метода нормальных форм является итерационным и заключается в последовательном переводе отношений из первой нормальной формы в нормальную форму более высокого порядка по определенным правилам. Каждая следующая нормальная форма ограничивает определенный тип функциональных зависимостей, сохраняет свойства предшествующей нормальной формы и устраняет избыточное дублирование. Основная операция, применяемая при переходе отношения из одной нормальной формы в другую - это операция проекции.

Отношение находится в первой нормальной форме, если все его атрибуты являются простыми.

Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме (каждый атрибут является простым) и каждый не ключевой атрибут функционально полно зависит от первичного ключа, причем ключ, как правило, составной. Если имеет место частичная функциональная зависимость, то для ее устранения необходимо использовать операцию проекции различных отношений на два новых следуюшим образом: построить проекцию без атрибутов, находящихся в частичной функциональной зависимости от составного ключа и построить проекции на части составного первичного ключа и атрибутов, зависящих от этих частей. Перевод таблиц во вторую нормальную форму обычно позволяет устранить явное избыточное дублирование.

Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и каждый не ключевой атрибут нетранзитивно зависит от первичного ключа. Транзитивные зависимости порождают избыточное дублирование информации. Для устранения транзитивных зависимостей необходимо с помощью операции проекции преобразовать исходное отношение таким образом, чтобы в получаемом отношении отсутствовала транзитивная зависимость между атрибутами.

На практике построение третьей нормальной формы в большинстве случаев является достаточным и приведенный к ней процесс проектирования БД завершается. Если же в отношении имеет место зависимость атрибутов составного ключа от неключевых атрибутов, то необходимо перейти к усиленной третьей нормальной форме. Отношение находится в НФБК, если оно находится в третьей нормальной форме и в нем отсутствуют зависимости ключей от неключевых атрибутов.

Кроме метода нормальных форм применяется метод ER-диаграмм. Если метод нормальных форм используется обычно при проектировании отношений небольших БД, то метод «сущность-связь» позволяет проектировать большие БД. Каждая сущность (информационный объект) представляется как отношение, а связи между сущностями позволяют установить связи между таблицами (отношения) и ввести ключевой атрибут в таблицу для установления этих связей.

Отношение находится в 4НФ, если оно находится в НФБК и в нем отсутствуют многозначные зависимости, не являющиеся функциональными.

Тот факт, что отношение может быть восстановлено без потерь соединением некоторых его проекций, известен как зависимость по соединению. Говорят, что отношение находится в 5НФ тогда и только тогда, когда любая зависимость по соединению в R определяется возможными ключами R. Другими словами, каждая проекция R содержит не менее одного возможного ключа и по крайней мере один непервичный атрибут.



Глава 2. Разработка реляционной базы данных для предметной области «Работники школы»

2.1 Постановка задачи

Обоснование выбора программных средств разработки: На первом шаге в соответствии с заданием создаем информационную базу данных в среде Microsoft Access.

Предметная область: Данная БД предназначена для облегчения труда работников школы, что будет выражаться, например, в частичном (а затем и полном) отказе от заполнения многочисленных бумажек и формуляров. В данной БД будут храниться информация о личных и служебных данных работников. Добавление, удаление и редактирование данных происходит посредством СУБД Access.

Входные данные: В данной БД мы используем 3 таблицы: Личная информация, Персонал, Служебная информация.

Таблица Персонал - это таблица с данными о сотрудниках школы. Поле ИНН- ключевое поле таблицы. Поля Фамилия, Имя, служат для хранения фамилии и имени сотрудников школы. Дата рождения, Занимаемая должность - это соответственно поля Дата рождения, Занимаемая Должность. В таблице Занимаемая Должность хранятся данные о должностях сотрудников школы.

Таблица Личная информация- это таблица с данными: домашний адрес, контактный телефон, семейное положение, количество детей у сотрудников школы. Поле ИНН - это ключевое поле таблицы.

В таблице Служебная информация хранятся данные о: номер страхового свидетельства - текстовое поле, где хранятся номера страховых свидетельств, дата приема на работу, дата увольнения, номер приказа о приеме на работу, номер приказа об увольнение, начало трудовой деятельности- это соответственно поля Дата приема на работу, Дата увольнения, Номер приказа о приеме на работу, Номер приказа об увольнение, Начало трудовой деятельности. Поле ИНН - ключевое поле таблицы.

2.2 Описание БД на языке ER-диаграмм и на языке инфологического моделирования

Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).

Сущность - любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. В нашей базе данных «Работники школы», сущности - это люди. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть Фамилия, а экземпляром - Иванов, Сидоров и т.д.

Атрибут - поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей. Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности: Иванов являются страховой номер, инн и т.д. каждому экземпляру сущности присваивается только одно значение атрибута.

Ключ - минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.

Связь - ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных - это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

Характеристика связей и язык моделирования:

При построении инфологических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). В них сущности изображаются помеченными прямоугольниками, ассоциации - помеченными ромбами или шестиугольниками, атрибуты - помеченными овалами, а связи между ними - ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение.

Между двумя сущностям, возможны четыре вида связей:

1. ОДИН-К-ОДНОМУ

2. ОДИН-КО-МНОГИМ.

3. МНОГИЕ-К-ОДНОМУ

4. МНОГИЕ-КО-МНОГИМ.

В данной базе данных «Работники школы» используется только второй тип связи. Один ко многим. Одной должности могут соответствовать несколько сотрудников школы. Вести один предмет могут несколько преподавателей (сотрудников). В одно подразделение может входить несколько должностей.

2.3 Схема данных

На данном этапе на Схему данных MS Access выносятся все созданные

таблицы и устанавливаются связи между ними. При установлении связей между таблицами необходимо установить режим обеспечения целостности данных.

Рис. 1



Просмотр списка объектов, использующих указанный объект, помогает осуществлять поддержку базы данных и предотвращать ошибки, связанные с потерей источников записей. Реализована возможность просматривать объекты, зависящие от данного объекта, а также объекты, от которых зависит он.

2.4 Таблицы

Создаем таблицу Личная информация (Рис. 2) с помощью Конструктора, Путем ввода данных задаются названия полей, типы данных. В данной таблице созданы следующие поля: ИНН - тип данных числовой, Домашний адрес - тип данных текстовый, контактный телефон - тип данных текстовый, семейное положение - тип данных логический, количество детей - тип данных числовой. Для изменения типа данных нажимаем в столбце Тип данных на поле, в котором нужно изменить тип данных. Справа в этом поле появляется стрелочка, при нажатии на нее появляются возможные типы данных, где и выбираем нужный тип. С помощью Конструктора задаем Ключевое поле (ИНН), т.к. с помощью этого поля можно связывать данную таблицу с другими, и для каждого ИНН соответствует свой код.

Рис.2



Создаем таблицу Персонал (Рис. 3) с помощью Конструктора, Путем ввода данных задаются названия полей, типы данных. В данной таблице созданы следующие поля: ИНН - тип данных числовой, Фамилия - тип данных текстовый, Имя - тип данных текстовый, дата рождения - тип данных Дата/ Время, Занимаемая должность - тип данных текстовый. С помощью Конструктора задаем Ключевое поле (ИНН).

Рис. 3

Создаем таблицу (Служебная информация) с помощью Конструктора, Путем ввода данных задаются названия полей, типы данных. В данной таблице созданы следующие поля: ИНН - тип данных числовой, Номер страхового свидетельства - тип данных числовой, Дата приема на работу - тип данных Дата/ Время, Дата увольнения - тип данных Дата/ Время, Номер приказа о приеме на работу - тип данных числовой, номер приказа об увольнении - тип данных текстовый, Начало трудовой деятельности - тип данных Дата/ Время. С помощью Конструктора задаем Ключевое поле (ИНН), т.к. с помощью этого поля можно связывать данную таблицу с другими, и для каждого ИНН соответствует свой код.



Рис. 4

2.5 Запросы

Запросы особенно цены тем, что в отличие от фильтров могу выполнять не только информационно - справочную функцию, отображая необходимые данные из таблиц, но и производить некоторый анализ данных. Например, можно построить запрос, который будет отображать сведения о молодых специалистах данной школы. Кроме того, запросы готовы взять на себя сложные операции манипулирования данными: так называемые запросы на изменение позволяют, например, удалить сразу несколько записей, удовлетворяющих определенному условию, создать новую таблицу по результатам запроса или скопировать данные из одной таблицы в другую. Однако список преимуществ запросов этим далеко не ограничивается. Запросы позволяют собирать воедино информацию из одной или нескольких таблиц, учитывая связи, установленные между таблицами.

Один к одному. Каждой записи главной таблицы соответствует одна связанная запись подчиненной таблицы. Такой тип отношения используется редко, так как все данные фактически могу быть помещены в одну таблицу. Он полезен, когда целесообразно разделить одну громоздкую таблицу, содержащую множество полей, на две.

Один ко многим. Одна запись главной таблицы связана с множеством записей подчиненной таблице.

Многие ко многим. Каждой записи главной таблицы соответствует много записей подчиненной таблицы и наоборот. Через связующую таблицу, содержащую ключ первой и второй таблицы.

Можно указать какая часть результирующих записей будет отображена. В запросе можно задать выполнение вычислений, основываясь на значениях полей таблицы. Существующий запрос можно в дальнейшем использовать в качестве основы при создании нового запроса, который вы можете изменить и сохранить под другим именем. Результат работы запроса - группа записей, которые удовлетворяют заданному критерию запроса. Совокупность этих записей называется динамическим набором записей и отображается в виде таблицы. В Access можно создать различные виды запросов:

1. Наиболее часто используемым типом запроса является запрос на выборку, осуществляет выборку данных, соответствующих указанному условию отбора, из одной или нескольких таблиц.

2. Программа позволяет создать четыре различных типа запроса на изменение:

- запрос на создание таблицы позволяет сохранить результирующий набор записей в качестве новой таблицы;

- запрос на обновление записей используется для изменения данных в соответствии с заданным выражением.

- запрос на добавление добавляет записи, соответствующие заданному условию, в другую таблицу.

- запрос на удаление удаляет записи, соответствующие заданному условию.

Создаем Запрос (о молодых специалистах (стаж работы менее 3 лет)) в режиме Конструктора. (Рис.6) В качестве источника укажем таблицы: Служебная информация и Персонал. Задаем нужные поля: Фамилия, Имя, Занимаемая должность, Начало трудовой деятельности. Условие запроса касается молодых специалистов стаж работы, которых менее 3 лет, поэтому условие будем писать в соответствующем столбце. Так как стаж работы менее 3 лет, то условие запишется: <1095.

Рис. 6

Создаем Запрос (работники, прибывшие за прошедший год) в режиме Конструктора. (Рис.7) В качестве источника укажем таблицы: Служебная информация и Персонал. Задаем нужные поля: Фамилия, Имя, Занимаемая должность, Дата приема на работу, Номер приказа о приеме на работу. Условие запроса касается работников, прибывших за прошлый год.



Рис. 7

база данных реляционный инфологическое моделирование

Создаем Запрос (работники, уволенные за последний год) в режиме Конструктора. (Рис.8) В качестве источника укажем таблицы: Служебная информация и Персонал. Задаем нужные поля: Фамилия, Имя, Занимаемая должность, Дата увольнения, Номер приказа об увольнении. Условие запроса касается работников, уволенных за последний год, поэтому условие будем писать в соответствующем столбце. Так как работники, уволенные за последний год, то условие запишется: <365.



Рис.8

Создаем Запрос (сортировка по должностям) в режиме Конструктора. (Рис.9) В качестве источника укажем таблицы: Персонал и Служебная информация. Задаем нужные поля: Фамилия, Имя, Занимаемая должность, ИНН, Номер страхового свидетельства. Условие запроса осуществляет выборку данных по должностям, из нескольких таблиц. В Условия отбора вписываем: [Введите должность].



Рис. 9

2.6 Формы

Для удобства ввода значений в таблицы базы данных предусмотрена возможность Создания форм. Создадим новую форму, в свойствах выберем Источник записей - Сортировка по должностям. Рис. 10(а) На форму выносим поля и их названия: Фамилия, Имя, Персонал ИНН, Номер страхового свидетельства, Служебная информация ИНН. Для этого берем нужные поля и тянем, в какое-либо место формы. Добавляем в форму кнопки: Предыдущая запись, Следующая запись, Последняя запись, Первая запись, Добавить запись, Удалить запись, Выход из формы. После этого установим некоторые свойства формы. На панели инструментов нажмем на кнопку свойства: в пункте Применение фильтров поставим да, в пункте Всплывающее окно поставим да, т.е. всплывающая форма всегда располагается над другими окнами Access, в ячейке свойства Тип границы выберем Тонкая (запрет изменения размеров формы), уберем полосы прокрутки, кнопки размеров окна, кнопки перехода в соответствующих ячейках и кнопку закрытия.

( Рис.10(а,б))

Рис.10 (а) Форма в режиме конструктора

Рис. 10 (б) Внешний вид созданной формы

Создадим форму в режиме Конструктора с Заголовком: Молодые специалисты. Рис. 11(а) На форму выносим поля и их названия: Фамилия, Имя, Занимаемая должность, Начало трудовой деятельности. Для этого берем нужные поля и тянем, в какое-либо место формы. Добавляем в форму кнопки: Предыдущая запись, Следующая запись, Последняя запись, Первая запись, Добавить запись, Удалить запись, Выход из формы.

Рис.11 (а) Форма в режиме конструктора

Рис. 11 (б) Внешний вид созданной формы



Создадим форму в режиме Конструктора с Заголовком: Общая форма. Рис. 12(а,б) На форму выносим поля и их названия: ИНН, Фамилия, Имя, Занимаемая должность, Дата рождения, Домашний адрес, Контактный телефон, Женат (замужем), количество детей, Номер страхового свидетельства, Дата приема на работу, Дата увольнения, Номер приказа о приеме на работу, Номер приказа об увольнении, Начало трудовой деятельности. Для этого берем нужные поля и тянем, в какое-либо место формы. Добавляем в форму кнопки: Предыдущая запись, Следующая запись, Последняя запись, Первая запись, Добавить запись, Удалить запись, Выход из формы.



Рис.12 (а) Форма в режиме конструктора



Рис. 12 (б) Внешний вид созданной формы

Создадим новую форму, в свойствах выберем Источник записей - Работники, прибывшие за прошедший год. Рис. 13(а,б) На форму выносим поля и их названия: Фамилия, Имя, Занимаемая должность, Дата приема на работу, Номер приказа о приеме на работу. Для этого берем нужные поля и тянем, в какое-либо место формы. Добавляем в форму кнопки: Предыдущая запись, Следующая запись, Последняя запись, Первая запись, Добавить запись, Удалить запись, Выход из формы.



Рис.13 (а) Форма в режиме конструктора

Рис. 13 (б) Внешний вид созданной формы

Создадим новую форму, в свойствах выберем Источник записей - Работники, прибывшие за прошедший год. Рис. 14 (а,б) На форму выносим поля и их названия: Фамилия, Имя, Занимаемая должность, Дата увольнения, Номер приказа об увольнении. Для этого берем нужные поля и тянем, в какое-либо место формы. Добавляем в форму кнопки: Предыдущая запись, Следующая запись, Последняя запись, Первая запись, Добавить запись, Удалить запись, Выход из формы.

Рис.14 (а) Форма в режиме конструктора

Рис. 14 (б) Внешний вид созданной формы



2.7 Отчеты

Отчет является эффективным средством представления данных в печатном формате. Имея возможность управлять размером и внешним видом всех элементов отчета, пользователь может отобразить сведения желаемым образом.

Создадим отчет в режиме Конструктора. Для начала добавим Заголовок отчета, который будет использоваться в качестве титульной страницы: Общий отчет. Затем откроем форму «Общая», возьмем из него поля: и переместим в область данных. Затем нажимаем на Вид и сохраняем отчет под именем Общий. (Рис15,16).

Рис. 15. Отчет в режиме конструктора



Рис. 16. Внешний вид созданного отчета

Создадим отчет в режиме Конструктора. Для начала добавим Заголовок отчета, который будет использоваться в качестве титульной страницы: Работники, прибывшие за прошедший год. Затем откроем форму «Работники, прибывшие за прошедший год», возьмем из него поля: и переместим в область данных. Затем нажимаем на Вид и сохраняем отчет под именем Работники, прибывшие за прошедший год. (Рис17,18).

Рис. 17. Отчет в режиме конструктора



Рис. 18. Внешний вид созданного отчета

Создадим отчет в режиме Конструктора. Для начала добавим Заголовок отчета, который будет использоваться в качестве титульной страницы: Работники, уволенные за последний год. Затем откроем форму «Работники, уволенные за последний год», возьмем из него поля: и переместим в область данных. Затем нажимаем на Вид и сохраняем отчет под именем Работники, уволенные за последний год. (Рис19, 20).

Рис. 19. Отчет в режиме конструктора



Рис. 20. Внешний вид созданного отчета



Заключение

В ходе выполнения курсовой работы была создана база данных в Microsoft Access «Работники школы». Данная база служит для хранения в ней необходимой информации. В рамках этой базы данных используются следующие объекты:

­ Таблицы (Личная информация, Персонал, Служебная информация) для сохранения данных;

­ Запросы (Молодые специалисты, Работники, прибывшие за прошедший год, Работники, уволенные за последний год, сортировка по должностям) для поиска и извлечения только требуемых данных;

­ Формы (Должности, Молодые специалисты, Общая форма, Работники, прибывшие за прошедший год, Работники, уволенные за последний год) для просмотра, добавления и изменения данных в таблицах;

­ Отчеты (Общий, Работники, прибывшие за прошедший год, Работники, уволенные за последний год) для анализа и печати данных в определенном формате.

Разработанная база данных позволяет автоматизировать все данные, сократить ошибки в документации. При появлении новой информации о сотрудниках школы в кратчайшие сроки можно реализовать их в базе данных, путем добавления строк, столбцов и целых таблиц.



Список литературы

1. Бакаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2002. - СПб.: БХВ-Петербург, 2002.

2. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. - М.: Финансы и статистика, 1989.

3. Гончаров А. Ю. Access 2003. Самоучитель с примерами., Москва, 2004г.

4. Карпова, Т. Базы данных: модели, разработка, реализация. / Т. Карпова. - СПб.: Питер, 2001. - 304 с.

5. Лекции по курсу «Базы данных» - Д.Н. Кузнецов, 2007.

6. Мейер М. Теория реляционных баз данных. - М.: Мир, 1987.

7. Основы проектирования реляционных баз данных. Электронное учебное пособие.

8. http://pkks.ucoz.ru/index/proektirovanie_reljacionnykh_baz_dannykh_s_ispolzovaniem_normalizacii/0-116

9. http://citforum.ru/database/dbguide/index.shtml

10. http://sqlsite.narod.ru/4.html

Размещено на Allbest.ru