Базы данных и субд. Характеристика базы данных

База данных – это совокупность структурированных и взаимосвязанных данных, относящихся к определенной предметной области.

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

К основным функциям СУБД относятся следующие:

· физическое размещение в памяти данных и их описаний;

· поддержка баз данных в актуальном состоянии;

· механизмы поиска запрашиваемых данных;

· доступ к данным при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

· способы обеспечения защиты данных от некорректных обновлений и/или несанкционированного доступа.

Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры.

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

СУБД использует следующие модели и описания:

· инфологическую;

· даталогическую;

· физическую.

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

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

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

В основе каждой СУБД лежит концепция модели данных, то есть некоторой абстракции представления данных. Изначально были успешными две конкурирующие модели – иерархическая и сетевая. Иерархическая БД состоит из упорядоченного набора деревьев. Корпорация IBM разработала и внедрила язык описания данных DL/I (Data Language One), который моделировал данные в иерархической форме (представление данных в форме деревьев). Эта модель была разработана совместно с промышленными предприятиями и предназначалась для хранения и поддержки данных, которые иерархически связаны между собой, например, сметы материалов и списки деталей. Типичным представителем иерархической СУБД является СУБД IMS (Information Management System) компании IBM, первая версия которой появилась в 1968 г.

На рис.8.1 показан пример схемы иерархической БД. Тип записи ФАКУЛЬТЕТ является предком (родительской или исходной записью) для типов записей КАФЕДРЫ и ДЕКАНАТ, а записи КАФЕДРЫ и ДЕКАНАТ – потомки (дочерние или порожденные записи) для записи ФАКУЛЬТЕТ.

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

Рис. 8.1. Схема иерархической модели базы данных

В терминологии IMS вместо термина "запись" использовался термин "сегмент", а под термином "запись базы данных" понималось все дерево сегментов. В 1970 году группа CODASYL, которая разрабатывала стандарты для языка COBOL, создала модель под названием DBTG (Data Base Task Group, группа задач базы данных). Модель DBTG была готова к представлению как иерархических, так и сетевых данных. Однако эта модель была очень сложной, поэтому не имела большого успеха.

Типичным представителем систем, основанных на сетевой модели данных, является СУБД IDMS (Integrated Database Management System), разработанная компанией Cullinet Software, Inc. Сетевой подход к организации данных является расширением иерархического подхода. Как и в иерархической модели, связи ведут от родительской записи к дочерней, но на этот раз поддерживается множественное наследование. В сетевой модели допускается несколько исходных записей для одной порожденной записи наряду с возможностью наличия записей без исходной записи (рис.8.2). Другими словами, в сетевой модели любая запись может участвовать в нескольких отношениях предок-потомок. Сетевая модель – неориентированный граф.

Рис. 8.2. Схема сетевой модели базы данных

Большинство применяемых сегодня баз данных основаны на реляционной модели. Основная идея реляционной модели – представить произвольную структуру данных в виде двумерных таблиц. Наиболее распространенной в настоящее время настольной реляционной базой данных является MS Access, пример которой рассматривается в разделе 6.3.3.

Реляционная модель впервые была предложена Э.Ф. Коддом (E.F. Codd) в 1970 году. Понятие модели данных, введенное Коддом, впоследствии развил Кристофер Дейт. Согласно Дейту, реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части. Данные хранятся в таблицах. Столбцы таблиц называются полями, а строки – записями. В каждом поле может храниться информация только одного типа. Запросы предназначены для манипулирования данными, содержащимися в базе данных.

Кодд определил правила реляционной модели, которые получили название "12 правил Кодда". Позже Кодд добавил "нулевое" правило.

1. Реляционная СУБД должна быть способна полностью управлять базой данных, используя связи между данными.

2. Информационное правило: вся информация в реляционной БД, включая имена таблиц и столбцов, должна определяться строго как значения таблиц.

3. Гарантированный доступ: любое значение БД должно быть гарантированно доступным через комбинацию имени таблицы, первичный ключ и имя столбца.

4. Поддержка нулевого значения: СУБД должна уметь работать с нулевыми (пустыми) значениями. Нулевое значение – это неизвестное, независимое, неприменимое значение, в отличие от значений по умолчанию и обычных значений.

5. Активный, оперативный реляционный каталог – описание БД и ее содержимое – должны быть определены на логическом уровне через таблицы, к которым можно применять запросы, используя DML (Data Manipulation Language – язык манипулирования данными).

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

