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

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

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

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

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

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

Примером простого иерархического представления может служить административная структура высшего учебного заведения: институт – отделение – факультет – студенческая группа (см. рис. 2.2).

Рис. 2.2. Пример иерархической структуры

К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения операций над данными.

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

На иерархической модели данных основано сравнительно ограниченное количество СУБД, в числе которых можно назвать зарубежные системы IMS , PC / Focus , Team - Up и Data Edge , а также отечественные системы Ока, ИНЭС и МИРИС.

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

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

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

Недостатком сетевой модели данных являются высокая сложность и жесткость схемы БД, построенной на ее основе.

Наиболее известными сетевыми СУБД являются IDMS , db _ VistaIII , СЕТЬ, СЕТОР и КОМПАС.

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

Реляционная модель данных была предложена Е.Ф. Коддом, известным исследователем в области баз данных, в 1969 году, когда он был сотрудником фирмы IBM. Впервые основные концепции этой модели были опубликованы в 1970.

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

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

Данные в таблицах удовлетворяют следующим принципам:

1. Каждое значение, содержащееся на пересечении строки и столбца, должно быть атомарным.

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

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

4. Каждое поле имеет уникальное имя.

5. Последовательность полей в таблице несущественна.

6. Последовательность записей в таблице несущественна.

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

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

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

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

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

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

 

Рис. 2.5. Схема реляционной модели данных

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

Примерами зарубежных реляционных СУБД для ПЭВМ являются: DB 2, Paradox , FoxPro , Access , Clarion , Ingres , Oracle .

К отечественным СУБД реляционного типа относятся системы ПАЛЬМА и HyTech .

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

1.Инфологическое проектирование

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

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

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

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

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

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

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

правил именования и обозначения сущностей ПО, атрибутов и связей;

содержания и формата создаваемых ими документов.

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

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

4. В Microsoft Access прежде чем создавать таблицы, формы и другие объекты необходимо за-дать структуру базы данных. Хорошая структура базы данных является основой для создания эффективной и отвечающей требованиям базы данных. Этапы проектирования базы данных: 1. Определение цели создания базы данных. 2. Определение таблиц, которые должна содержать база данных. 3. Определение необходимых в таблице полей. 4. Задание первичного ключа для каждой таблицы. 5. Определение связей между таблицами. 6. Обновление структуры базы данных. 7. Добавление данных и создание других объектов базы данных. 1. Определение цели создания базы данных На первом этапе проектирования базы данных необходимо определить цель создания базы данных, основные ее функции и информацию, которую она должна содержать. То есть нуж-но определить основные темы таблиц базы данных и информацию, которую будут содержать поля таблиц. База данных должна отвечать требованиям тех, кто будет непосредственно с ней работать. Для этого нужно определить темы, которые должна покрывать база данных, отчеты, которые она должна выдавать, проанализировать формы, которые в настоящий момент используются для записи данных, сравнить создаваемую базу данных с хорошо спроектированной, подоб-ной ей базой. 2. Определение таблиц, которые должна содержать база данных Одним из наиболее сложных этапов в процессе проектирования базы данных является разра-ботка таблиц, так как результаты, которые должна выдавать база данных (отчеты, выходные формы и др.) не всегда дают полное представление о структуре таблицы. При проектировании таблиц вовсе не обязательно использовать Microsoft Access. Сначала лучше разработать структуру на бумаге. При проектировке таблиц рекомендуется руково-дствоваться следующими основными принципами: - Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами. Когда определенная информация храниться только в одной таблице, то и изменять ее при-дется только в одном месте. Это делает работу более эффективной, а также исключает воз-можность несовпадения информации в разных таблицах.  - Каждая таблица должна содержать информацию только на одну тему. Сведения на каждую тему обрабатываются намного легче, если содержатся они в независи-мых друг от друга таблицах. Например, адреса и заказы клиентов хранятся в разных табли-цах для того, чтобы при удалении заказа информация о клиенте осталась в базе данных. 3. Определение необходимых в таблице полей Каждая таблица содержит информацию на отдельную тему, а каждое поле в таблице содер-жит отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить: - Каждое поле должно быть связано с темой таблицы. - Не рекомендуется включать в таблицу данные, являющиеся результатом выражения. - В таблице должна присутствовать вся необходимая информация. - Информацию следует разбивать на наименьшие логические единицы (Например, поля «Имя» и «Фамилия», а не общее поле «ФИО»). 4. Задание первичного ключа для каждой таблицы С тем чтобы Microsoft Access мог связать данные из разных таблиц, например, данные о кли-енте и его заказы, каждая таблица должна содержать поле или набор полей, которые будут однозначно идентифицировать каждую запись в таблице. Такое поле или набор полей назы-вают первичным ключом. 5. Определение связей между таблицами После распределения данных по таблицам и определения ключевых полей необходимо определить связи между таблицами. Для этого надо служит кнопка Схема данных. Связи нужны для того, чтобы обеспечить синхронное изменение одноименных полей в разных таблицах. Самый распространенный вид связи - «один-ко-многим». 6. Обновление структуры базы данных После проектирования таблиц, полей и связей необходимо еще раз просмотреть структуру базы данных и выявить возможные недочеты. Желательно это сделать на данном этапе, пока таблицы не заполнены данными. Для проверки необходимо ввести несколько записей в каждую таблицу и посмотреть, отве-чает ли база данных поставленным требованиям. Рекомендуется также создать черновые вы-ходные формы и отчеты и проверить, выдают ли они требуемую информацию. Кроме того необходимо исключить из таблиц все возможные повторения данных. 7. Добавление данных и создание других объектов базы данных Если структуры таблиц отвечают поставленным требованиям, то можно вводить все данные. Затем можно создавать любые запросы, формы, отчеты, макросы и модули.

