Главная
База знаний "Allbest"
Программирование, компьютеры и кибернетика
Этапы разработки базы данных в среде Microsoft Access 2003
Этапы разработки базы данных в среде Microsoft Access 2003
Разработка прикладного программного обеспечения деятельности отдела кадров университета в среде Microsoft Access 2003. Характеристика этапов проектирования базы данных. Построение семантической модели. Нормализация данных, понятие нормальной формы.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 14.11.2012 |
| Размер файла | 4,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Содержание
- Введение
- 1. Этапы проектирования базы данных
- 2. Концептуальное проектирование
- 2.1 Анализ предметной области
- 2.2 Построение семантической модели БД
- 3. Логическое проектирование
- 3.1 Понятие erd-диаграммы
- 3.2 Определение сущностей и атрибутов
- 3.3 Нормализация данных, понятие нормальной формы
- 3.4 Первая нормальная форма
- 3.5 Вторая нормальная форма
- 3.5.1 Определение ключевых полей
- 3.5.2 Установка связей между сущностями
- 3.6 Третья нормальная форма
- 3.7 Проверка адекватности логической модели
- 3.8 Установление параметров связей между сущностями
- 3.8.1 Определение типа и мощности связей
- 3.8.2 Задание правил декларативной ссылочной целостности
- 3.9 Установление альтернативных ключей, инверсных входов и определение типов атрибутов
- 4. Физическое проектирование
- 4.1 Переход к физическому уровню модели
- 4.2 Денормализация данных
- 4.3 Корректировка типов и размеров полей
- 4.4 Проверка структурной целостности модели данных
- 4.5 Генерация системного каталога базы данных
- 4.6 Задание правил валидации
- 4.6.1 Общее понятие правил валидации
- 4.6.2 Задание правил проверки вводимых значений
- 4.6.3 Создание списка допустимых значений
- 5. Проектирование на уровне MS Access 2003
- 5.1 создание запросов
- 5.2 Создание отчётов
- 6. Разработка приложения
- 6.1 Разработка структуры приложения
- 6.1.1 Разработка режима пользователя
- 6.1.2 Разработка режима администратора
- 6.2 Создание главной кнопочной формы
- Заключение
- Список источников
- Приложение
Введение
Необходимость автоматизации процессов рано или поздно возникает на любом предприятии. В том числе всё сильнее ощущается потребность в программных решениях, позволяющих систематизировать разнородные данные в удобную и упорядоченную систему хранения данных, или, по-другому, в удобную базу данных. В настоящее время существует множество программных средств, подходящих для подавляющего большинства автоматизируемых задач.
Одним из таких средств является Microsoft Access 2003 - реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.
Основные компоненты MS Access:
· построитель таблиц;
· построитель экранных форм;
· построитель SQL-запросов;
· построитель отчётов, выводимых на печать.
Они могут вызывать скрипты на языке VBA, поэтому MS Access позволяет разрабатывать приложения и БД практически "с нуля" или написать оболочку для внешней БД.
Microsoft Access является файл-серверной СУБД и потому применима лишь к маленьким приложениям. Отсутствует ряд механизмов, необходимых в многопользовательских БД, таких, например, как триггеры.
Данный курсовой проект имеет как теоретическую, так и программную части. Программная составляющая данной курсовой работы будет выполнена в среде Microsoft Access 2003.
Цель курсовой работы: Изучить на практике отдельные аспекты курса "разработка корпоративных информационных систем", разобраться во внутреннем устройстве проектирования информационной системы на примере создания реляционной базы данных, смоделировав на практике реальную ситуацию выполнения определённого заказа на разработку программного обеспечения.
Задача курсовой работы: Разработать прикладное программное обеспечение деятельности отдела кадров университета.
В ходе выполнения курсовой работы будут использованы такие программные средства как CA ERwin Data Modeler 7.3, CA Erwin Data Model Validator 7.3 и Microsoft Access 2003.
CA ERwin Data Modeler (ранее называвшийся AllFusion Process Modeler) - программный продукт в области реализации средств CASE-технологий.
Позволяет проводить описание, анализ и моделирование модели данных - построитель мета-моделей данных. Занимает одно из лидирующих мест в своём сегменте рынка. В настоящее время выпускается компанией Computer Associates. Распространяется на коммерческой основе.
CA ERwin Data Model Validator - инструмент для проверки структуры баз данных и моделей, создаваемых в CA ERwin Data Modeler, позволяющий выявлять недочеты и ошибки проектирования. Гибкость CA ERwin Data Model Validator заключается в том, что можно проводить выборочные тесты, а также анализировать отдельные таблицы. Продукт дополняет функциональность CA ERwin Data Modeler, автоматизируя трудоемкую задачу поиска и исправления ошибок, одновременно повышая квалификацию проектировщиков баз данных, благодаря встроенной системе обучения.
база программное обеспечение access
1. Этапы проектирования базы данных
Проектирование базы данных проходит в три этапа.
Концептуальное (инфологическое) проектирование - построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую - либо конкретную СУБД и модель данных. Термины "семантическая модель", "концептуальная модель" и "инфологическая модель" являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова "модель базы данных" и "модель предметной области" (например, "концептуальная модель базы данных" и "концептуальная модель предметной области"), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.
Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам.
Чаще всего концептуальная модель базы данных включает в себя:
описание информационных объектов, или понятий предметной области и связей между ними.
описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.
Логическое (даталогическое) проектирование - создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель - набор схем отношений, обычно с указанием первичных ключей, а также "связей" между отношениями, представляющих собой внешние ключи.
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.
На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
Физическое проектирование - создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.
2. Концептуальное проектирование
2.1 Анализ предметной области
В отделе кадров университета находятся данные всех сотрудников: от преподавателя до ректора, и их трудовой деятельности. Наряду с такими данными, как специальность сотрудника и занимаемая должность, обязательно учитываются сведения об ученой степени сотрудника (кандидат наук, доктор) и ученом звании (доцент, профессор). Также в отделе кадров хранится информация о трудовой деятельности сотрудника: о предыдущих местах работы, сроке работы и предприятии. Отдел кадров занимается подготовкой трудовых договоров с преподавателями после избрания их по конкурсу на очередной срок. Также в его ведении находятся сведения о наложении взысканий на сотрудников и их поощрениях. Взыскания в трудовую книжку не заносятся, а хранятся в электронном виде.
Основные задачи отдела кадров:
· Кадровое обеспечение деятельности университета.
· Подготовка и представление руководству информационно - аналитических материалов о состоянии и перспективах развития трудовых ресурсов и кадровой работы университета.
· Ведение учета по качественному составу ППС, наличие ученой степени и ученого звания.
· Обеспечение мероприятий по формированию корпоративной культуры (награждения юбиляров и т.д.)
· Запрос у руководителей структурных подразделений и должностных лиц вуза необходимые данные о работниках, а при приеме на работу и перемещениях работников - мнение руководителей соответствующих подразделений о целесообразности предлагаемых кадровых перестановок.
2.2 Построение семантической модели БД
После детального анализа предметной области, для которой будет разрабатываться база данных, можно приступить к построению непосредственно семантической модели конечного программного продукта. На данный момент в моём распоряжении находится только первичный, неструктурированный минимальный набор основных данных, с которыми нужно будет работать базе данных в будущем (Приложение).
Для начала я выделю из исходного набора данных несколько очевидных смысловых блоков. На первый взгляд их четыре. Это информация о сотрудниках, информация об образовании сотрудников, информация о предыдущих местах работы и о текущем месте работы.
Выделив 4 больших смысловых блока данных, я получил следующую картину (Табл.1-4)
Таблица 1
Информация о сотруднике
|
№ |
Поле |
Тип |
Размер |
Описание |
|
|
1 |
PersonID |
Числовой |
5 |
Регистрационный номер сотрудника |
|
|
2 |
Name |
Текстовый |
40 |
ФИО сотрудника |
|
|
3 |
Birth |
Дата |
Авто |
Дата рождения сотрудника |
|
|
4 |
Place |
Текстовый |
20 |
Место рождения |
|
|
5 |
Address |
Текстовый |
60 |
Домашний адрес сотрудника |
|
|
6 |
Phone |
Текстовый |
15 |
Домашний телефон сотрудника |
|
|
7 |
Passport |
Текстовый |
20 |
Номер паспорта |
|
|
8 |
PassportDate |
Дата |
Авто |
Дата выдачи паспорта |
|
|
9 |
Region |
Текстовый |
40 |
Кем выдан паспорт |
|
|
10 |
Picture |
Поле OLE |
Авто |
Фотография сотрудника |
Таблица 2
Информация о предыдущих местах работы
|
1 |
WorkBegin |
Дата |
Авто |
Дата начала трудовой деятельности |
|
|
2 |
WorkEnd |
Дата |
Авто |
Дата окончания трудовой деятельности |
|
|
3 |
Work |
Текстовый |
20 |
В качестве кого работал |
|
|
4 |
WorkPlace |
Текстовый |
20 |
Название предприятия |
|
|
5 |
WorkAddress |
Текстовый |
60 |
Адрес предприятия |
|
|
6 |
WorkPhone |
Текстовый |
15 |
Телефон предприятия |
|
|
7 |
Reason |
Текстовый |
30 |
Причина увольнения |
|
|
8 |
Penalty |
Поле Memo |
Авто |
Сведения о взысканиях |
|
|
9 |
Rewards |
Поле Memo |
Авто |
Сведения о награждениях |
Таблица 3
Информация о текущем месте работы
|
1 |
Department |
Текстовый |
40 |
Название кафедры, на которой работает |
|
|
2 |
Institute |
Текстовый |
40 |
Название института (департамента) |
|
|
3 |
Post |
Текстовый |
20 |
Занимаемая должность |
|
|
4 |
Comment |
Поле Memo |
Авто |
Примечания |
Таблица 4
Информация об образовании сотрудника
|
1 |
Education |
Текстовый |
40 |
Оконченный ВУЗ |
|
|
2 |
Year |
Числовой |
4 |
Год окончания ВУЗа |
|
|
3 |
Speciality |
Текстовый |
30 |
Специальность сотрудника |
|
|
4 |
DegreeYes |
Логический |
1 |
Ученая степень (есть/нет) |
|
|
5 |
Degree |
Числовой |
1 |
Ученая степень сотрудника |
|
|
6 |
Rank |
Числовой |
1 |
Ученое звание сотрудника |
На этом формирование концептуальной модели базы данных можно закончить.
3. Логическое проектирование
3.1 Понятие erd-диаграммы
После создания Концептуальной модели базы данных можно переходить к формированию логической модели, а для этого уже понадобятся дополнительные программные средства. В данной работе используется программа CA ERwin Data Modeler версии 7.3.
Первым шагом при создании логической модели БД является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи - глаголами.
ERD-диаграмма позволяет рассмотреть систему целиком и выяснить требования, необходимые для ее разработки, касающиеся хранения информации.
ERD-диаграммы можно подразделить на отдельные куски, соответствующие отдельным задачам, решаемым проектируемой системой. Это позволяет рассматривать систему с точки зрения функциональных возможностей, делая процесс проектирования управляемым.
Как известно основным компонентом реляционных БД является таблица. Таблица используется для структуризации и хранения информации. В реляционных БД каждая ячейка таблицы содержит одно значение. Кроме того, внутри одной БД существуют взаимосвязи между таблицами, каждая из которых задает совместное пользование данными таблицы.
ERD-диаграмма графически представляет структуру данных проектируемой информационной системы. Сущности отображаются при помощи прямоугольников, содержащих имя. Имена принято выражать существительными в единственном числе, взаимосвязи - при помощи линий, соединяющих отдельные сущности. Взаимосвязь показывает, что данные одной сущности ссылаются или связаны с данными другой.
Рис.1 Пример ERD-диаграммы
3.2 Определение сущностей и атрибутов
Сущность - это субъект, место, вещь, событие или понятие, содержащие информацию. Точнее, сущность - это набор (объединение) объектов, называемых экземплярами. В приведенном на рис.2 примере сущность "Работник" представляет всех возможных сотрудников университета. Каждый экземпляр сущности обладает набором характеристик. Так, каждый работник может иметь имя, адрес, телефон и т.д. В логической модели все эти характеристики называются атрибутами сущности.
Итак, я начинаю создание ERD-диаграммы для целевой БД. Первым шагом будет внесение имеющихся данных в 4 разные, не связанные между собой сущности. Называться сущности будут "Работник", "Образование", "Предыдущее место работы" и "Текущее место работы" соответственно. На рис.2 можно увидеть рабочее окно ERwin с построенной ERD-диаграммой. Верхняя строчка каждой сущности, отчёркнутая линией от остальной области, отводится для определения ключей. Но, поскольку к определению ключевых полей я ещё не приступил, эти поля остаются пустыми. В рабочем окне ERwin можно выделить несколько функциональных областей:
· Список основных меню программы;
· Чуть ниже находятся панели быстрого доступа к определённым функциональным возможностям программы;
· Непосредственно рабочая область для построения диаграмм;
· Внизу можно увидеть историю всех операций, проводимых в программе за последний сеанс работы.
Рис.2 ERD-диаграмма с атрибутами в рабочем окне ERwin
Приступая к созданию нового приложения, главное - самым тщательным образом спроектировать структуру его таблиц. Если не уделить структуре должного внимания, то в лучшем случае это может проявиться в неэффективной работе приложения, а в худшем - в невозможности реализации некоторых требований к системе в целом. И, наоборот, при хорошей организации набора таблиц будут решены не только текущие проблемы, но и потенциальные, которые в данный момент вы не могли предвидеть. В общем, структура данных является определяющим фактором успеха или провала всего приложения.
Э.Ф. Кодд доказал, что, следуя при создании таблиц и связей между ними только немногим формализованным правилам, можно обеспечить простоту манипулирования данными. Его методика получила наименование нормализации данных. Теория реляционных баз данных основана на концепции использования ключевых полей для определения отношений между таблицами. Чем больше таблиц, тем больше отношений требуется определить, чтобы связать их между собой. Из теории Кодда отнюдь не следует, что каждая таблица должна быть напрямую связана с любой другой таблицей. Но, поскольку каждая таблица связана хотя бы с одной таблицей в базе данных, можно утверждать, что все таблицы в базе имеют прямые или косвенные отношения друг с другом.
Я установил, какие поля будут включены в базу данных и разбил их на таблицы. Следующий шаг создания логической структуры базы данных заключается в нормализации хранящейся в ней информации.
3.3 Нормализация данных, понятие нормальной формы
Итак, фраза "нормализация данных" означает приведение структуры БД к нормальной форме.
Нормальная форма - свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение.
Процесс преобразования отношений базы данных (БД) к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в базе данных информации. Как отмечает К. Дейт, общее назначение процесса нормализации заключается в следующем:
· исключение некоторых типов избыточности;
· устранение некоторых аномалий обновления;
· разработка проекта базы данных, который является достаточно "качественным" представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;
· упрощение процедуры применения необходимых ограничений целостности.
Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов).
Существует всего 8 нормальных форм, причём каждая последующая нормальная форма является положительной модификацией предыдущей, но в данном курсовом проекте я остановлюсь на третьей нормальной форме, поскольку дальнейшая нормализация не имеет смысла, так как все последующие нормальные формы предназначены для гораздо более сложных и масштабных баз данных.
3.4 Первая нормальная форма
Сущность находится в первой нормальной форме, если и только если все её атрибуты содержат только атомарные значения. Среди атрибутов не должно встречаться повторяющихся групп, т.е. нескольких значений для каждого экземпляра. Иными словами, для приведения сущности к первой нормальной форме, необходимо разбить все её атрибуты (столбцы таблицы) на логические неделимые составляющие.
Для приведения логической модели базы данных к первой нормально форме необходимо, чтобы все сущности этой модели были в первой нормальной форме. Поскольку я уже выделил 4 логически связанные между собой группы данных ранее, тем самым выполнив одно из условий первой нормальной формы таблицы ещё на этапе концептуального проектирования, сейчас мне остаётся только добиться атомарности всех атрибутов каждой сущности.
В сущности "Работник" атрибут Name заменим тремя атрибутами Name, Family и Second, что соответствует имени, фамилии и отчеству работника. В изначальном наборе данных одно поле Name описывало имя, фамилию и отчество сотрудника, т.е. в одном поле было описано сразу три атрибута одной таблицы, а это противоречит правилу атомарности данных в каждой таблице, а, следовательно, противоречит требованиям первой нормальной формы.
По тому же принципу в сущности "Работник" атрибут Place заменим двумя атрибутами NativeLand и HomeTown, которые характеризуют родную страну и город, в котором родился работник (он же может быть выходцем из солнечного Еревана, например). Атрибут Address разложим на 4 атрибута City, Street, House и Apartment, что соответствует значениям населённого пункта, в котором живёт сотрудник, названию улицы, номеру дома и квартиры. Далее в сущности "Предыдущее место работы" атрибут WorkAdress заменим атрибутами WorkCity (город), WorkStreet (Улица), WorkBuildihg (номер дома), и Unit (номер блока\цеха\стороны дома), таким образом атомарно и точно описав адрес предыдущего места работы сотрудника университета.
Теперь все атрибуты всех сущностей (колонки всех таблиц) приведены к атомарному, логически неделимому виду, а все данные разделены на 4 родственные группы. Таким образом, можно сказать, что моя логическая модель базы данных приведена к первой нормальной форме (Рис.3).
Рис.3 первая нормальна форма
3.5 Вторая нормальная форма
Таблица находится во второй нормальной форме, если она удовлетворяет условиям первой нормальной формы, и любое неключевое поле однозначно идентифицируется полным набором ключевых полей.
3.5.1 Определение ключевых полей
Настало время поговорить о ключевых полях. Мощь реляционных баз данных, таких как Microsoft Access, опирается на их способность быстро найти и связать данные из разных таблиц при помощи запросов, форм и отчетов. Для этого каждая таблица должна содержать одно или несколько полей, однозначно определяющих каждую запись в таблице. Такие поля называют первичным ключом таблицы. Если для таблицы определен первичный ключ, то Microsoft Access предотвращает дублирование значений полей или ввод значений Null в эти поля. В Microsoft Access 2003 можно выделить три типа ключевых полей: простой ключ, составной ключ и счетчик. Если поле содержит уникальные значения, то его можно определить как ключевое или простой ключ. Примеры из нашей реальной жизни: идентификационный номер налогоплательщика, однозначно определяющий каждого жителя нашей страны, номер свидетельства пенсионного фонда, кадастровый номер земельного участка, реестровый номер строения, номер автомобиля - все это уникальные номера в пределах страны.
Существует так же понятие первичного ключа. Первичный ключ (primary key) - в реляционной модели данных один из потенциальных ключей отношения, выбранный в качестве основного ключа (или ключа по умолчанию).
Если в отношении имеется единственный потенциальный ключ, он является и первичным ключом. Если потенциальных ключей несколько, один из них выбирается в качестве первичного, а другие называют "альтернативными".
Что же касается моей базы данных, то наиболее подходящим на роль простого первичного ключа полем является поле PersonID. Регистрационный номер работника ВУЗа выполняет функции табельного номера. Каждому сотруднику внутри университета присвоен свой уникальный регистрационный номер, который не может повторяться, а это значит, что этот номер будет уникально идентифицировать каждого сотрудника по любому признаку в любой сущности, а именно этими свойствами должен обладать первичный ключ базы данных.
3.5.2 Установка связей между сущностями
Логические взаимосвязи представляют собой связи между сущностями. Они определяются глаголами, показывающими, как одна сущность относится к другой.
Некоторые примеры взаимосвязей:
· команда включает много игроков,
· самолет перевозит много пассажиров,
· продавец продает много продуктов.
Во всех этих случаях взаимосвязи отражают взаимодействие между двумя сущностями, называемое "один-ко-многим". Это означает, что один экземпляр первой сущности взаимодействует с несколькими экземплярами другой сущности. Взаимосвязи отображаются линиями, соединяющими две сущности с точкой на одном конце и глаголом, располагаемым над линией.
Кроме взаимосвязи "один-ко-многим" существует еще один тип - это "многие-ко-многим". Этот тип связи описывает ситуацию, при которой экземпляры сущностей могут взаимодействовать с несколькими экземплярами других сущностей. Связь "многие-ко-многим" используют на первоначальных стадиях проектирования. Этот тип взаимосвязи отображается сплошной линией с точками на обоих концах.
Связь "многие-ко-многим" может не учитывать определенные ограничения системы, поэтому может быть заменена на "один-ко-многим" при последующем пересмотре проекта.
При проведении связи между двумя сущностями в дочерней сущности автоматически образуются внешние ключи (foreign key). Связь образует ссылку на атрибуты первичного ключа в дочерней сущности, и эти атрибуты образуют внешний ключ в дочерней сущности. Атрибуты внешнего ключа обозначаются символами (FK) после своего имени.
В представленной мной модели базы данных в качестве основной сущности, через которую будут связаны все сущности базы данных, я выбрал сущность "Работник", поскольку база данных направлена на хранение информации о непосредственно работниках вуза. Ключевым атрибутом сущности "Работник", как уже писалось выше, стал атрибут PersonID.
Для того чтобы установить связь сущности "Работник" с остальными, в рабочем окне ERwin на панели toolbox нужно выбрать связь типа identifying relationship (идентифицирующая связь) и кликнуть сначала на родительской сущности (в моём случае "работник"), а затем на дочерней (в моём случае их три - "Текущее место работы", "Предыдущее место работы" и "Образование").
На рис.4 видно, что первичный ключ, установленный для родительской сущности "работник", мигрировал во все дочерние сущности с пометкой (FK). Поскольку моя модель базы данных находится в первой нормальной форме и все поля всех её таблиц полностью и однозначно идентифицируются первичным внешним ключом, то можно сказать, что моя модель базы данных находится во второй нормальной форме.
Рис.4. Вторая нормальная форма
3.6 Третья нормальная форма
Таблица находится в третьей нормальной форме, если она удовлетворяет условиям второй нормальной формы и ни одно из неключевых полей таблицы не идентифицируется с помощью другого неключевого поля.
На данном этапе модель претерпевает самые значительные и кардинальные изменения в своей структуре. Если внимательно посмотреть на 4 образовавшиеся таблицы, то можно заметить, что многие неключевые атрибуты сущностей однозначно идентифицируют несколько других атрибутов. Так, например атрибут Passport (номер паспорта) сущности "работник" однозначно определяет атрибуты NativeLand (родная страна), HomeTown (родной город), PassportDate (дата выдачи паспорта), Birth (дата рождения) и Region (кем выдан паспорт). Данная ситуация является нарушением требований третьей нормальной формы, поэтому я создал ещё одну сущность с названием "паспортные данные" и вынес туда все вышеописанные атрибуты, связав при этом её с сущностью "работник" идентифицирующей связью. Поскольку помимо внешнего ключа, мигрировавшего к дочерней сущности от родительской, у каждой сущности нужно определить также и свой собственный ключ, который может быть как простым, так и составным, я сделал атрибут Passport ключевым для данной сущности.
Аналогично предыдущему случаю, в сущности "работник" атрибут Phone однозначно определяет атрибуты City, Street, House, Apartment, поскольку в одной квартире, находящейся только в одном доме и только на одной улице может быть только один домашний номер телефона. В двух разных квартирах, находящихся по разным адресам один и тот же номер домашнего телефона быть не может.
Рассмотрев сущность "предыдущее место работы", можно увидеть, что связка атрибутов WorkBegin и Work однозначно определяет атрибуты WorkEnd, Reason, Penalty и Rewards, потому что если определённый сотрудник начал работать, скажем, менеджером по подбору персонала, он не может два раза в разное время окончить свою работу на этой должности. Отсюда следует, что если он окончил свою работу на определённой должности, то причина увольнения может быть указана только один раз, как и сведения о взысканиях и награждениях. Логично будет в этой ситуации создать ещё одну сущность с названием "опыт работы" и вынести туда все вышеописанные атрибуты, установив определяющие атрибуты ключевыми и создав зависимую связь с сущностью "работник".
Данные распределены по таблицам и структура модели стала более логически упорядоченной и менее загруженной. Но при внимательном рассмотрении сущности "Образование" можно заметить ещё одну транзитивную зависимость атрибутов DegreeYes и Degree от внешнего ключа модели. Избавиться от неё можно созданием ещё одной сущности "Научные достижения" и вынесением туда атрибутов Degree, Rank и DegreeYes в качестве ключа. Но на этом останавливаться пока рано, поскольку вариантов записи учёного звания и учёной степени может быть несколько, а это недопустимо по правилам первой нормальной формы. Для того чтобы избежать конфликтов и повторений, я создал ещё две таблицы-справочника под названием "учёная степень" и "учёное звание". Они будут содержать всего по 2 поля - номер звания или степени и само их название. Отличие этих сущностей от остальных в том, что они связаны только с сущностью "Научные достижения" неидентифицирующей связью (объект non-identifying relationship на панели toolbox). Это означает, что эти сущности сами являются родительскими и их ключевые атрибуты мигрируют в дочернюю в качестве внешних ключей. В таблице "Научные достижения" эти поля будут содержать просто ссылку на номер учёного звания или учёной степени, название которых хранится в одноимённых таблицах, что позволит избежать недопустимых значений в этих полях.
Осталась только одно несоответствие правилам нормализации - в сущности "предыдущее место работы" атрибут WorkPhone может принимать несколько значений, ведь в организации, в которой раньше работал сотрудник, может быть несколько рабочих телефонов, а это противоречит даже правилам первой нормальной формы. Необходимо создать отдельную сущность "рабочий телефон" и связать её с сущностью "предыдущее место работы" идентифицирующей связью, что подразумевает миграцию ключей родительской сущности в дочернюю. После определения ключевых атрибутов у остальных сущностей можно сказать, что модель базы данных полностью удовлетворяет требованиям третье нормальной формы и находится в ней (рис.5).
Рис.5 третья нормальная форма
3.7 Проверка адекватности логической модели
Если взаимосвязи между сущностями были правильно установлены, то можно составить предложения, их описывающие. Например, по моей модели, показанной на рис.6 можно составить следующие предложения:
· Работник работает на месте работы.
· Работник имеет опыт работы.
· Работник имеет научные достижения.
· Учёное звание присвоено за научные достижения.
· На предыдущем месте работы имеется рабочий телефон
· Учёная степень присвоена за научные достижения и др.
Составление таких предложений позволяет проверить соответствие полученной модели требованиям и ограничениям создаваемой системы. Судя по тому что для каждой связи в моей модели возможно составить глагольное предложение, можно сделать вывод, что модель логически адекватна.
Рис.6 пример связей с проверочными глаголами
3.8 Установление параметров связей между сущностями
3.8.1 Определение типа и мощности связей
Связь является логическим соотношением между сущностями. Связь имеет имя, мощность, тип.
Имя связи (Verb Phrase) - фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи один-ко-многим достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child).
Мощность связи (Cardinality) - служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
Различают четыре типа мощности:
общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности (не помечается каким-либо символом);
символом P помечается случай, когда одному
P экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);
символом Z помечается случай, когда одному
Z экземпляру родительской сущности соответствуют 0 или
1 экземпляр дочерней сущности (исключены множественные значения);
цифрой помечается случай, когда одному экземпляру
N родительской сущности соответствует заранее заданное
число экземпляров дочерней сущности.
Различают два типа связей: идентифицирующая и неидентифицирующая.
Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами.
Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. В дочерней сущности новые атрибуты помечаются как внешние ключи - (FK).
При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов дочерней. Неидентифицирующая связь служит для связи независимых сущностей.
Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи, неидентифицирующая - пунктирной.
Для неидентифицирующей связи можно указать обязательность (Nulls). В случае обязательной связи (No Nulls) при генерации схемы БД атрибут внешнего ключа получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в состав первичного ключа дочерней сущности. В случае необязательной связи (Nulls Allowed) внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности.
Атрибуты первичного ключа родительской сущности по умолчанию мигрируют со своими именами. ERwin позволяет ввести для них роли или функциональные имена (Rolename), т.е. новые имена, под которыми мигрирующие атрибуты будут представлены в дочерней сущности.
Для того чтобы указать определённый набор настоек связи, нужно выделить связь, щелкнув по ней указателем мыши. Затем нажать правую кнопку мыши и в контекстном меню выбрать пункт Relationship Properties (редактор связей).
В верхней части редактора связей находится выпадающий список, содержащий полное название связи. В моём случае осмысленные глагольные фразы для всех связей уже определены, поэтому в этом поле значится сама фраза. Здесь же находятся две кнопки New и Delete, с помощью которых можно добавить на схеме новую связь или удалить существующую.
Кроме того, диалоговое окно редактора связей содержит следующие закладки:
џ General (общие свойства). Здесь задаются общие свойства связи - имя, тип и мощность связи.
џ Definition (определение). На этой странице вводится определение связи, облегчающее восприятие модели.
џ Rolename (Имя роли) - вводятся функциональные имена (для мигрирующих атрибутов).
џ RI Actions (Установки ссылочной целостности) - задаются правила ссылочной целостности.
Из настроек связей я на данном этапе проектирования изменял только имя связи, тип и мощность, их можно увидеть на рис.7
Преобладают в моей модели связи с мощностью "One or More", поскольку в большинстве случаев у работника может быть один или больше экземпляров сущности. Так, сущность "место работы" связана с сущностью "работник" связью "One or More", потому что широко распространена практика работы одного преподавателя в нескольких вузах одновременно. Связь такого же типа связывает сущности "Работник" и "Жильё", поскольку у одного человека, теоретически, может быть несколько квартир. Так как высших образования у человека может быть так же несколько, к сущности "Образование" так же проведена связь "One or More". Сущности "Предыдущее место работы" связана с сущностью "Рабочий телефон" этим же типом связи, так как вероятность того что на предыдущем месте работы сотрудника вообще не будет рабочего телефона крайне мала. Сущность "Опыт работы" связана с сущностью "работник" связью мощностью "Zero, One or More", поскольку опыта работы у сотрудника может как не быть вовсе, так и быть более чем на одном предприятии. Учёные степени или звания могут либо быть у работника, либо отсутствовать, поэтому для сущности "научные достижения" установлены связи мощностью "Zero or One". Паспорт у одного человека может быть только один, поэтому у связи сущностей "Работник" и "Паспортные данные" установлена мощность связей в фиксированном выражении 1 экземпляра.
Рис.7 типы и мощность связей
3.8.2 Задание правил декларативной ссылочной целостности
Правила ссылочной целостности - это логические конструкции, которые выражают бизнес-правила использования данных. Они определяют, какие действия должна выполнить СУБД при удалении, вставке или изменении строки таблицы (экземпляра сущности). Заданные таким образом действия используются впоследствии при автоматической генерации триггеров, поддерживающих целостность данных.
Существуют следующие виды действий или правил, определяемых в логической модели:
· RESTRICT - запрет удаления, вставки или изменения экземпляра сущности.
· CASCADE - при удалении экземпляра родительской сущности удаление всех экземпляров дочерней сущности, ссылающихся на удаляемый родительский экземпляр.
· SET NULL - при удалении экземпляра родительской сущности атрибутам внешнего ключа всех экземпляров дочерней сущности присваивается значение NULL.
· SET DEFAULT - то же самое, что и в предыдущем случае, только вместо значения NULL присваивается значение по умолчанию.
· NONE - никаких действий не предпринимается.
Эти правила задаются на вставку, удаление и изменение экземпляра как родительской, так и дочерней сущности. Таким образом, каждая связь должна обладать набором из шести правил, которые вводятся в поля, объединенные общим заголовком "RI Actions". При добавлении связи в диаграмму ERwin по умолчанию устанавливает для нее набор правил, которые можно редактировать. Для вызова редактора связей необходимо выделить связь "паспорт" между сущностями "Работник" и "Паспортные данные", щелкнув по ней указателем мыши. Затем нужно нажать правую кнопку мыши и в контекстном меню выбрать пункт Relationship Properties (редактор связей). В окне редактора связей Relationship я перехожу на вкладку RI Actions. Здесь можно ознакомиться с правилами ссылочной целостности для связи "Работник - Паспортные данные", присвоенными по умолчанию (рис.8). Данные установки запрещают вставку и изменение экземпляра дочерней сущности, а также удаление и изменение родительской сущности. Это означает, что не допускается удаление или изменение работника, если в базе данных имеются записи о его паспортных данных, а также ввод паспортных данных без указания работника или со ссылкой на несуществующего работника. Тем самым мы выполнили условие, по которому запись о паспортных данных может существовать только для конкретного сотрудника университета.
Рис.8 Установки ссылочной целостности для связи "паспорт"
Указанные на рис.8 настройки являются настройками по умолчанию для всех сущностей, и в данной работе изменятся эти настройки не будут, поскольку настройки по умолчанию соответствуют требованиям, представленным к структуре данных в моём конкретном случае. Тем не менее, анализ ссылочной целостности является важным аспектом логического проектирования структуры базы данных, и поэтому механизм этого анализа был освещён в моей курсовой работе.
3.9 Установление альтернативных ключей, инверсных входов и определение типов атрибутов
Потенциальный ключ, не ставший первичным, называется альтернативным ключом (Alternate Key). ERWin позволяет выделить атрибуты альтернативных ключей, и по умолчанию в дальнейшем при генерации схемы БД по этим атрибутам будет генерироваться уникальный индекс. При создании альтернативного ключа на диаграмме рядом с атрибутом появляются символы (АК).
Атрибуты, участвующие в неуникальных индексах, называются инверсионными входами (Inversion Entries). Инверсионные входы - это атрибут или группа атрибутов, которые не определяют экземпляр уникальным образом, но часто используются для обращения к экземплярам сущности. ERWin генерирует неуникальный индекс для каждого инверсионного входа.
В данном примере я устанавливаю альтернативные ключи и инверсные входы для сущности "Предыдущее место работы". Для установления альтернативного ключа или инверсного входа необходимо вызвать редактор ключевых групп Key Groups, щелкнув правой кнопкой мыши по сущности "Предыдущее место работы и выбрав из контекстного меню пункт Key Groups. Редактор ключевых групп также можно вызвать через главное меню: Model | Key Groups.
Редактор ключевых групп содержит элементы управления:
Entity - поле с выпадающим списком, в котором следует выбрать сущность для редактирования.
Окно с перечнем ключевых групп. Каждая группа представлена отдельной строкой, включающей в себя имя (Key Group), тип (Type) и определение (Definition).
Кроме того, диалоговое окно редактора ключевых групп содержит следующие закладки:
џ Members (члены). Задаются члены ключевых групп и их порядок следования в группе.
џ General (общие установки). Переключатели, позволяющие задавать тип ключевой группы. Для первичного и внешнего ключа эти группы недоступны.
џ Definition (определение). Произвольная текстовая информация, относящаяся к выбранной ключевой группе.
џ Note (примечание). Примечание к выбранной группе.
џ UDP (пользовательские свойства).
Для создания нового альтернативного ключа необходимо нажать кнопку New
џ Далее в окне New Key Group в поле Key Group ввести имя ключевой группы - Предыдущее место работы. В поле Index выводится генерируемое программой Erwin имя индекса. Его я оставляю без изменений.
џ Переключатель Key Group Type задает тип создаваемого ключа. Это может быть альтернативный ключ (Alternate Key) или инверсный вход (Inversion Entry). В данном случае я выбрал сначала Alternate Key и нажал ОК. Вновь введенный альтернативный ключ появился в перечне ключей.
џ Перехожу на закладку Members. Новый ключ пока не содержит никаких атрибутов, поэтому правый список Key Group Members (члены ключевой группы) пуст. Выбираю в левом списке атрибуты WorkStreet, WorkBuilding и Unit, и перемещаю их в правый список при помощи кнопки со стрелкой (рис.9).
Рис.9 редактор ключевых групп
Аналогичным образом я указал альтернативные ключи и инверсные входы для каждой сущности моей модели.
Создание инверсного входа проходит по точно такому же алгоритму, и единственным отличием является выбор пункта Inversion Entry после нажатия кнопки New в окне редактора ключевых групп, а не Alternate Key. В моём примере поля для определения инверсного входа так же отличаются от полей альтернативного ключа, но, тем не менее, возможны случаи, когда один и тот же атрибут входит как в состав альтернативного ключа или является им, так и в состав инверсного входа. В моём случае в качестве инверсного входа я указал атрибут WorkPlace, поскольку название предприятия может часто использоваться в запросах на выборку определённых данных.
Для определения типов данных необходимо выделить любую сущность, щёлкнув по ней, а затем вызвать пункт меню Model | Attributes. То же самое можно выполнить, выбрав пункт Attributes контекстного меню. При этом на экране появится окно редактора атрибутов Attributes.
В верхней части диалогового окна находится выпадающий список, в котором можно выбрать сущность для редактирования. В моём примере я выбрал сущность "опыт работы".
В группе Domain находится список доменов, представляющих основные типы данных, используемые в СУБД: строковый (string), числовой (number), время (datetime), двоичный (blob). Также, в случае, когда определение домена вызывает затруднения, можно не выбирать конкретный домен, а оставить значение default. Для атрибута WorkBegin, например, я указал домен даты - datetime, а при определении домена для атрибута penalty-строковый домен (string). Аналогичным образом я определил типы доменов для каждого атрибута. В результате окно редактора атрибутов будет выглядеть так, как показано на рис.10.
Рис.10 Атрибуты сущности Penalty
Порядок следования атрибутов в списке можно изменять при помощи кнопок со стрелками, находящимися над окном списка. Для этого необходимо выбрать нужный атрибут в списке, нажать одну их этих кнопок, и атрибут сместится в списке в направлении стрелки, изображенной на кнопке.
Итак, после указания всех альтернативных ключей, инверсных входов, и определения доменных типов данных для всех атрибутов, этап логического проектирования модели данных заканчивается. На рис.11 можно увидеть логическую модель данных в полностью завершённом виде. Символами (AK) обозначаются альтернативные ключи, обозначение (IE) соответствует инверсным входам, а доменные типы данных указаны в каждой сущности справа от каждого атрибута. Следующий шаг - создание физической модели данных.
Рис.11 окончательный вид логической модели данных
4. Физическое проектирование
4.1 Переход к физическому уровню модели
В предыдущей главе я полностью спроектировал модель базы данных на логическом уровне. Теперь нужно перейти к физическому уровню проектирования, а для этого необходимо трансформировать спроектированную ранее логическую модель в физическую, поскольку ERwin позволяет работать как с логической, так и с физической моделью базы данных.
Целью создания физической модели является обеспечение администратора соответствующей информацией для переноса логической модели данных в СУБД.
ERWin поддерживает автоматическую генерацию физической модели данных для конкретной СУБД. При этом логическая модель трансформируется в физическую по следующему принципу: сущности становятся таблицами, атрибуты становятся столбцами, а ключи становятся индексами.
Для трансформации логической модели в физическую необходимо выбрать меню Tools | Derive New Model. В открывшемся диалоговом окне (рис.12) выбрать тип модели, в которую необходимо произвести трансформацию. ERwin может создать как чисто физическую модель данных, для работы с моделью только на физическом уровне, так и комбинированную физико-логическую модель. Она удобна тем, что даёт возможность в любой момент времени переключаться между видом модели на физическом и логическом уровне проектирования. Внизу диалогового окна необходимо выбрать сервер (СУБД), на который в будущем будет перенесена база данных.
В блоке New Model Type я выбрал пункт Logical/Physical, поскольку существует вероятность того, что в процессе разработки модели БД на физическом уровне мне придётся возвращаться на логический и обратно, так как некоторые функции редактирования модели ERwin делает доступными либо только на логическом уровне, либо, наоборот, только на физическом.
В блоке Target Database программа предлагает выбрать целевую СУБД, в которую потом будет переносится созданная структура. В выпадающих списках я выбрал пункт Access версии 2000/2002/2003.
Рис.12 окно трансформации логической модели данных в физическую
Нажатие кнопки далее переведёт в следующее диалоговое окно более детальной настройки создания физической модели базы данных, но в моём случае можно остановиться и на данном этапе. Указанной мной информации достаточно, поэтому нажатием кнопки Derive я создаю физическую модель на основе логической и сразу перехожу в режим работы с ней.
Теперь я могу переключаться между логической и физической моделью структуры данных с помощью выпадающего меню в верхней части окна программы и работать с ними одновременно. Внешне окно почти не изменяется в зависимости от переключения с одной модели на другую, только при работе на физическом уровне в списке основных меню программы в верхней части окна появляется ещё пункт Database, который отсутствует при работе на логическом уровне.
4.2 Денормализация данных
После нормализации все взаимосвязи данных определены, исключая ошибки при оперировании данными. Но нормализация данных снижает быстродействие БД. Для более эффективной работы с данными, используя возможности конкретного сервера БД, приходится производить процесс, обратный нормализации - денормализацию.
Денормализация - намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.
Устранение аномалий данных в соответствии с теорией реляционных баз данных требует, чтобы любая база данных была нормализована, то есть соответствовала требованиям нормальных форм. Соответствие требованиям нормализации минимизирует избыточность базы данных и обеспечивает отсутствие многих видов логических ошибок обновления и выборки данных.
Однако в некоторых случаях для некоторых запросов выборки операция соединения (JOIN) нормализованных отношений выполняется неприемлемо долго. Вследствие этого в ситуациях, когда производительность таких запросов невозможно повысить иными средствами, может проводиться денормализация - композиция нескольких отношений (таблиц) в одну, которая, как правило, находится во второй, но не в третьей нормальной форме. Новое отношение фактически является хранимым результатом операции соединения исходных отношений.
За счёт такого перепроектирования операция соединения при выборке становится ненужной и запросы выборки, которые ранее требовали соединения, работают быстрее.
Следует помнить, что денормализация всегда выполняется за счёт повышения риска нарушения целостности данных при операциях модификации.
Кроме того, следует учесть, что ускорение одних запросов на денормализованной БД может сопровождаться замедлением других запросов, которые ранее выполнялись отдельно на нормализованных отношениях.
Для процесса денормализации не существует стандартного алгоритма, поэтому в каждом конкретном случае приходится искать свое решение. Денормализация обычно проводится на физическом уровне модели. ERWin имеет следующие возможности по поддержке процесса денормализации:
· Сущности, атрибуты, группы ключей и домены можно создавать только на логическом уровне модели.
· В ERWin существует возможность выделения элементов логической модели таким образом, чтобы они не появлялись на физическом уровне.
· Таблицы, столбцы, индексы и домены можно создавать только на физическом уровне.
· В ERWin существует возможность выделения элементов модели таким образом, чтобы они не появлялись на логическом уровне. Эта возможность напрямую поддерживает денормализацию физической модели, так как позволяет проектировщику включать таблицы, столбцы и индексы в физическую модель, ориентированную на конкретную СУБД.
· Разрешение связей "многие-ко-многим". При разрешении этих связей в логической модели ERWin добавляет ассоциированные сущности и позволяет добавить в них атрибуты. При разрешении связей в логической модели автоматически разрешаются связи и в физической модели.
Вот пример ситуации, когда в модели данных необходима денормализация.
В запросах к полностью нормализованной базе нередко приходится соединять до десятка, а то и больше, таблиц. А каждое соединение - операция весьма ресурсоемкая. Как следствие, такие запросы кушают ресурсы сервера и выполняются медленно.
В такой ситуации может помочь:
· Денормализация путем сокращения количества таблиц. Лучше объединять в одну несколько таблиц, имеющих небольшой размер, содержащих редко изменяемую (как часто говорят, условно-постоянную, или нормативно-справочную) информацию, причем информацию, по смыслу тесно связанную между собой.
Подобные документы
Основные понятия баз данных: нормализация, связи и ключи. Создание и этапы проектирования базы данных, решение задачи о предметной области. Изучение СУБД 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
