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

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

Страницы – это специальные  объекты баз данных, реализованных в последних версиях СУБД  Microsoft Access (начиная с Access 2000). Правда, более корректно их называть страницами доступа к данным. Физически это особый объект, выполненный в коде HTML, размещаемый на Web-странице и передаваемый клиенту вместе с ней. Сам по себе этот объект не является базой данной, но содержит компоненты, через которые осуществляется связь переданной Web-страницы с базой данных, остающейся на сервере. Пользуясь этими компонентами, посетитель Web-узла может просматривать записи базы в полях страницы доступа. Таким образом, страницы доступа к данным осуществляют интерфейс между клиентом, сервером и базой данных, размещенной на сервере. Эта база данных не обязательно должна быть базой данных Microsoft Access. Страницы доступа, созданные средствами Microsoft Access, позволяют работать также с базами данных Microsoft SQL Server.[12]

Макросы и модули предназначены  как для автоматизации повторяющихся  операций при работе с СУБД, так  и для создания новых функций  путем программирования. В СУБД Microsoft Access макросы состоят из последовательности внутренних команд СУБД и являются одним из средств автоматизации работы с базой. Модули создаются средствами внешнего языка программирования, в данном случае языка Visual Basic for Applications.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Глава 2. Моделирование  баз данных

        2.1. Виды моделей данных

 

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

Модель данных — совокупность структур данных и операций их обработки.

СУБД основывается на использовании иерархической, сетевой или реляционной модели, на комбинации этих моделей или на некотором их подмножестве.[4]

Рассмотрим три основных типа моделей данных: иерархическую, сетевую и реляционную.

1. Иерархическая модель данных

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

К основным понятиям иерархической  структуры относятся: уровень, элемент (узел), связь. Узел — это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в базе данных определяется числом корневых записей.[4]

К каждой записи базы данных существует только один (иерархический) путь от корневой записи.

2. Сетевая модель данных

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

Кроме того, существенным недостатком иерархической и  сетевой моделей является то, что  структура данных задается на этапе  проектирования БД и не может быть изменена при организации доступа  к данным. [4]

3. Реляционная модель данных

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

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

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

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

Выбор объектно-реляционной  модели решил бы проблемы с реализацией связей, однако возникли бы неоправданные проблемы с созданием математического представления и выбором СУБД. Принимая во внимание всё вышесказанное, делаем выбор – реляционная модель данных.[1]

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

Реляционная модель ориентирована  на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

-каждый элемент таблицы  — один элемент данных;

-все столбцы в таблице  однородные, т.е. все элементы  в столбце имеют одинаковый  тип (числовой, символьный и т.д.) и длину;

-каждый столбец имеет  уникальное имя;

-одинаковые строки  в таблице отсутствуют;

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

Отношения представлены в виде таблиц, строки которых соответствуют  кортежам или записям, а столбцы  — атрибутам отношений, доменам, полям.

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

  Чтобы связать  две реляционные таблицы, необходимо  ключ первой таблицы ввести  в состав ключа второй таблицы  (возможно совпадение ключей); в противном случае нужно ввести в структуру первой таблицы внешний ключ — ключ второй таблицы.

 

2. Концептуальное проектирование

 

Внешнее представление (внешняя  схема) данных является совокупностью  требований к данным со стороны некоторой  конкретной функции, выполняемой пользователем. Концептуальная схема является полной совокупностью всех требований к данным, полученной из пользовательских представлений о реальном мире. Внутренняя схема – это сама база данных.[5]

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

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

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

 

3. Модель «сущность – связь»

 

Логическое проектирование заключается в определении числа  и структуры таблиц, формировании запросов к БД, определении типов  отчетных документов, разработке алгоритмов обработки информации, создании форм для ввода и редактирования данных в базе и решении ряда других задач.

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

Метод сущность-связь  называют также методом «ER-диаграмм»: во-первых, ER – аббревиатура от слов Essence (сущность) и Relation (связь), во-вторых, метод основан на использовании диаграмм, называемых соответственно диаграммами ER-экземпляров и диаграммами ER-типа.

Основными понятиями ER-модели являются сущность, связь и атрибут.

Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В  диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего  имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа. Для большей выразительности и лучшего понимания имя сущности может сопровождаться примерами конкретных объектов этого типа.[10]

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

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

Связь представляется в виде линии, связывающей две сущности или  ведущей от сущности к ней же самой. При это в месте "стыковки" связи с сущностью используются трехточечный вход в прямоугольник  сущности, если для этой сущности в  связи могут использоваться много (many) экземпляров сущности, и одноточечный вход, если в связи может участвовать только один экземпляр сущности. Обязательный конец связи изображается сплошной линией, а необязательный - прерывистой линией.[3]

Каждая связь может  иметь один из следующих типов связи:

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

Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими  экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней.

Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими  экземплярами второй сущности, и каждый экземпляр второй сущности может  быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.[11]