5. 1. Страховая компания Описание предметной области Вы работаете в страховой компании. Вашей задачей является от слеживание ее финансовой деятельности. Компания имеет различные филиалы по всей стране. Каждый филиал характеризуется названием, адресом и телефоном. Деятельность компании организована следующим образом: к вам обращаются различные лица с целью заключения договора о страховании. В зависимости от принимаемых на страхование объектов и страхуемых рисков договор заключается по определенному виду страхования (например, страхование автотранспорта от угона, страхование домашнего имущества, добровольное медицинское страхование). При заключении договора вы фиксируете дату заключения, страховую сумму, вид страхования, тарифную ставку и филиал, в котором заключался договор. Таблицы Договоры (Номер договора, Дата заключения, Страховая сумма, Тарифная ставка, Код филиала, Код вида страхования). Вид страхования (Код вида страхования, Наименование). Филиал (Код филиала, Наименование филиала, Адрес, Телефон). Развитие постановки задачи Нужно учесть, что договоры заключают страховые агенты. Помимо информации об агентах (фамилия, имя, отчество, адрес, телефон), нужно еще хранить филиал, в котором работают агенты. Кроме того, исходя из базы данных, нужно иметь возможность рассчитывать заработную плату агентам. Заработная плата составляет некоторый процент от страхового платежа (страховой платеж – это страховая сумма, умноженная на тарифную ставку). Процент зависит от вида страхования, по которому заключен договор. Внести в структуру таблиц изменения, учитывающие эти факты, и изменить существующие запросы. Добавить новые запросы. 2. Гостиница Описание предметной области Вы работаете в гостинице. Вашей задачей является отслеживание финансовой стороны ее работы. Ваша деятельность организована следующим образом: гостиница предоставляет номера клиентам на определенный срок. Каждый номер характеризуется вместимостью, комфортностью (люкс, полулюкс, обычный) и ценой. Вашими клиентами являются различные лица, о которых вы собираете определенную информацию (фамилия, имя, отчество и некоторый комментарий). Сдача номера клиенту производится при наличии свободных мест в номерах, подходящих клиенту по указанным выше параметрам. При поселении фиксируется дата поселения. При выезде из гостиницы для каждого места запоминается дата освобождения. Таблицы Клиенты (Код клиента, Фамилия, Имя, Отчество, Паспортные данные, Комментарий). Номера (Код номера, Номер, Количество человек, Комфортность, Цена). Поселение (Код поселения, Код клиента, Код номера, Дата поселения, Дата освобождения, Примечание). Развитие постановки задачи Необходимо не только хранить информацию по факту сдачи номера клиенту, но и осуществлять бронирование номеров. Кроме того, для постоянных клиентов, а также для определенных категорий клиентов предусмотрена система скидок. Скидки могут суммироваться. Внести в структуру таблиц изменения, учитывающие этот факт, и изменить существующие запросы. Добавить новые запросы. 3. Ломбард Описание предметной области Вы работаете в ломбарде. Вашей задачей является отслеживание финансовой стороны его работы. Деятельность компании организована следующим образом: к вам обращаются различные лица с целью получения денежных средств под залог определенных товаров. У каждого из приходящих к вам клиентов вы запрашиваете фамилию, имя, отчество и другие паспортные данные. После оценивания стоимости принесенного в качестве залога товара вы определяете сумму, которую готовы выдать на руки клиенту, а также свои комиссионные. Кроме того, определяете срок возврата денег. Если клиент согласен, то ваши договоренности фиксируются в виде документа, деньги выдаются клиенту, а товар остается у вас. В случае если в указанный срок не происходит возврата денег, товар переходит в вашу собственность. Таблицы Клиенты (Код клиента, Фамилия, Имя, Отчество, Номер паспорта, Серия паспорта, Дата выдачи паспорта). Категории товаров (Код категории товаров, Название, Примечание). Сдача в ломбард (Код, Код категории товаров, Код клиента, Описание товара, Дата сдачи, Дата возврата, Сумма, Комиссионные). Развитие постановки задачи После перехода прав собственности на товар ломбард может продавать товары по цене, меньшей или большей, чем была заявлена при сдаче. Цена может меняться несколько раз, в зависимости от ситуации на рынке. (Например, владелец ломбарда может устроить распродажу зимних вещей в конце зимы.) Помимо текущей цены, нужно хранить все возможные значения цены для данного товара. Внести в структуру таблиц изменения, учитывающие эти факты, и изменить существующие запросы. Добавить новые запросы.

