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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


курсовая работа Проектирование БД «Комплектация персональных компьютеров»

Информация:

Тип работы: курсовая работа. Добавлен: 11.05.2012. Сдан: 2011. Страниц: 10. Уникальность по antiplagiat.ru: < 30%

Описание (план):


МФ НОУ  ВПО
«Санкт-Петербургский  Гуманитарный университет Профсоюзов» 
 
 
 
 
 
 
 
 
 

Курсовая работа 

По дисциплине: «Базы данных»
Тема: «Проектирование БД «Комплектация персональных компьютеров» 
 

Выполнил: 
 

_________________________ 

Руководитель: 
 

_________________________ 
 

Мурманск
2010 г.
 

СОДЕРЖАНИЕ 
 

 

ВВЕДЕНИЕ

      Информатизация  общества и связанное  с ней широкое  распространение  вычислительной техники  и средств коммуникации выводят в ранг наиважнейших задачу создания специальных  методов обработки  данных: их поиск, защиту, обработку и хранение.
      Большие объёмы информации практически  невозможно проработать  без специальных  средств машинной обработки. В последнее время широкое распространение получили автоматизированные информационные системы: информационно-справочные, информационно-поисковые. Все они предназначены для регистрации, хранения и обработки данных с целью поиска и выдачи ответов на запросы пользователей. В большинстве случаев автоматизированные информационные системы разрабатывают как базы данных (БД).
      Базы  данных, которые широко используются на практике, – это совокупность специальных методов и математических, информационных, программных, языковых, организационных и технических средств для поддержки динамической информационной модели предметной отрасли с целью обеспечения информационных запросов пользователей. Скорость доступа к информации, которая хранится в базах данных, удобство работы с ней зависит от организации структуры хранения данных, вида представления, возможностей поиска [7, c. 6].
      Примером  использования баз данных на практике можно назвать системы, в функции которых входит определённая обработка информации, данные в которых постоянно обновляются, в соответствии с текущими изменениями. Обновление информации может выполняться автоматически, в результате представления данных с помощью специальных автоматизированных систем. В другом случае изменения в систему вносятся администратором баз данных, или обычным оператором.
      На  современном этапе  развития науки и  техники, автоматизации  подлежат практически  все области нашей жизни. Нет области, где невозможно внедрить машинную обработку данных. Везде, где есть большой объём сгруппированной однородной информации об однородных объектах можно использовать программы, которые строятся по принципам баз данных. Такие программы могут кроме хранения данных, выполнять функции сортировки, поиска, а также необходимые расчёты.
      Актуальной  становится задача проектирования и создания систем хранения и обработки  информации с целью  сокращения рутинного, малоэффективного человеческого труда. Широкое распространение вычислительной техники в разных сферах предприятия, промышленности, экономики, увеличение специалистов в данной области даёт реальную возможность для решения данной задачи.
      Основные  идеи современной информационной технологии базируются на концепции баз данных. Согласно данной концепции основой информационной технологии являются данные, организованные в БД, адекватно отражающие реалии действительности в той или иной предметной области и обеспечивающие пользователя актуальной информацией в соответствующей предметной области. Как сущности, атрибуты и связи отображаются на структуры данных – определяется моделью данных. Традиционно все СУБД классифицируются в зависимости от модели данных, которая лежит в их основе.
      В процессе курсового проектирования необходимо разработать в среде реляционной СУБД Microsoft Access базу данных для предметной области «Комплектация персональных компьютеров», которая автоматизирует деятельность предприятия по учёту комплектов ПК и их комплектующих для них.
      В связи с актуальностью  разработки информационной системы для заданной предметной области цель работы заключается в освоении основных свойств реляционной модели данных и возможностей работы с базами данных универсальными методами. Данная цель реализуется посредством решения конкретных задач: анализ предметной области, синтез модели, выбор способов представления информации и программного инструментария, синтез компьютерной модели объекта в соответствии с требованиями задания с использованием средств СУБД Microsoft Access.
 

