Создание новой базы данных

Методические указания

По дисциплине

«ИНФОРМАЦИОННЫЕ СИСТЕМЫ»

 

 

Москва 2013

План УМД 2012/13 учебного года

 

Методические указания по дисциплине

«ИНФОРМАЦИОННЫЕ СИСТЕМЫ»

 

Составитель Ванина М.Ф., канд. техн. наук, доцент

 

Утверждено на заседании кафедры 17.04.2013, протокол № 8.

 

© Московский технический университет связи и информатики, 2013

 

Оглавление

1. ПРОЕКТИРОВАНИЕ СТРУКТУРЫ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ.. 4

1.1. Основные понятия экономических информационных систем (ЭИС) 4

Модели баз данных. 4

Реляционная модель данных. 4

1.2. Нормализация базы данных и ее необходимость. 5

2. СОЗДАНИЕ БАЗЫ ДАННЫХ MSACCESS. 10

2.1. Создание новой базы данных. 10

2.2. Интерфейс Microsoft Office Access. 11

2.3. Создание таблиц. 13

2.4. Контроль правильности ввода данных. 17

Добавление условия на значение поля. 17

Добавление условия на значение записи. 17

2.5. Сохранение таблицы.. 17

3. СОЗДАНИЕ СВЯЗЕЙ МЕЖДУ ТАБЛИЦАМИ.. 18

3.1. Создание первичных ключей и индексов. 18

3.2. Создание связей между таблицами. 19

Создание связи "один-ко-многим". 19

Создание связи "один-к-одному". 20

4. РАБОТА С ДАННЫМИ В РЕЛЯЦИОННОЙ БАЗЕ.. 21

4.1. Создание запроса в режиме конструктора. 21

4.2. Использование параметров запроса. 23

4.3. Выборка с исключением дубликатов. 24

4.4. Выборка вычисляемых значений. 25

Использование арифметических операций. 25

Использование функций. 26

4.5. Реляционные объединения. 31

5. СОЗДАНИЕ ПРИЛОЖЕНИЯ БАЗЫ ДАННЫХ.. 32

5.1. Привязка задач к формам и отчетам.. 32

5.2. Создание базовых запросов для форм и отчетов. 32

5.3. Создание форм для ввода и редактирования данных. 33

Использование мастера форм.. 33

Добавление в форму полей со списком.. 36

Создание группы переключателей. 38

5.4. Создание отчетов для вывода данных. 39

Мастер создания отчетов. 39

 

 

 

Проектирование структуры реляционных баз данных

 

Основные понятия экономических информационных систем (ЭИС)

Модели баз данных

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

 

Реляционная модель данных

Основная идея реляционной модели данных заключается в том, чтобы представить любой набор данных в виде двумерной таблицы. В простейшем случае реляционная модель описывает единственную двумерную таблицу, но чаще всего эта модель описывает структуру и взаимоотношения между несколькими различными таблицами. Основоположником теории реляционных баз данных считается сотрудник фирмы IBM доктор Э.Кодд, опубликовавший в 1970 г. статью A Ralational Model of Data for Large Shared Data Banks (Реляционная модель данных для больших коллективных банков данных). В этой статье впервые был использован термин «реляционная модель данных», что и положило начало реляционным базам данных. Теория реляционных баз данных, разработанная доктором Э.Коддом, имеет под собой мощную математическую основу, описывающую правила эффективной организации данных. Реляционной считается такая база данных, в которой все данные представлены для пользователя в виде прямоугольных таблиц значений данных, и все операции над базой сводятся к манипуляции с таблицами. Таблица состоит из столбцов (колонок, полей) и строк (записей). Таблица отражает тип объекта реального мира (сущность), а каждая ее строка – конкретный объект.

 

 

1.2. Нормализация базы данных и ее необходимость

	В качестве примера рассмотрим таблицу ПРОДАЖИ, которая содержит: · сведения о покупателях; · дату заказа и количество заказанного товара; · дату выполнения заказа и количество проданного товара; · характеристику проданного товара (наименование, стоимость, категория). Таблицу ПРОДАЖИ можно рассматривать как однотабличную базу данных.
	Рис.1.1. Однотабличная база данных ПРОДАЖИ.
