30

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

Содержание

• Введение
• Глава 1

1.1 Этапы проектирования базы данных

1.2 Выделение информационных объектов

1.3 Нормализация таблиц-отношений

1.4 Функциональные зависимости

1.5 Ключ отношения

1.6 Описание предметной области

1.6.1Ограничения предметной области

Глава 2

2.1 Создание БД и построение ИЛМ ПО

2.1.1 Связи между информационными объектами

2.1.2 Графическое построение схемы ИЛМ

2.1.3 Определение логической структуры базы данных

Глава 3 Основные сведения о СУБД Access

• Заключение
• Приложение №1 Анализ обеспеченности договоров планами выпуска
• Приложение №2 Схема БД
• Приложение №3 Количество запланированных к выпуску товаров
• Приложение №4 Количество заказанных товаров
• Приложение №5 Анализ обеспеченности договоров планами выпуска по цехам
• Список использованной литературы
• Введение

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

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

Одной из распространенных СУБД является Ассеss, входящая в состав пакета прикладных программ Microsoft Office, разработанного корпорацией Microsoft. проектирование база данные схема

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

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

· определение задач, выполняемых создаваемой СУБД;

· разработка;

· создание запросов;

· построение форм для ввода/вывода данных и просмотра информации, хранящихся в таблицах и запросах;

· создание необходимых отчетов.

Именно подробному изучению работы с отчетами в МS Ассеss и посвящена данная курсовая работа.

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

Задачи работы сводятся к получению:

· основных сведений из теории баз данных и их проектирования;

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

· практических навыков создания баз данных и проектирования их объектов: запросов, форм, отчетов в среде СУБД.

Глава 1

1.1 Этапы проектирования базы данных

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

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

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

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

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

1. Концептуальное проектирование.

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

Формализованное описание предметной области называется её концептуальной моделью. В литературе 70-80 годов использовались термины «инфологическое проектирование» и «инфологическая модель».

Моделирование любой системы невозможно без предварительной формализации.

Формализация -- это процесс выделения и перевода внутренней структуры объекта в определенную информационную структуру -- форму.

По сути, формализация -- это первый и очень важный этап процесса моделирования.

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

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

2. Проектирование информационно - логической модели предметной области

Процесс разработки информационно-логической модели предметной области (ИЛМ) является творческим и трудно поддается описанию.

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

При проектировании базы данных могут использоваться два подхода:

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

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

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

Построение информационно-логической модели разделяется на два основных этапа выделение информационных объектов и определение связей между ними.

1.2 Выделение информационных объектов

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

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

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

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

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

1.3 Нормализация таблиц-отношений

Центральная задача проектирования базы данных - определение количества таблиц-отношений и их атрибутного состава.

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

· множество отношений должно обеспечивать минимальную избыточность представления информации;

· корректировка отношений не должна приводить к двусмысленности или потере информации;

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

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

Нормализация - это разделение целой базы данных на части и связывание полей, основанных на общих значениях. Этот процесс разработал Е.Ф. Кодд, который широко известен как автор теории реляционных баз данных. Основные цели нормализации просты:

· Устранение избыточной информации;

· Расширение взаимодействия данных;

· Повышение эффективности системы.

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

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

Известно шесть нормальных форм: 1-я, 2-я, 3-я, НФБК, 4-я, 5-я. Каждая последующая форма отношения обладает всеми свойствами предыдущей формы, т.е. является её подмножеством, но обладает преимуществом.

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

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

Нормализация отношений реляционной БД обычно производится до ЗНФ или 4НФ.

Реляционная база данных в целом характеризуется 1НФ, если все ее отношения соответствуют 1НФ.

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

1.4 Функциональные зависимости

Функциональные зависимости определяются для атрибутов находящихся в одном и том же отношении.

Определяются функциональные зависимости (ФЗ) на основе семантического анализа предметной области.

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

Простейший случай функциональной зависимости охватывает 2 атрибута. В отношении R (A,B,...) атрибут А функционально определяет атрибут В, если в любой момент времени каждому значению А соответствует единственное значение В (А --> В).

Иначе говорят, что В функционально зависит от А (обозначается В = f (A)). Отсутствие функциональной зависимости обозначается А--/-> В.

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

1.5 Ключ отношения

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

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

· ограничениями предметной области;