7. Правило обновления представлений: все представления, теоретически обновляемые, могут быть обновлены через систему.

8. Вставка, обновление и удаление: СУБД поддерживает не только запрос данных, но и вставку, обновление и удаление.

9. Физическая независимость данных: логика программ-приложений остается прежней при изменении физических методов доступа к данным и структур хранения.

10. Логическая независимость данных: логика программ-приложений остается прежней, в пределах разумного, при изменении структур таблиц.

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

12. Независимость распределения: перенос базы данных с одного компьютера на другой компьютер не должен оказывать влияния на запросы программ-приложений. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

13. Согласованность языков всех уровней: низкоуровневый язык доступа к данным не должен игнорировать правила безопасности и целостности, поддерживаемые языком более высокого уровня.

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

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

Реляционная алгебра и реляционное исчисление имеют одинаковую выражающую мощность; т. е. все запросы, которые можно сформулировать с помощью реляционной алгебры, могут быть также сформулированы с помощью реляционного исчисления и наоборот. Первым это доказал Э. Ф. Кодд в 1972 году. Это доказательство основано на алгоритме, по которому произвольное выражение реляционного исчисления может быть сокращено до семантически эквивалентного выражения реляционной алгебры. Алгоритм носит название "алгоритм редукции Кодда".

Реляционные базы данных имеют следующие специфические особенности.

· Для каждого поля таблицы базы данных определен тип данных, таким образом нельзя в одно поле разных записей вводить данные разных типов.

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

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

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

· Можно устанавливать связи между таблицами и затем при помощи запросов совместно использовать данные разных таблиц. Данные, полученные в результате запроса, представляются также в виде таблицы.

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

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

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

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

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

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

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

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

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

Процесс нормализации представляет собой последовательное преобразование исходной БД к нормализованной базе данных путем поэтапного приведения таблиц к нормальным формам (НФ). При этом каждая следующая НФ обязательно включает в себя предыдущую, что позволяет разбить процесс на этапы и производить его однократно, не возвращаясь к предыдущим этапам. Всего в реляционной теории насчитывается 6 нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (3НФ), нормальная форма Бойса-Кодда (НФБК), четвертая нормальная форма (4НФ) и пятая нормальная форма (5НФ).

По существу, таблица находится в 2НФ, если она находится в 1НФ и удовлетворяет, кроме того, некоторым дополнительным условиям. Таблица находится в 3НФ, если она находится в 2НФ и, помимо этого, удовлетворяет другим дополнительным условиям и т.д.

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

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

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

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

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

В настоящее время практически каждый производитель СУБД предлагает собственный программный продукт автоматизированного проектирования. Это Oracle Designer (Oracle), Power Desinger (Sybase) и другие. Демонстрационные версии данных программных продуктов можно загрузить с соответствующих сайтов (www.oracle.com, www.sybase.com). Кроме того, для автоматизированного проектирования представлены решения фирм, не производящих СУБД. Наиболее распространенными являются программные продукты фирмы AllFusion – AllFusion ERwin Data Modeler и AllFusion Process Modeler (ранее – BPwin) (см. www.interface.ru).

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

Выделяют следующие разновидности языков реляционной алгебры:

· dBASe-подобные языки приближены к языкам структурного программирования. Эти языки обеспечивают создание интерфейса пользователя и типовые операции обработки данных;

· графические реляционные языки, ориентированные на конечных пользователей;

· SQL-подобные языки запросов, реализованные в большинстве многопользовательских и распределенных систем управления базами данных.

dBASe-подобные языки используют базы данных dBASe, Paradox, FoxPro, Clipper, Rbase и др.

Типичным представителем графического реляционного языка является язык QBE (Query By Example), реализованный в среде электронных таблиц, в различных базах данных, например, в MS Access, в пакете Microsoft Query. Этот язык относится к языкам манипулирования данными и имеет простейшие синтаксические конструкции, легко осваиваемые пользователями-непрограммистами.

SQL (Structured Query Language) применяется при работе с реляционными базами данных в современных СУБД (ORACLE, dBASE IY, dBASE Y, Paradox, Access и др.). Для отдельных СУБД синтаксис версий языка SQL может различаться.

