Проектирование БД, обеспечивающую отслеживание графика поступлений заготовок в цех

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ………………………………………………………………….…....3

1. ТЕОРИТИЧЕСКАЯ ЧАСТЬ………………………………………………...5

1.1. Концептуальная  модель…………………………………………………..5

1.2. Реляционная  модель………………………………………………………7

1.2.1. Понятие  реляционной модели данных………………………………7

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

1.2.3. Первая  нормальная форма……………………………………………9

1.2.4. Вторая  нормальная форма…………………………………………..10

1.2.5. Вторая  нормальная форма…………………………………………..10

1.2.6. Другие  нормальные формы…………………………………………11

1.3. Язык запросов SQL……………………………………………………...12

1.3.1. История возникновения и стандарты языка SQL………………….12

1.3.2. Достоинства  языка SQL……………………………………………..14

1.3.3. Общая  характеристика SQL…………………………………………15

2. ПРАКТИЧЕСКАЯ ЧАСТЬ…………………………………………………16

2.1 Модель базы данных в Access………………………………………………...16

2.2 Реляционная схема базы данных………………………………………..19

2.3 Интерфейс……………………………………………………………...…19

2.4 Создание отчета…………………………………………………………..25

ЗАКЛЮЧЕНИЕ………………………………………………………………...27

СПИСОК  ЛИТЕРАТУРЫ…………………………………………………….28

ПРИЛОЖЕНИЕ  А……………………………………………………………...29 
ВВЕДЕНИЕ

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

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

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

1. «Регистрация выполнения заказа». Данная функция должно обеспечивать учет поступлений по каждому заказу. Каждая регистрация должна сопровождаться записью в архив зарегистрированного количества по заказу, времени регистрации, места хранении на складе и табельного номера лица, выполняющего регистрацию.
2. «Сведения и выполнения заказа». В форме таблицы выводятся следующие данные: код заказа, код предмета, плановое количество, плановый срок выполнения, выполненное количество, реальный срок выполнения. Предусмотреть возможность формирования части таблицы по коду предмета и плановой дате.
3. «Просмотр архива выполнения заказов». В форме таблицы выводится архив регистрации по отдельному заказу.

 

1. ТЕОРИТИЧЕСКАЯ ЧАСТЬ

1.1. Концептуальная модель

    Концептуальная  модель — модель предметной области, состоящей из перечня взаимосвязанных понятий, используемых для описания этой области, вместе со свойствами и характеристиками, классификацией этих понятий, по типам, ситуациям, признакам в данной области и законов протекания процессов в ней. (Толковый словарь по искусственному интеллекту)

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

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

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

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

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

    Разработка  концептуальной модели как первая стадия проектирования пользовательского  интерфейса имеет ряд преимуществ:

• Разделение области задач на объекты и действия позволяет определить действия, одинаковые для нескольких объектов. Впоследствии один и тот же пользовательский интерфейс может быть использован для работы с разными объектами. Например, если в хорошо продуманном приложении пользователь может использовать объекты А и Б, и он хочет создать объект А, но умеет создавать только Б, он сумеет создать и А, поскольку это действие происходит единообразно для двух данных объектов. (Как впрочем, и копирование, перемещение, удаление, редактирование, печать и т.д.) Это в свою очередь делает пользовательский интерфейс более простым и последовательным, а значит, и более удобным в изучении и использовании.
• Даже если не брать в расчет упрощение, вызванное существованием обобщенных действий, при проектировании пользовательской модели разработчики должны признать относительную важность концептов, их значимость для области задач (в противоположность технической области), типовую иерархию и иерархию включения объектов. Все эти явления в значительной степени облегчают проектирование пользовательского интерфейса.
• Концептуальная модель представляет собой начальный этап разработки терминологии программного продукта, то есть словаря терминов, которые будут использоваться для идентификации каждого объекта и действия, реализованного в программе. Это способствует сохранению устойчивости терминологии не только в самой программе, но и в сопутствующей документации. Недостатками программы, разработанной без такой терминологии, являются: 1) использование многочисленных терминов для определения одного концепта; 2) использование одного термина для определения разных концептов.
• Наконец, разработка концептуальной модели представляет собой первоначальный вид объектной модели (по крайней мере, для объектов, необходимых пользователю), которую разработчики могут в дальнейшем использовать при реализации программного обеспечения. Это особенно актуально если разработчик пишет программу на объектно-ориентированных языках, таких как Java или С++.

1.2. Реляционная модель

    1.2.1 Понятие реляционной  модели данных

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

• Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений
• Аспект (составляющая) целостности — отношения (таблицы) отвечают определенным условиям целостности. Реляционная модель данных поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.
• Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление)

    Реляционная модель данных является приложением к задачам обработки данных таких разделов математики как теория множеств и фундаментальная логика. Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово «таблица». Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране.

    Для лучшего понимания реляционной модели данных следует отметить три важных обстоятельства:

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

    Принципы  реляционной модели были сформулированы в 1969-1970 годах Э. Ф.Коддом. Идеи Кодда были впервые подробно изложены в статье «A Relational Model of Data for Large Shared Data Banks», ставшей классической.

1.2.2. Нормализация отношений

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

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

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

    1.2.3.Первая  нормальная форма

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

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

      Функциональная зависимость. Пусть  Х и Y - два атрибута некоторого  отношения, Говорят, что Y функционально зависит от X, если в любой момент времени каждому значению Х соответствует не более чем одно значение атрибута Y. Функциональную зависимость можно обозначить так: Х>Y.

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

    1.2.4. Вторая нормальная форма

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