Проблемы избыточности данных	Основной недостаток однотабличной базы данных состоит в том, что в ней содержится значительное количество повторяющейся информации. Такая избыточность данных ведет к возникновению следующих проблем: 1. Потребуется значительное время на ввод повторяющихся данных. 2. Наличие повторяющейся информации приведет к неоправданному увеличению базы данных. В результате снизится скорость выполнения запросов. 3. При многократном вводе повторяющихся данных возрастает вероятность ошибки. При больших размерах таблиц поиск ошибок будет занимать значительное время. Процесс уменьшения избыточности информации в БД называется нормализацией. В теории нормализации разработаны достаточно формализованные подходы к разбиению данных на несколько таблиц и организации между ними взаимосвязей.
Теория нормализации	Теория нормализации оперирует с пятью нормальными формами отношений (от 1НФ до 5НФ включительно). Эти формы предназначены для уменьшения избыточной информации, при этом каждая последующая нормальная форма должна удовлетворять требованиям предыдущей формы и некоторым дополнительным условиям. При практическом проектировании баз данных четвертая и пятая формы, как правило, не используются, поэтому ограничимся рассмотрением первых трех нормальных форм.
Первичный ключ	В таблице ПРОДАЖИ поле КодПокуп может быть выбран в качестве первичного ключа (primary key, РК). Значению поля КодПокуп соответствуют: · единственные значения полей Фамилия, Имя, Отчество, Телефон, Индекс, Страна, Область, Город, Адрес, Предпр, Руководит, Кредит; · N значений полей КодТов, ДатаЗаказ, Заказано, ДатаПрод, Продано, Цена, Категория, НаимТов (где N - количество заказов у данного покупателя).
1НФ	Отношение имеет первую нормальную форму (1НФ), если оно удовлетворяет следующим требованиям: 1) отношение должно иметь уникальный первичный ключ; 2) должна иметься однозначная зависимость каждого атрибута отношения от первичного ключа; 3) должны отсутствовать повторяющиеся группы атрибутов. Для устранения повторяющихся групп (каждый покупатель может иметь N заказов) разобьем таблицу ПРОДАЖИ на две таблицы (Рис.1.2): · таблицу ПОКУПАТЕЛЬ, каждая строка которой содержит сведения об одном из покупателей; · таблицу ЗАКАЗ, каждая строка которой содержит сведения об одном из N заказов каждого из покупателей.
N	Рис.1.2. База данных "Продажи" в 1НФ
	Для таблицы ПОКУПАТЕЛЬ создается простой первичный ключ, основанный на поле КодПокуп. Для исключения повторяющихся записей в таблице ЗАКАЗ следует образовать составной первичный ключ, содержащий поля КодПокуп, КодТовара и ДатаЗаказ.
2НФ	Отношение имеет вторую нормальную форму (2НФ), если оно соответствует 1НФ и не содержит неполных функциональных зависимостей (ФЗ). Неполная ФЗ - это две зависимости: 1) ключ таблицы определяет некоторый ее неключевой атрибут; 2) часть ключа определяет этот же неключевой атрибут. Из определения следует, что понятие 2НФ применимо только к отношениям, имеющим составной ключ. Таблица ЗАКАЗ, имеющая составной ключ, не находится в 2НФ, поскольку неключевые поля НаимТов, Цена и Категория однозначно определяются частью составного ключа КодТовара (рис. 2.3). Т.е. имеется неполная ФЗ. Для приведения таблицы к 2НФ выделим из таблицы ЗАКАЗ таблицу ТОВАРЫ, которая будет содержать информацию о товарах каждого типа.
Рис.1.3. База данных "Продажи" в 2НФ 3НФ	Отношение имеет третью нормальную форму (3НФ), если оно соответствует 2НФ и среди его атрибутов отсутствуют транзитивные ФЗ. ТранзитивныеФЗ - это две зависимости: 1) ключ отношения определяет некоторый неключевой атрибут; 2) этот неключевой атрибут определяет другой неключевой атрибут.   В таблице ПОКУПАТЕЛЬ (рис. 1.4) неключевое поле Руководит содержит имена руководителей компаний, которые однозначно определяются другим неключевым полем Предпр. Т.е. существует транзитивная ФЗ. Для приведения таблицы ПОКУПАТЕЛЬ к 3НФ создается новая таблица КОМПАНИЯ.
	Рис.1.4. База данных "Продажи" в 3НФ
	Требование нормализации всех таблиц в реляционной базе данных не является обязательным. Разбить таблицу на более мелкие (теоретически - свести ее к 3НФ) практически может потребоваться в следующих случаях: · некоторая информация из этой таблицы используется не очень часто; · нельзя давать доступ к некоторым данным любым желающим

 