Язык SQL стал стандартом языков запросов для работы с реляционными базами данных архитектуры "файл-сервер" и "клиент-сервер" и для управления распределенными базами данных. Это реляционно полный язык, предназначенный для работы с базами данных, создания запросов на выборку данных, для выполнения вычислений, для обеспечения целостности баз данных.

Построение реляционных баз данных

Основы построения реляционных баз данных

Описание реляционных данных

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

Обзор терминологии

Как указывалось в главе 5, отношение - это таблица, обладающая определенны­ми свойствами.

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

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

3. В отношении не может быть двух одинаковых строк, и порядок следова­ния строк несуществен (рис. 8.1). Строки отношения называются также кортежами.

Рисунок 8.1 являет собой пример, или отдельный экземпляр, реляционной структуры, содержащей сведения о пациенте клиники. Обобщенный формат, PATIENT (Name , Birth Date , Gender , AccountNumber , Physician ) - это структура отноше­ния; именно ее большинство людей имеют в виду под термином отношение. (Вспомните из главы 5, что подчеркиванием выделяется атрибут, являющийся ключом отношения.) Если мы добавим в структуру отношения ограничение на возможные значения данных, мы получим реляционную схему (relational schema). Все эти термины приведены в табл. 8.1.

Недоразумения относительно термина «ключ»

Термин ключ зачастую является источником недоразумений, так как он имеет различные значения на стадиях проектирования и реализации. В процессе про­ектирования под ключом понимается один или несколько столбцов, однозначно определяющих строку отношения. Как мы знаем из главы 5, каждое отношение имеет хотя бы один ключ, поскольку каждая строка является уникальной; в пре­дельном случае ключ представляет собой комбинацию всех столбцов отношения. Обычно ключ состоит из одного-двух столбцов.

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

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

Иногда, чтобы различать два значения слова ключ, употребляются термины логический ключ (logical key) и физический ключ (physical key). Логический ключ - это уникальный идентификатор, а физический ключ - это столбец, для которого с целью увеличения быстродействия создан индекс или другая структура данных.

Индексы

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

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

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

Реализация реляционной базы данных

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

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

Описание структуры базы данных для СУБД

Есть несколько способов, с помощью которых структура базы данных описывает­ся для СУБД. Эти способы зависят от того, какая конкретно СУБД используется. 13 некоторых продуктах создается текстовый файл, который описывает структуру базы данных. Язык, используемый для определения такой структуры, иногда на­зывается языком определения данных (data definition language, DDL). В текстовом DDL-файле перечислены названия таблиц базы данных, указаны названия столб­цов этих таблиц и описано их содержимое, определены индексы, а также описаны другие структуры (ограничения, меры безопасности). В листинге 8.1 с помощью типичного языка определения данных описана простая реляционная база данных для гипотетической СУБД. Более реалистичные примеры с использованием стандарта под названием SQL приведены в главах 12 и 13.

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

Вообще говоря, графические средства описания данных распространены в СУБД, предназначенных для работы на персональных компьютерах. На серве­рах и больших ЭВМ применяются как графические, так и текстовые средства. Например, в Oracle и SQL Server для определения данных могут применяться оба способа. На рис. 8 .2 представлена общая схема процесса описания данных для СУБД.

При любом способе определения структуры данных разработчик должен дать название каждой таблице, определить столбцы для этой таблицы и описать фи­зический формат данных в каждом столбце (скажем, TEXT 10). Кроме того, в зави­симости от возможностей используемой СУБД, разработчик может указать ог­раничения, которые должны реализовываться СУБД. Значения столбцов могут определяться, например, как NOT NULL (не пустой) или UNIQUE (уникальный). Не­которые продукты позволяют также устанавливать ограничения на возможные значения (атрибут Часть может принимать значения, меньшие 10 000, а атрибут Цвет может принимать одно из значений ["Красный"/Зеленый"/Синий"]). Наконец, могут быть введены ограничения целостности по внешнему ключу. Приведем при­мер такого ограничения: «Значение атрибута НомерОтдела в таблице СОТРУДНИК должно быть равно значению атрибута НомерОтдела в таблице ОТДЕЛ».

Во многих СУБД разработчик может также устанавливать пароли и исполь­зовать другие средства контроля и безопасности. Как будет показано в главе 11, существует множество различных стратегий обеспечения безопасности. В одних стратегиях объектами контроля являются структуры данных (например, таблица защищается паролем), в других - пользователи (обладатель пароля X может чи­тать и обновлять таблицы Т1 и Т2).