· минимизацией объёма внешней памяти, занимаемой базой данных;

· использованием ключа в СУБД при решении задач пользователей.

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

Использование наименования в качестве ключа ИО имеет следующие недостатки:

· наименования могут иметь повторяющиеся значения, например, ФИО студента или работающего;

· они имеют большой размер (занимают много места во внешней памяти);

· не позволяют производить отбор данных из базы данных в соответствии с заданными значениями классификационных признаков.

Использование кодов номенклатуры в качестве ключа лишено перечисленных выше недостатков ключей-наименований:

· коды не имеют повторяющихся значений;

· они существенно короче наименований;

· коды позволяют производить отбор данных из базы данных в соответствии с заданными значениями классификационных признаков, в том числе в соответствии со значением части кода.

В качестве ключа следует использовать коды номенклатуры, а не их наименования. Если код номенклатуры отсутствует в документе, то его следует ввести в ИО, соответствующий этому документу, для использования кода в качестве ключа.

Один и тот же реквизит в разных ИО объектах может быть ключевым и не ключевым (описательным). Замена наименования номенклатуры её кодом целесообразна и в том случае, если этот реквизит не ключевой, т.к. в этом случае он будет занимать меньше места на машинном носителе.

1.6 Описание предметной области

В качестве предметной области рассматриваются функции, выполняемые сотрудниками отдела сбыта предприятия в процессе:

а) Планирования:

– отгрузки продукции в соответствии с договорами;

– сдачи цехами продукции на склад;

б) Учета:

– фактически отгруженной продукции;

– фактически сданной цехами продукции на склад;

в) Анализа:

– корректности договоров на поставку продукции;

– выполнения цехами плана сдачи продукции на склад;

– текущего запаса продукции на складах;

– выполнения плана отгрузки;

Цель выполняемых функций:

– согласование планов выпуска цехами продукции и планов отгрузки продукции;

– постоянный контроль за состоянием запаса продукции на складах и за выполнением договорных обязательств предприятия;

– анализ обеспеченности договоров планами выпуска по цеху;

Описание предметной области

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

1.6.1 Ограничения предметной области отдела сбыта готовой продукции предприятия.

Логические ограничения:

1. Рассматриваются только договора текущего года.

2. В договоре может быть несколько изделий, одно и то же изделие может быть затребовано в разные месяцы.

3. Счет и ТТН всегда ссылаются на договор-основание.

4. Документ об отгрузке продукции (накладная на отпуск товаров, товарно-транспортная накладная) всегда привязан к одному договору, может содержать несколько наименований товаров, и его номер уникален для предприятия.

5. Товар закреплен за одним складом продукции и может выпускаться несколькими цехами.

6. Код товара является уникальным и неизменным.

7. Каждый цех может выпускать несколько наименований товаров.

8. Количество товара измеряется целым числом единиц измерения.

9. У товара только одна единица измерения.

10. Номера цехов и номера складов уникальны и не изменяются, а их наименования могут изменяться.

11. Период плана выпуска цехом продукции равен месяцу.

12. Заданный промежуток анализа задается номером месяца конца периода (начало промежутка анализа по умолчанию равно началу текущего года).

13. Нормативный запас является постоянной величиной для каждого вида товара. По указанию преподавателя процент может задаваться в качестве параметра в процессе решения задачи средствами СУБД.

14. Текущий остаток товара на складе равен разности между его общим количеством, поступившим согласно цеховым накладным, и его общим количеством, отгруженным со склада согласно ТТН.

15. На одном складе могут храниться различные товары.

16. Каждый товар может храниться только на одном складе.

17. План отгрузки товаров определяется только на основании договоров на поставку товаров.

18. Цена товара постоянна в течение действия договора на поставку товаров.

19. Все цены - в рублях.

20. Отчетный период - месяц.

Количественные ограничения:

1. Номенклатура изделий - 5;

2. Число цехов, выпускающих продукцию - 3.

3. Число складов продукции -3.

Глава 2

2.1 Создание БД и построение ИЛМ ПО

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

Создать выходной документ - отчет (см. прил. №1)

Для решения задачи необходимо создать базу банных для ведения учета заказанных и запланированных к выпуску товаров, построить ИЛМ данной предметной области (ПО).

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

