Этапы разработки базы данных в среде Microsoft Access 2003
Разработка прикладного программного обеспечения деятельности отдела кадров университета в среде Microsoft Access 2003. Характеристика этапов проектирования базы данных. Построение семантической модели. Нормализация данных, понятие нормальной формы.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 14.11.2012 |
| Размер файла | 4,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
В общем случае, если в большом количестве запросов требуется объединять более пяти или шести таблиц, следует рассмотреть вариант денормализации базы данных.
· Денормализация путём ввода дополнительного поля в одну из таблиц. При этом появляется избыточность данных, требуются дополнительные действия для сохранения целостности БД.
Поскольку масштаб разрабатываемой мной базы данных относительно мал, то существенного повышения быстродействия путём значительного изменения структуры данных добиваться не имеет смысла. Тем не менее, в рамках денормализации данных моего проекта необходимо создать удобную систему выборки сотрудников университета из общего списка по датам рождения.
При анализе предметной области и формулировке основных задач отдела кадров университета, была означена обязанность организации мероприятий по формированию корпоративной культуры. Эти мероприятия могут быть разноплановыми, но основную часть их составляет награждения юбиляров, поздравления с днём рождения и т.д. Значит, разрабатываемая база данных должна обеспечивать возможность мониторинга дат рождения всех сотрудников в удобной форме запроса. В моей базе данных присутствует атрибут Birth, описывающий дату рождения работников ВУЗа, но, поскольку типом данных этого атрибута является тип дата/время, использовать его в вышеописанных целях неудобно.
Для решения данной проблемы нужно создать ещё одну сущность "День рождения", связав его идентифицирующей связью с ключевой сущностью "Работник". После создания сущности я внёс в неё атрибуты BirthDay, BirthMounth и BirthYear, описывающие день, месяц и год рождения соответственно.
Таким образом, за счёт избыточности данных о днях рождения сотрудников, я создал структуру, позволяющую с помощью запросов наиболее быстро определить, например, всех сотрудников, рождённых в один месяц, с последующим определением чисел их рождения. На рис.13 показана денормализованная физическая модель моей базы данных.
Рис.13 Денормализованная физическая модель базы данных
4.3 Корректировка типов и размеров полей
На этапе логического проектирования я указывал только типы доменов для каждого атрибута. Но в ERwin поддерживается ещё и точное определение типов полей для конкретной выбранной СУБД. Сейчас в полученной физической модели необходимо скорректировать типы и размеры полей для заданной СУБД Access в соответствии с табл.5.
Таблица 5
Типы данных и размеры колонок таблиц физической модели
|
Таблица |
Колонка |
Тип данных |
|
|
Опыт работы |
WorkBegin |
Date/Time |
|
|
Work |
Text (20) |
||
|
WorkEnd |
Date/Time |
||
|
Reason |
Text (30) |
||
|
Penalty |
Memo |
||
|
Rewards |
Memo |
||
|
Научные достижения |
DegreeYes |
Yes\No |
|
|
Rank |
Integer |
||
|
Degree |
Integer |
||
|
Учёная степень |
DegreeName |
Text (40) |
|
|
Учёное звание |
RankName |
Text (20) |
|
|
Образование |
Education |
Text (40) |
|
|
Year |
Integer |
||
|
Speciality |
Text (30) |
||
|
Место работы |
Department |
Text (40) |
|
|
Institute |
Text (40) |
||
|
Post |
Text (20) |
||
|
Comment |
Memo |
||
|
Жильё |
Phone |
Text (15) |
|
|
City |
Text (20) |
||
|
Street |
Text (20) |
||
|
House |
Integer |
||
|
Apartment |
Integer |
||
|
Работник |
PersonID |
Integer |
|
|
Name |
Text (15) |
||
|
Family |
Text (20) |
||
|
Second |
Text (20) |
||
|
Picture |
OLE Object |
||
|
Предыдущее место работы |
WorkPlace |
Text (20) |
|
|
WorkCity |
Text (20) |
||
|
Unit |
Text (5) |
||
|
WorkBuilding |
Integer |
||
|
WorkStreet |
Text (20) |
||
|
Рабочий телефон |
WorkPhone |
Text (15) |
|
|
День рождения |
BirthDay |
Integer |
|
|
BirthMounth |
Text (10) |
||
|
BirthYear |
Integer |
||
|
Паспортные данные |
Passport |
Long Integer |
|
|
Birth |
Date/Time |
||
|
NativeLand |
Text (15) |
||
|
HomeTown |
Text (20) |
||
|
PassportDate |
Date/time |
||
|
Region |
Text (40) |
Для этого необходимо вызвать редактор колонок Columns через пункт главного меню Model | Column, либо через контекстное меню.
Редактируемая таблица выбирается в списке Table. Для каждой колонки таблицы на закладке Access определяется тип данных согласно табл.5, выбрав в поле Access Datatype из списка нужное значение.
Кроме того, здесь задается опция NULL (группа Null Option), которая определяет допустимость пустых значений поля.
Всего в модели фигурируют 7 различных типов данных:
· Text - текстовый тип, допускает использование любых знаков и символов в поле, набор знаков в поле не должен превышать 255 символов. В скобках указывается количество допустимых в поле знаков.
· Integer - числовой тип. Допускает использование чисел различных форматов.
· Memo - числовое поле, допускающее набор текста длиной до 65000 символов.
· OLE Object - поле, позволяющие вставлять рисунки, звуки и данные других типов.
· Date/Time - типа дата\время.
· Long Integer - числовой тип данных, позволяет использовать числовые значения, слишком длинные для типа Integer.
· Yes/No - логический тип, допускает только значения поля "Да" или "Нет".
После выполнения всех описанных выше действий, физическая модель данных приняла свой завершённый вид. На рис.14 представлена полностью готовая к переносу в СУБД модель моей базы данных. На этом работа с программой ERwin завершена. Следующее действие - проверка полученной модели данных с помощью программного решения CA Erwin Data Model Validator, позволяющего проанализировать работоспособность и адекватность построенной модели данных и, при необходимости, внести определённые коррективы в её структуру.
Рис.14 готовая к переносу в СУБД физическая модель данных
4.4 Проверка структурной целостности модели данных
Прежде чем переносить спроектированную модель данных в систему управления базами данных, будет нелишним проверить полученную схему на предмет логической целостности и отсутствия ошибок проектирования. Для этих целей я использовал программу CA ERwin Data Model Validator. Предлагаемые в ней средства диагностики и проверки, основанные на правилах реляционного моделирования, помогут убедиться в структурной целостности моделей данных CA ERwin Data Modeler или кода SQL/DDL. Все несоответствия в проекте будут выявлены немедленно, после чего программа предложит рекомендации по устранению неисправностей и автоматически сгенерирует сценарии для реализации выбранных исправлений.
Продукт CA ERwin Data Model Validator позволяет анализировать структуры данных, ключи, индексы, столбцы и отношения. Кроме того, решение поможет отобразить в графическом виде структуру всей базы данных, включая столбцы с перекрестными ссылками и списки отношений.
Самостоятельная проверка и подтверждение моделей данных занимает достаточно много времени. Решение CA ERwin Data Model Validator предлагает функцию "Show Me" для локализации проблем, возникающих при проектировании сложных моделей баз данных. Таким образом, разработчикам не придется вручную перебирать тысячи строк программного кода. Кроме того, предоставляемая в составе продукта функция "Teach Me" позволит без труда предугадать эффект от внесенных в проект изменений.
Для проверки схемы данных необходимо сохранить ERD-диаграмму, построенную в CA ERwin Data Modeler, и затем выбрать пункт меню Tools | CA ERwin Data Model Validator. В открывшемся окне CA ERwin Data Model Validator, нужно выбрать пункт File | New, и в открывшемся диалоговом окне прописать путь до сохранённой ранее ERD-диаграммы.
При открытии файла с диаграммой, ERwin Validator автоматически проверяет модель на ошибки проектирования и логическое несоответствие данных и связей, после чего выдаёт предварительные результаты в виде списка всех таблиц модели с соответствующей графической пометкой, как на рис.15.
Рис.15 Предварительные результаты проверки ERwin Validator
При нажатии кнопки OKотображается рабочее окно программы, в котором можно провести детальную диагностику модели данных. В нижней части рабочего окна можно увидеть кнопки Tables, Relationships и Diagnostics. Первая показывает список таблиц и их характеристики, вторая список и характеристики связей, третья предоставляет доступ к модулю диагностики.
Проведя диагностику моей модели, ERwin Validator выдал результаты в виде иерархического списка ошибок, предупреждений, предостережений и советов по увеличению производительности базы данных. На рис.16 видно, что в моей модели данных отсутствуют серьёзные ошибки (several errors) и другие ошибки (errors). Предостережений (cautions) так же нет. Программа даёт 9 рекомендаций по увеличению производительности БД, но выполнить их не представляется возможным, поскольку все они имеют отношение к слишком большому, по мнению ERwin Validator, количеству связей таблицы "Работник" с остальными.
Но поскольку именно такая структура данных подразумевалась с самого начала разработки, то ошибками это не является, и обращать внимание на это не следует.
Рис.16 Результаты анализа модели данных
Итак, опираясь на данные ERwin Validator, можно сказать, что моя модель данных адекватна и отвечает всем требования логической целостности данных. Теперь моя модель БД полностью готова к переносу на выбранную ранее СУБД.
4.5 Генерация системного каталога базы данных
Прежде чем приступать к генерации физической схемы базы данных необходимо создать новую базу данных в Access. После этого необходимо проделать следующие действия.
В программе Erwin выполнить команду Tools | Forward Engineer/Schema Generation.
В диалоговом окне Access Schema Generation на закладке Option задать опции генерации объектов модели, выбирая в левом списке объект, а в правом - соответствующие ему опции. Щелкнуть по кнопке Generate.
В диалоговом окне Access Connection установить связь с созданной базой данных, заполнив все предложенные поля.
В случае установления соединения будет выполняться SQL-скрипт. Если в процессе генерации возникают ошибки, то она прекращается, открывается окно с сообщениями об ошибках.
После генерации в базе данных, созданной в Access ранее, появляются все таблицы, представленные на физическом уровне модели, а на схеме данных можно увидеть, каким образом все таблицы связаны между собой (рис.17).
Рис.17 Сгенерированная схема данных в Microsoft Access 2003
4.6 Задание правил валидации
4.6.1 Общее понятие правил валидации
Последний этап физического проектирования моей базы данных - это задание правил валидации, т.е. это установка определённых ограничений на ввод данных в определённые поля определённых таблиц.
Определение условий на значения позволяет поставить условие, ограничивающее круг принимаемых данных. Эти условия проверяются при вводе или изменении данных в таблице в режиме таблицы, в форме, связанной с таблицей, в запросе на добавление, в запросе на обновление, в программе Visual Basic для приложений или при импорте данных из другой таблицы. Также допускается определение двух типов условий на значение: условие на значение поля и условие на значение записи.
Условие на значение поля задает проверку введенных значений при выходе пользователя из поля. Например, примером условия на значение для числового поля может служить выражение ">=10 And <=100", разрешающее ввод значений только от 10 до 100.
Условие на значение записи применяется при сохранении всей записи. В отличие от условий на значение поля, в условиях на значение записи допускаются ссылки на другие поля. Это позволяет использовать такие условия для сравнения значений, введенных в разные поля таблицы. Например, в качестве условия на значение для таблицы "Заказы" можно указать выражение: " [КонечнаяДата] <= [ДатаЗаказа] +30". Это гарантирует, что дата, введенная в поле "КонечнаяДата", будет отличаться от даты в поле "ДатаЗаказа" не более чем на 30 дней.
Если условие на значение для поля или записи нарушается, Access выводит сообщение, содержащее сведения, как правильно вводить данные.
В моём примере встречаются 2 типа условий на значение: задание правил проверки вводимых значений, и задание списка допустимых значений.
4.6.2 Задание правил проверки вводимых значений
Первое поля, для которого я установил правила проверки - поле Birth в таблице "Паспортные данные". В это поле вводится дата рождения сотрудника. Для того чтобы ввести условие на значение для этого поля, необходимо выделить в списке таблиц таблицу "Паспортные данные" и выбрать режим конструктора для редактирования свойств таблицы. В конструкторе нужно выбрать поле Birth и внизу, во вкладке Общие, ввести в строчку Условие на значение правило проверки значений таблицы. Для данного поля будет достаточно внесения временного диапазона более-менее разумной протяжённостью. Я задал условие проверки таким образом, чтобы в данное поле можно было внести дату, которая находилась бы во временном диапазоне между 01.01.1912, поскольку родившемуся в 1912 человеку сейчас было бы 100 лет, что не вписывается в разумные пределы проверки возраста, и настоящим временем. Согласно синтаксису языка SQL для версии Microsoft Access 2003, все даты записываются между двумя символами "#". Таким образом Access распознаёт, что указанный набор цифр является датой. Настоящее время же считывается с системной даты на компьютере, на котором база данных открыта в каждый момент времени. Для того чтобы дата считывалась с системных показателей используется оператор Date (). В итоговом виде правило для проверки даты рождения выглядит так: >=#01.01.1912# And <Date (). Одной строчкой ниже расположена строка "сведения об ошибке". Сюда записывается небольшое информационное сообщение для пользователя базы данных, который допустил ошибку при работе и ввёл значение, не соответствующее допустимому. В данном случае пользователь, который ввёл дату не из описанного выше диапазона, увидит следующее сообщение: "введите дату между 01.01.1912г. и сегодняшней".
Аналогичным образом я установил правило проверки для поля Year в таблице "Образование". В данное поле вводится год окончания работником ВУЗа. Но, поскольку на работу в преподавательский состав университета не могут взять человека, который ещё сам не получил высшего образования, или получившего его только что, необходимо отмести возможность ввода года окончания обучения более позднего, чем текущий. Для этого Я прибегнул к помощи оператора Year, который возвращает значение типа Variant (Integer) - целое число, обозначающее год. А для того чтобы оператор Year возвращал год из значения системной даты я опять же применил оператор Date. В итоге получилось следующее выражение условия на значение: <Year (Date ()). В описании ошибки было указано "введите более раннюю дату".
Следующим правилом я задал проверку даты начала трудовой деятельности. Полем WorkBegin в таблице "Опыт работы". Особенностью этого условия на значение является то, что оно задаётся для записи, а не для поля, поскольку согласно механизму проверки и здравому смыслу, дата начала трудовой деятельности должна быть раньше, чем дата её окончания, а ссылки на разные колонки одной таблицы допускаются только при задании условия на значения для записи. Для задания правила проверки для всей записи необходимо щёлкнуть правой кнопкой мыши на любом пустом участке рабочей области конструктора и в выпадающем меню выбрать пункт Свойства. Далее в строке Условие на значение я ввёл выражение, которое не допускает ввод даты окончания рабочей деятельности, если дата более ранняя, чем введённая в поле WorkBegin (начало рабочей деятельности). Ведь невозможно закончить рабочую деятельность на определённой должности раньше, чем начать её. Итоговое выражение выглядит так: [WorkBegin] < [WorkEnd]. В квадратных скобках, согласно синтаксису SQL, заключаются названия полей одной таблицы
4.6.3 Создание списка допустимых значений
Последним правилом валидации я установил список допустимых значений. Этот метод проверки несколько отличается от выражения для проверки вводимого значения. При создании списка допустимых значений в поле для ввода условия на значение вводится оператор In (), в котором перечисляются все значения через знак ";". Такой список я создал для поля BirthMounth, содержащий информацию о месяце рождения в таблице "День рождения". Поскольку месяцев всего 12, то для создания списка достаточно перечислить их названия. В сообщении об ошибке я вписал просьбу ввести словесное обозначение месяца с большой буквы.
5. Проектирование на уровне MS Access 2003
5.1 создание запросов
После заполнения базы данных осталось сделать запросы, отчёты и создать формы для ввода и редактирования данных. В моём примере я начал с запросов. Все запросы и отчёты я создавал в режиме конструктора, для этого в меню запросов в верхней части окна достаточно нажать кнопку "создать" и в следующем окне выбрать конструктор как инструмент создания. Изначально в моей базе данных появилось 4 запроса:
· "Список работников" - отражает полный список сотрудников, которые находятся в базе данных.
· "Сотрудники с учёной степенью" - содержит перечень сотрудников из базы, имеющих учёную степень, а так же показывает наименование учёной степени для каждого сотрудника.
· "Сотрудники с учёным званием" - по содержанию аналогичен предыдущему запросу, только показывает не учёные степени сотрудников, а их звания.
· "Место обучения и предыдущее место работы" - содержит сводную информацию о месте обучения и предыдущем место работы каждого сотрудника в базе данных.
Механизм создания этих запросов довольно прост и практически идентичен. Для создания запроса в режиме конструктора необходимо выбрать таблицы, поля которых будут использоваться в запросе, и перенести эти поля в область формирования запроса. При необходимости можно оставить или отменить опцию отображения определённого поля в итоговом виде запроса, и поставить условия отбора записей по определённому критерию.
Например, для создания запроса "Сотрудники с учёной степенью", я использовал поля из таблиц "Работник", "Научные достижения" и "Учёная степень". Из таблицы "Работник" Я использовал поля Name (Имя), Family (Фамилия) и Second (Отчество). Они служат для идентификации каждого сотрудника в удобной для восприятия форме в виде имени, фамилии и отчества (рис.18). Из таблицы "Научные достижения" используется поле DegreeYes, которое и позволяет отобрать именно тех сотрудников ВУЗа, которые имеют учёную степень.
Рис.18 Построение запроса
Для того чтобы запрос корректно работал, нужно чтобы в него попадали только те записи поля DegreeYes, значение которых соответствует истине, поэтому в условии отбора я написал слово "Истина", и снял галочку в пункте "Вывод на экран". Целевому пользователю совсем не обязательно видеть поле, в котором в каждой записи написано слово "да". И последнее поле, которое будет использовано в запросе - это поле Degree, содержащее в себе информацию о названии учёной степени, присвоенной сотруднику.
Подобным образом создавались все запросы моего программного комплекса, поэтому описывать создание остальных запросов не имеет смысла.
5.2 Создание отчётов
Создание отчётов происходит в два этапа. Сначала необходимо создать базовый запрос или таблицу, и только потом на их основе редактировать отчёт. В качестве примера можно взять отчёт "Перечень доцентов по кафедрам". Для начала я создал одноимённый запрос, в который вошли, соответственно, поля, содержащие информацию об имени, фамилии, отчестве сотрудника, а так же кафедре, на которой он работает и его учёном звании. Поскольку название запроса говорит само за себя, то необязательно отображать в отчёте поле с информацией о том, что данный сотрудник является доцентом, это и так очевидно. Но, тем не менее, это поле необходимо добавить в запрос для отбора данных, поэтому я сделал его невидимым, сняв галочку "Вывод на экран" (Рис. 19).
Рис. 19 Создание базового запроса для отчёта
Итак, базовый запрос готов, теперь достаточно просто создать на его основе в режиме конструктора отчёт, перенеся на область данных отчёта все поля запроса и отредактировав их местоположение относительно друг друга. При построении отчёта необходимо выбрать, на основе какого запроса или таблицы будет сформирован отчёт. Для построения отчёта в моём случае подходит только запрос, поскольку его можно сформировать из полей разных таблиц (Рис. 20).
Рис.20 создание отчёта на основе выбранного запроса.
По такому же алгоритму создаются все остальные отчёты в моей базе данных, вот их полный список:
· Список сотрудников, имеющих благодарности;
· Список сотрудников, имеющих взыскания;
· Перечень всех сотрудников по кафедрам;
· Перечень кандидатов наук по кафедрам;
· Перечень доцентов по кафедрам;
· Дни рождения сотрудников.
6. Разработка приложения
Прежде чем приступать к непосредственно разработке приложения, необходимо продумать его структуру. В моём случае приложение должно работать в двух режимах: Режим пользователя и режим администратора. Пользователь должен комфортно для себя работать с данными, содержащимися в базе, следовательно, необходимо обеспечить пользователю максимально удобный доступ к данным и к поиску определённых записей в базе. Также большое внимание уделяется внешнему оформлению рабочей области, а не только удобной организации полей базы.
Режим администратора должен быть удобен для редактирования базы данных, поскольку задача администратора - это заполнение БД, редактирование уже существующих записей и их удаление, поэтому в режиме администратора организация всех форм соответствует структурной организации таблиц базы. Сам интерфейс несколько проще, поскольку предполагается, что администратор умеет пользоваться встроенными возможностями Access и для него не нужно отдельно выводить некоторые кнопки на форму.
Отчёты и запросы в обоих режимах выглядят одинаково, лишь с незначительными изменениями. Единственная разница между режимами пользователя и администратора заключается в том, что для пользователя на форме с отчётами доступны функции распечатки отчётов и вывода их в текстовый файл.
Вся работа с приложением проходит через кнопочные формы, что упрощает работу с данными и делает её более удобной и комфортной.
6.1 Разработка структуры приложения
6.1.1 Разработка режима пользователя
В своей работе я начал разработку приложения с режима пользователя. Поскольку для пользователя важно сделать максимально удобную организацию полей базы, то реализовать это я решил с помощью одной материнской и нескольких подчинённых форм. На первой форме, названной "Сотрудник", находится вся информация о человеке, связанная с его рабочей деятельностью в ВУЗе. Фамилия, имя, отчество, научные достижения, кафедра, должность, поощрения и взыскания. Так же на этой форме находится фотография сотрудника. С этой же формы, с помощью кнопок можно перейти на любую из 3 подчинённых форм, содержащих информацию о паспортных данных сотрудника, его домашнем адресе и опыте работы. К самим формам применены средства визуализации фона и шрифта. Также на форме находятся кнопки навигации по записям, поиск записи в базе и возможность перехода на главную кнопочную форму. Отсюда же пользователь имеет доступ на формы, содержащие кнопки перехода к отчётам и запросам моей БД (Рис.21).
Рис.21 Вид основной формы для работы в режиме пользователя
Помимо форм, предоставляющих информацию о каждом человеке в моём программном комплексе, я создал ещё две формы для режима пользователя. На одной из них располагаются кнопки перехода к каждому созданному запросу (Рис.22).
Рис.22 Форма перехода к запросам
На другой - кнопки запуска отчётов, а так же кнопки для их распечатки и вывода в отдельный текстовый файл, поскольку пользователю, работающему с этими данными, может потребоваться вывести отчёт на печать или пересохранить отдельно в электронном виде (Рис.23).
Рис.23 Форма перехода к отчётам
На каждой форме режима пользователя находятся кнопки закрытия текущей формы и кнопки перехода на главную кнопочную форму программы, с одновременным закрытием текущей формы. Реализовано это посредством макросов.
6.1.2 Разработка режима администратора
Режим администратора должен иметь вид, более удобный для внесения, изменения и удаления записей из БД. Его структура в моей работе очень отличается от структуры режима пользователя. Нажатие на кнопку "База данных" отсылает к другой форме, на которой посредством кнопок реализованы переходы к формам, по набору полей практически идентичным каждой таблице в БД. Единственное изменение - в таблицах у меня повторяется только поле PersonID, которое является ключевым, а в формах я так же добавил поля ФИО, чтобы администратору было проще идентифицировать людей, данные на которых он редактирует (Рис.24).
Рис.24 Основная форма для работы в режиме администратора
Так же в режиме администратора не применялось никакого визуального оформления для самих форм, не прорабатывалась возможность поиска по значению и навигации по записям одной формы, поскольку эта возможность реализована непосредственно в оболочке Access. На каждой форме режима администратора так же есть кнопки перехода на главную форму с последующим закрытием текущей и кнопка закрытия текущей формы.
Формы открытия отчётов и запросов идентичны в обоих режимах, только в режиме администратора в форме вывода отчётов отсутствуют кнопки сохранения в файл и печати.
6.2 Создание главной кнопочной формы
После разработки режимов пользователя и администратора можно приступать к созданию главной кнопочной формы. На ней симметрично друг другу расположены кнопки доступа к режиму пользователя и администратора, запросам и отчётам, а так же кнопка выхода из программы (Рис.25).
Рис.25 Главная форма программного комплекса
Поскольку при запуске программы работа должна начинаться именно с этой формы, необходимо чтобы при открытии файла БД эта форма открывалась автоматически. Для этого нужно выбрать меню "Сервис", затем строчку "Параметры запуска" и в появившемся окне выбрать необходимую форму, с которой должна начинаться работа с программой, заголовок и другие параметры (Рис.26).
Рис.26 Настройка параметров запуска для главной формы
После того как главная кнопочная форма создана, можно считать завершённой процесс разработки моего программного комплекса. На этом процесс разработки завершён.
Заключение
В ходе выполнения курсовой работы были рассмотрены основные методы работы с Microsoft Access 2003, базовые инструменты и приёмы работы с такими CASE-средствами как CA ERwin Data Modeler и CA ERwin Data Model Validator.
Microsoft Access 2003 - универсальный набор программных средств, которые обеспечивают широкие возможности для профессиональных разработчиков и вместе с тем могут быть легко освоены новичками. Любой пользователь может создавать и применять универсальные решения для баз данных, значительно упрощающие организацию, совместное использование данных и доступ к ним.
CA Erwin Data Modeler: CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания.
AllFusion ERwin Data Modeler (ERwin) предназначен для всех компаний, разрабатывающих и использующих базы данных, для администраторов баз данных, системных аналитиков, проектировщиков баз данных, разработчиков, руководителей проектов. AllFusion ERwin Data Modeler позволяет управлять данными в процессе корпоративных изменений, а также в условиях стремительно изменяющихся технологий.
AllFusion ERwin Data Modeler (ERwin) позволяет наглядно отображать сложные структуры данных. Удобная в использовании графическая среда AllFusion ERwin Data Modeler упрощает разработку базы данных и автоматизирует множество трудоемких задач, уменьшая сроки создания высококачественных и высокопроизводительных транзакционных баз данных и хранилищ данных. Данное решение улучшает коммуникацию в вашей организации, обеспечивая совместную работу администраторов и разработчиков баз данных, многократное использование модели, а также наглядное представление комплексных активов данных в удобном для понимания и обслуживания формате.
CA ERwin Data Model Validator - cредства диагностики и проверки, используются для проверки структурной целостности моделей данных CA ERwin Data Modeler или кода SQL/DDL путем применения правил реляционной технологии. CA ERwin Data Model Validator помогает обнаруживать дефекты проектирования, выдает рекомендации корректирующих действий и автоматически генерирует сценарии для реализации выбранных корректировок.
CA ERwin Data Model Validator анализирует структуры данных, ключи, индексы, поля столбцов и отношения на предмет нарушений правил проектирования реляционных баз данных. CA ERwin Data Model Validator выдает детализированные диагностические отчеты, помогающие увеличивать продуктивность за счет ускорения процесса анализа.
При выполнении курсовой работы была разработана автоматизированная система для поддержки деятельности отдела кадров университета, что должно упростить работу данного отдела. В ходе выполнения курсового проекта были освоены общие приёмы разработки прикладного программного обеспечения на основе реляционный базы данных, многие методы и аспекты проектирования стали прозрачны и понятны вследствие применения их на практике разработки определённого программного комплекса.
Список источников
1. Трипутина, В.В. Проектирование баз данных с помощью Case-средства ErWin. Методические указания к выполнению лабораторных работ: учебное пособие / В.В. Трипутина. - Иркутск: Издательство Иркутского государственного технического университета.
2. Кренке, Д. Теория и практика построения баз данных / Д. Кренке. - СПб: ПИТЕР, 2005 г.
3. Дорофеев, A.С. Методические указания к выполнению курсового проекта по дисциплинам базы данных, управление данными: учебное пособие / А.С. Дорофеев. - Иркутск: Издательство Иркутского государственного технического университета, 2007 г.
4. Г.А. Разработка реального приложения в среде клиент-сервер.
5. Учебное пособие. - Хабаровск: Изд-во ДВГУПС, 2005. - 204 с.: ил.
6. Журнал "Открытые системы" №2 2009.
7. Гончаров А.Ю. ACCESS 2003. Самоучитель с примерами. Учебное пособие. - М: Кудиц-Образ, 2004 - 270с.
8. Гурвиц Г.А. Разработка реального приложения в среде клиент-сервер. Учебное пособие. - Хабаровск: Изд-во ДВГУПС, 2005. - 204
9. http://itteach.ru/bpwin/sozdanie-logicheskoy-modeli/vse-stranitsi
10. http://itteach.ru/bpwin/sozdanie-fizicheskoy-modeli/vse-stranitsi
11. http://belieteni.com/subdt2r30part3.html
12. http://www.ci.ru/inform12_98/astr1. htm
13. http://www.guu5.ru/chapter1578_1.html
14. http://www.interface.ru/ca/ERw2. htm
15. http://www.studfiles.ru/dir/cat32/subj95/file9840/view96581.html
16. http://habrahabr.ru/post/64524/
17. http://office. microsoft.com/ru-ru/access-help/HP005187556. aspx
18. http://samoucka.ru/document20001.html
19. http://office. microsoft.com/ru-ru/access-help/HA001181384. aspx#BM6
20. http://office. microsoft.com/ru-ru/access-help/HP005262348. aspx
21. http://ru. wikipedia.org/wiki/Нормальная_форма
22. http://ru. wikipedia.org/wiki/Денормализация
23. http://ru. wikipedia.org/wiki/Проектирование_баз_данных
Приложение
Набор исходных данных для разработки программного обеспечения
|
№ |
Поле |
Тип |
Размер |
Описание |
|
|
1 |
PersonID |
Числовой |
5 |
Регистрационный номер сотрудника |
|
|
2 |
Name |
Текстовый |
40 |
ФИО сотрудника |
|
|
3 |
Department |
Текстовый |
40 |
Название кафедры, на которой работает |
|
|
4 |
Institute |
Текстовый |
40 |
Название института (департамента) |
|
|
5 |
Birth |
Дата |
Авто |
Дата рождения сотрудника |
|
|
6 |
Place |
Текстовый |
20 |
Место рождения |
|
|
7 |
Address |
Текстовый |
60 |
Домашний адрес сотрудника |
|
|
8 |
Phone |
Текстовый |
15 |
Домашний телефон сотрудника |
|
|
9 |
Education |
Текстовый |
40 |
Оконченный ВУЗ |
|
|
10 |
Year |
Числовой |
4 |
Год окончания ВУЗа |
|
|
11 |
Speciality |
Текстовый |
30 |
Специальность сотрудника |
|
|
12 |
Picture |
Поле OLE |
Авто |
Фотография сотрудника |
|
|
13 |
DegreeYes |
Логический |
1 |
Ученая степень (есть/нет) |
|
|
14 |
Degree |
Числовой |
1 |
Ученая степень сотрудника |
|
|
15 |
Rank |
Числовой |
1 |
Ученое звание сотрудника |
|
|
16 |
Post |
Текстовый |
20 |
Занимаемая должность |
|
|
17 |
Comment |
Поле Memo |
Авто |
Примечания |
|
|
18 |
Passport |
Текстовый |
20 |
Номер паспорта |
|
|
19 |
PassportDate |
Дата |
Авто |
Дата выдачи паспорта |
|
|
20 |
Region |
Текстовый |
40 |
Кем выдан паспорт |
|
|
21 |
WorkBegin |
Дата |
Авто |
Дата начала трудовой деятельности |
|
|
22 |
WorkEnd |
Дата |
Авто |
Дата окончания трудовой деятельности |
|
|
23 |
Work |
Текстовый |
20 |
В качестве кого работал |
|
|
24 |
WorkPlace |
Текстовый |
20 |
Название предприятия |
|
|
25 |
WorkAddress |
Текстовый |
60 |
Адрес предприятия |
|
|
26 |
WorkPhone |
Текстовый |
15 |
Телефон предприятия |
|
|
27 |
Reason |
Текстовый |
30 |
Причина увольнения |
|
|
28 |
Penalty |
Поле Memo |
Авто |
Сведения о взысканиях |
|
|
29 |
Rewards |
Поле Memo |
Авто |
Сведения о награждениях |
Размещено на Allbest.ru
Подобные документы
Основные понятия баз данных: нормализация, связи и ключи. Создание и этапы проектирования базы данных, решение задачи о предметной области. Изучение СУБД Microsoft Access s 2003: пользовательский интерфейс, главное окно приложения, создание таблиц.
реферат [2,1 M], добавлен 10.11.2010Microsoft Access как система управления базами данных (СУБД), ее предназначение. Организованная структура для хранения данных. Типы данных при работе с Microsoft Access 2003 и Microsoft Access 2007. Проектирование баз данных и построение ER-диаграммы.
контрольная работа [16,3 K], добавлен 10.10.2010Создание базы данных, планирование разработки и системные требования. Проектирование базы данных в среде Microsoft Access, элементы и типы данных. Создание таблицы и использование конструктора для их модернизации. Построение запросов и создание макросов.
курсовая работа [2,0 M], добавлен 16.04.2011Анализ возможностей системы управления базами данных "Microsoft Access 2003". Создание базы данных, предназначенной для отражения деятельности аэропорта. Концептуальная и физическая модель базы данных. Создание таблиц, запросов, отчетов и главной формы.
курсовая работа [1,8 M], добавлен 26.06.2013Системы управления базами данных: сущность и характеристика. Типы данных и свойства полей СУБД Access. Объекты базы данных: таблицы, схемы данных, формы, запросы, отчеты. Разработка и проектирование базы данных "Продажи книг" в среде Microsoft Access.
курсовая работа [1,8 M], добавлен 04.02.2013Применение Microsoft Office Access для создания базы данных "Гостиница" с целью ведения списка постояльцев и учета забронированных мест. Методы построения таблиц, запросов, форм, отчетов, макросов и модулей. Реализация концептуальной и логической модели.
курсовая работа [418,1 K], добавлен 14.06.2011Основные понятия базы данных. Разработка сложной формы для обработки данных. Модели организации данных. Архитектура Microsoft Access. Реляционные связи между таблицами баз данных. Проектирование базы данных. Модификация данных с помощью запросов действий.
лабораторная работа [345,5 K], добавлен 20.12.2011Техника создания списков, свободных таблиц и диаграмм в среде табличного процессора Microsoft Excel. Технология создания базы данных в среде СУБД Microsoft Access. Приобретение навыков подготовки и демонстрации презентаций в среде Microsoft Power Point.
лабораторная работа [4,8 M], добавлен 05.02.2011Краткая характеристика и функциональные возможности MS Access. Базы данных и системы управления базами данных. Проектирование в теории и создание на практике базы данных в продукте корпорации Microsoft для управления базами данных "Microsoft Access".
курсовая работа [1,6 M], добавлен 07.03.2015Анализ баз данных и систем управления ими. Проектирование и создание реляционной базы данных в среде MS Access для ресторана "Дельфин": построение информационно логической модели, разработка структур таблиц базы данных и схемы данных, создание Web-узла.
курсовая работа [3,7 M], добавлен 15.11.2010
