15

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

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

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

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

Этапы проектирования баз данных

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

Процесс разработки БД можно разбить на несколько этапов:

•Исследование предметной области;

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

•Даталогическое проектирование;

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

•Проектирование на физическом уровне.

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

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

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

Основные элементы данной модели:

1.Описание объектов предметной области и связей между ними.

2.Описание информационных потребностей пользователей (описание основных запросов к БД).

3.Описание алгоритмических зависимостей между данными.

16

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

Языковые средства современных СУБД

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

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

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

Язык запросов (ЯЗ) позволяет выбирать данные из БД, агрегировать и подвергать всевозможной аналитической обработке.

Аналогично языку определения данных ЯМД не обязательно выступает в форме синтаксически самостоятельного языка СУБД. На практике разделение ЯОД и ЯМД играет скорее методическую роль или используется в технологических целях.

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

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

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

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

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

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

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

17

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

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

Логическое (даталогическое) проектирование – отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель – набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определённым формализованным правилам, а также нормализацию этих таблиц. Этот этап может быть в значительной степени автоматизирован.

Проектирование на физическом уровне

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

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

Средства и методы проектирование БД

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

При «восходящем» подходе осуществляют структурное проектирование снизу—вверх. Этотпроцессназываютсинтезом,попыткойполученияцелого(адекватноотображающегоописание предметной области) на основе описания составляющих его частей.

«Восходящее» проектирование – это достаточно сложная и устаревшая методика, которая подходит для проектирования только небольших баз данных.

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

Метод «нисходящего» проектирования достаточно формализован и используется в CASE (Computer Aided System /Software Engineering — компьютерное проектирование программного обеспечения и систем) средствах. Проведение тщательного анализа предметной области, выявление всех присущих ей классов объектов и связей между ними, правильное их отображение в ИЛМ предметной области, ведет к получению высоко нормализованной схемы логической структуры

18

реляционной БД.

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

CASE—средства классифицируются по методологиям проектирования (структурно— ориентированные, объектно—ориентированные, комплексно—ориентированные), по графическим нотациям построения диаграмм, по степени интегрированности (отдельные локальные средства, набор интегрированных средств, охватывающих большинство этапов разработки АИС), по режиму коллективной разработки проекта (режим реального времени, режим объединения проектов) и ряду других. Современный рынок программных средств насчитывает около 300 различных CASE − средств

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

Целостностью данных можно назвать механизм поддержания соответствия базы данных предметной области.

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

Целостность ссылок. Целостность сущностей.

Под целостностью понимают правильность данных в любой момент времени.

Данной цели можно достигнуть только в определенных пределах: СУБД не может выполнять контроль правильности каждого отдельного значения, которое вводится в базу данных (несмотря на то, что можно выполнить проверку каждого значения на правдоподобность). К примеру,невозможнопроверить,чтовведенноезначение7,котороепредставляетномерднянедели, на самом деле должно быть равным 4. Но значение 8 однозначно будет являться ошибочным и база данныхдолжнаотвергнутьтакоезначение.ВтакомслучаеСУБДнеобходимосообщить,чтономера дней недели должны выбираться из набора чисел (от 1 до 7).

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

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

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

Ограничения целостности делятся на 3 основные категории:

1Средства обеспечения доменной целостности - предназначены для недопущения ввода

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

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

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

Внешний ключ должен иметь значение, которое:

Равно значению первичного ключа характеризуемой (ассоциируемой) сущности;