Выделяют три этапа проектирования БД:

•  инфологическое моделирование

•  даталогическое моделирование

•  физическая реализация

1) На первом этапе создается инфологическая модель предметной области.

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

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

2) На основе инфологической модели строится даталогическая модель.

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

3) Третий этап проектирования состоит в привязке ДЛМ к среде хранения с помощью модели данных физического уровня ( физической модели ). Описание физической структуры БД называется схемой хранения .

Компоненты ИЛМ:

•  описание объектов и связей между ними (ER – модель);

•  описание информационных потребностей пользователей;

•  алгоритмические связи показателей;

•  лингвистические отношения;

•  ограничения целостности.

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

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

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

 

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

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

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

Рис. 3.3. Изображение класса

объектов и его свойств

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

Различают связи типа:

•  один к одному (1:1);

•  один ко многим (1: М);

•  многие к одному (М:1);

•  многие ко многим (М :М ).

Иногда эти типы связей называют степенью связи.

Кроме степени связи в ИЛМ для характеристики связи между разными объектами указывается класспринадлежности , который показывает, может ли отсутствовать связь объекта одного класса с каким-либо объектом другого класса. Различают обязательный и необязательный класс принадлежности.

Пусть в ИЛМ отображается связь между двумя классами объектов: Сотрудники и Язык иностранный .

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

Соответствующие диаграммы

ER – типов ER - экземпляров

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

Соответствующие диаграммы

ER – типов ER – экземпляров

