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

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

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

1.2        База данных

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

                                                           СУБД

                                               Разработчик

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

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

                                    Прикладные

                                               программы

                                                         Рис. 12.1

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

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

         Сегодня большинство баз данных представляют данные пользователя в виде отношений (relations). Формальное определение термина отношение мы дадим ниже. На данный же момент будем рассматривать отношение как таблицу данных. Столбцы таблицы содержат поля, или атрибуты, а строки содержат запи­си о конкретных объектах делового мира.

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

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

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

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

1.4        Метаданные

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

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

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

К странице регистрации капитанов можно обра­щаться через Интернет или интрасеть, используя браузер Micro­soft 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