1. Реляционная модель данных. Свойства реляционной модели данных

 
      Работающая  информационная система (ИС) подразумевает  использование модели предметной области. В общем случае понятиями, формирующими модель, являются объекты и отношения между ними. Модель может иметь явное описание, хранимое полностью или частично в ЭВМ, и храниться (также полностью или частично) в ЭВМ сама. Хранимую в ЭВМ и используемую программно модель можно называть базой данных. Альтернативу явному хранимому описанию модели составляет её неявное и часто некорректное описание «логикой прикладной программы».
      Принципиальные  трудности описания предметной области, технические трудности реализации баз данных и исторический ход  событий привели к тому, что  в программировании понятие базы данных связано в первую очередь с хранением «данных», доступом к ним. В этом случае для базы данных нет однозначного строгого определения, и чаще всего встречается два различных её понимания. В первом речь идёт о хранилище структур данных – чаще всего связанных множеств записей – и о способе для пользователей (программы) работать с записями. Во втором – о хранении собственно модели предметной области, допускающей организацию доступного конечному пользователю способа взаимодействия с моделью.
      При проектировании ИС используется несколько моделей: две «крайних», обобщённая (понятийная) модель и модель, представленная схемой базы данных, могут дополняться рядом промежуточных. Промежуточной может быть, например, модель «сущность-связь» определённого уровня общности.
      Использование модели данных при работе с БД неизбежно  по нескольким причинам. Во-первых, модель дает общий язык пользователям, работающим с данными. Во-вторых, модель может  обеспечить предсказуемость результатов  работы с данными. Становится возможным объяснить пользователю, почему он получил конкретный результат при просмотре или изменении данных, и наоборот, работающий с базой может предвидеть, какого сорта он получит результат. За время существования разработок программных систем предложено много различных моделей разной степени распространённости [6].
      Не  будучи хронологически первой, наиболее популярной с начала 80-х гг. 20 века была и до сих пор остаётся реляционная модель данных. Она первая получила математическое описание, и она экономна по части базовых понятий. Первое повлекло возможность тщательного и интенсивного исследования свойств этой модели, а второе сделало её привлекательной для программистов и пользователей.
      Наиболее  распространённая трактовка реляционной модели данных принадлежит К. Дейту [5, с. 74]. Согласно ему реляционная модель состоит из трёх частей:
      Структурная часть. Описывает, какие объекты рассматриваются реляционной моделью. Постулируется, что единственной структурой данных, используемой в реляционной модели, являются нормализованные n-арные отношения.
      Целостная часть. Описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных базах данных. Это целостность сущностей и целостность внешних ключей.
      Манипуляционная часть. Описывает два эквивалентных способа манипулирования реляционными данными – реляционную алгебру и реляционное исчисление.
      Реляционная модель обеспечивает единственный способ представления данных в виде двумерной  таблицы, называемой отношением [4, стр. 67]. Строки в каждой таблице – это кортеж неструктурированных единиц данных, «атрибутов». Набор кортежей, составляющий таблицу, образует математическое отношение; таким образом, модель данных представляется множеством таблиц-отношений (называемых также R-таблицами); отсюда название «реляционная», т.е. модель, представленная отношениями.
      Отношение состоит из двух частей: заголовка отношения и тела отношения. Заголовок отношения – это аналог заголовка таблицы. Заголовок отношения состоит из атрибутов, количество которых называется степенью отношения. Тело отношения – это аналог тела таблицы.
      Отношение обладает следующими свойствами:
      в отношении нет одинаковых кортежей;
      кортежи не упорядочены (сверху вниз);
      атрибуты не упорядочены (слева направо);
      все значения атрибутов атомарны;
      отношение находится в Первой Нормальной Форме (1НФ), если оно содержит только скалярные (атомарные) значения;
      средством, позволяющим однозначно идентифицировать кортежи отношения, являются потенциальные ключи отношения, один из потенциальных ключей объявляется первичным ключом, остальные – альтернативными;
      отношения связываются друг с другом при помощи внешних ключей, которые не обязаны обладать свойством уникальности, поэтому, одному кортежу родительского отношения может соответствовать несколько кортежей дочернего отношения – такой тип связи между отношениями называется «один-ко-многим», а связи типа «много-ко-многим» реализуются использованием нескольких отношений типа «один-ко-многим».
      В реляционной модели данных при организации данных основными понятиями являются: домен, атрибут, кортеж, первичный ключ, отношение, схема отношения, внешний ключ, схема базы данных и база данных.
      Понятие «тип данных» адекватно понятию  типа данных в языках программирования (поддерживаются символьные, числовые и другие типы данных).
      Домен – допустимое подмножество элементов какого-либо типа данных; понятие домена имеет и семантическую нагрузку: данные считаются сравнимыми, когда они относятся и поддерживаются не во всех реляционных СУБД.
      Схема отношения – это именованное множество пар {имя атрибута, имя домена} или, если понятие домена не поддерживается, то {имя атрибута, имя типа данных}.
      Кортеж, соответствующий данной схеме отношения – это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения: «значение» является допустимым значением домена (или типа данных, если понятие домена не поддерживается) данного атрибута.
      Отношение – это множество кортежей, соответствующих одной схеме отношения. Иногда говорят «отношение-схема» и «отношение-экземпляр». Часто отношение называется таблицей, схема отношения – заголовком таблицы, кортежи – строками таблицы, атрибуты – столбцами (именами столбцов) таблицы.
      Схема БД – это набор именованных схем отношений. Поэтому реляционная БД – это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.
      Главной структурной единицей в реляционной модели данных являются не отдельные записи-кортежи, а множества кортежей – отношения.
      Отношения обладают следующими свойствами: они не содержат кортежей-дубликатов; кортежи отношений не упорядочены; атрибуты отношений не упорядочены; значения всех атрибутов атомарны (т.е. в них не присутствуют составные атрибуты), такие отношения называют представленными в первой нормальной форме (в виде плоских таблиц).
      В реляционной модели данных понятие  «группового отношение» отсутствует. Для отражения связей между отношениями и их кортежами используется дублирование ключей. Атрибуты, представляющие собой копии ключей других отношений, называются внешними ключами.
      В рамках реляционной теории имеется  список операций, которые можно осуществлять над R-таблицами, причём так, что результатом снова будет R-таблица (и, таким образом, в результате выполнения операции мы снова получим реляционную базу данных). Обычно это следующие операции:
      базовые операции:
        ограничение – исключение из таблицы некоторых строк;
        проекция – исключение из таблицы некоторых столбцов;
        декартово произведение – из двух таблиц получается третья по принципу декартова произведения двух множеств строк;
        объединение – объединение множеств строк двух таблиц;
        разность – разность множеств строк двух таблиц;
        присвоение – именованной таблице присваивается значение выражения над R-таблицами;
      производные операции:
        группа операций соединения;
        пересечение – пересечение множеств строк двух таблиц;
        деление – позволяет отвечать на вопросы типа: «какие студенты посещают все курсы?»;
        разбиение – позволяет отвечать на вопросы типа: «какие пять служащих в отделе наиболее оплачиваемы?»;
        расширение – добавление новых столбцов в таблицу;
        суммирование – в новой таблице с меньшим чем в исходной числом строк, строки получены как агрегирование (например, суммирование по какому-то столбцу) строк исходной.
      Помимо  «основных» таблиц, «изначально» присутствующих в БД, приведённые операции позволяют получать выводимые таблицы –«представления», получаемые в результате применения операций.
      Основная идея использования реляционного подхода в СУБД – это предсказуемость результатов работы с данными, обеспечиваемая математическим аппаратом в основе этого подхода. Поскольку в основе лежит корректная математическая модель, то любой запрос к базе данных, составленный на каком-нибудь «корректном» (формальном) языке повлечёт ответ, однозначно определенный схемой данных и конкретными данными.
      Кроме того реляционный подход приносит относительную  простоту работы разработчику ИС, поскольку  прикладная область часто описывается  в терминах таблиц достаточно естественно.
      Основы  реляционной модели данных были впервые изложены в статье Е. Кодда в 1970 г., в которой он опубликовал свои 12 правил соответствия произвольной СУБД реляционной модели, дополнив основные понятия реляционных баз данных определениями, важными для практики. Ниже приводятся эти правила вместе с дополняющим их подразумеваемым общим положением.
      0. Основное (подразумеваемое) правило. Система, которая рекламируется или провозглашается поставщиком как реляционная СУБД, должна управлять базами данных исключительно способами, соответствующими реляционной модели.
      1. Информационное правило. Вся информация, хранимая в реляционной базе данных, должна быть явно, на логическом уровне, представлена единственным образом: в виде значений в R-таблицах.
      2. Правило гарантированного логического  доступа. К каждому имеющемуся в реляционной базе атомарному значению должен быть гарантирован доступ с помощью указания имени R-таблицы, значения первичного ключа и имени столбца.
      3. Правило наличия значения. В полностью реляционной СУБД должны иметься специальные индикаторы (отличные от пустой символьной строки или строки из одних пробелов и отличные от нуля или какого-то другого числового значения) для выражения (на логическом уровне, систематично и независимо от типа данных) того факта, что значение отсутствует по меньшей мере по двум различным причинам: его действительно нет либо оно неприменимо к данной позиции. СУБД должна не только отражать этот факт, но и распространять на такие индикаторы свои функции манипулирования данными независимо от типа данных.
      4. Правило динамического диалогового реляционного каталога. Описание базы данных выглядит логически как обычные данные, так что авторизованные пользователи и прикладные программы могут употреблять для работы с этим описанием тот же реляционный язык, что и при работе с обычными данными.
      5. Правило полноты языка работы  с данными. Сколько бы много в СУБД ни поддерживалось языков и режимов работы с данными, должен иметься по крайней мере один язык, выразимый в виде командных строк в некотором удобном синтаксисе, который бы позволял формулировать:
      определение данных;
      определение правил целостности;
      манипулирование данными (в диалоге и из программы);
      определение выводимых таблиц (в том числе возможности их модификации);
      определение правил авторизации;
      границы транзакций.
      6. Правило модификации таблиц-представлений. В СУБД должен существовать корректный алгоритм, позволяющий автоматически для каждой таблицы-представления определять во время её создания, может ли она использоваться для вставки и удаления строк и какие из столбцов допускают модификацию, и заносящий полученную таким образом информацию в системный каталог.
      7. Правило множественности операций. Возможность оперирования базовыми или выводимыми таблицами распространяется полностью не только на выдачу информации из БД, но и на вставку, модификацию и удаление данных.
      8. Правило физической независимости. Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от каких-либо изменений во внутреннем хранении данных или в методах доступа СУБД.
      9. Правило логической независимости. Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от таких изменений в базовых таблицах, которые сохраняют информацию и теоретически допускают неизменность этих операторов и программ.
      10. Правило сохранения целостности. Диалоговые операторы и прикладные программы не должны изменяться при изменении правил целостности в БД (задаваемых языком работы с данными и хранимых в системном каталоге).
      11. Правило независимости от распределённости. Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от совершаемого физического разнесения данных (если первоначально СУБД работала с нераспределёнными данными) или перераспределения (если СУБД действительно распределённая).
      12. Правило ненарушения реляционного  языка. Если в реляционной СУБД имеется язык низкого уровня (для работы с отдельными строками), он не должен позволять нарушать или «обходить» правила, сформулированные на языке высокого уровня (множественном) и занесённые в системный каталог.
      Важность  правил Кодда в том, что, будучи сформулированы более 20 лет назад, они никем не оспаривались, не дополнялись и до сих пор являются единственными правилами такого рода. Несмотря на то, что не все они равноценны, а некоторые носят «печать времени» своего появления, эти правила в течение длительного периода задают определенную точку отсчёта для одних (разработчики) и критерий соответствия для других (разработчики и пользователи).
      Реляционная модель данных, несмотря на её достоинства (простота и наглядность табличного представления данных, непроцедурность запросов и обеспечение большей, чем в других моделях, степени независимости данных, хорошее теоретическое обоснование), совсем не идеальна. В ряде случаев она не позволяет ясно (или вовсе) отразить особенности предметной области: например, по причине отсутствия прямых средств выражения иерархии. Поэтому постоянно ведутся поиски других моделей, которые также имеют свои сильные и слабые стороны.
      В настоящее время СУБД именно реляционного типа имеют наибольшее применение. 

 

