extracted_text:
Лекция № 12 Введение в
разработку баз данных. СУБД. Создание базы данных. Компоненты
приложения. Процесс разработки базы данных

1.1
Введение в
разработку баз данных.

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

1.2
База данных

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

ЯДРО

СУБД

Средства
  проектирования

Средство для создания таблиц

Средство для создания формул

Средство
  для создания запросов

Средство для создания отчётов

Подсистема обработки

Процессор
  форм

Процессор запросов

Генератор отчётов

Средства
  обработки, реализованные на процедурных языках

                                               Разработчик

База
данных                          Прикладные                                                  программы

                                               Пользователи

                                    Прикладные
                                               программы

                                                         Рис.
12.1

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

1.3
Данные
пользователя

         Сегодня большинство баз данных
представляют данные пользователя в виде отношений (relations). Формальное определение термина отношение мы дадим
ниже. На данный же момент будем рассматривать отношение как таблицу данных.
Столбцы таблицы содержат поля, или атрибуты, а строки содержат записи о
конкретных объектах делового мира.
         Не все отношения являются
одинаково желательными; некоторые отношения структурированы лучше, чем другие.
Процесс, с помощью которого получаются хорошо структурированные отношения,
называется нормализацией (normalization). Чтобы получить представление о разнице
между плохо и хорошо структурированными отношениями, рассмотрим отношение R1 (ИмяСтудента, Телефон Студента, ИмяРуководителя,
ТелефонРуководителя), содержащее имена и телефоны студентов и их
руководителей:

ИмяСтудента

ТлфСтудента

ИмяРуковод

  ТлфРуковод

Бейкер, Рекс

232-8897

Парке

236-0098

Бет, Мэри

232-4487

Джонс

236-0110

Скотт, Гленн

232-4444

Парке

236-0098

Зилог, Фрита

232-5588

Джонс

236-0110

Чарлз Джонсон,

232-0099

Парке

236-0098

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

ИмяСтудента

ТлфСтудента

ИмяРуковод

Бейкер, Рекс

232-8897

Парке

Бет, Мэри

232-4487

Джонс

Скотт, Гленн

232-4444

Парке

Зилог, Фрита

232-5588

Джонс

Чарлз Джонсон,

232-0099

Парке

Второе отношение, R3 (ИмяРуководителя, ТелефонРуководителя), будет содержать фамилию
и телефон руководителя

ИмяРуковод

  ТлфРуковод

Парке

236-0098

Джонс

236-0110

Парке

236-0098

Джонс

236-0110

Парке

236-0098

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

1.4
Метаданные

         Как было указано в лекции 11,
база данных является самодокументированной, то есть одной из ее составляющих
является описание собственной структуры. Это описание называется метаданными
(metadata). Так как СУБД предназначены для хранения
таблиц и манипуляции ими, большинство из них хранят метаданные в форме таблиц,
иногда называемых системными таблицами (system tables).
В табл. 12.1 представлены два примера хранения метаданных в системных таблицах.
В таблице SysTables перечислены все таблицы, имеющиеся в базе
данных, и для каждой таблицы указаны количество столбцов и имена одного или нескольких
столбцов, служащих первичным ключом. Такой столбец или набор столбцов является
уникальным идентификатором строки. В таблице SysColumns перечислены столбцы, имеющиеся в каждой таблице, а также
тип данных и ширина каждого столбца. Эти две таблицы представляют собой
типичные образцы системных таблиц; в других подобных таблицах хранятся списки
индексов, ключей, хранимых процедур и т. п.

Таблица 12.1. Примеры метаданных

Таблица
  SysTables
Имя
  таблицы

Число
  столбцов

Первичный
  ключ

Студент

4

НомерСтудента

Руководитель

3

ИмяРуководителя

Дисциплина

3

НомерДисциплины

УчебныйПлан

3

{НомерСтудента,
  НомерДисциплины}

Таблица
  SysColumns
Имя
  столбца

Имя
  таблицы

Тип
  данных

