Теория и практика построения баз данных (1088289), страница 15
Текст из файла (страница 15)
Поэтому, для того чтобы построить эффективную базу данных и ес приложения, команда разработчиков должна ясно представить себе пользовательскую модель. Для этого команда строит модель данных, идснтифипнрующую объекты, которые должны храниться в базе данных, и определяет их структуру и связи между ними. Это понимание должно быть достигнуто на ранней стадии процесса разработки пугем опроса пользователей и составления технического задания (этагешсп1 о1 гег)п1гевепгэ). Большинство таких технических заданий включают использование прототипов (ргосогуреэ) — шаблонных баз данных и приложений, представляющих различные аспекты создаваемой системы.
Есть две обгцих стратегии разработки баз данных: сверху вниз и снизу вверх. Разработка сверхп вниз (гор-г)ожп дагаЬазе йеуе1оршепг) идет от общего к частному. Она начинается с изучения стратегических целей организации, способов, при помощи которых эти цели могут быть достигнуты, требований к информации, которые должны быть удовлетворены для достижения этих целей, и систем, необходимых для предоставления такой информации.
Результатом такого исследования является абстрактная модель данных. Отгалкпваясь от этой общей модели, команда разработчиков двигается «вниз», к все более и более подробным описаниям и моделям. Модели промежуточного уровня также постоянно детализируются, пока не воплотятся в конкретные базы данных и нх приложения. Одно пли более из этих приложений берется затем в разработку. В конце концов вся высокоуровневая модель данных трансформируется в низкоуровневые модели, после чего реализуются все указанные системы, базы данных и приложения. При разработке снизу вверх (Ьоггопыпр дагаЬазе г1еуе!ортспг) уровень абстракции меняется в обратном направлении: исходным пунктом является необходимость в конкретной системе. Способ выбора первой системы варьируется от организации к организации.
В одних организациях приложение выбирается правлением, в других пользователи могут выбирать его самостоятельно, в третьих побеждает мнение того, кто в администрации громче всех кричит. Так или иначе, для разработки выбирается конкретная система, Команда разработчиков затем составляет техническое задание, рассматривая выходы и входы существующих компьютерных систем, анализируя формы и отчеты, используемые в существующих системах с ручной записью, и опрашивая пользователей с целью определения их потребностей в новых отчетах, формах и запросах, а также других требований.
Исходя из этого всего, команда программистов разрабатывает информационную систему. Если система включает в себя базу данных, команда на основании технического задания строит модель данных, а имея модель данных, оца проектирует и реализует базу данных. Когда создание данной системы завершается, запускаются другие проекты, целью которых являешься построение дополнительных информационных систем. Сторонники разработки сверху вниз утверждают, что этот подход имеет преимущество перед разработкой снизу вверх, поскольку модели данных (и соответствующие им системы) строятся с глобальной перспективой. Они считают, что такие системы гораздо лучше взаимодействуют между собой, являются более согласованными и требуют намного меньше переделок. Сторонники разработки снизу вверх говорят, что такой подход рабо~ает быстрее и сопряжен с меньшим риском. Они утверждают, что моделирование сверху вниз выливается в большое количество трудновыполнимых исследований и что процесс планирования часто заходит в тупик.
Хотя моделирование снизу вверх не обязательно имеет своим результатом оптимальный набор систем, тем пе менее, с его помощью можно быстро создать работающую систему. Такие системы начинают давать прибыль гораздо быстрее, чем системы, смоделированные сверху вниз, и ато более чем компенсирует любые переделки и модификации, которые придется сделать, чтобы настроить систему на глобальную перспективу. В этой книге описываются средства и способы, которые можно использовать при любом стиле системной разработки. Например, хотя и модель «су)цпость — связь» (глава 3), и семантическая объектная модель (глава 4) работают при разработке как сверху вниз, так и снизу вверх, модель «сущность — связь» более эффективна при разработке сверху вниз, а семантическая объектная модель — при разработке снизу вверх.
Моделирование данных !<ак уже говорилось, наиболее важная цель на стадии разработки технического задания — это создание модели данных пользователя (цзег пата 1посе!), илп моделирование данных (дага шодейпй). Как бы это нн делалось — сверху вниз или Список заказов продавца 03 октября 2001 Имя Кек1п Ооиянегту Западный $2,349,88 $2,349,88 $23,445,00 $17,339,44 Саоо Сап!го14 9/1 2/2001 Западный вагу в ууо А/ах Е!ес!пс Агпепсап Махе11 9/1 7/2001 9/24/2001 $40,784,44 Общая сумма. $43,134,32 Отчего комиссионных продавца 03 октября 2001 КеМп Ооиопе ту 2З2-9988 9/30/2001 $487,38 $487,38 $237,44 $1,785,39 Магу В. Учо 232-9987 9/30/2001 9/ЗО/2001 С А $2,022,83 Общая сумма: $2,510,21 74 Глава 2. Введение в разработку баз данных снизу вверх, — это включает в себя опрос пользователей, документирование требований н построение модели данных и прототипов на основе этих требований.
Такая модель показывает, какие объекты должны храниться в базе ланных, и опрелеляет их структуру и связи между ними. Рассмотрим, например, рпс. 2.13, и — список заказов, выполненных продавцом за опрелеленный период времени. Чтобы приложение базы данных могло выдать такой отчет, база данных лолжна содержать информацию, представленную в этом отчете, поэтому разработчики базы данных должны исследовать этот отчет и на его основании определить, какие данные должны хра/ппься в базе. В нашем случае должны быть данные о продавцах (пмя и регион) и данные о заказах (компания, дата заказа и количество товара).
Разработка баз данных осложняется тем, что требований может быть несколько и они обычно перекрываются. Отчет на рпс. 2.13, 6 также содержит ланные о продавцах, но вместо заказов вием перечислены комиссионные. Глядя ца этот отчет, мы можем предположить, что существуют различные типы заказов и для каждого из них определен свой процент комиссионных. Регион НазеаниеКомпании Датазаказа Сумма Имя МестныйНОмер Датаныпискичека ТипКомиссионных СуммаКомиссионных Рис. 2.13. Примеры двух связанных отчетов: а — отчет о продажах и б — отчет о комиссионных Процесс разработки базы данных 75 Заказы, перечисленные в отчете на рис. 2.13, б, какнм-то образом связаны с заказами, перечисленными на рис.
2.13, а, но каким именно, остается не слишком ясным. Команла разработчиков должна определить эти связи, лелая выводы из отчетов и форм, интервьюируя пользователей, !/спользуя собственные знания по данному вопросу и лругпе источники. Моделирование данных как делание выводов Когда пользователи говорят, что им нужны формы и отчеты с определенными данными и структурами, это подразумевает, что у них в голове имеется некая модель, прелставляюшая вещи в их мире. Однако пользователи могут быть нс в состоянии точно описать эту т/опель. Если бы разработчик спросил типичного пользователя: «Как вы себе прелставляете структуру модели данных, касающихся пролавцов? сч то мпр пользователя выглядел бы по меньшей мере загадочным, поскольку большинство пользователей не мыслят такими категориями.
Вместо того чтобы задавать подобные вопросы. разработчики лолжны из высказываний пользователя о формах и отчетах делать выволы о структуре и связях объектов, которые должны храниться в базе данных. Затем разработчики воплощают эти выводы в модели ланных, которая трансформируется в проект базы данных, который, в свою очередь, реализуется при помощи СУБД. Затем конструируются приложения, генерирую/цие отчеты н формы для пользователей. Таким образом, построение модели данных — это процесс делания предположений. Отчеты н формы напоминают тени на стене.
Пользователи могут описать тени, но пе могут описать формы тел, отбрасывающих эти тени. Поэтому разработчикам приходится лелать предположения, решать обратную задачу, и реконструировать из этих теней структуры и связи. Этот процесс является, к сожалению, в большей степени искусством, чем наукой. Можно изучить все средства и способы молелирования данных (фактически эти срелства и способы являются прелметом разговора в слелующих двух главах), но их использование представляет собой искусство, которое требует опыта, направляемого интуицией. Качество модели является важным аспектом. Если документированная модель ланных алекватно отображает модель данных, присутствующую в воображении цользова!еля, есть отличный и!анс, что разработанные на ее основании приложения будут отвечать потребностям пользователей.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