В рассмотренных случаях между объектами наблюдается связь типа М:1; в случае а) класс принадлежности является необязательным для обоих объектов; в случае б) – для объекта Сотрудники класс принадлежности является обязательным, что изображается точкой в прямоугольнике.

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

Соответствующие диаграммы

ER – типов ER – экземпляров

В этом случае связь между объектами имеет тип М :М .

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

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

Составной объект соответствует отображению связи «целое - часть». Примеры таких объектов: класс – ученики, группа – студенты и т.п. (связь между составным и составляющими его объектами отображается отношением 1: М)

Обобщенный объект отражает наличие связи «род - вид» между объектами предметной области. Например, объекты Студент , Школьник , Аспирант образуют обобщенный объект Учащиеся . Объекты, составляющие обобщенный объект, называются его категориями. Как «родовой» объект, так и «видовые» объекты могут обладать определенным набором свойств. Причем «видовые» объекты обладают всеми теми свойствами, которыми обладает «родовой» объект, плюс свойствами, присущими только объектам этого вида.

Определение родо-видовых связей означает классификацию объектов предметной области по тем или иным признакам. Подклассы могут выделяться в ИЛМ в явном виде (см. рис. 3.5).

Рис. 3.5. Изображение обобщенного объекта

 

Агрегированный объект соответствует обычно какому-либо процессу, в который оказываются «вовлеченными» другие объекты. Например, агрегированный объект Поставка (см. рис. 3.6) объединяет в себе объекты Поставщик, Получатель , Продукт и Дата . Для отображения агрегированного объекта в схеме использован ромб. Агрегированный объект может, так же как и простой объект, иметь характеризующие его свойства.

Рис. 3.6. Изображение агрегированного объекта

6. Администраторы данных и администраторы баз данных База данных и СУБД являются корпоративными ресурсами, которыми следует управлять так же, как и любыми другими ресурсами. Обычно управление данными и базой данных предусматривает управление и контроль за СУБД и помещенными в нее данными. Администратор данных, или АД (Data Administrator — DA), отвечает за управление данными, включая планирование базы данных, разработку и сопровождение стандартов, прикладных алгоритмов и деловых процедур, а также за концептуальное и логическое проектирование базы данных. АД консультирует и дает свои рекомендации руководству высшего звена, контролируя соответствие общего направления развития базы данных установленным корпоративным целям. Администратор базы данных, или АБД (Database Administrator — DBA), отвечает за физическую реализацию базы данных, включая физическое проектирование и воплощение проекта, за обеспечение безопасности и целостности данных, за сопровождение операционной системы, а также за обеспечение максимальной производительности приложений и пользователей. По сравнению с АД обязанности АБД носят более технический характер, и для него необходимо знание конкретной СУБД и системного окружения. В одних организациях между этими ролями не делается различий, а в других важность корпоративных ресурсов отражена именно в выделении отдельных групп персонала с указанным кругом обязанностей. Более подробно администрирование данных и баз данных рассматривается в разделе 9.15. Разработчики баз данных В проектировании больших баз данных участвуют разработчики двух разных типов: разработчики логической базы данных и разработчики физической базы данных.Разработчик логической базы данных занимается идентификацией данных (т.е. сущностей и их атрибутов), связей между данными, и устанавливает ограничения, накладываемые на хранимые данные. Разработчик логической базы данных должен обладать всесторонним и полным пониманием структуры данных организации и ееделового регламента. Деловой регламент описывает основные требования к системес точки зрения организации. Ниже приведен пример типичного делового регламента для проекта DreamHome.

• Любой сотрудник не может отвечать одновременно более чем за сто сдаваемых в аренду или продаваемых объектов недвижимости.

• Любой сотрудник не имеет права продавать или сдавать в аренду свою собственную недвижимость.

• Доверенное лицо не может выступать одновременно и как покупатель, и как продавец недвижимости.

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

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

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

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

• преобразованием логической модели данных в набор таблиц и ограничений целостности данных;

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

• проектированием любых требуемых мер защиты данных.