Распределение пространства на физических носителях

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

Другие СУБД, в особенности предназначенные для серверов и больших ЭВМ, требуют больших усилий. Чтобы повысить быстродействие и улучшить контроль, необходимо тщательно спроектировать распределение информации в базе дан­ных по дискам и каналам. Например, в зависимости от специфики обработки приложений, может оказаться, что определенные таблицы лучше размещать на одном и том же диске. И наоборот, может быть важно, чтобы определенные таб­лицы не находились на одном и том же диске.

Рассмотрим, например, объект-заказ, скомпонованный из таблиц ЗАКАЗ, СТР0КА_ ЗАКАЗА и ТОВАР. Предположим, что при обработке заказа приложение считывает одну строку из таблицы ЗАКАЗ, несколько строк из таблицы СТР0КА_ЗАКАЗА и по одной строке из таблицы ТОВАР для каждой строки из таблицы СТР0КА_ЗАКАЗА. Далее, строки из таблицы СТР0КА_ЗАКАЗА, относящиеся к одному и тому же за­казу, обычно сгруппированы вместе, а строки в таблице ТОВАР не сгруппированы никак. Эту ситуацию иллюстрирует рис. 8.3.

Теперь представим, что организация параллельно обрабатывает множество за­казов и что у нее есть два диска: один большого объема и быстродействующий, а другой - меньшего объема и более медленный. Разработчик должен опреде­лить наилучшее место для хранения данных. Возможно, производительность улучшится, если таблица ТОВАР будет храниться на большом диске с быстрым доступом, а таблицы СТРОКА_ЗАКАЗА и ЗАКАЗ - на диске меньшего размера и бы­стродействия. А может быть, производительность будет выше, если поместить данные из таблиц ЗАКАЗ и СТРОКА_ЗАКАЗА за предыдущие месяцы на более мед­ленный диск, а за текущий месяц - на более быстрый.

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

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

При создании базы данных разработчику понадобится выделить файловое пространство для журналов базы данных. О ведении журналов вы узнаете в гла­вах 11-13; на данном этапе вам просто следует знать, что СУБД ведет журнал изменений в базе данных, который потом, в случае необходимости, можно ис­пользовать для восстановления базы. Файловое пространство для журналов вы­деляется на этапе создания базы данных.

Составление плана обслуживания базы данных

План обслуживания (maintenance plan) базы данных - это расписание процедур, которые необходимо выполнять на регулярной основе. Эти процедуры включают в себя резервное копирование базы данных, сброс содержимого журнала базы данных в архивные файлы, проверка на наличие нарушений ссылочной целост­ности, оптимизация дискового пространства для данных пользователя и индексов и т. д. К этим вопросам мы также обратимся в главе 11, но имейте в виду, что план обслуживания базы данных должен составляться в процессе ее создания или вскоре после него.

Заполнение базы данных информацией

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

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

Манипулирование реляционными данными

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

На сегодняшний день предложено четыре стратегии манипулирования реляци­онными данными. Первая из стратегий, реляционная алгебра (relational algebra), определяет операторы, действующие на отношения (они подобны операторам высшей алгебры +, - и т. д.). Эти операторы позволяют манипулировать отноше­ниями для достижения желаемого результата. Но реляционная алгебра трудна в использовании, отчасти потому, что она является процедурной. Это значит, что при использовании реляционной алгебры мы должны знать не только то, что мы делаем, но и то, как это делается.

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

Реляционное исчисление (relational calculus) - вторая стратегия манипулиро­вания реляционными данными. Реляционное исчисление не является процедур­ным; оно представляет собой язык, выражающий то, что мы хотим сделать, без указания на то, как этого достичь. Вспомните переменную интегрирования в ин­тегральном исчислении: эта переменная принимает значения из того диапазона, по которому происходит интегрирование. В реляционном исчислении есть по­добная переменная. В кортежио-реляционном исчислении областью значений этой переменной являются кортежи отношения, а в доменно-реляционном ис­числении - значения домена. В основе реляционного исчисления лежит область математики, называемая исчислением предикатов.

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

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

Языки, ориентированные на преобразования (transform-oriented languages), - это класс непроцедурных языков, которые преобразуют входные данные, имею­щие вид отношений, в результат, представляющий собой одно отношение. В этих языках имеются простые в использовании структуры, позволяющие указать дей­ствия, которые необходимо совершить с предоставленными данными. SQUARE, SEQUEL и SQL - это примеры языков, ориентированных на преобразования. Язык SQL будет подробно изучаться нами в главах 9, 12 и 13.

