При создании базы данных можно выделить следующие этапы:

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

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

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

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

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


17. ТАБЛИЦЫ

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

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

Запись - строка таблицы базы данных, в которой собрана вся информация о конкретном предмете. Например, в таблице «Книги» базы данных «Библиотека» - это информация о конкретной книге.

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

СТРУКТУРА ТАБЛИЦЫ

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

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

При разработке БД можно выделить следующие этапы работы.

I этап. Постановка задачи.

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

II этап. Анализ объекта.

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

III этап. Синтез модели.

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

IV этап. Выбор способов представления информации и программного инструментария.

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

В большинстве СУБД данные можно хранить в двух видах:

с использованием форм;

без использования форм.

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

V этап. Синтез компьютерной модели объекта.

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

Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

Стадия 2. Создание исходной таблицы или таблиц.

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

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

Стадия 3. Создание экранных форм.

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

Стадия 4. Заполнение БД.

Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE - в виде формы.

VI этап. Работа с созданной базой данных.

Работа с БД включает в себя следующие действия:

поиск необходимых сведений;

сортировка данных;

отбор данных;

вывод на печать;

изменение и дополнение данных.

Пользователи БД и СУБД

Классификация баз данных

Архитектура БД

Классификация СУБД

Основные функции СУБД

Обработка данных.

Этап 1. Постановка задач

Этап 2. Анализ данных

Этап 3 Определение структуры данных.

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

Этап 4. Физическая реализация БД средствами выбранной СУБД.

Этап 5. Создание приложения, включая пользовательский интерфейс.

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

Этап 6. Тестирование, усовершенствование и внедрение приложения.

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

Модели организации баз данных

Пример

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

Поэтому, для информационной системы управления персоналом необходимо создать групповое отношение, состоящее из родительской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на (Для простоты полагается, что имеются только две дочерние записи).

Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры: заказчик - контракты с ним - сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК (НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА).

Если исполнитель может принимать участие более чем в одном контракте, то в базу данных необходимо ввести еще одно групповое отношение , в котором ИСПОЛНИТЕЛЬ будет являться исходной записью, а КОНТРАКТ - дочерней. Таким образом, информация дублируется.

Операции над данными, определенные в иерархической модели :

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

· Изменить значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.

· Удалить некоторую запись и все подчиненные ей записи.

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

· Извлечь следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева ).

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

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

Объектно-реляционные СУБД

Разница между объектно-реляционными и объектными СУБД : первые являют собой надстройку над реляционной схемой, вторые же изначально объектно-ориентированы. Главная особенность и отличие объектно-реляционных (как и объектных) СУБД от реляционных заключается в том, что ОРСУБД интегрированы с Объектно-Ориентированным (OO) языком программирования, внутренним или внешним как C++, Java .

Объектно-реляционными СУБД являются, например, широко известные Oracle Database , Microsoft SQL Server , PostgreSQL, Microsoft Access.

Первая нормальная форма

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

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

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

· таблица должна содержать данные об одном типе объектов;

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

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

Третья нормальная форма

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

Простые и составные ключи

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

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

Такой первичный ключ называют составным ключом

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

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

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

Пользователи БД и СУБД

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

Классификация баз данных

Архитектура БД

Классификация СУБД

Основные функции СУБД

Организация данных. Создание объектов БД.

Управление размещением данных во ВП и в ОП.

Обеспечение целостности данных. Обеспечение безопасности данных.

Обеспечение восстановления БД.

Обработка данных.

Реализация бизнес-логики приложения

Основные этапы разработки БД и приложения

Этап 1. Постановка задач

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

Этап 2. Анализ данных

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

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

Этапы разработки базы данных:

1. Постановка задачи.

2. Разработка информационно-логической (инфологической) модели.

3. Выбор СУБД. Разработка логической модели базы данных.

4. Разработка программного обеспечения базы данных.

5. Заполнение базы рабочими данными и поддержание ее в актуальном состоянии.

Рассмотрим эти этапы более подробно.

1-й этап. Постановка задачи

На этом этапе определяются цели разработки: что должно получиться в результате. При этом следует получить ответы на множество вопросов:

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

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

2-й этап. Разработка информационно-логической (инфологической) модели

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

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

3-й этап. Выбор СУБД. Разработка логической модели базы данных

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

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

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



4-й этап. Разработка программного обеспечения базы данных

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

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

5-й этап. Заполнение базы рабочими данными и поддержание ее в актуальном состоянии

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

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

Вопросы для самоконтроля:

1. Перечислите этапы разработки базы данных.

2. На каком этапе производится первичное обучение пользователей?

3. На каком этапе определяется перечень входной и выходной информации и детальные характеристики этой информации?

4. На каком этапе определяются цели разработки БД?

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

1.5 Особенности архитектуры информационных систем. Одно – двух – и трехуровневые системы

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

· централизованная архитектура;

· архитектура "файл-сервер";

· архитектура "клиент – сервер";

· трехзвенная (многозвенная) архитектура "клиент – сервер"

Рассмотрим эти технологии более подробно.

С точки зрения конечного пользователя процесс создания базы данных можно представить в виде четырех этапов:

  • Анализ предметной области
  • Инфологическое (концептуальное) описание данных;
  • Логическое проектирование баз данных;
  • Физическое проектирование баз данных.

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

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

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

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

Существует два подхода к выбору состава и структуры предметной области:

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

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

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

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

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

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

Существует три основных типа отношений:

1) «один-к-одному». Такая связь означает, что каждому значению реквизита А соответствует одно и только одно значение связанного с ним реквизита В, и наоборот. Например, каждому значению реквизита Номер паспорта соответствует единственное значение реквизита ФИО гражданина страны, и наоборот. Такую связь обозначают 1:1, графически в инфологических моделях эта связь изображается одинарными стрелками.

2)«один-ко-многим». Эта связь означает, что каждому значению реквизита А соответствует одно или несколько значений связанного с ним реквизита В, а каждому значению реквизита В соответствует одно и только одно значение реквизита А. Например, для аэропорта , из которого осуществляется множество рейсов, характерна следующая связь между описывающими этот объект реквизитами: одному значению реквизита Название аэропорта вылета соответствует несколько значений реквизита Номер рейса, а каждому значению Номер рейса соответствует только одно Название аэропорта вылета.

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

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

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

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

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

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

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

Более сложными моделями внутримашинной организации данных являются сетевые и иерархические модели.

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

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

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

Физическое проектирование предполагает определение способов и мест размещения базы данных, оценку ее объема и других параметров.

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

Файлы прямого доступа;

Файлы последовательного доступа;

Индексные файлы.


Похожая информация.