Многие этапы физического проектирования базы данных в значительной степени зависят от выбранной целевой СУБД, а потому может существовать несколько различных способов воплощения требуемой схемы. Следовательно, разработчик физической базы данных должен разбираться в функциональных возможностях целевой СУБД и понимать достоинства и недостатки каждого возможного варианта реализации. Разработчик физической базы данных должен уметь выбрать наиболее подходящую стратегию хранения данных с учетом всех существующих особенностей их использования. Если концептуальное и логическое проектирование базы данных отвечает на вопрос ««что?», то физическое проектирование отвечает на вопрос««как?». Для решения этих задач требуются разные навыки работы, которыми чаще всего обладают разные люди. Методология концептуального проектирования базы данных рассматривается в главе 14, логического проектирования — в главе 15, а физического — в главах 16 и 17. Прикладные программисты Сразу после создания базы данных следует приступить к разработке приложений, предоставляющих пользователям необходимые им функциональные возможности. Именно эту работу и выполняют прикладные программисты. Обычно прикладные программисты работают на основе спецификаций, созданных системными аналитиками. Как правило, каждая программа содержит некоторые операторы, требующие от СУБД выполнения определенных действий с базой данных — например, таких как извлечение, вставка, обновление или удаление данных. Как уже упоминалось в предыдущем разделе, эти программы могут создаваться на различных языках программирования третьего или четвертого поколения. Пользователи Пользователи являются клиентами базы данных — она проектируется, создается и поддерживается для того, чтобы обслуживать их информационные потребности. Пользователей можно классифицировать по способу использования ими системы.

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

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

7. Запись – совокупность элементов данных логически связанных друг с другом

 Поле – наименьшая проименованная единица данных

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

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

8 – 9. Access ориентирована на работу с объектами, к которым относятся таблицы базы данных, запросы, а также объекты приложений для работы с базой данных: формы, отчеты, страницы, макросы и модули.

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

Запросы (Queries) создаются пользователем для выборки нужных данных из одной или нескольких связанных таблиц. Результатом выполнения запроса является таблица, которая может быть использована наряду с другими таблицами БД при обработке данных. Запрос может формироваться в виде запросов по образцу (QBE) или с помощью инструкции SQL - языка структурированных запросов. С помощью запроса можно также обновить, удалить или добавить данные в таблицы или создать новые таблицы на основе уже существующих.

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

Отчеты (Reports) предназначены для формирования выходных документов, содержащих результаты решения задач пользователя, и вывода их на печать.

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

Макросы (Macros). Макрос является программой, которая содержит описание последовательности действий, выполняемых при наступлении некоторого события в объекте или элементе управления приложения. Каждое действие реализуется макрокомандой. Создание макросов осуществляется в диалоговом режиме путем выбора нужных макрокоманд и задания параметров, используемых ими при выполнении.

Модули (Modules) содержат процедуры на языке VBA. Могут создаваться процедуры- функции, которые разрабатываются пользователем для реализации нестандартных функций в приложении пользователя, и процедуры для обработки событий. В Access 2000 для удобства пользователя объекты базы данных могут быть объединены в группы по функциональному или иному признаку. Группы содержат ссылки на объекты базы данных различных типов.

10.

Текстовый	Алфавитно-цифровые данные	До 255 байт
Мемо	Алфавитно-цифровые данные большого объема	До 64 Кбайт
Числовой	Числовые данные	1,2,4,8 байт
Дата/Время	Дата и время	8 байт
Денежный	Числовые данные с 4 точками после запятой	8 байт
Счетчик	Уникальное длинное целое, генерируемое ACCESS при запросе нового значения	4 байта
Логический	Логические данные	1 байт
Объект OLE	Всевозможные OLE-объекты из приложений Windows	До 1 Гбайт

11. Свойства полей Access.

Размер поля. Определяет максимальную длину текстового или числового поля, так как если размер подобран неоптимальное, расходуется, лишня память.

Формат поля. Устанавливает формат отображения данных в форме, запросе, отчете.