Четвертая категория языков манипулирования реляционными данными - это графические языки. К этой категории относятся запрос по образцу (Query-by-Example) и запрос из формы (Query-by-Form). В числе продуктов, поддерживаю­щих эту категорию, можно упомянуть Approach (фирмы Lotus) и Access. Поль­зователю выдается графическое представление одного отношения или более. Представление может иметь вид формы для ввода данных, электронной таблицы или какой-либо другой структуры. СУБД преобразует представление в соответ­ствующее отношение и формирует запросы (скорее всего, на SQL) от лица поль­зователя. После этого пользователи инициируют выполнение операторов DML, по они об этом не знают. Четыре категории языков манипулирования реляцион­ными данными:

реляционная алгебра;

реляционное исчисление;

языки, ориентированные на преобразования (например, SQL);

запрос по образцу, запрос из формы.

Интерфейсы языков манипулирования данными

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

Манипулирование данными посредством форм

В большинстве реляционных СУБД имеются средства для создания форм. Неко­торые формы генерируются автоматически при определении таблицы, другие должны создаваться разработчиком. Помощь в этом процессе может оказать ин­теллектуальный ассистент, присутствующий, например, в Access. Форма может иметь вид таблицы (электронной таблицы), в которой одновременно показыва­ются несколько строк отношения. Есть и другой вид форм, где каждая строка от­ношения представляется отдельно. На рис. 8.4 и 8.5 приведены примеры обоих типов форм для таблицы PATIENT с рис. 8.1. Большинство продуктов обеспечивают некоторую гибкость в обработке форм и отчетов. Например, строки для обработки могут выбираться по значениям столбцов и могут быть отсортированы. Таблица па рис. 8.4 отсортирована по значению поля AccountNumber.

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

Интерфейс языка запросов и обновлений

Второй тип интерфейса к базе данных - это язык запросов и обновлений (query/ update language), или просто язык запросов (query language). (Хотя большинство такого рода языков позволяют выполнять как запрос, так и обновление данных, их чаще всего называют языками запросов.) В этом случае пользователь вводит команды, которые указывают, какие действия необходимо произвести над базой данных. СУБД расшифровывает эти команды и выполняет предписанные дейст­вия. Рисунок 8.6 показывает, какие программы участвуют в обработке запроса.

Важнейшим из всех языков запросов является SQL. Чтобы дать вам пред­ставление о языках запросов, рассмотрим следующий SQL-оператор, который обрабатывает отношение PATIENT , показанное на рис. 8.1:

SELECT Name. DateOfBirth FROM PATIENT

WHERE Physician = "Levy"

Этот оператор извлекает из отношения PATIENT все строки, в которых атрибут Physician имеет значение " Levy ". Значения атрибутов Name и DateOf Birth из этих строк он затем помещает во вторую таблицу.

Хранимые процедуры

Со временем пользователи и разработчики баз данных обнаружили, что некото­рые последовательности команд SQL приходится выполнять регулярно. Единст­венное, что при этом меняется, - это значения, указываемые в предложении WHERE . Например, при ежемесячном начислении платежей выполняются одни и те же SQL-операторы, но с различной датой закрытия. Чтобы учесть эту потреб­ность, производители СУБД ввели так называемые хранимые процедуры (stored procedures). Такая процедура представляет собой набор SQL-операторов, кото­рый хранится в файле и может быть запущен на выполнение одной командой. Параметры, указываемые в предложении WHERE и т. д., могут передаваться при вызове процедуры. Примером может служить следующее:

DO BILLING STORED_PROCEDURE FOR BILLDATE = "9/1/2000"

Эта строка запускает хранимую процедуру под названием BILLING со значени­ем параметра BILLDATE , равным "9/1/2000".

По мере накопления разработчиками опыта выявилась одна проблема. SQL создавался как подъязык данных, и при этом не делалось попыток наделить его всеми элементами полноценного языка программирования. Однако некоторые из этих элементов были необходимы для написания хранимых процедур, и про­изводители СУБД создали расширенные версии SQL, включив в них допол­нительные возможности. Один такой язык, PL/SQL, был разработан для Oracle, а еще один, под названием TRANSACT-SQL, - для SQL Server. Более подробно об этих языках вы узнаете из глав 12 и 13.