Весь массив информации можно интерпретировать как отношение и представить в виде двухмерной таблицы с поименованными графами.

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

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

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

На каждом этапе нормализации производится разбиение отношений на проекции без потерь. Выбор проекций осуществляется с учётом заданных ограничений предметной области. Переход от первичных документов к отношениям, которые должны находиться в 3НФ возможен, двумя способами. Независимо от выбранного способа, вначале необходимо выполнить следующие два действия:

1.Выявить все функциональные зависимости.

2.Определить все ключевые реквизиты.

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

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

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

Алгоритм получения набора отношений, находящихся в ЗНФ.

1. Определить все ключевые реквизиты.

2. Выявить все функциональные зависимости.

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

Таблица 1

№ плана	Месяц выпуска по плану	Наименование изделия	Ед. изм.	№ договора	Месяц поставки	Количество заказанных по договорам	Количество запланированных к выпуску	Отклонение

Этой Таблице-отношению, которая находится в 1НФ, присуще недостатки, выражающимися в излишней избыточности хранения данных и аномалиях (затруднениях) ведения БД при выполнении стандартных процедур вставки, замены, удаления.

Выберем ключевые реквизиты и определим функциональные зависимости.

За счёт разбиения основной Таблицы - отношение на проекции, избавимся от избыточности, аномалий вставки, замены, удаления.

1. Таблица - проекция. Сведения о товаре представим в таблице «Справочник товаров» (табл. 2), которая будет находиться в 1НФ, и во 2НФ и 3НФ. Так как только от КТ будет зависеть Наименование товара, Ед. изм. Товара, Цена за Ед. изм. Товара, Нормативное значение.

Таблица 2

Код товара	Наименование товара	Ед. изм. товара	Цена за Ед. изм. товара	Нормативное значение	№ Склада

2. Таблица - проекция. Сведения о планах выпуска продукции представим в таблице «План выпуска изделий» (табл.3), которая будет находиться в 1НФ, 2НФ 3НФ, так как только от № цеха и КТ будет зависеть № плана, Месяц выпуска и Количество.

Таблица 3

№ плана	№ цеха	Месяц выпуска	Код товара	Количество

3. Таблица - проекция. Сведения о договорах представим в таблице «Договора» (табл.4), которая будет находиться в 1НФ, так как только от № договора зависит Дата поставки.

Таблица 4

№ договора	Дата поставки

4. Таблица - проекция. Сведения о заказанных товарах представим в таблице «Заказы» (табл.5), которая будет находиться в 1НФ,2НФ и 3НФ, так как только от № договора и КТ зависит Количество заказанного товара.

Таблица 5

№ договора	Код товара	Количество

5. Таблица - проекция. Сведения о произведенном товаре представим в таблице «Цеховая накладная» (табл.6), которая будет находиться в 1НФ,2НФ и 3НФ, так как только от № цеховой накладной и № цеха зависит Дата выпуска товара.

Таблица 6

№ цеховой накладной	№ цеха	Дата выпуска товара

Таким образом, получили пять таблиц-отношений, другими словами Информационных объекта (ИО), которые будут нести всю информацию о документе «Анализ обеспеченности договоров планами выпуска по цеху».

2.1.1 Связи между информационными объектами.

Определить тип связи между двумя ИО можно, руководствуясь следующими правилами:

1) между ИО имеется связь типа 1:1. если внешний ключ является ключом (записи) в обоих ИО;

2) между ИО имеется связь типа 1 : М, если

- внешний ключ одного из ИО является его уникальным ключом (такой ИО находится на стороне - "один"), - внешний ключ другого ИО является частью его ключа или не является его ключом (описательный реквизит);

- такой ИО находится на стороне "много".

