Физическое проектирование базы данных

Размещено на http://www.allbest.ru/

2

БАЛАКОВСКИЙ ИНЖЕНЕРНО-ТЕХНОЛОГИЧЕСКИЙ ИНСТИТУТ - ФИЛИАЛ ФЕДЕРАЛЬНОГО ГОСУДАРСТВЕННОГО АВТОНОМНОГО ОБРАЗОВАТЕЛЬНОГО УЧРЕЖДЕНИЯ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ЯДЕРНЫЙ УНИВЕРСИТЕТ (МИФИ)»

РЕФЕРАТ

ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

Выполнил: Каргин В.А.

Ст. гр. ИФСТ-21

Проверила: Виштак Н.М.

Балаково 2015



Оглавление

операционный данные пользовательский система

Введение

Проектирование основных отношений

Разработка способов получения производных данных

Анализ транзакций

Определение индексов

Проектирование пользовательских представлений

Обоснование необходимости введения контролируемой избыточности

Текущий контроль и настройка операционной системы

Заключение

Список используемых источников



Введение

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

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

В случае реляционной модели данных под этим подразумевается следующее:

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

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

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

- Они связаны с совершенно разными аспектами системы, поскольку отвечают на вопрос, что делать, а не как делать.

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

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

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

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

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

- Управление данными на жёстком диске.

- управление данными в оперативной памяти с использованием кэша;

- протокол изменений, восстановление базы данных после сбоев;

- поддержка языков БД (язык определения данных, язык манипулирования данными).

Обычно современная СУБД содержит следующие компоненты:

- Ядро, которое отвечает за управление данными во внешней и оперативной памяти и протоколирование.

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

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

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

Рисунок 1



Проектирование основных отношений

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

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

- имя отношения;

- список простых атрибутов, заключенный в круглые скобки;

- определение первичного ключа и (если таковые существуют) альтернативных (АК) и внешних (FK) ключей;

- список производных атрибутов и описание способов их вычисления; - определение требований ссылочной целостности для любых внешних ключей.

Для каждого атрибута в словаре данных должна присутствовать следующая информация:

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

- принимаемое по умолчанию значение атрибута (необязательно);

- допустимость значения NULL для данного атрибута.



Разработка способов получения производных данных

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

Например, производными являются все перечисленные ниже атрибуты:

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

- количество общежитий, выделенных для данного факультета.

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

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

- дополнительные затраты на хранение производных данных и поддержание их согласованности с реальными данными, на основе которых они вычисляются;

- затраты на вычисление производных данных, если их вычисление выполняется по мере необходимости.

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

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

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

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

Анализ транзакций

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

- транзакции, выполняемые наиболее часто и оказывающие существенное влияние на производительность;

- транзакции, наиболее важные для работы организации;

- периоды времени на протяжении суток/недель, в которые нагрузка базы данных возрастает до максимума (называемые периодами пиковой нагрузки).

Эта информация используется для определения компонентов базы данных, которые могут вызвать проблемы производительности. Кроме того, необходимо определить такие характеристики транзакций высокого уровня, как атрибуты, модифицируемые в транзакциях обновления, или критерии, которые служат для ограничения количества строк, возвращаемых по запросу. Эта информация используется для определения наиболее подходящей файловой организации и создания индексов. Во многих случаях проанализировать все ожидаемые транзакции просто невозможно, поэтому необходимо тем или иным образом выбрать наиболее "важные" из них (это слово взято в кавычки, потому что критерии выбора чаще всего являются субъективными). Существует эмпирическое правило, согласно которому выполнение около 20% наиболее активных запросов пользователей создает примерно 80% общей нагрузки на базу данных [325]. Это правило "80/20" может использоваться как рекомендация по проведению анализа. Для определения того, какие из транзакций подлежат детальному анализу, воспользуемся таблицей соответствия транзакций и отношений, в которой показаны отношения, доступ к которым происходит при выполнении каждой транзакции, а также диаграммой частоты выполнения транзакций, которая схематически показывает отношения, вероятность использования которых в транзакциях наиболее высока. Для выделения областей, которые с наибольшей вероятностью могут явиться источником проблем, необходимо выполнить перечисленные ниже действия.

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

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

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

Определение индексов

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

Если вы поняли, какая польза от применения индексов в структуре базы данных, у вас может возникнуть вопрос: если наличие индексов значительно ускоряет поиск, почему бы не создать индексы для каждого поля каждой таблицы? Ответ прост: индексы -- это не только плюс, но и минус. При увеличении количества индексов физически увеличивается размер базы данных, а значит, и объем занимаемой памяти и дискового пространства, в результате чего компьютер работает медленнее. В этом случае польза от применения индексов сводится к нулю. Не существует жесткого правила насчет оптимального количества индексов для каждой таблицы, но основная рекомендация состоит в создании индексов только по таким полям, которые, по вашему мнению, будут чаще всего использованы в запросах. (За дополнительной информацией о том, как использовать содержимое поля в качестве критерия запроса для выборки наборов записей, обращайтесь к главе 2, "Запросы и команды на языке SQL".)

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