Специальный тип хранимой процедуры - триггер (trigger) - вызывается СУБД при выполнении заданного условия. Например, в приложении, обрабаты­вающем заказы, разработчик должен создать триггер, который запускается в тех случаях, когда количество товара на складе оказывается ниже заданного предела (то есть пора заказывать товар у оптового поставщика). Более подробно о храни­мых процедурах вы узнаете из глав 12 и 13.

Интерфейс прикладных программ

Четвертый тип интерфейса доступа к данным - это доступ через прикладные программы, написанные на таких языках программирования, как COBOL, BASIC, Perl, Pascal и С++. Кроме того, некоторые прикладные программы пишутся на встроенных в используемые СУБД языках. Из таких языков программирования наибольшей известностью пользуется dBASE.

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

В некоторых случаях вместо вызовов функций используется объектно-ориен­тированный синтаксис. В приведенном ниже коде Access объектный указатель db устанавливается на открытую в данный момент базу данных, а объектный указа­тель rs ссылается на строки таблицы PATIENT ;

set db = currentdbC)

set rs = db.OpenRecordsetCPATIENT")

С помощью последнего указателя можно обращаться к свойствам откры­ того набора записей и запускать его методы. Например, с помощью свойства rs . AllowDeletions можно определить, могут ли быть удалены записи из набора за­писей PATIENT . Метод MoveFirst перемещает курсор на первую строку.

Второй, более старый тип интерфейса используется иногда в СУБД, предна­значенных для больших ЭВМ и серверов. Здесь производителем СУБД опреде­лен набор высокоуровневых команд доступа к данным. Эти команды, которые относятся к обработке базы данных и не являются частью какого-либо стандарт­ного языка, встраиваются в код прикладной программы.

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

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

В этой статье:

Что представляет собой база данных?

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

Компьютерная база данных - это хранилище объектов. В одной базе данных может быть больше одной таблицы. Например, система отслеживания складских запасов, в которой используются три таблицы, - это не три базы данных, а одна. В базе данных Access (если ее специально не настраивали для работы с данными или кодом, принадлежащими другому источнику) все таблицы хранятся в одном файле вместе с другими объектами, такими как формы, отчеты, макросы и модули. Для файлов баз данных, созданных в формате Access 2007 (который также используется в Access 2016, Access 2013 и Access 2010), используется расширение ACCDB, а для баз данных, созданных в более ранних версиях Access, - MDB. С помощью Access 2016, Access 2013, Access 2010 и Access 2007 можно создавать файлы в форматах более ранних версий приложения (например, Access 2000 и Access 2002–2003).

Использование Access позволяет:

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

изменять информацию, уже находящуюся в базе, например перемещать артикул;

удалять информацию, например если артикул был продан или утилизирован;

упорядочивать и просматривать данные различными способами;

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

Элементы базы данных Access

Ниже приведены краткие описания элементов стандартной базы данных Access.

Таблицы

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

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

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

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

Дополнительные сведения о таблицах см. в статье Общие сведения о таблицах .

Формы

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

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

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

Дополнительные сведения о формах см. в статье Формы .

Отчеты

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

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

Запросы

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

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

Есть два основных вида запросов: запросы на выборку и на изменение. Запрос на выборку только находит данные и предоставляет к ним доступ. Результаты такого запроса можно просмотреть на экране, распечатать или скопировать в буфер обмена, а также использовать в качестве источника записей для формы или отчета.

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

Дополнительные сведения о запросах см. в статье Знакомство с запросами .

Макросы

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

Дополнительные сведения о макросах см. в статье Общие сведения о программировании в Access .

Модули

Подобно макросам, модули - это объекты, с помощью которых базу данных можно сделать более функциональной. Но если макросы в Access составляются путем выбора из списка макрокоманд, модули создаются на языке Visual Basic для приложений (VBA). Модули представляют собой наборы описаний, инструкций и процедур. Существуют модули класса и стандартные модули. Модули класса связаны с конкретными формами или отчетами и обычно включают в себя процедуры, которые работают только с этими формами или отчетами. В стандартных модулях содержатся общие процедуры, не связанные ни с каким объектом. Стандартные модули, в отличие от модулей класса, перечисляются в списке Модули в области навигации.

Инфологическая модель

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

· наглядность;

· модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;

Основные элементы ER-моделей:

