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

метки: Данные, Проблема, Запись, Проектирование, Система, Модель, Представление, Помощь

^

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

структур данных

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

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

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

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

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

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

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

^

Данные

с однопользовательской

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

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

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

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

менеджер базы данных

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

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

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

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

прикладные программисты

конечные пользователи

администраторы базы данных

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

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

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

В общих чертах они представляют собой следующее.

^

^

^

Рис. 2 Три уровня архитектуры ANSI/SPARC

индивидуальными

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

Конечно, этот пример полностью гипотетичен и мало похож на реальные сис­темы, поскольку в нем умышленно опущены многие не относящиеся к делу детали.

^

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

• На концептуальном уровне база данных содержит информацию о типе сущности с именем 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.

Базы данных и системы управления базами данных

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

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

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

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

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

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

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

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

подъязык данных, т.е.

сильно связанными.

языка определения данных

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

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

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

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

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

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

внешней схемы,

^

1.2.2 Концептуальный уровень, Концептуальное представление

концептуальных записей.

концептуальной схе­мы,

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

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

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

^

внутренней схемы,

утилитами

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

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

неизбыточного дублирования

С_Т

Сотрудник	Телефон
Иванов	3721
Петров	4328
Сидоров	4328
Егоров	4328

^

избыточного дублирования (избыточности)

С_Т_Н

Сотрудник	Телефон	Н_комн
Иванов	3721	109
Петров	4328	111
Сидоров	4328	111
Егоров	4328	111

а)

С_Т_Н

Сотрудник	Телефон	Н_комн
Иванов	3721	109
Петров	4328	111
Сидоров	—	111
Егоров	—	111

б)

Т_Н

Телефон	Н_комн
3721	109
4328	111

С_Н

Сотрудник	Н_комн
Иванов	109
Петров	111
Сидоров	111
Егоров	111

^

Процедура декомпозиции отношения С_Т_Н на два отношения С_Н и Н_Т явля­ется основной процедурой нормализации отношений.

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

Аномалиями

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

^

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

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

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

^

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

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

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

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

^

^

Достоинством

клиент-сервер

достоинства:

^

недостатком

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

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

^

Рис. 10. Системы, поставляющие информацию

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

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

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

^ Internet

доступа к БД на стороне сервера

Достоинством

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

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

на стороне клиента

Достоинством

Во второй модели клиентская часть системы оказывается сложнее, чем в первой. Это усложняет навигатор, но в то же время разгружает 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, был пересен на , то нужно будет писать конвертор из одной базы в другую.

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

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

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

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

Система должна обладать возможностью изменять свои свойства за счёт изменения своей структуры.

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

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

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

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

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

4 Модели

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

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

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

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

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

^

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

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

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

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

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

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

достоинствам

Недостатком

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

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

^

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

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

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

Достоинством, Недостатком

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

предложена сотрудником фирмы IBM Эдгаром Код-дом и основывается на понятии отношение (relation).

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

Таблица имеет строки (записи) и столбцы (колонки).

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

связывание

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

Достоинство

недостатками

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

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

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

ассоциацией.

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

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

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

Достоинством, Недостатком

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

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

Многомерные СУБД, Агрегируемостъ, Историчность, Прогнозируемость

достоинством

Недостатком

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

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

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

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

^

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

Инкапсуляция, Наследование,, Полиморфизм

достоинством

Недостатками, Заключение

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

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

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

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

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

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

[Электронный ресурс]//URL: https://litfac.ru/referat/problemyi-proektirovaniya-baz-dannyih/

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

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

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

---

---