Каждая создаваемая вами таблица должна иметь по крайней мере один первичный ключ и должна быть проиндексирована по тем полям, которые чаще всего будут участвовать в запросах. В случае с таблицей tbl:, как и с многими другими таблицами баз данных, первичный ключ создается по полю ID. (В предыдущем разделе это поле уже было определено как первичное.) Вторичными индексами могут быть поля FirstName и LastName.

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

1. Щелкните правой кнопкой мыши на окне с определением таблицы tblCustomer в окне компонента Server Explorer и выберите в контекстном меню команду Indexes/Keys.

2. После этого на экране появится страница свойств со списком существующих индексов, в котором уже присутствует индекс первичного ключа PK_tblCustomer. Щелкните на кнопке New (Создать) для создания нового индекса для поля FirstName.

3. В списке полей выберите поле FirstName, как показано на рис. 1.3, а затем щелкните на кнопке Close.

4. Повторите действия из пп. 1-3, чтобы создать индекс для поля FirstName



Проектирование пользовательских представлений

Представление - наиболее ресурсоёмкая часть “движка” базы данных. Это очень заметно при первом открытии представления. Время открытия представления значительно. Зато уже следующее открытие происходит моментально. Это связано с технологией работы представления, в основе которой - две ступени

Первый этап - вычисления, связанные с построением и поддержкой актуальности индекса представления, второй - вычисления, связанные с показом представления пользователю

Можно упомянуть ещё предварительный этап, связанный с включением свойства базы Optimize document table map. Эта таблица содержит список документов исходя из их формы (поля Form), что с одной стороны делает более эффективным отбор документов в представления, использующие в формуле отбора имя формы, с другой стороны, возникают трудности в поддержке представлений в приложениях, оперирующих сменой форм документов

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

Следовательно, на объём индекса представления оказывает сильное влияние задание группировки, вычисления итогов столбцов, организация доступа на уровне документа

Кроме того, задание альтернативной сортировки (сортировки по щелчку на заголовке столбца) заставляет строить и “альтернативный” индекс, увеличивая объём индекса в разы

Поддержка индекса на сервере осуществляется задачей Indexer, представленной в двух ипостасях: Update и UpdAll

Задача Update входит в список задач, запускаемых в момент старта сервера (переменная notes.ini ServerTasks) и работающих, пока работает сервер. Задача поддерживает актуальность индексов представлений и полнотекстовых индексов баз данных, отслеживая событие изменения документов. При этом изменение индекса представления происходит за какой-то гарантированный промежуток времени. Обработка документа заключается в вычислении формул столбцов документа, хранящихся в индексе, определении позиции документа относительно других документов в соответствии с заданными параметрами сортировки, группировки, вычислению итоговых результатов

Задача Updall запускается в соответствии с расписанием (переменная notes.ini ServerTasksAt<hour>) или вручную с консоли сервера и обрабатывает индексы представлений и полнотекстовые индексы баз в соответствии с параметрами запуска задачи. После выполнения задания задача выгружается

Второй этап. Вычисления при показе представления пользователю

Две задачи вычислений, решаемые при визуализации представления: актуализация индекса представления и ограничение доступа к документам, защищённым на просмотр данным пользователем

Первая задача решается путём форсированной обработки Indexer'ом (задачей Update) индекса представления по изменённым документам (ранее указывалось, что задача обрабатывает изменения в гарантированный период времени, но пользователь должен получить актуальные данные немедленно)

Более детального описания заслуживает механизм вычислений доступа к документам, ограниченным механизмом Notes на основе полей READERS. Программное обеспечение клиента Lotus Notes запрашивает сервер на получение данных представления. Сервер получает фрагмент индекса, отфильтровывает документы на основе информации о доступе и передаёт данные клиенту Notes. Клиент Notes отслеживает интерфейсную наполненность экрана представления (таким образом, чтобы данные представления заполняли весь экран и был ещё избыток данных на случай незначительной навигации в пределах представления - перемещения вверхвниз в пределах нескольких позиций не требовали нового запроса к серверу). Если экран не заполнен до конца - следует запрос к серверу за новой порцией данных. Вычисления доступа могут привести к увеличению времени открытия/навигации по представлению для пользователей, имеющих существенные ограничения в доступе к документам в базе. Это следует учитывать при проектировании представлений в базах, содержащих большое количество документов.

Обоснование необходимости избыточности

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

• денормализация может усложнить физическую реализацию системы;

• денормализация часто приводит к снижению гибкости;

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

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

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

Если говорить конкретнее, на этом этапе рассматривается возможность дублирования отдельных атрибутов или объединения нескольких отношений в одну таблицу с целью сокращения числа запросов на соединение отношений. На самом деле мы уже встречались с неявным случаем денормализации, когда рассматривали атрибуты адреса. Например, рассмотрим определение отношения Branch, представляющее список отделений компании: Branch(branchNo,street,city,postcode,mgrStaffNo) Это отношение, строго говоря, не находится в третьей нормальной форме: атрибут city (город) функционально определяется атрибутом postcode (почтовый индекс). Иными словами, мы можем определить значение атрибута city, зная значение атрибута postcode. Таким образом, отношение Branch находится лишь во второй нормальной форме.

Чтобы привести это отношение к третьей нормальной форме, его пришлось бы разбить на два отношения: Branch (branchNo,street, postcode, mgrStaffNo) Branch(postcode, city) Однако адрес отделения редко требуется без атрибута city, т.е. без указания города. Это означает, что после такого разделения таблиц придется формировать соединение (и выполнять соответствующий запрос) каждый раз, когда потребуется получить полный адрес. Учитывая это, можно остановиться на второй нормальной форме и реализовать в базе данных первоначальный вариант отношения Branch. К сожалению, нельзя сформулировать общие правила определения того, когда действительно требуется денормализация отношений.

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

1. Объединение таблиц со связями типа "один к одному" (1:1).

2. Дублирование неключевых атрибутов в связях "один ко многим" (1:*) для уменьшения количества соединений.

3. Дублирование атрибутов внешнего ключа в связях "один ко многим" (1:*) для уменьшения количества соединений.

4. Дублирование атрибутов в связях "многие ко многим" (1:*) для уменьшения количества соединений.

5. Введение повторяющихся групп полей.

6. Объединение справочных таблиц с базовыми таблицами.

7. Создание таблиц из данных, содержащихся в других таблицах.

Текущий контроль и настройка операционной системы

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

- настройка системы позволяет устранить потребность в дополнительном оборудовании;

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

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

- сокращение времени ответа на запрос улучшает психологическое состояние персонала;

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

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

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

1. Возможность хранения в базе данных фотографий арендуемых объектов недвижимости, а также кратких комментариев, описывающих главные характеристики предлагаемого объекта. Если мы работаем с СУБД Microsoft Access, то можем удовлетворить это требование, используя для хранения фотографии поле OLE. Объекты OLE (Object Linking and Embedding -- связывание и внедрение объектов) используются для хранения данных, которые создаются и обрабатываются другими приложениями; к этим объектам относятся документы Microsoft Word и Microsoft Excel, рисунки (в частности, сканированные фотографии), звуковые файлы и многое другое. Объекты OLE могут быть связаны или внедрены в поле таблицы Microsoft Access, а затем отображены в форме или отчете. Для реализации этого нового требования изменим структуру таблицы PropertyForRent, добавив к ней два поля: поле picture типа OLE и поле comments типа Memo (поля этого типа позволяют хранить длинный текст).

На рисунке 2 представлена соответствующая форма, включающая некоторые поля таблицы PropertyForRent, в том числе и два новых поля -- picture и comments. Поле picture содержит графическое изображение объектов недвижимости, сдаваемых в аренду, которое создано путем сканирования фотографий арендуемых объектов недвижимости и сохранения полученных изображений в виде графических файлов BMP (сокращение от Bit Map -- битовое изображение). Впрочем, главная проблема при хранении графических изображений связана с увеличением объема дискового пространства, требуемого для хранения файлов изображений. Поэтому необходимо проверить показатели производительности базы DreamHome и убедиться в том, что, удовлетворив новое требование, мы не нарушили требований, предъявляемых к производительности системы.

2. Возможность публиковать в World Wide Web (WWW, или Web) отчет с описанием арендуемого объекта недвижимости. Это требование можно удовлетворить при работе как в Microsoft Access, так и в Oracle, поскольку обе СУБД предоставляют набор средств для разработки Webприложений и публикации данных в сети Internet. Впрочем, чтобы использовать эти средства, необходимо иметь Web-броузер, например

3. Методология -- контроль и настройка работающей системы 615

Newly docotaled Ihrourfraut. WeB equipped kitchen. Close to local amenities



Размещено на http://www.allbest.ru/

2

Рис 2 Форма, базирующаяся на таблице PropertyForRent сновыми полями picture и comments



Заключение

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



Список используемых источников

1) Коннолли, Томас, Бегг, Каролин. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание.: Пер. с англ. М.: Издательский дом "Вильяме", 2003. 1440 с.: ил.

2) http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%B4%D0%B5%D0 %BA%D1%81_(%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D 0%BD%D0%BD%D1%8B%D1%8.

3)http://ru.wikipedia.org/wiki/%D0%A5%D0%B5%D1%88- %D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F.

Размещено на Allbest.ru

...