· объекты (сущности);

· атрибуты объектов;

· связи между объектами.

Сущность - объект предметной области, имеющий атрибуты.

Связь между сущностями характеризуется:

· типом связи (1:1, 1:N, N:М);

· классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности - обязательный, иначе - необязательный.

В данном дипломном проекте ER-модель реализована в системе автоматизированного проектирования баз данных ERWin, и изображена на рисунке №2.3.

Рисунок №2.3. Инфологическая модель

Даталогическая модель

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

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

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

Рисунок №2.3. Даталогическая модель.

Программное обеспечение задачи (комплекса задач)

Общие положения (дерево функций и сценарий диалога)

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

Схема сценариев диалога представляет собой пути диалога пользователя программы с самим программным продуктом. В данной схеме отображается то, как пользователь может дойти до определённого документа или вызвать требуемую функцию. Схема сценариев диалога изображена на рисунке № 2.5.

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

Запись – полный набор данных об определенном объекте. В режиме таблицы запись изображается как строка.

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

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

Структура базы данных – это набор полей, которые определяют содержание и вид БД. Она определяет методы занесения данных и хранения их в базе.

Термины база данных, таблица, запись, поле и значение указывает на иерархию от наибольшего элемента к наименьшему в базах данных Access.

Если в базе данных нет никаких данных, то это все равно полноценная база данных. Хотя данных в базе и нет, но информация в ней все-таки есть – это структура базы

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

Первым этапом при создании таблицы является определение перечня полей, из которых она должна состоять, их типов и размеров.

Каждому полю таблицы присваивается уникальное имя, которое не может содержать более 64 символов, не разрешается использовать символы: “.”, “!”, “[”, “]”.

Тип поля указывает Access, как обрабатывать эти данные. Можно использовать следующие типы:

Текстовый – для текстовой информации и чисел при невыполнении математических расчетов (до 255 символов).

Поле МЕМО – для хранения произвольного текста, комментариев.

Числовой – при выполнении над данными математических операций.

Денежный – специальное числовое поле используется для операций с деньгами.

Дата/Время – предназначено для хранения информации о дате и времени.

Счетчик – специальное числовое поле, в котором Access автоматически присваивает уникальный порядковый номер каждой записи.

Логический – может иметь только одно из двух возможных значений “Да” или “Нет”.

Поле объекта OLE – объект, созданный другим приложением.

Базы данных, имеющие связанные таблицы по совпадающим значениям полей, называются реляционными. Большинство современных БД для персональных ЭВМ являются реляционными.

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

Прежде, чем начать непосредственную работу по разработке базы данных, остановимся на характеристиках некоторых основных объектов базы данных.

Исходное окно Access отличается простотой и лаконичностью. Шесть вкладок этого окна представляют шесть видов объектов, с которыми работает программа.

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

Форма – объект Microsoft Access, предназначенный, в основном, для ввода данных. В форме можно разместить элементы управления, применяемые для ввода, изображения и изменения данных в полях таблиц.

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

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

Макросы – это макрокоманды (простые команды), предназначенные для автоматизации выполнения каких-то операций с базой без программирования.

Модули – это программные процедуры, написанные на языку VBasic.

Открытие базы данных делает ее объекты доступными для Access. С помощью вкладок можно выбрать тип нужного объекта.

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

Любая таблица Microsoft Access может быть представлена в двух режимах:

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

2) режиме таблицы, предназначенном для ввода данных, их просмотра и редактирования.

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

При любом из указанных способов ввода и корректировки, данных таблицы Access сохраняет введенную или исправленную запись на диске (том, на котором создана таблица БД).

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

Вдоль верхнего края окна расположены имена полей таблицы. Каждое поле соответствует определенному столбцу в таблице. Каждая запись занимает одну строку таблицы. Ввод в определенную ячейку таблицы (выделенную курсором) осуществляется путем набора информации на клавиатуре и последующим нажатием клавиши Enter или Tab. При окончании ввода данных в последнее поле записи Access сам переходит на первое поле новой записи и ожидает ввода данных.

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

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

Администратор проводит записи на предоставление услуг и берёт оплату.

База данных предназначена для хранения данных о посетителях, компьютерах и услугах.

Спроектируем БД (рис. 3.1.1)

Рисунок 3.1.1 Диаграмма классов

Создадим базу данных с такими таблицами:

Администраторы;

Компьютеры;

Посетители;