2. ПОСТАНОВКА  ЗАДАЧИ 

      Необходимо спроектировать информационную систему на основе базы данных для автоматизации учёта поставок комплектов ПК и комплектующих.
      База  данных создается для поддержки  следующих процессов:
      учёт комплектов ПК;
      учёт поставок комплектов и комплектующих;
      ведение справочников поставщиков и комплектующих.
      Необходимо  создать таблицы:
      Поставщик (ИНН, Наименование, Адрес);
      Справочник комплектующих (Номенклатурный номер, Наименование);
      Комплектующие (Номенклатурный номер, ИНН поставщика, Наличие, Цена);
      Комплект (Номер комплекта, Наименование, ИНН поставщика, Количество, Цена);
      Состав комплекта (Номер комплекта, Номенклатурный номер).
      Отчёты, запросы которые необходимо реализовать:
      сведения об указанном комплекте (состав комплекта, количество комплектов);
      сведения о наличии указанного комплектующего изделия;
      сведения об имеющихся изделиях указанного поставщика.
 

3. Анализ предметной области

 
3.1. ОБЩЕЕ ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ 

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

3.2. БИЗНЕС-ПРОЦЕССЫ 

      База  данных проектируется для поддержки следующих бизнес-процессов:
      Учёт состава комплектов ПК и их количества.
      Учёт поставленных комплектующих и комплектов ПК.
      Учёт поставщиков изделий.
 