Число десятичных знаков. Количество знаков после запятой в десятичном числе.

Маска ввода. Задает маску (шаблон), при вводе данных в таблицу или форму.

Значение по умолчанию. Содержит значение, установленное по умолчанию, для всех новых записей таблицы.

Подпись. Задает подпись поля, которое выводиться в формах, отчетах, таблицах (не путать с именем поля).

Условие на значение. Позволяет задать то условие, которое проверяется при вводе данных в поле.

Сообщение об ошибке. Задается текст, сообщение выводится в диалоговом окне, если вводимые данные не соответствуют, заданному условию на значение.

Обязательное поле. Определяет, может ли поле быть пустым или нет.

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

Индексированное поле. Задает индексы, для ускоренного поиска информации в таблице.

12. Создание таблицы в режиме конструктора.

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

Наименование поля вводится в столбце Имя поля. При задании имен необходимо следовать следующим правилам:

- имя поля может содержать буквы, цифры, пробелы (не желательно, лучше использовать большую букву или знак подчеркивания) и специальные символы кроме («.», «!», «[ ]») и управляющих символов с кодами ASCII 0-31;

- имя поля не может начинаться с пробела;

- два поля в одной таблице не могут иметь одинаковые имена.

Второй столбец Тип данных (выпадающий список). Существует девять типов данных:

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

- Поле МЕМО – текстовое поле, используется для ввода текста произвольной длины. На самом деле здесь хранится не сам текст, а метка, указывающая на его местонахождение.

- Числовое – для ввода дробных, целых, положительных и отрицательных чисел. Свойства: размер(байт, целое, длинное целое, с плавающей точкой), формат поля, число десятичных знаков.

- Дата/время – главное свойство – формат поля (длинный, средний, краткий формат даты).

- Денежный – свойства: формат поля, число десятичных знаков.

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

- поле типа Логический – это поле, данные в котором могут иметь только одно из двух возможных значений, например, Да или Нет.

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

- поле Гиперссылка используется для хранения адресов Web-страниц Интернета.

Столбец Описание заполняется произвольно. После нажатия Enter или Tab осуществляется переход на другую строку.

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

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

Все типы полей, кроме счетчика имеют следующие общие свойства:

- размер поля – задает максимальное число символов для ввода в данное поле (например, для почтового индекса оно будет 6);

- новые значения – определяет способ изменения значений счетчика при добавлении новых записей;

- формат поля – определяет, как должно отображаться содержимое поля;

- число десятичных знаков;

- маска ввода – для облегчения ввода данных.

При вводе данных в некоторые поля удобно сделать так, чтобы в поле заранее стояли символы, которые часто повторяются и специальные символы: дефис, скобки и прочее – тогда эти символы не придется вводить вручную. Форматы для ввода данных называется масками ввода. Маска состоит из трех разделов, разделенных (;). Например, шифр студента образован из двухзначного номера факультета, трехзначного порядкового номера студента и последних двух цифр года поступления.

Маска: 00 – 000 - «05»; 0; #

«05» - значит стоящее в кавычках добавляется обязательно в поле автоматически;

0 – символы маски сохраняются в таблице вместе с введенными символами (иначе 1);

# - указывает, какой знак должен стоять на месте вводимых символов.

При вводе данных пользователь увидит следующую маску: ## - ### - 05.

Применение маски ввода позволяет не только упростить ввод но и уменьшить вероятность ошибки при вводе. Недостаток – знание и умение применять значения кодов используемых при создании маски ввода.

- подпись – определяет текст, который выводится рядом с полем в форме или отчете;

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

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

- сообщение об ошибке – позволяет указать текст сообщения, выводящегося на экран, если введенные данные нарушают условие на значение;

- обязательное поле – содержит значение Да или Нет и указывает, требует ли поле обязательного ввода значения (значение Нет говорит о том, что поле может оставаться пустым);

- пустые строки – определяет индекс, создаваемый по одному полю;

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