Проектирование информационной базы данных

Содержание

Введение…………………………………………………………………………3

Глава 1…………………………………………………………………………….5

1. Этапы проектирования базы данных……………………………………...5

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

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

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

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

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

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

Глава 2…………………………………………………………………………....16

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

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

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

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

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

Заключение……………………………………………………………………..29

Приложение №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