База данных автосервис

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

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

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

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

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

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

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

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

-         Храниться в словаре данных, а не в программных приложениях.

Эти возможности в том или ином виде реализованы в большинстве систем.

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

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

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

В 1992 г. был принят новый стандарт SQL-92. Этот язык существенно более сложен, чем SQL-89, а конструкции SQL-92 специфицированы в стандарте существенно более полно. Первой компанией, которая объявила о соответствии своего продукта новому стандарту, была компания Oracle со своей седьмой версией (это произошло прямо в 1992 г.). Теперь и все остальные компании обещают вскоре выпустить продукты, соответствующие стандарту SQL-92.

Кроме того, как это бывает всегда, производители стремятся добавить к своим продуктам качества, превышающие требования стандарта. Например, современные версии Oracle и Ingres содержат возможности определения триггеров (подробнее об этом см. ниже), в системе uniVerse компании VMark поддерживается расширенная ненормализованная реляционная модель и т.д. Другими словами, компании стремятся смотреть в будущее, предвидя требования следующего стандарта SQL (его условно называют SQL-3; ожидается принятие этого стандарта в 1995 г.).

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

Однако с появлением на рынке симметричных мультипроцессорных аппаратных архитектур, производители СУБД были вынуждены пересмотреть организацию своих серверов, допустив в них внутреннюю параллельность. Естественно, это требует очень основательного перепроектирования системы с ее существенным усложнением. Заметим, что в большинстве случаев компании пошли на это после появления в ОС UNIX механизма "легковесных" процессов (threads).

О серьезности этой работы говорит тот факт, что, например, в компании Informix было образовано новое подразделение, занимающееся исключительно вопросами распараллеливания работы серверов.

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

В большинстве случаев предлагаемые решения основываются на использовании индустриальных стандартов распределенных объектных систем (например, стандарта CORBA, разработанного OMG). Тем не менее производители СУБД вынуждены решать многочисленные проблемы для вхождения их систем в новые интегрированные среды.

2. СРЕДСТВА РЕАЛИЗАЦИИ

2.1 Обзор и обоснование методов разработки

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

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

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

Так как Microsoft Access 2003 является современным приложением Windows, можно использовать в работе все возможности DDE (динамический обмен данными) и OLE (связь и внедрение объектов). DDE позволяет осуществлять обмен данными между Access и любым другим поддерживающим DDE приложением Windows. В Microsoft Access 2003 можно при помощи макросов или Access Basic осуществлять динамический обмен данными с другими приложениями.

OLE  является более изощренным средством Windows, которое позволяет установить связь с объектами другого приложения или внедрить какие-либо объекты в базу данных Access. Такими объектами могут быть картинки, диаграммы, электронные таблицы или документы из других поддерживающих OLE приложений Windows.

В Microsoft Access 2003 для обработки данных базовых таблиц используется мощный язык SQL (структурированный язык запросов). Используя SQL  можно выделить из одной или нескольких таблиц необходимую для решения конкретной задачи информацию. Access значительно упрощает задачу обработки данных. Совсем не обязательно знать язык SQL. При любой обработке данных из нескольких таблиц Access использует однажды заданные связи между таблицами.

В Microsoft Access 2003 имеется также простое и в то же время богатое возможностями средство графического задания запроса – так называемый «запрос по образцу» (query by example), которое используется для задания данных,  необходимых для решения некоторой задачи. Используя для выделения и перемещения элементов на экране стандартные приемы работы с мышью в Windows и несколько клавиш на клавиатуре, можно буквально за секунды построить довольно сложный запрос.

Microsoft Access 2003 спроектирован таким образом, что он может быть использован как в качестве самостоятельной СУБД на отдельной рабочей станции, так и в сети – в режиме «клиент-сервер». Поскольку в Microsoft Access 2003 к данным могут иметь доступ одновременно несколько пользователей, в нем предусмотрены надежные средства защиты и обеспечения целостности данных. Можно заранее указать, какие пользователи или группы пользователей могут иметь доступ к объектам (таблицам, формам, запросам) базы данных. Microsoft Access 2003 автоматически обеспечивает защиту данных от одновременной их корректировки разными пользователями. Access также опознает и учитывает защитные средства других подсоединенных к базе данных структур (таких,  как базы данных Paradox, dBASE и SQL).

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

Microsoft Access 2003 предоставляет дополнительные средства разработки приложений, которые могут работать не только с собственными форматами данных, но и с форматами других наиболее распространенных СУБД. Возможно, наиболее сильной стороной Access является его способность обрабатывать данные электронных таблиц, текстовых файлов, файлов dBASE, Paradox, Btrieve, FoxPro и любой другой базы данных SQL, поддерживающей стандарт ODBE. Это означает, что можно использовать Access для создания такого приложения Windows, которое может обрабатывать данные, поступающие с сетевого сервера SQL или базы данных SQL на главной ЭВМ.

Все выше сказанное позволило остановить выбор на СУБД Access для  постановки и решения задачи автоматизации процесса  ведения  документации и отчетности  в учебном заведении.

2.2 Основные структурные элементы Microsoft Access 2003

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