Каждая из введённых связей характеризуется групповым отношением экземпляров объектов типа 1 : М ("один-ко-многим") или типа М:1 ("многие - к - одному)". В приведённых ниже схемах связи между ИО под обозначением типа связи указан идентификатор реквизита, по которому осуществляется связь. Под схемой приводится обоснование связи.

1. Связь между ИО "Справочник товаров" и "План выпуска изделий цехами" 1 : М

Справочник товаров План выпуска изделий цехами

КТ

2. Связь между ИО " Справочник товаров" и " Заказы"

1 : М

Справочник товаров Заказы КТ

3. Связь между ИО "Договоры" и "Заказы"

1 : М

Договоры Заказы

№ договора

4. Связь между ИО " Справочник цехов" и " План выпуска изделий цехами"

1 : М

Справочник цехов План выпуска изделий цехами

№ цеха

2.1.2 Графическое построение схемы ИЛМ

Информационно-логическая модель должна быть представлена в каноническом виде.

Для представления ИЛМ и каноническом виде должны быть выполнены следующие правила.

1. Все связи информационных объектов в канонической ИЛМ должны быть только типа "1 : 1" и "1 : М".

2. Реквизитный состав каждого информационного объекта канонической ИЛМ должен отвечать требованиям третьей нормальной формы реляционной модели данных.

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

На рисунке представлена информационно-логическая модель (ИЛМ), отображённая в графическом виде в соответствии с выявленными связями.

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

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

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

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

2.1.3 Определение логической структуры базы данных

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

Глава 3 Основные сведения о СУБД Access

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

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

Можно производить обмен данными между компонентами СУБД Access и другими приложениями Windows. Это могут быть рисунки, диаграммы и т.д. Поддерживается экспорт и импорт данных из текстовых файлов и электронных таблиц.

При коллективном использовании СУБД Access дает возможность защитить информацию так, что разные пользователи имеют разные права по просмотру или изменению информации: при этом предусмотрены средства обеспечения целостности данных.

Каждая база данных хранится на диске в виде файла с расширением .mdb (Access 2003), .accdb (Access 2007). При запуске СУБД Access появляется меню для работы с объектами базы данных.

Объекты базы данных

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

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

Все объекты базы данных можно импортировать, т.е. копировать из других баз данных, а не вводить заново. Если таблицы были связаны в старой базе данных, то они таким же образом будут связаны и в новой.

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

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

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

Все элементы, добавляемые в форму - поля, надписи, списки, переключатели, кнопки, линии - являются элементами управления. Способ создания элемента управления зависит от того, какой элемент создается: присоединенный, свободный или вычисляемый.

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

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

арифметическими: *, +, -, /, ^;

сравнения: <, <=, >, >=, =, <>;

логическими: And (И), Not (Нет), Оr (Или);

Like - для использования логики замены в выражениях;

In - для определения, содержится ли элемент данных в списке значений;

Between...And - для выбора значений из определенного интервала.

Между условиями в разных полях одного столбца выполняется логическая операция ИЛИ (Or). Она истинна, когда истинно хотя бы одно из входящих в список условий.

Между условиями в разных полях одной строки выполняется логическая операция И (And). Она истинна, когда истинны все входящие в список условия.

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

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

Модуль - это программа на языке Access Basic.

Типы данных и форматы

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

Типы данных:

Текстовый. Простой, обычно набранный текст, который включает в себя числа, буквы и символы. Поле Текстовый может содержать до 255 символов.

Полу MEMO. Тоже простой, обычный текст, если не считать того, что вы не устанавливаете максимальную длину поля. Поэтому можете набирать текст любого размера (64000 символов).

Числовой. Простое, обычное число. Access не разрешает здесь использовать никакой текст.

Дата/Время. Дата или время.

Денежный. Число, имеющее денежный формат.

Счетчик. Access автоматически добавляет к каждой записи номер по порядку.

Логический. Ответ на вопрос: истина/ложь? В нем может находится одно из двух значений (Да или Нет, Истина или Ложь, Включить или Выключить).

Поле объекта OLE. Связь с другой базой данных или с другим файлом.

Гиперссылка. Ссылка на веб-страницы WWW (Word Wide Web).

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

Свойства поля

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

Размер поля. Максимальное количество символов, которое пользователь может ввести в данное поле.

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

Значение по умолчанию. Если в каком-то поле обычно содержится определенное значение, то вы можете ввести сюда это значение, чтобы сэкономить время. Это значение всегда будет появляться в новой записи, а в тех редких случаях, когда оно не потребуется, вы сможете ввести данные вместо него.

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

Обязательное поле. Можно выбрать Да или Нет, чтобы сообщить Access, оставить это поле пустым при вводе новой записи пользователем или заполнять. Если Да заполнять обязательно, если Нет можно не заполнять.

Назначение ключевого поля

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

Заключение

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

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

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

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

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

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

...