3.3 ОПИСАНИЕ ВХОДНОЙ И ВЫХОДНОЙ ДОКУМЕНТАЦИИ 

      Входной документацией служит:
      Накладная на приход товара.
      Приходная накладная применяется для учёта поступления материальных ценностей на склад. Форма приходной накладной представлена в приложении.
      Выходной  информацией служит:
      отчёты о наличии комплектующих, по поставщикам и по наименованию;
      отчёт о составе комплекта и его наличии.
 
3.4. БИЗНЕС-ПРАВИЛА 

      Описание  бизнес-правил выполнения бизнес-процессов  для данной предметной области:
      Одно и тоже комплектующее изделие, комплект ПК может быть поставлено разными поставщиками.
      Каждое комплектующее изделие имеет свой номенклатурный номер, комплект ПК – номер комплекта.
      В одной поставке могут быть как комплектующие, так и комплекты ПК.
 
3.5. ИНФОРМАЦИОННЫЕ ПОТРЕБНОСТИ ПОЛЬЗОВАТЕЛЕЙ 

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

4. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ БАЗЫ ДАННЫХ 

      Суть  проектирования состоит в выделении  сущностей, которые подлежат хранению в БД, а также в определении  атрибутов объектов и взаимосвязей между ними. В результате анализа данных были получены следующие типы сущностей:
      Поставщик;
      Справочник комплектующих;
      Комплектующие;
      Комплект;
      Состав комплекта;
      Приходная накладная.
      Свойства  атрибутов представлены в таблице 4.1.