Длина
  (Длины приведены в байтах или, что
  то же самое, в символах (для текстовых данных)

НомерСтудента

Студент

Integer

4

Имя

Студент

Text

20

Фамилия

Студент

Text

30

Специальность

Студент

Text

10

ИмяРуководителя

Руководитель

Text

25

Телефон

Руководитель

Text

12

Кафедра

Руководитель

Text

15

НомерДисциплины

Дисциплина

Integer

4

Название

Дисциплина

Text

10

КоличествоЧасов

Дисциплина

Decimal

4

НомерСтудента

УчебныйПлан

Integer

4

Курс

УчебныйПлан

Text

2

НомерДисциплины

УчебныйПлан

Integer

4

         Хранение метаданных в таблицах не
только эффективно для СУБД, но и удобно для разработчиков, поскольку для
запроса метаданных они могут использовать те же самые средства, что и для
запроса пользовательских данных. В лекции 14 мы обсудим язык под названием SQL, который используется для запроса и обновления
таблиц метаданных и пользовательских данных.
         В качестве возможного примера
использования SQL представьте, что вы разработали базу
данных с 15 таблицами и 200 столбцами. Вы помните, что некоторые столбцы имеют
тип данных currency, но не можете вспомнить, какие именно. С
помощью SQL можно обратиться к таблице SysColumns и по ней определить, какие столбцы имеют
указанный тип данных.

1.5
Индексы

         Третий тип данных, которые
хранятся в базе данных, призван улучшить ее производительность и доступность.
Эти данные, называемые иногда избыточными данными (overhead data), состоят главным образом из индексов (indexes), хотя в ряде случаев используются и
другие структуры данных, такие как связанные списки (индексы и связанные списки
обсуждаются ниже).
         В табл. 2.2 приведены данные о
студентах и два индекса к ней. Чтобы уяснить, какая может быть польза от
индексов, представьте себе, что данные в таблице СТУДЕНТ расположены в порядке
возрастания значения поля НомерСтудента, а пользователь хотел бы создать из
этих данных отчет, отсортированный по полю Фамилия. Для этого можно было бы
извлечь все данные из таблицы и отсортировать, но, если размеры таблицы не
слишком малы, этот процесс может занять много времени. В качестве альтернативы
можно создать индекс Фамилия, приведенный в табл. 2.2. Записи в этом индексе
отсортированы по полю Фамилия, поэтому достаточно считать записи из индекса в
порядке следования, чтобы затем получать данные из таблицы СТУДЕНТ,
отсортированные в нужном порядке.

Таблица 12.2. Примеры индексов
Таблица СТУДЕНТ
НомерСтудента    Имя____________Фамилия_______Специальность____________________
100
Джеймс                Бейкер                   Бухгалтерский учет
200
Мэри                     Абернати               Информационные системы
300
Бет                        Джексон                 Бухгалтерский учет
400
Элдридж                Джонсон                Маркетинг
500
Крис                      Тафт                      Бухгалтерский учет
600
Джон                     Сматерс                 Информационные системы
700
Майкл                   Джонсон                Бухгалтерский учет
Индекс Фамилия
Фамилия_____________________НомерСтудента________________________________
Абернати
200
Бейкер
100
Джонсон
300
Джонсон                                            400,
700
Сматерс
600
Тафт_________________________500____________________________________________
Индекс Специальность
Специальность_______________НомерСтудента_________________________________
Бухгалтерский
учет                          100,300,500,700
Информационные системы            200, 600
Маркетинг____________________400____________________________________________

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

1.6
Метаданные
приложений

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

1.7
СУБД

         СУБД значительно различаются по
своим характеристикам и функциям. Первые продукты такого рода были разработаны
для больших ЭВМ в конце 1960-х годов и были весьма примитивны. С тех пор СУБД
постоянно совершенствовались, а функции их расширялись. Усовершенствования
касались не только обработки баз данных: СУБД также снабжались функциями,
упрощающими создание приложений баз данных.
В этой лекции для иллюстрации возможностей
СУБД мы будем использовать Microsoft Access 2002. Это обусловлено тем, что Access 2002 обладает всеми типичными
характеристиками и функциями современной СУБД. Однако Access 2002 не является единственной СУБД такого рода, и наш выбор ни в
коей мере не предполагает какого-либо предпочтения перед другими подобными продуктами,
например MS SQL Server
2003.
         Как видно из рис. 12.1,
характеристики и функции СУБД можно разделить на три подсистемы:
Ø
подсистему средств
проектирования,
Ø
подсистему средств
обработки,
Ø
ядро СУБД.

1.8
Подсистема
средств проектирования

         Подсистема средств проектирования (design tools subsystem)
представляет собой набор инструментов, упрощающих проектирование и реализацию
баз данных и их приложений. Как правило, этот набор включает в себя средства
для создания таблиц, форм, запросов и отчетов. В СУБД имеются также языки
программирования и интерфейсы для них. Например, в Access есть два языка: макроязык, не требующий глубокого знания
программирования, и версия языка BASIC под названием
Visual Basic.

1.9
Подсистема
обработки

         Подсистема обработки (run-time subsystem)[1]
занимается обработкой компонентов приложения, созданных с помощью средств
проектирования. Например, в Access 2002
имеется компонент, материализующий формы и связывающий элементы форм с данными
таблиц. Представьте себе форму с текстовым полем, где отображается значение
столбца НомерСтудента из таблицы СТУДЕНТ. В процессе работы приложения при
открытии формы процессор форм (form processor) извлекает значение поля НомерСтудента
из текущей строки таблицы и отображает его в форме. Все это делается
автоматически - ни пользователю, ни разработчику не требуется ничего делать,
если имеется готовая форма. Другие процессоры подсистемы обработки
предназначены для выполнения запросов и вывода отчетов. Кроме того, в
подсистеме обработки имеется компонент, обрабатывающий запросы прикладных
программ на чтение и запись данных в базу.
Хотя это не показано на рис. 2.1, СУБД
должны также предоставлять интерфейс для стандартных языков программирования,
таких как C++ и Java.

1.10
Ядро СУБД

         Третий компонент СУБД — это ее ядро
(DBMS engine), которое выполняет функцию посредника между подсистемой средств
проектирования и обработки и данными. Ядро СУБД получает запросы от двух других
компонентов, выраженные в терминах таблиц, строк и столбцов, и преобразует эти
запросы в команды операционной системы, выполняющие запись и чтение данных с
физического носителя.
Кроме того, ядро СУБД участвует в
управлении транзакциями, блокировке, резервном копировании и восстановлении.
Действия с базой данных должны выполняться как единое целое. Например, при
обработке заказа изменения в таблицах КЛИЕНТ, ЗАКАЗ и СКЛАД должны производиться
согласованно: либо выполняются все, либо не выполняется ни одно. Ядро СУБД
помогает координировать действия, с тем, чтобы либо выполнялись все действия в
группе, либо не выполнялись ни одного.
         Microsoft предоставляет два различных ядра для Access 2002: Jet Engine и SQL Server.
Ядро Jet Engine используется для небольших персональных и коллективных баз
данных. Ядро SQL Server, представляющее собой независимый продукт Microsoft, предназначено для крупных баз данных
уровня отдела и небольших или среднего размера организационных баз данных. Когда вы
создаете базу данных с помощью встроенных в Access 2002 средств генерации таблиц (такие базы данных хранятся вместе
с suffix.mdb), вы
используете Jet Engine. Создавая проект Access 2002 (с suffix.adp), вы
тем самым создаете прикладной интерфейс для ядра SQL Server.

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

         Схема базы данных (database scheme) определяет структуру базы данных, ее таблиц, связей и доменов,
а также деловой регламент. Схема базы данных — это проект, основа, на которой
строятся база данных и ее приложения.

1.12
Пример схемы
базы данных

         Чтобы уяснить себе, что такое
схема базы данных и зачем она нужна, рассмотрим пример. Колледж Highline — небольшой колледж свободных искусств на
Среднем Западе США. Отдел студенческого досуга колледжа финансирует локальные
спортивные секции, но испытывает проблемы с учетом спортивного инвентаря,
выданного капитанам различных команд. Схема базы данных для системы учета
спортинвентаря будет содержать следующие компоненты.

1.13
Таблицы

         База данных имеет две таблицы[2]:
CAPTAIN (CaptainName, Phone, Street City, State, ZIP), содержащую сведения о капитанах, и ITEM (Quantity, Description, Dateln, DateOut), содержащую данные об инвентаре. Здесь
перед скобками даны имена таблиц, а в скобках указываются имена столбцов.
Ни
CaptainName (имя капитана), ни Description
(описание) не обязаны быть уникальными, поскольку вполне может быть два
капитана по имени Мэри Смит, и уж наверняка имеется много инвентаря под
названием «футбольные мячи». Чтобы обеспечить однозначную идентификацию каждой
строки (важность этого будет объяснена в последующих главах), мы добавим в
каждую из этих таблиц столбец с уникальным номером, как показано ниже:
CAPTAIN(CAPTAIN_ID, CaptainName, Phone, Street, City,
State, ZIP) ITEM(ITEM_ID, Quantity, Description, Dateln, DateOut)

1.14
Связи

         Две представленные здесь таблицы
имеют следующие связи: одна строка таблицы CAPTAIN связана с несколькими строками таблицы ITEM, но
одна строка таблицы ITEM связана с
одной и только одной строкой таблицы CAPTAIN.
Такая связь обозначается 1:N и произносится
«один к N» или «один ко многим». Обозначение 1:N следует понимать так, что одна строка в первой таблице
связана с несколькими строками во второй таблице.
         По
тем обозначениям таблиц, которые даны выше, невозможно сказать, какая строка
таблицы CAPTAIN связана с какими строками таблицы ITEM. Поэтому, чтобы
обозначить их связь, мы добавим в таблицу ITEM столбец CAPTAIN_ID.
Полная структура двух таблиц выглядит следующим образом:
CAPTAIN(CAPTAIN_ID, CaptainName, Phone, Street, City, State, ZIP)
ITEM(ITEM_ID, Quantity, Description,
Dateln, DateOut, CAPTAIN_ID)
         При
такой структуре легко определить, какому капитану был выдан данный инвентарь.
Например, чтобы узнать, кому был выдан инвентарь за номером 1234, в
соответствующей строке таблицы ITEM мы найдем значение CAPTAIN_ID.
По этому номеру мы сможем определить имя и номер телефона данного капитана.

1.15
Домены

         Домен[3] (domain) — это множество значений, которые может
принимать столбец. Рассмотрим домены для столбцов таблицы ITEM. Предположим, что ITEM_ID и Quantity (количество) - целые числа, Description - текст с максимальной длиной 25
символов, Dateln и DateOut (даты выдачи и возврата) имеют тип «дата», a CAPTAIN_ID также является целым числом. Кроме
задания физического формата, нам также необходимо решить, будут ли какие-либо
из доменов уникальными для данной таблицы. В нашем примере мы хотим, чтобы
столбец ITEM_ID был
уникальным, поэтому необходимо указать это в определении домена. Поскольку
капитану может быть выдано более одной единицы инвентаря, столбец CAPTAIN_ ID не является уникальным для таблицы ITEM.
Необходимо также задать домены для
столбцов таблицы CAPTAIN. CAPTAIN_ID является целым числом, а все остальные
столбцы — это текстовые поля различной длины. CAPTAIN_ID должен быть уникальным для таблицы CAPTAIN.

1.16
Деловой
регламент

         Последний элемент схемы базы
данных — это деловой регламент (business rules),
представляющий собой ограничения на возможные действия пользователя, которые
необходимо отразить в базе данных и ее приложениях. Примером делового
регламента для колледжа Highline может
служить следующий набор правил:
1.   Чтобы капитан мог
получить на руки какой-либо инвентарь, у него должен быть местный телефон.
2.   Ни за одним капитаном не
должно числиться более семи футбольных мячей.
3.   По окончании каждого
семестра капитаны обязаны возвратить весь инвентарь »в течение пяти дней.
4.   Капитан не может
получить на руки новый инвентарь, если у него имеется задолженность по ранее
взятому инвентарю.

Деловой регламент является важной частью
схемы, поскольку он задает такие ограничения на возможные значения данных,
которые должны выполняться в любом случае, независимо от того, каким образом
изменения достигают ядра СУБД. Не важно, что является источником запроса на
изменение данных — пользователь формы, запрос на обновление/чтение или
прикладная программа: СУБД должна позаботиться о том, чтобы эти изменения не
нарушили никаких правил.
         К сожалению, реализация делового
регламента осуществляется в различных СУБД по-разному. В Access 2002 некоторые правила могут задаваться в
схеме и выполняться автоматически. В таких продуктах, как SQL Server и Oracle, деловой регламент реализуется с помощью
так называемых хранимых процедур (stored procedures).
В некоторых случаях СУБД оказывается неспособной реализовать выполнение
требуемых правил, и их приходится закладывать в прикладные программы.

1.17
Создание таблиц

         Следующим
шагом после разработки схемы базы данных является создание таблиц. Для этого
используются специализированные средства, предоставляемые СУБД. Имя каждого
столбца создаваемой таблицы указывается в столбце Field Name (Имя поля), а тип
данных задается в столбце Data Type (Тип данных). В столбце Description
(Описание), не обязательном к заполнению, даются описания столбцов таблицы и
комментарии. Дополнительные данные по каждому столбцу - количество символов,
формат, заголовок и прочее - указываются в полях ввода группы Field Properties
(Свойства поля), расположенной в нижней части окна. Обратите внимание, что
свойство Indexed (Индексируется) в нижней части окна установлено в значение Yes
(No Duplicates), что означает, что для столбца ITEM_ID должен быть создан индекс
из уникальных значений. Таблица CAPTAIN создается аналогичным образом.

1.18
Определение
связей

         Связь
между таблицами CAPTAIN и ITEM имеет вид 1:N, что изображается на схеме путем
помещения ключа таблицы CAPTAIN в таблицу ITEM. Столбец, играющий ту же роль,
что и столбец CAPTAIN_ID в таблице ITEM, называется иногда внешним ключом
(foreign key), поскольку он является ключом таблицы, внешней по отношению к
той таблице, в которой он находится. При создании форм, запросов и отчетов
СУБД может оказать большую помощь разработчику, если она знает, что столбец
CAPTAIN_ID в таблице ITEM является внешним ключом таблицы CAPTAIN. В различных
СУБД статус внешнего ключа объявляется по-разному. В Microsoft Access для этого
рисуется связь между ключом и внешним ключом. Столбец CAPTAIN_ID основной
таблицы (CAPTAIN) соответствует столбцу CAPTAIN_ID в связанной с ней таблице
(ITEM).
         Одним из преимуществ объявления
связи для СУБД является то, что когда данные из столбцов двух таблиц
считываются в форму, запрос или отчет, СУБД знает, как связаны строки этих
таблиц. Хотя эту связь можно указать для каждой конкретной формы, запроса или
отчета, однократное объявление экономит время и снижает вероятность ошибок. На
прочие элементы в окне Edit Relationship (Редактировать связь) мы пока не будем
обращать внимания: о них вы узнаете в ходе дальнейшего изложения. Когда
определены таблицы, столбцы и связи, следующим шагом является построение
компонентов приложения.
1.19
Компоненты
приложения

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

1.20
Формы

         Существуют три различных
представления данных, содержащихся в таблицах CAPTAIN и ITEM. Первый вид данных представлен в
табличном формате. Щелкнув мышью на знаке «плюс», имеющемся в начале каждой
строки, пользователь может увидеть записи из таблицы ITEM, связанные с конкретной строкой таблицы CAPTAIN.
Второй вид представления - в виде формы
для ввода данных (data entry form). В
этой форме в каждый момент времени отображаются данные для одного капитана.
Неопытные пользователи, скорее всего, найдут это представление более простым в
использовании, чем табличный формат.
К странице регистрации капитанов можно
обращаться через Интернет или интрасеть, используя браузер Microsoft Internet Explorer. Для этого страница должна храниться на web-сервере, подобном Internet Information Server.
На данный момент следует просто знать, что такие формы можно создавать с помощью
средств, входящих в состав Access 2002.
         Табличное представление
автоматически генерируется Access 2002 для
каждой таблицы, определенной в схеме базы данных. Формы для ввода данных,
однако, должны создаваться с помощью генераторов форм. В качестве источника
данных для новой формы заявлена таблица CAPTAIN. Access выводит окно, называемое списком
полей (field list), в котором перечислены все столбцы таблицы CAPTAIN. Пользователь перетащил (drag-n-drop) поле Captain Name из
списка полей в форму. В ответ на это Access
создал метку с названием CaptainName и поле
ввода, куда будут вводиться значения CaptainName.
Теперь поле ввода привязано (bound) к
столбцу CaptainName таблицы CAPTAIN. Другие столбцы таблицы привязываются аналогичным образом;
столбцы таблицы ITEM привязываются к форме с помощью средства,
называемого субформой (subform). В Access имеется также мастер форм, позволяющий
создавать формы.

1.21
Процесс
разработки базы данных

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

1.22
Общие стратегии

         База данных — это модель
пользовательской модели деловой активности. Поэтому, для того чтобы построить
эффективную базу данных и ее приложения, команда разработчиков должна ясно
представить себе пользовательскую модель. Для этого команда строит модель
данных, идентифицирующую объекты, которые должны храниться в базе данных, и
определяет их структуру и связи между ними. Это понимание должно быть
достигнуто на ранней стадии процесса разработки путем опроса пользователей и
составления технического задания (statement of requirements). Большинство таких технических заданий включают
использование прототипов (prototypes)
— шаблонных баз данных и приложений, представляющих различные аспекты
создаваемой системы.
Есть две общих стратегии
разработки баз данных: сверху вниз и снизу вверх.
         Разработка сверху вниз (top-down database development) идет от общего к частному. Она
начинается с изучения стратегических целей организации, способов, при помощи
которых эти цели могут быть достигнуты, требований к информации, которые
должны быть удовлетворены для достижения этих целей, и систем, необходимых для
предоставления такой информации. Результатом такого исследования является
абстрактная модель данных.
Отталкиваясь от этой общей модели, команда
разработчиков двигается «вниз», к всё более и более подробным описаниям и
моделям. Модели промежуточного уровня также постоянно детализируются, пока не
воплотятся в конкретные базы данных и их приложения. Одно или более из этих
приложений берется затем в разработку. В конце-концов вся высокоуровневая
модель данных трансформируется в низкоуровневые модели, после чего реализуются
все указанные системы, базы данных и приложения.
         При разработке снизу вверх
(bottom-up database development) уровень абстракции меняется в обратном направлении:
исходным пунктом является необходимость в конкретной системе. Способ выбора
первой системы варьируется от организации к организации. В одних организациях
приложение выбирается правлением, в других пользователи могут выбирать его
самостоятельно, в третьих побеждает мнение того, кто в администрации громче
всех кричит.
         Так или иначе, для разработки
выбирается конкретная система. Команда разработчиков затем составляет
техническое задание, рассматривая выходы и входы существующих компьютерных
систем, анализируя формы и отчеты, используемые в существующих системах с
ручной записью, и опрашивая пользователей с целью определения их потребностей в
новых отчетах, формах и запросах, а также других требований. Исходя из этого
всего, команда программистов разрабатывает информационную систему. Если
система включает в себя базу данных, команда на основании технического задания
строит модель данных, а имея модель данных, она проектирует и реализует базу
данных. Когда создание данной системы завершается, запускаются другие проекты,
целью которых является построение дополнительных информационных систем.
         Сторонники разработки сверху вниз
утверждают, что этот подход имеет преимущество перед разработкой снизу вверх,
поскольку модели данных (и соответствующие им системы) строятся с глобальной
перспективой. Они считают, что такие системы гораздо лучше взаимодействуют
между собой, являются более согласованными и требуют намного меньше переделок.
         Сторонники разработки снизу вверх
говорят, что такой подход работает быстрее и сопряжен с меньшим риском. Они
утверждают, что моделирование сверху вниз выливается в большое количество
трудновыполнимых исследований и что процесс планирования часто заходит в тупик.
Хотя моделирование снизу вверх не обязательно имеет своим результатом оптимальный
набор систем, тем не менее, с его помощью можно быстро создать работающую
систему. Такие системы начинают давать прибыль гораздо быстрее, чем системы,
смоделированные сверху вниз, и это более чем компенсирует любые переделки и
модификации, которые придется сделать, чтобы настроить систему на глобальную
перспективу.
         В этой лекции описываются
средства и способы, которые можно использовать при любом стиле системной
разработки. Например, хотя и модель «сущность—связь», и семантическая
объектная модель работают при разработке как сверху вниз, так и снизу вверх,
модель «сущность—связь» более эффективна при разработке сверху вниз, а
семантическая объектная модель — при разработке снизу вверх.

1.23
Моделирование
данных

         Как уже говорилось, наиболее
важная цель на стадии разработки технического задания - это создание модели
данных пользователя (user data model),
или моделирование данных (data modeling). Как бы это ни делалось - сверху вниз
или снизу вверх, - это включает в себя опрос пользователей, документирование
требований и построение модели данных и прототипов на основе этих требований.
Такая модель показывает, какие объекты должны храниться в базе данных, и определяет
их структуру и связи между ними.
Рассмотрим, например,  список
заказов, выполненных продавцом за определенный период времени. Чтобы
приложение базы данных могло выдать такой отчет № 1, база данных должна
содержать информацию, представленную в этом отчете, поэтому разработчики базы
данных должны исследовать этот отчет и на его основании определить, какие
данные должны храниться в базе. В нашем случае должны быть данные о продавцах
(имя и регион) и данные о заказах (компания, дата заказа и количество товара).
Разработка баз данных осложняется тем, что
требований может быть несколько и они обычно перекрываются. Отчет № 2 также
содержит данные о продавцах, но вместо заказов в нем перечислены комиссионные.
Глядя на этот отчет, мы можем предположить, что существуют различные типы
заказов и для каждого из них определен свой процент комиссионных.
         Заказы, перечисленные в отчете №
2, каким-то образом связаны с заказами, перечисленными в отчёте № 1,
но каким именно, остается не слишком ясным. Команда разработчиков должна
определить эти связи, делая выводы из отчетов и форм, интервьюируя пользователей,
используя собственные знания по данному вопросу и другие источники.

1.24
Моделирование
данных как делание выводов

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

1.25
Моделирование в
многопользовательских системах

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

1.26
Недоразумения
по поводу термина «модель»

         Существуют два альтернативных
средства для построения моделей данных: модель «сущность—связь» и
семантическая объектная модель. Обе модели представляют собой структуры для
описания и документирования требований пользователя к данным. Чтобы избежать
недоразумений, обратите внимание на различное использование термина модель. Команда
разработчиков анализирует требования и строит пользовательскую модель
данных, или модель требований к данным (requirements data model). Эта модель является представлением
требований пользователя к структуре и связям объектов, которые должны храниться
в базе данных. Для создания пользовательской модели данных команда
разработчиков использует средства, которые называются моделью
«сущность—связь» и семантической объектной моделью. Эти средства
состоят из языковых и изобразительных стандартов для представления
пользовательской модели данных. Их роль в разработке баз данных подобна той
роли, которую выполняют алгоритмы и псевдокод в программировании.

1.27
Резюме

         Компонентами системы базы данных
являются база данных, СУБД и прикладные программы, с которыми работают как
пользователи, так и разработчики. База данных состоит из данных, метаданных,
индексов и метаданных приложения. Большинство современных баз данных
представляют данные в виде отношений, или таблиц, хотя не все отношения
одинаково желательны. Нежелательные отношения могут быть преобразованы в два
или более желательных с помощью процесса, называемого нормализацией.
Метаданные часто хранятся в специальных таблицах, которые называются системными
таблицами.
         Характеристики и функции СУБД
можно сгруппировать в три подсистемы. С помощью подсистемы средств
проектирования определяется структура базы данных, приложений и их компонентов.
Функцией подсистемы обработки является материализация форм, отчетов и запросов
путем чтения или записи данных в базу. Ядро СУБД является посредником между
двумя другими подсистемами и операционной системой. Она принимает запросы,
выраженные в терминах таблиц, строк и столбцов, и преобразует их в запросы на
физическое чтение и запись.
         Схема
- это описание структуры базы данных. Она включает в себя описание таблиц,
связей и доменов, а также деловой регламент. Строки одной таблицы могут быть
связаны со строками других таблиц. В этой главе проиллюстрирована связь вида
1:N между двумя таблицами; как вы увидите из следующей главы, есть и другие
типы связей.
         Домен
- это множество значений, которые может иметь столбец. Мы должны указывать
домен для каждого столбца каждой таблицы.
         Наконец,
деловой регламент — это ограничения на виды деловой активности, которые должны
быть отражены в базе данных и ее приложениях.
         Для
создания табличных структур, определения связей и создания форм, запросов,
отчетов и меню используются средства, предоставляемые СУБД. СУБД также включают
в себя средства для взаимодействия с прикладными программами, написанными либо
на входном языке СУБД, либо на стандартных языках, таких как Java.
         Поскольку
база данных является моделью пользовательской модели деловой активности,
разработка базы данных начинается с изучения и записи этой модели. Иногда она
выражается в форме прототипов будущего приложения или компонентов приложения.
         Два
общих стиля разработки таковы: разработка сверху вниз, которая идет от общего к
частному, и разработка снизу вверх, которая идет от частного к общему. В
первом случае приложения разрабатываются с глобальной перспективой, зато во
втором случае разработка идет быстрее. Иногда используется комбинация этих
двух подходов.
         Модели
данных конструируются путем делания выводов из высказываний пользователя.
Собираются формы, отчеты и запросы, и на их основании разработчики делают
вывод о структурах, существующих в воображении пользователей. Это необходимо,
поскольку большинство пользователей не способны непосредственно описать свои
модели данных. Моделирование данных может быть особенно затруднительным в
многопользовательских приложениях, где представления различных пользователей
могут противоречить друг другу, и ни один пользователь не может представить
себе всю картину деловой активности.
         Термин
модель данных используется двояко: он может означать как модель
пользовательских представлений о данных, так и средства, используемые для
описания этих представлений.

Скачано с www.znanio.ru

[1]
В
английском языке подсистема обработки обозначается термином run-time subsystem. He следует
путать его с похожим термином run-time product, который
имеет несколько другое значение. Этим термином некоторые производители
обозначают урезанный вариант комплектации СУБД, куда входят подсистема
обработки и ядро, но не входит подсистема средств проектирования. Такой вариант
позволяет лишь запускать готовое приложение. Назначение таких продуктов в том,
чтобы снизить стоимость приложения для конечного пользователя. Обычно СУБД без
подсистемы средств разработки стоит намного дешевле, чем полноценная СУБД, а
иногда и вовсе бесплатна. Следовательно, полную версию продукта покупает
только разработчик, а конечные пользователи покупают сокращенную версию

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

[3]
Это
определение значительно упрощено, с тем, чтобы сконцентрироваться на
компонентах системы базы данных. Более полное обсуждение доменов происходит в лекции __.

file_name: 012. Введение в разработку баз данных. СУБД. Создание базы данных.doc

alt: R 1 (ИмяСтудента, Телефон Студента,

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

alt: Информационные системы 200, 600

alt: N и произносится «один к N » или «один ко многим»

alt: Большинство таких технических заданий включают использование прототипов ( prototypes ) — шаблонных баз данных и приложений, представляющих различные аспекты создаваемой системы