Основные сведения о базах данных. База данных

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

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

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

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

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

Как указывалось в главе 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). Модули представляют собой наборы описаний, инструкций и процедур. Существуют модули класса и стандартные модули. Модули класса связаны с конкретными формами или отчетами и обычно включают в себя процедуры, которые работают только с этими формами или отчетами. В стандартных модулях содержатся общие процедуры, не связанные ни с каким объектом. Стандартные модули, в отличие от модулей класса, перечисляются в списке Модули в области навигации.

3 Описание базы данных

Особую значимость для подсистемы составляют базы данных

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

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

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

В смешанных БД представлены как фотографические, так и документальные массивы информации.

БД имеют определенные способы построения, так называемые модели баз данных: иерархические, сетевые, реляционные и объектно-ориентированные.

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

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

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

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

Организация ООБД имеет несколько стадий:

1) концептуальная модель, когда множество объектов БД прошли описание по соответствующим правилам;

2) логическая модель, когда определены свойства объектов и указаны логические взаимосвязи между объектами;

3) физическая модель, когда определены адреса и проведено размещение объектов в памяти ЭВМ

В структуру БД АИС входят различные компоненты – агрегаты, массивы, файлы и др. Агрегат – структурированная совокупность информационных объектов, определяемая как единый тип данных.

Массив информации – это поименованная совокупность однотипных (логически однородных) элементов, упорядоченных по индексам, которые определяют положение элементов в массиве

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

Расчета премии. Рис. 3.4 – Диаграмма IDEF3. Основные элементы модели представлены в таблицах 3.4 – 3.6. Таблица 3.4. Основные элементы модели Название проекта: Проектирование ИС для расчета оплаты труда в торговле Цель проекта: реализация структурной функциональной модели ИС Технология моделирования: метод описания бизнес-процессов IDEF3 Инструментарий: программный продукт BPwin ...

Начисленные в текущем месяце – ОПВ за текущий месяц – Сумма ИПН, подлежащая удержанию. ЗАКЛЮЧЕНИЕ В данной дипломной работе, при проектировании информационной системы «Начисление заработной платы сотрудникам школы» были рассмотрены принципы проектирования концептуальной модели, логической модели и были рассмотрены основные причины, по которым данный выбор программного обеспечения Delphi был...

Рисунок 5 – Диаграмма классов 3 Описание проблем и формирование концепции информационной системы 3.1 Проблемы предметной области После проведения исследования предметной области были выявлены следующие проблемы: − с увеличением количества пациентов сети поликлиник, увеличивается количество информационных потоков, что приводит к снижению управляемости...

Информационных технологий на деятельность организации. 2. Создание логической модели ЕСВ Нашей первой задачей является создание логической модели информационной системы единой среды взаимодействия студентов для образования полноценного научно-образовательного сообщества. Основным концептуальным понятием общей модели системы мы выбрали процессы. Процессы: · учебная работа · научная...

База данных составлялась на основе реляционной системы. Реляционная модель данных основывается на математических принципах, вытекающих непосредственно из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 1960-х гг. доктором Е.Ф. Коддом, в то время работавшим в IBM, а впервые опубликованы - в 1970 г.

Техническая статья «Реляционная модель данных для больших разделяемых банков данных» доктора Е.Ф. Кодда, опубликованная в 1970 г., является родоначальницей современной теории реляционных БД. Доктор Кодд определил 13 правил реляционной модели (которые называют 12 правилами Кодда).

• 12 правил Кодда:
• 1. Реляционная СУБД должна быть способна полностью управлять базой данных через ее реляционные возможности.
• 2. Информационное правило - вся информация в реляционной БД (включая имена таблиц и столбцов) должна определяться строго как значения в таблицах.
• 3. Гарантированный доступ - любое значение в реляционной БД должно быть гарантированно доступно для использования через комбинацию имени таблицы, значения первичного ключа и имени столбца
• 4. Поддержка пустых значений (null value) - СУБД должна уметь работать с пустыми значениями (неизвестными или неиспользованными значениями), в отличие от значений по умолчанию и независимо для любых доменов.
• 5. Онлайновый реляционный каталог - описание БД и ее содержания должны быть представлены на логическом уровне как таблицы, к которым можно применять запросы, используя язык базы данных.
• 6. Исчерпывающий язык управления данными - по крайней мере, один из поддерживаемых языков должен иметь четко определенный синтаксис и быть всеобъемлющим. Он должен поддерживать описание структуры данных и манипулирование ими, правила целостности, авторизацию и транзакции.
• 7. Правило обновления представлений (views) - все представления, теоретически обновляемые, могут быть обновлены через систему.
• 8. Вставка, обновление и удаление - СУБД поддерживает не только запрос на отбор данных, но и вставку, обновление и удаление
• 9. Физическая независимость данных - на программы-приложения и специальные программы логически не влияют изменения физических методов доступа к данным и структур хранилищ данных.
• 10. Логическая независимость данных - на программы-приложения и специальные программы логически не влияют, в пределах разумного, изменения структур таблиц.
• 11. Независимость целостности - язык БД должен быть способен определять правила целостности. Они должны сохраняться в онлайновом справочнике, и не должно существовать способа их обойти.
• 12. Независимость распределения - на программы-приложения и специальные программы логически не влияет, первый раз используются данные или повторно.
• 13. Неподрывность - невозможность обойти правила целостности, определенные через язык базы данных, использованием языков низкого уровня

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

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

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

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

• 1. все данные представляются в виде упорядоченной структуры, определенной в виде строк и столбцов и называемой отношением;
• 2. все значения являются скалярами. Это означает, что для любой строки и столбца любого отношения существует одно и только одно значение;
• 3. все операции выполняются над целым отношением, и результатом их выполнения также является целое отношение. Этот принцип называется замыканием

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

• · D_id - № по порядку
• · D_name - № договора
• · Stoimost - стоимость договора
• · Obor - оборудование
• · Data_zakl - дата заключения договора
• · Srok_deistv - срок действия договора

Таблица dogovor_dop - дополнительная информация по договорам:

• · P_name - №-ра проектов
• · Zakazchik - заказчик
• · Rukovoditel - руководитель договора
• · Ispolnitel - исполнители договора

Таблица proekt:

• · P_name - № проекта
• · Stoimost - стоимость
• · Data - дата исполнения проекта

Таблица proekt_dop:

• · P_name - № проекта
• · D_name - №-ра договоров
• · Zakazchik - заказчик
• · Rukovoditel - руководитель проекта
• · Ispolnitel - исполнители проекта

Таблица obor:

• · Otdel_id - № отдела
• · Ob_name - название оборудования
• · P_name - №-ра проектов
• · Data - дата эксплуатации

Таблица otdel_dop:

• · Otdel_id - № отдела
• · Prinadlegn - принадлежность отделу
• · Ispolzovanie - пользование отделом

Таблица otdel_dop:

• · Otdel - название отдела
• · Dolznost - должность
• · Familia - фамилия
• · Name - имя
• · Otchestvo - отчество
• · God_rozden - год рождения
• · Zarplata - заработная плата

Таблица kontragenti:

• · Kg_name - название организации
• · Specifik - спецификация
• · Adres - адрес
• · Tel - телефон
• · Bank_rekv - банковские реквизиты

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

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

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

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

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

Термины база данных, таблица, запись, поле и значение указывает на иерархию от наибольшего элемента к наименьшему в базах данных 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 Диаграмма классов

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

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

Компьютеры;

Посетители;