Внешний ключ	Результатом нормализации является получение базы данных в виде набора отдельных таблиц. В схеме данных особенно важно определить, как будут взаимодействовать различные таблицы. В реляционной базе данных связь между таблицами устанавливается с помощью связующих полей (см. Рис.1.5).
PK FK FK PK FK PK	Рис.1.5. Многотабличная база данных с эффективной структурой

 

Внешний ключ (foreign key, FK) - это поле в таблице, которое соответствует первичному ключу в другой таблице. Поскольку у каждого клиента может быть несколько заказов, а каждый заказ принадлежит только одному клиенту, то между таблицами ПОКУПАТЕЛЬ и ЗАКАЗ устанавливается связь один-ко-многим. Поскольку каждый товар может присутствовать в нескольких заказах, а каждый заказ связан только с одним товаром, то между таблицами ТОВАРЫ и ЗАКАЗ также устанавливается связь один-ко-многим. Между таблицами ПОКУПАТЕЛЬ и КОМПАНИЯ существует связь один-к-одному, поскольку компания, в которой работает покупатель, имеет одно определенное руководство.

Использование внешних ключей обеспечивает эффективность работы приложений: 1. Поддержка соответствующих значений первичного и внешнего ключа обеспечивает целостность данных: · реляционная база данных не позволит добавить в таблицу строку, если заданное в ней значение внешнего ключа не совпадает ни с одним значением соответствующего первичного ключа, например, в таблицу ЗАКАЗ нельзя ввести строку с неправильным полем КодПокуп - т.е. хранить заказы для несуществующих покупателей; · реляционная база данных не позволит удалить из таблицы строку с первичным ключом, если в базе с этим же значением имеется соответствующий внешний ключ, например, в таблице ПОКУПАТЕЛЬ нельзя удалить запись о покупателе, у которого имеются заказы - т.е. имеются соответствующие ему строки в таблице ЗАКАЗ. 2. Задаваемые при создании таблиц связи первичных ключей с внешними ключами используются для объединения данных из нескольких таблиц. Внешний ключ позволяет реализовать операцию поиска парных строк между таблицами. Например, объединяя таблицы ПОКУПАТЕЛЬ и КОМПАНИЯ с помощью внешнего ключа Предпр, можно получить полную информацию о покупателе.

2. Создание базы данных MSAccess

Создание новой базы данных

 

1. Запустите Microsoft Access 2010 на вашем компьютере.

На экране появится стартовое окно Microsoft Office Access.

1. Щелкните по пиктограмме Новая база данных.
2. Определитесь с именем файла и папкой, в которой будет расположена база данных. Пусть имя файла — Продажи. Нажмите кнопку Создать.

Будет создана новая база данных и открыта таблица Таблица1 в режиме таблицы. База данных получила свое название и место на жестком диске.

 

Отличительной особенностью Microsoft Access 2010 является то, что окно базы данных (Область переходов) является отправной точкой, с которой начинается выполнение всех операций над объектами базы данных: таблицами, запросами, формами, отчетами, макросами и модулями. Все эти элементы хранятся в одном-единственном файле.

 

 

В MS Office Access 2010 представлено несколько расширений файлов:

· accdb — расширение файла формата Office Access 2010. Заменяет файлы с расширением mdb;

· accde — расширение файлов MS Office Access 2010, которые работают в режиме исполнения. В accde-файлах удален весь исходный код. Работающий с accde-файлом может только выполнять код VBA, но не может изменять его. Файлы accde пришли на смену файлам с расширением mde;

· accdt — расширение файлов шаблонов баз данных MS Access 2010;

· accdr — новое расширение файлов, позволяющее открывать базу данных в режиме выполнения. С помощью элементарной замены расширения файла базы данных с accdb на accdr можно создать "закрытую" версию базы данных MS Office Access 2010. Чтобы восстановить полную функциональность, просто верните файлу старое расширение accdb.

12345Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: