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

Введение

 

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

С появлением ЭВМ и  использованием их для обработки  информации появилась возможность  автоматизировать решение многих информационно - справочных и расчетных задач.

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

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

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

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

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

1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

 

1. Описание деятельности ООО «Сиберия»

 

ООО «Сиберия» предоставляет  целый комплекс услуг по оплате, проверке и последующей отправке товаров, выигранных  на аукционе eBay или приобретенных в онлайн-магазинах. Если товар пересылается через компанию, он проверяется на качество, функциональность, наличие дефектов, а также отправление снабжается товарным чеком, перечнем вложения и квитанцией с указанием правильной стоимости для бухгалтерии. По e-mail заказчику высылаются копии всех сделанных по поручению заказчика платежей (по требованию) и поддерживается связь вплоть до получения посылки заказчиком. Все действия отражаются в деталях покупки (в счете покупателя), и заказчик в любой момент сможет видеть, на какой стадии находится процесс оплаты и получения товара. Для этого специально разработана онлайн-система. В случае возникновения конфликтных ситуаций с продавцами ООО «Сиберия» защищает интересы заказчика и прилагает все усилия для разрешения конфликта в пользу заказчика.

 

ООО «Сиберия» является официально зарегистрированной в США и Европе фирмой, регистрационные данные есть в официальном справочнике бизнесов штата Нью-Йорк, США, а также в официальном справочнике бизнесов земли Райнланд-Пфальц, Германия..

 

ООО «Сиберия» имеем  огромный опыт в сфере интернет-трейдинга, компания не только обслуживаем продавцов и покупателей, но и активно торгует на аукционе EBAY с апреля 1999 года. Компания носит звание "Почетный Продавец" (Power Seller), присвоенное нам аукционом EBAY. Опираясь на опыт, ООО «Сиберия» дает своим клиентам квалифицированные консультации по выбору товара и надежности продавца.

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

Услуги, предоставляемые  ООО «Сиберия»

- покупка любого товара  в интернет-магазинах США и  Европы или на аукционе EBAY, даже  тех, которые не высылается  за пределы США и Европы. Покупки  в Европе обслуживает европейский  филиал, имеющий офисы в Германии  и Франции;

- переговоры с магазином/продавцом самостоятельно производит компания;

- произведение расчеты  с продавцом или магазином  наиболее быстрым, удобным и  надежным способом (включая PayPal, BidPay, АCH, wire transfer, кредитные карты,  мани-ордера и чеки).

- возможность рассчитываться  с компанией за купленный товар через WebMoney, Contact РусСлавБанка, ПриватБанк или банковским переводом, покупки в Европе могут быть оплачены через Western Union.

-слежение за всеми  этапами заказа (обработка, оплата, получение, проверка, отправка), включая  даты и имена ответственных за операции наших сотрудников, с помощью Интернет-системы;

- формирование одной  посылки из нескольких заказов;

- проверка товара перед  отправкой на адрес клиента;

- предложение наиболее  быстрого и недорогого способа  отправки с возможностью следить за передвижением отправления.

- защита интересов  клиента в случае конфликтной  ситуации

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2. Постановка задачи разработки базы данных

 

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2. МОДЕЛИРОВАНИЕ СТРУКТУРЫ БАЗЫ ДАННЫХ

 

1. Описание реляционной модели данных

 

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

Ядром  любой  базы  данных  является  модель  данных.  Модель   данных представляет собой множество  структур  данных,  ограничений  целостности  и операций  манипулирования  данными.  С  помощью  модели  данных  могут  быть представлены объекты предметной области и взаимосвязи между ними. Модель данных – совокупность структур данных и операций их обработки.  По способу установления связей  между  данными  СУБД  основывается  на использовании  трёх  основных  видах  моделей:  иерархической,  сетевой   или реляционной, на комбинации этих моделей или на некотором их подмножестве.

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

Доктор И.Ф. Кодд, автор  реляционной модели, разработал целый  список критериев, которым должна удовлетворять  реляционная модель. Чтобы считаться  реляционной по Кодду, система управления базами данных должна:

1. Представлять всю информацию в виде таблиц;
2. Использовать язык высокого уровня для структурирования, выполнения запросов и изменения информации в базах данных;
3. Поддерживать логическую структуру данных, независимо от их физического представления;
4. Различать в таблицах неизвестные значения (nulls), нулевые значения и пропуски в данных;
5. Поддерживать основные реляционные операции (выбор, проектирование и объединение), а также теоретико-множественные операции, такие как объединение, пересечение и дополнение;
6. Поддерживать виртуальные таблицы, обеспечивая пользователям альтернативный способ просмотра данных в таблицах;
7. Обеспечивать механизмы для поддержки целостности, авторизации, транзакций и восстановления данных.

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

В моей базе, например в  таблице «Сотрудники» объектом является фамилия сотрудника, характеристикой объекта – цена должность сотрудника. Таким образом, на пересечении строки и столбца находится значение той должности, которую занимает выбранный сотруднник. Ключевым атрибутом является код сотрудника.

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

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

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

«Нуль» не означает пустое поле или обычный математический нуль. Он отображает тот факт, что значение неизвестно, недоступно или неприменимо. Существенно, что использование нулей инициирует переход с двухзначной логики (да/нет) на трехзначную (да/нет/может быть). С точки зрения другого эксперта по реляционным системам, Дейта, нули не являются полноценным решением проблемы пропусков информации. Тем не менее они являются составной частью большинства официальных стандартов различных реляционных СУБД.

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