Таблица 4.1
Свойства  атрибутов
Тип cущности Атрибут Свойства  атрибутов
уникальность значений
допустимость NULL значений
однозначное (О) / многозначное (М)
простое (П) / составное (С) статическое (С) / динамическое (Д) условное исходное (И) / расчётное (Р)
Поставщик ИНН Да Нет О П С Нет И
Наименование Нет Нет О П С Нет И
Адрес Нет Нет О П С Нет И
Справочник  комплектующих Номенклатурный  номер Да Нет О П С Нет И
Наименование Нет Нет О П С Нет И
Комплектующие Номенклатурный  номер Нет Нет О П С Нет И
Код приходной  накладной Нет Нет О П С Нет И
Наличие Нет Нет О П Д Да И
Цена Нет Нет О П С Нет И
Количество Нет Нет О П С Нет И
Комплект Номер комплекта Да Нет О П С Нет И
Наименование Нет Нет О П С Нет И
Код приходной  накладной Нет Нет О П С Нет И
Количество Нет Нет О П С Нет И
Цена Нет Нет О П С Нет И
Состав  комплекта Номер комплекта Нет Нет О П С Нет И
Номенклатурный номер Нет Нет О П С Нет И
Приходная накладная Код Да Нет О П С Нет И
ИНН Поставщика Нет Нет О П С Нет И
Дата Нет Да О П Д Да И
 
      Концептуальная  информационная модель предметной области представлена на рисунке 4.1.
        
 
 
 
 
 
 
 
 
 
 
 
 

Рис. 4.1. Концептуальная информационная модель предметной области
 

5. Логическая модель базы данных

 
      Схема данных в среде СУБД Microsoft Access, которая соответствует, логической модели базы данных, приведена на рисунке 5.1. 


Рис. 5.1. Схема данных, построенная средствами СУБД Microsoft Access
 

6. Физическая модель базы данных

 
      Описания  таблиц БД представлены в таблицах 6.1-6.6. 

      Таблица 6.1
      Таблица БД «Поставщик»
Заголовок столбца (поля)
Идентификатор поля Ключ Тип данных
Размер
ИНН
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.