Программирование >>  Разработка пользовательского интерфейса 

1 ... 3 4 5 [ 6 ] 7 8 9 ... 147


ОGbSfa КЛИЕНТ

УНИКАЛЬНЫЙ КЛЮЧ

НАИМЕНОВАНИЕ КЛИЕНТА

Хитрая лиса

Злой волк

Проме-гкуточный объект

КЛЮЧ КЛИЕНТА

КЛЮЧ ПРОДАВЦА

\

Объент ПРОДАВЕЦ

УНИКАЛЬНЫЙ КЛЮЧ ПРОДАВЦА

ИМЯ ПРОДАВЦА Карина

Лена

Рис. 2.6.

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

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

Взаимосвязь один к одному (между двумя атрибутами)

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

Взаимосвязь один ко многим (между двумя атрибутами)

Имя клиента и его номер существуют совместно. Клиентов с одинаковыми именами может быть много, но все они имеют различные номера. Каждому клиенту присваивается уникальный номер. Это означает, что данному номеру клиента соответствует только одно имя. Взаимосвязь один ко многим обозначается одинарной стрелкой в направлении к одному и двойной стрелкой в направлении ко многим (рис. 2.7,б).

Взаимосвязь многие ко многим (между двумя атрибутами)

Несколько клиентов с одинаковыми именами могли быть обслужены несколькими продавцами. Несколько продавцов с одинаковыми именами могли полу-чить заказы от нескольких клиентов.



Между атрибутами имя клиента и имя продавца существует взаимосвязь многие Мы обозначаем эту взаимосвязь двойными стрелками (рис. 2.7,в).

ко многим .

Типы моделей данных

Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.

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

На рис. 2.8 узлы и ветви образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих объект. Наивысший в иерархии узел называется корневым (это главный тип объекта). Корневой узел находится на первом уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и т. д. уровнях

Уровень 1

Уровень 2

Уровень Z

I I I

i i i



г л г -

Рис. 2.8.

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




У i

/ \

/ \ / \



Рис. 2.9.

2.2. Проектирование базы данных

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

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

В этом параграфе мы изучим:

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

принципы нормализации данных;

основные требования к реализации физической модели.

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

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

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

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

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

База данных должна легко расширяться при реорганизации и расширении предметной области.

База данных должна легко изменяться при изменении программной и аппаратной среды.

Загруженные в базу данных корректные данные должны оставаться корректными.

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

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

Этапы проектирования базы данных с учетом рассмотренных выше аспектов представлены на рис. 2.11.



1 ... 3 4 5 [ 6 ] 7 8 9 ... 147

© 2006 - 2024 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика