Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

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


Реферат - Проблемы проектирования базы данных: концептуальная, логическая и физическая модели
скачать (1689.5 kb.)

Доступные файлы (1):

1.doc1690kb.15.12.2011 07:15скачать

содержание

1.doc

Уфимский государственный авиационный технический университет
Кафедра ТК
Реферат

Тема: «Проблемы проектирования базы данных: концептуальная, логическая и физическая модели».

Выполнил студент гр. РС – 313

Голенастов И.В.

Проверил:

УФА-2004г.
Содержание

Введение 3

1 Объект исследования как система 3

1.1 Система баз данных 3

1.2 Структура системы баз данных 6

1.2.1 Внешний уровень 8

1.2.2 Концептуальный уровень 10

1.2.3 Внутренний уровень 11

1.3 Избыточное дублирование данных и аномалии 12

1.4 Базы данных в Internet и intranet 15

2 Общие системные принципы 18

2.1 Принцип декомпозиции 18

2.2 Принцип оперативного принятия решения 18

2.3 Принцип согласованности 19

2.4 Принцип совместимости (достижимости) 19

2.5 Принцип реализуемости 19

2.6 Принцип типизации и стандартизации 19

2.7 Принцип самоорганизации (гибкости) 19

3 Проблемы управления базой данных 20

4 Модели 20

4.1. Иерархическая модель 20

4.2. Сетевая модель 21

4.3. Реляционная модель 22

4.4. Постреляционная модель 22

4.5. Многомерная модель 23

4.6. Объектно-ориентированная модель 24

Заключение 25

Список использованной литературы 27

Введение

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

^ Логическое проектирование заключается в определении числа и структуры таблиц, формировании запросов к БД, определении типов отчетных документов, разработке алгоритмов обработки информации, создании форм для ввода и редактирования дан­ных в базе и решении ряда других задач.

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

При проектировании структур данных для автоматизированных систем можно выделить три основных подхода:

1. Сбор информации об объектах решаемой задачи в рамках одной таблицы (одно­го отношения) и последующая декомпозиция ее на несколько взаимосвязанных таб­лиц на основе процедуры нормализации отношений.

2. Формулирование знаний о системе (определение типов исходных данных и их взаимосвязей) и требований к обработке данных, получение с помощью CASE-систе-мы (системы автоматизации проектирования и разработки баз данных) готовой схе­мы БД или даже готовой прикладной информационной системы.

3. Структурирование информации для использования в информационной сис­теме в процессе проведения системного анализа на основе совокупности правил и рекомендаций.

1 Объект исследования как система
1.1 Система баз данных

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

На рис. 1 показана весьма упрошенная схема системы баз данных. Здесь отражено четыре главных компонента системы, а именно: данные, аппаратное обеспечение, программное обеспечение и пользователи. Каждый из этих компонентов кратко рас­сматривается ниже.


^ Рис. 1 Упрощенная схема системы баз данных

Данные

Системы с базами данных существуют как на самых малых компьютерах, так и на крупнейших мэйнфреймах. Нет необходимости говорить, что предоставляемые каждой конкретной системой средства в некоторой мере зависят от мощности и возможностей базовой машины. В частности, системы на больших машинах ("большие системы"), в основном, многопользовательские, тогда как системы на малых машинах ("малые сис­темы"), как правило, однопользовательские. Однопользовательская система (single-user system) — это система, в которой одновременно к базе данных может получить доступ не более одного пользователя, а многопользовательская система (multi-user system) — это такая система, в которой к базе данных могут получить доступ сразу не­сколько пользователей. Как и в схеме на рис. 1, исходя из соображений общности, мы обычно будем подразумевать именно второй вид систем, хотя, с точки зрения пользователей, между этими системами фактически не существует большого различия. Основная задача большинства многопользовательских систем— позволить каждому отдельному пользователю работать с ней так, как он мог бы работать с однопользовательской системой. Различия между этими двумя видами систем проявляются в их внутренней структуре, и потому практически не видны конечному пользователю (о чем речь пойдет ниже).

Аппаратное обеспечение

К аппаратному обеспечению системы относится следующее.

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

• Аппаратный процессор (или процессоры) вместе с основной (первичной) памя­тью, предназначенные для поддержки работы программного обеспечения системы баз данных.

Программное обеспечение

Между собственно физической базой данных (т.е. данными, которые реально хра­нятся) и пользователями системы располагается уровень программного обеспечения, который можно называть по-разному: менеджер базы данных (database manager), сервер базы данных (database server) или, что более привычно, система управления базами данных, СУБД (database management system — DBMS). Все запросы пользо­вателей на доступ к базе данных обрабатываются СУБД. Все имеющиеся средства до­бавления файлов (или таблиц), выборки и обновления данных в этих файлах или таб­лицах также предоставляет СУБД. Основная задача СУБД — предоставить пользова­телю базы данных возможность работать с ней, не вникая в детали на уровне аппа­ратного обеспечения. (Пользователь СУБД более отстранен от этих деталей, чем при­кладной программист, применяющий языковую среду программирования.) Иными словами, СУБД позволяет конечному пользователю рассматривать базу данных как объект более высокого уровня по сравнению с аппаратным обеспечением, а также предоставляет в его распоряжение набор операций, выражаемых в терминах языка вы­сокого уровня (например, набор операций, которые можно выполнять с помощью язы­ка SQL).

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

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

• Первая группа — прикладные программисты, которые отвечают за написание прикладных программ, использующих базу данных. Для этих целей применимы такие языки, как COBOL, PL/I, C++, Java или какой-нибудь высокоуровневый язык четвертого поколения. Прикладные программы получают доступ к базе данных посредством выдачи соответствующего запроса к СУБД (обычно это некоторый SQL-оператор).

• Вторая группа — конечные пользователи, которые работают с системой баз данных непосредственно через рабочую станцию или терминал. Конечный поль­зователь может получать доступ к базе данных, применяя одно из интерактивных приложений, упомянутых выше, или же интерфейс, интегрированный в про­граммное обеспечение самой СУБД. Безусловно, подобный интерфейс также под­держивается интерактивными приложениями, однако эти приложения не создают­ся пользователями-программистами, а являются встроенными в СУБД. Большин­ство СУБД включает по крайней мере одно такое встроенное приложение, а именно — процессор языка запросов, позволяющий пользователю в диалоговом режиме вводить запросы к базе данных (их часто иначе называют операторами (statement) или командами (commands)), например SELECT или INSERT. Язык SQL — типичный пример языка запросов базы данных.

• Третья группа — администраторы базы данных.
1.2 Структура системы баз данных

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

Архитектура ANSI/SPARC включает три уровня: внутренний, внешний и концепту­альный (рис. 2). В общих чертах они представляют собой следующее.

^ Внутренний уровень (также называемый физическим) наиболее близок к физи­ческому хранилищу информации, т.е. связан со способами сохранения информа­ции на физических устройствах.

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

^ Концептуальный уровень (также называемый общим логическим или просто ло­гическим) является "промежуточным" уровнем между двумя первыми.



Рис. 2 Три уровня архитектуры ANSI/SPARC
Если внешний уровень связан с индивидуальными представлениями пользователей, тс концептуальный уровень связан с обобщенным представлением пользователей. Иначе говоря, может существовать несколько внешних представлений, каждое из которых со­стоит из более или менее абстрактного представления определенной части базы данных и только одно концептуальное представление, состоящее из абстрактного представления базы данных в целом. (Вспомните, что большинство пользователей интересует не вся база данных, а лишь ее некоторая ограниченная часть.) Также существует единственное внутреннее представление, отражающее способ физического хранения всей базы данных

Для лучшего понимания этих идей рассмотрим пример, представленный на рис. 3. Здесь отображено концептуальное представление простой базы данных о персонале, а также соответствующие ему внутреннее и два внешних представления (одно — для поль­зователя, применяющего язык PL/I, а другое — для пользователя, применяющего язык COBOL). Конечно, этот пример полностью гипотетичен и мало похож на реальные сис­темы, поскольку в нем умышленно опущены многие не относящиеся к делу детали.



^ Рис. 3 Пример трех уровней представления базы данных
Рассматриваемый здесь пример нуждается в пояснениях.

  • На концептуальном уровне база данных содержит информацию о типе сущности с именем EMPLOYEE (служащий). Каждый экземпляр сущности EMPLOYEE включает атрибуты номера служащего EMPLOYEE_NUMBER (длиной шесть символов), номера отдела DEPARTMENT_NUMBER (длиной четыре символа) и зарплаты служащего SALARY (пять десятичных цифр).

  • На внутреннем уровне служащие представлены типом хранимой записи STORED_EMP, длина которой составляет 20 байт. Запись STORED_EMP содержит че­тыре хранимых поля: шестибайтовый префикс (возможно, содержащий управ­ляющую информацию, такую как флаги или указатели) и три поля данных, соот­ветствующие трем свойствам сущности, которая представляет служащего. Кроме того, записи STORED ЕМР индексированы по полю ЕМР# с помощью индекса ЕМРХ определение которого не показано.

  • Пользователь, применяющий язык PL/I, имеет дело с соответствующим внеш­ним представлением базы данных. В нем каждый сотрудник представлен за­писью на языке PL/I, содержащей два поля (номера отделов не представляют интереса для данного пользователя, поэтому в представлении они опущены). Тип записи определен с помощью обычной структуры, соответствующей пра­вилам языка PL/I.

  • Аналогично пользователь, применяющий язык COBOL, имеет дело с собст­венным внешним представлением базы данных, в котором каждый сотрудник представлен записью на языке COBOL, содержащей, опять же, два поля (в данном случае опущен размер оклада). Тип записи определен с помощью обычного описания на языке COBOL в соответствии с принятыми в нем стан­дартными правилами.

Нужно обратить внимание, что в каждом случае соответствующие элементы данных могут меть различные имена. Например, к номеру сотрудника обращаются, как к полю EMPt в представлении для языка PL/I и как к полю EMPNO в представлении для языка COBOL. Этот же атрибут в концептуальном представлении имеет имя EMPLOYEE_NUMBER, а во внутреннем представлении— имя ЕМР#. Конечно, системе должны быть известны все эти соответствия. Например, она должна знать, что поле EMPNO в представлении для языка COBOL образовано из концептуального поля EMPLOYEE NUMBER, которое, в свою очередь, отвечает хранимому полю ЕМР# во внутреннем представлении. Такие соответствия, или отображения, явно не показаны на рис. 3.

В данном случае не имеет особого значения, является ли рассматриваемая система реляционной или какой-нибудь иной.

1.2.1 Внешний уровень

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

У каждого пользователя есть свой язык общения.

  • Для прикладного программиста это либо один из распространенных языков программирования (например, PL/I, C++ или Java), либо специальный язык рассматриваемой системы. Такие оригинальные языки называют языками четвертого поколения на том (не вполне определенном!) основании, что машинный код, язык ассемблера и такие языки, как PL/I, можно считать языками трех первых "поколений", а оригинальные языки модернизированы по сравнению с языкам третьего поколения так же, как языки третьего поколения улучшены по сравнению с языком ассемблера.

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

Для нашего обсуждения важно, что все эти языки включают подъязык данных, т.е. подмножество операторов всего языка, связанное только с объектами баз дан­ных и операциями с ними. Иначе говоря, подъязык данных встроен в базовый язык, который дополнительно обеспечивает различные не связанные с базами дан­ных возможности (такие, как локальные (временные) переменные, вычислительные операции, логические операции и т.д.). Система может поддерживать любое количе­ство базовых языков и любое количество подъязыков данных. Однако существует один язык, который поддерживается практически всеми сегодняшними системами. Это язык SQL. Большинство систем по­зволяет использовать язык SQL и интерактивно, как самостоятельный язык запро­сов, и посредством внедрения его операторов в другие языки программирования, та­кие как PL/I и Java.

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

В принципе, любой подъязык данных является на самом деле комбинацией по крайней мере двух подчиненных языков — языка определения данных (data definition language — DDL), который поддерживает определения или объявления объектов базы данных, и языка обработки данных (data manipulation language — DML), который поддерживает операции с такими объектами или их обработку. На­пример, рассмотрим пользователя языка PL/I (см. рис. 3). Подъязык данных этого пользователя включает определенные средства языка PL/I, применяемые для орга­низации взаимодействия с СУБД.

  • Язык определения данных включает некоторые описательные структуры языка PL/I, необходимые для объявления объектов базы данных. Это сам оператор DECLARE (DCL), определенные типы данных языка PL/I, а также возможные специ­альные дополнения для языка PL/I, предназначенные для поддержки новых объек­тов, которые не поддерживаются существующей версией языка PL/I.

  • Язык обработки данных состоит из тех выполняемых операторов языка PL/I, ко­торые передают информацию в базу данных и из нее; опять же, возможно, вклю­чая новые специальные операторы.

Отдельного пользователя интересу­ет лишь некоторая часть всей базы данных. Кроме того, представление пользователя об этой части будет, безусловно, чем-то абстрактным по сравнению с выбранным способом физического хранения данных. В соответствии с терминологией ANSI/SPARC представление отдельного пользователя называется внешним пред­ставлением. Таким образом, внешнее представление— это содержимое базы данных, каким его видит определенный пользователь (т.е. для каждого пользователя знешнее представление и есть та база данных, с которой он работает). Например, пользователь из отдела кадров может рассматривать базу данных как набор записей с информацией об отделах плюс набор записей с информацией о служащих и ничего не знать о записях с информацией о материалах и их поставщиках, с которыми рабо­тают пользователи в отделе снабжения.

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

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


^ Рис. 4 Детальная схема архитектуры системы баз данных
1.2.2 Концептуальный уровень

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

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

Концептуальное представление определяется с помощью концептуальной схе­мы, включающей определения для каждого существующего типа концептуальных записей (см. рис. 3). Концептуальная схема использует другой язык определения данных — концептуальный. Чтобы добиться независимости данных, нельзя вклю­чать в определения концептуального языка какие-либо указания о структурах хране­ния или методах доступа. Определения концептуального языка должны относиться только к содержанию информации. Это означает, что в концептуальной схеме не должно быть никакого упоминания о представлении хранимого файла, упорядочен­ности хранимых записей, индексировании, хеш-адресации, указателях или других подробностях хранения данных или доступа к ним. Если концептуальная схема дей­ствительно обеспечивает независимость данных в этом смысле, то внешние схемы. определенные на основе концептуальной, заведомо будут обеспечивать независимость данных.

Концептуальное представление — это представление всего содержимого базы дан­ных, а концептуальная схема — это определение такого представления. Однако было бы ошибкой полагать, что концептуальная схема представляет собой не более чем на­бор определений, весьма напоминающих простые определения записей в программе на языке COBOL (или каком-либо другом языке). Определения в концептуальной схеме могут включать большое количество различных дополнительных аспектов обработки данных, например таких, как ограничения защиты или требования поддержки целост­ности данных. Более того, некоторые авторитетные специали­сты предлагают в качестве конечной цели создания концептуальной схемы описание всего предприятия — не только самих его данных, но и того, как эти данные исполь­зуются, как они перемещаются внутри предприятия, для чего используются в каждом конкретном месте, какая проверка и иные типы контроля применяются к ним в каждом отдельном случае и т.д. Однако необходимо подчеркнуть, что ни одна сегодняшняя система реально не поддерживает такого концептуального уровня, который хотя бы немного приблизился к указанной выше степени развитости. В большинстве суще­ствующих систем концептуальная схема в действительности представляет собой нечто, что лишь немного больше простого объединения всех независимых внешних схем с привлечением дополнительных средств безопасности и поддержкой правил обеспе­чения целостности. Вероятно, со временем системы будут гораздо "интеллектуальнее" в поддержке концептуального уровня.

1.2.3 Внутренний уровень

Третьим уровнем архитектуры является внутренний уровень. ^ Внутреннее представ­ление— это низкоуровневое представление всей базы данных как базы, состоящей из некоторого множества экземпляров каждого из существующих типов внутренних запи­сей. Термин "внутренняя запись" относится к терминологии ANSI/SPARC и означает конструкцию, иначе называемую хранимой записью (в дальнейшем мы будем использо­вать именно этот термин). Внутреннее представление, так же как внешнее и концепту­альное, отделено от физического уровня, поскольку в нем не рассматриваются физиче­ские записи, обычно называемые блоками или страницами, и физические области уст­ройства хранения, такие как цилиндры и дорожки. Другими словами, внутреннее пред­ставление предполагает наличие бесконечного линейного адресного пространства. Осо­бенности методов отображения этого адресного пространства на физические устройства хранения в значительной степени зависят от используемой операционной системы и по этой причине не включены в общую архитектуру.

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

В заключение отметим, что в некоторых исключительных ситуациях прикладные программы, в частности те, которые называются утилитами, могут выполнять операции непосредственно на внутреннем, а не на внешнем уровне. Конечно, использовать такую практику не реко­мендуется, поскольку она связана с определенным риском с точки зрения безопасно­сти (правила безопасности игнорируются) и сохранения целостности данных (правила целостности тоже игнорируются). К тому же такая программа будет зависеть от обра­батываемых данных. Однако иногда подобный подход может быть единственным спо­собом реализации требуемой функции или достижения необходимого быстродействия (так же, как пользователю языка высокого уровня иногда по тем же причинам необхо­димо прибегнуть к языку ассемблера).
1.3 Избыточное дублирование данных и аномалии
Следует различать простое (неизбыточное) и избыточное дублирование данных. Наличие первого из них допускается в базах данных, а избыточное дублирование дан­ных может приводить к проблемам при обработке данных. Приведем примеры обоих вариантов дублирования.

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

Сотрудник

Телефон

Иванов

3721

Петров

4328

Сидоров

4328

Егоров

4328

^ Рис. 5 Неизбыточное дублирование
Пример избыточного дублирования (избыточности) представляет приведенное на рис. 6а отношение С_Т_Н, которое, в отличие от отношения С_Т, дополнено атри­бутом Н_комн (номер комнаты сотрудника). Естественно предположить, что все слу­жащие в одной комнате имеют один и тот же телефон. Следовательно, в рассматрива­емом отношении имеется избыточное дублирование данных. Так, в связи с тем, что Сидоров и Егоров находятся в той же комнате, что и Петров, их номера можно узнать из кортежа со сведениями о Петрове.


С_Т_Н

Сотрудник

Телефон

Н_комн

Иванов

3721

109

Петров

4328

111

Сидоров

4328

111

Егоров

4328

111

а)

С_Т_Н

Сотрудник

Телефон

Н_комн

Иванов

3721

109

Петров

4328

111

Сидоров



111

Егоров



111

б)

^ Рис. 6 Избыточное дублирование
На рис. 6б приведен пример неудачного отношения С_Т_Н, в котором вместо телефонов Сидорова и Егорова поставлены прочерки (неопределенные значения). Неудачность подобного способа исключения избыточности заключается в следую­щем. Во-первых, при программировании придется потратить дополнительные уси­лия на создание механизма поиска информации для прочерков таблицы. Во-вторых, память все равно выделяется под атрибуты с прочерками, хотя дублирование данных н исключено. В-третьих, что особенно важно, при исключении из коллектива Петро­ва кортеж со сведениями о нем будет исключен из отношения, а значит уничтожена информация о телефоне 111-й комнаты, что недопустимо.

Возможный способ выхода из данной ситуации приведен на рис. 7. Здесь пока­заны два отношения С_Н и Н_Т, полученные путем декомпозиции исходного отно­шения С_Т_Н. Первое из них содержит информацию о номерах комнат, в которых располагаются сотрудники, а второе - информацию о номерах телефонов в каждой из комнат. Теперь, если Петрова и уволят из учреждения и, как следствие этого, удалят всякую информацию о нем из баз данных учреждения, это не приведет к утере инфор­мации о номере телефона в 111-й комнате.


Т_Н

Телефон

Н_комн

3721

109

4328

111



С_Н

Сотрудник

Н_комн

Иванов

109

Петров

111

Сидоров

111

Егоров

111




^ Рис. 7. Исключение избыточного дублирования
Процедура декомпозиции отношения С_Т_Н на два отношения С_Н и Н_Т явля­ется основной процедурой нормализации отношений.

Избыточное дублирование данных создает проблемы при обработке кортежей от­ношения, названные Э. Коддом «аномалиями обновления отношения». Он показал, что для некоторых отношений проблемы возникают при попытке удаления, добавле­ния или редактирования их кортежей.

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

Выделяют три основные вида аномалий: аномалии модификации (или редактиро­вания), аномалии удаления и аномалии добавления.

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

Так, например, изменение номера телефона в комнате 111 (рис. 6а), что пред­ставляет собой один единственный факт, потребует просмотра всей таблицы С_Т_Н и изменения поля Н_комн согласно текущему содержимому таблицы в записях, от­носящихся к Петрову, Сидорову и Егорову.

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

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

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

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

Вторым примером возникновения аномалии добавления может быть ситуация включения в таблицу нового сотрудника. При добавлении таких записей для исклю­чения противоречий желательно проверить номер телефона и соответствующий но­мер комнаты хотя бы с одним из сотрудников, сидящих с новым сотрудником в той же комнате. Если же окажется, что у нескольких сотрудников, сидящих в одной ком-пате, имеются разные телефоны, то вообще не ясно, что делать (то ли в комнате не­сколько телефонов, то ли какой-то из номеров ошибочный).
1.4 Базы данных в Internet и intranet

Технология intranet по существу представляет собой технологию Internet, перепе­сенную в среду корпоративных ИС. Архитектура информационных систем в Internet и intranet является результатом эволюционного перехода от первых многопользова­тельских централизованных вычислительных систем (мэйнфреймов) через системы типа клиент-сервер к распределенным системам с централизованной обработкой и подготовкой информации к непосредственному потреблению. Рассмотрим кратко ука­занные этапы эволюции.

^ 1. В мэйнфреймах (рис. 8) вычислительные ресурсы, хранимые данные и про­граммы обработки информации сконцентрированы в одной ЭВМ. Основным сред­ством доступа был алфавитно-цифровой терминал (дисплей), управляемый ЭВМ. Вся обработка информации и подготовка ее к выдаче выполнялись на центральной ЭВМ. С терминалов, как правило, в машину передавались коды нажатия клавиш или содер­жимое буфера экрана, а обратно на терминал — пересылались отображаемые экраны с соответствующими кодами управления отображением.



^ Рис. 8. Централизованная многопользовательская система
Достоинством системы является простота администрирования, защиты информа­ции и модификации системы, к недостаткам можно отнести высокую загрузку процес­соров и линий связи (как следствие — невысокую реакцию системы при большом коли­честве пользователей), низкую надежность (выход из строя ЭВМ приводит к полному отказу всей системы), сложность масштабирования системы и некоторые другие.

2. Исторически следующим решением в области информационных систем была архитектура клиент-сервер (рис. 9).

В этих системах место терминала заняла ПЭВМ, а мэйнфрейма — компьютер-сервер. Ранее мы рассматривали спектр моделей подобных систем с различным распределением функций между компонентами. Если не брать во внимание модель «распределенного пред­ставления» (по сути повторяет модель централизованной многопользовательской систе­мы), то можно заключить, что системы типа клиент-сервер имеют следующие достоинства: высокая живучесть и надежность, легкость масштабирования, качественный пользо­вательский интерфейс, возможность одновременной работы с несколькими приложени­ями, высокие характеристики оперативности обработки информации.



^ Рис. 9. Системы типа клиент-сервер
Основным недостатком клиент-серверных систем является то, что они ориенти­рованы на данные, а не на информацию. Это требует от пользователя знания не толь­ко предметной области, а и специфики используемой прикладной программы.

Существенным недостатком можно считать также сложность переноса таких сис­тем на другие компьютерные платформы и интеграцию с другими пакетами из-за «зак­рытости» используемых протоколов взаимодействия компонентов систем.

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

^ 3. Корпоративные системы intranet, в отличие от систем клиент-сервер, ориен­тированы не на данные, а на информацию в ее окончательном и пригодном для ис­пользования неквалифицированным пользователем виде (рис. 10).



Рис. 10. Системы, поставляющие информацию
Новые системы объединяют в себе преимущества централизованных многополь­зовательских систем и систем типа клиент-сервер. Им присущи следующие черты:

• на сервере порождается информация, пригодная для использования, а не дан­ные (например, в случае СУБД — записи БД);

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

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

В случае, когда источником информации в Internet и intranet являются БД, имеет место взаимодействие компонентов WWW и традиционных СУБД. Различают два сле­дующих варианта функционирования программного обеспечения WWW по доступу к БД: на стороне Web-сервера (рис. 11а) и на стороне Web-клиента (рис. 11б).


^ Рис. 11. Модели доступа к базе данных в Internet
В модели доступа к БД на стороне сервера обращение к серверу БД обычно про­изводится путем вызова программами Web-сервера внешних по отношению к ним про­грамм в соответствии с соглашениями одного из интерфейсов: CGI (Common Gateway Interface — общий шлюзовый интерфейс), FastCGI или API (Application Program Interface — интерфейс прикладного программирования).

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

• языковая зависимость — программа может быть написана только на языке, под­держиваемом данным API. Чаще всего это языки С и C++ (язык Perl, широко применяемый при написании CGI-скриптов, не применяется);

• слабая защита сервера от ошибок прикладных программ и от возможности не­санкционированного доступа к системным ресурсам, поскольку API-программа выполняется в адресном пространстве основного процесса сервера;

• программы, как правило, не переносимы на другие программно-аппаратные плат­формы, поскольку привязаны к интерфейсу и архитектуре сервера.

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

При доступе к БД на стороне клиента основным средством реализации механиз­мов взаимодействия Web-клиента и сервера БД является язык Java. Кроме того, может использоваться JavaScript, разработанный для расширения возможностей декла­ративного языка HTML (нет операторов присваивания, сравнения, математических функций и пр.) на основе добавления процедурных средств. Программы на языке JavaScript выполняются на компьютере Web-броузером в режиме интерпретации.

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

Во второй модели клиентская часть системы оказывается сложнее, чем в первой. Это усложняет навигатор, но в то же время разгружает Web-сервер.

В сравнительно недавно выпущенных программных продуктах фирмы Microsoft поддерживаются обе схемы. На стороне клиента (в среде Internet Explorer) существует возможность использовать динамический HTML, который реализуется на языке VBScript. Доступ к данным на стороне сервера осуществляется с помощью так называемых ASP-страниц (Active Server Pages — активные серверные страницы). ASP-страницы — это сценарии на языке VBScript, хранящиеся и выполняемые на Web-сервере (Internet Information Server).
2 Общие системные принципы
2.1 Принцип декомпозиции
Принцип заключается в расчленении системы по какому — либо признаку на составные части и наделению их собственными целями, функциями, согласно общим целям, функциям системы.

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

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

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

Например, если сайт используемый базу данных был размещён на сервере используемый СУБД MySQL, был пересен на Microsoft SQL Server, то нужно будет писать конвертор из одной базы в другую.
2.6 Принцип типизации и стандартизации
В проектируемой системе максимально должны использоваться стандартные типовые детали, что снижает ее себестоимость.

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

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

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

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

В иерархической модели связи между данными можно описать с помощью упоря­доченного графа (или дерева). Упрощенно представление связей между данными в иерархической модели показано на рис. 12.

Для описания структуры (схемы) иерархической БД на некотором языке програм­мирования используется тип данных «дерево».

Тип «дерево» схож с типами данных «структура» языков программирования ПЛ/1 и Си и «запись» языка Паскаль. В них допускается вложенность типов, каждый из которых находится на некотором уровне.



^ Рис. 12. Представление связей в иерархической модели
Тип «дерево» является составным. Он включает в себя подтипы («поддеревья»), каждый из которых, в свою очередь, является типом «дерево». Каждый из типов «де­рево» состоит из одного «корневого» типа и упорядоченного набора (возможно пустого) подчиненных типов. Каждый из элементарных типов, включенных в тип «дере­во», является простым или составным типом «запись». Простая «запись» состоит из одного типа, например, числового, а составная «запись» объединяет некоторую сово­купность типов, например, целое, строку символов и указатель (ссылку).

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

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

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

К достоинствам иерархической модели данных относятся эффективное исполь­зование памяти ЭВМ и неплохие показатели времени выполнения основных опера­ций над данными. Иерархическая модель данных удобна для работы с иерархически упорядоченной информацией.

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



^ Рис. 13. Представление связей в сетевой модели
Для описания схемы сетевой БД используется две группы типов: «запись» и «связь». Тип «связь» определяется для двух типов «запись»: предка и потомка. Пере­менные типа «связь» являются экземплярами связей.

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

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

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

Недостатком сетевой модели данных является высокая сложность и жесткость схемы БД, построенной на ее основе, а также сложность для понимания и выполне­ния обработки информации в БД обычным пользователем. Кроме того, в сетевой мо­дели данных ослаблен контроль целостности связей вследствие допустимости уста­новления произвольных связей между записями.
4.3. Реляционная модель
Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Код-дом и основывается на понятии отношение (relation).

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

Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам — атрибуты отношения.

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

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

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

Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерар­хических и сетевых связей.
4.4. Постреляционная модель

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

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

Помимо обеспечения вложенности полей постреляционная модель поддерживает ассоциированные многозначные поля (множественные группы). Совокупность ассо­циированных полей называется ассоциацией. При этом в строке первое значение од­ного столбца ассоциации соответствует первым значениям всех других столбцов ас­социации. Аналогичным образом связаны все вторые значения столбцов и т. д.

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

Поскольку постреляционная модель допускает хранение в таблицах ненормали­зованных данных, возникает проблема обеспечения целостности и непротиворечиво­сти данных. Эта проблема решается включением в СУБД механизмов, подобных хра­нимым процедурам в клиент-серверных системах.

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

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

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

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

Агрегируемостъ данных означает рассмотрение информации на различных уров­нях ее обобщения. В информационных системах степень детальности представления информации для пользователя зависит от его уровня: аналитик, пользователь-опера­тор, управляющий, руководитель.

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

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

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

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

Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стан­дартным типом (например, строковым — string) или типом, конструируемым пользо­вателем (определяется как class).

Значением свойства типа string является строка символов. Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов.



^ Рис. 14. Логическая структура БД библиотечного отдела

Рассмотрим кратко понятия инкапсуляции, наследования и полиморфизма при­менительно к объектно-ориентированной модели БД.

Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, если в объект типа КАТАЛОГ добавить свой­ство, задающее телефон автора книги и имеющее название телефон, то мы получим одноименные свойства у объектов АБОНЕНТ и КАТАЛОГ. Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано.

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа КНИГА, являющимся потомками объек­та типа КАТАЛОГ, можно приписать свойства объекта-родителя: isbn, удк, назва­ние и автор. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстракт­ное свойство типа abs. Так, определение абстрактных свойств билет и номер в объек­те БИБЛИОТЕКА приводит к наследованию этих свойств всеми дочерними объек­тами АБОНЕНТ, КНИГА и ВЫДАЧА. Не случайно поэтому значения свойства билет классов АБОНЕНТ и ВЫДАЧА, показанных на рисунке, будут одинаковы­ми - 00015.

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

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

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

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

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

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

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

Список использованной литературы

  1. Дейт, К., Дж. Введение в системы баз данных, 7-е издание. : Пер. с англ. — М. : Издательский дом "Вильяме", 2001. — 1072 с.

  2. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А.Д. Хомоненко. - СПб.: КОРОНА принт, 2000. - 416 с.

  3. Бекаревич Ю. Б., Пушкина Н. В. Microsoft® Access 2000. — СПб.: БХВ — Санкт-Петербург, 1999. — 480 с.






Скачать файл (1689.5 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации