Ершова Г.Н. Информационные технологии в книжном деле. Учебное пособие

Подождите немного. Документ загружается.

Поставщик

PK ИНН

Наименование

Адрес

Форма собственности

Контактное лицо

Телефон

Предложение

PK ИНН

PK Код товара

Атрикул поставщика

Отпускная цена

Товар

PK Код товара

Автор

Наименование

ISBN

Серия

Издательство

Год издания

Тип переплета

Тираж

Ставка НДС

Группа товара

PK Код группы

Наименование группы товара

Менеджер

PK Табельный номер

ФИО

Договор

PK Дата заключения договора

PK Номер договора

ИНН

Срок договора

Условия поставки

рис. 2 Пример диаграммы «сущность-связь».

Сущность не может иметь более одного значения каждого из ее атрибутов. Если

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

этого атрибута и с установлением связи типа «многие к одному» с первой сущностью.

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

объект или явление со своими собственными связями и атрибутами.

Например, если один или несколько поставщиков имеют несколько телефонов, то

атрибут телефон следует выделить в отдельную сущность «телефоны организации»,

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

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

телефон.

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

являются атрибуты, описывающие информацию о договоре с поставщиком. Если каждый

поставщик имеет один и только один договор с магазином, то информацию о договоре

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

поставщике. Однако, чаще всего с поставщиком заключается несколько договоров

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

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

выделить отдельную сущность и определить атрибуты, которые ее описывают.

Атрибуты делят на обязательные, которые должны быть известны всегда, и

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

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

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

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

Обязательным атрибутом сущности «поставщик» является его наименование, то

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

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

сообщение об ошибке и ввести необходимую информацию.

В сущности «менеджер» оба ее атрибута «табельный номер» и «Ф.И.О. менеджера»

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

его приема на работу и невозможно представить сотрудника, у которого отсутствовали

бы фамилия, имя и отчество.

Следует быть очень внимательным при проектировании обязательных атрибутов.

Поскольку добавление требования об обязательности того или иного атрибута должно

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

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

исключен.

Телефон, может быть необязательным атрибутом, например, если в организации

отсутствует телефон и связь с поставщиком осуществляется иными средствами. В таком

случае пользователь может не вносить в базу данных информацию о телефоне

поставщика.

Атрибуты характеризуются наименованием, описанием, форматом и длиной, а так

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

Например, атрибут «телефон» представляет собой строку текста длиной не более 7

символов. Тогда формат атрибута «телефон» может быть определен как: «строка текста

длиной 7 знаков». Атрибут «дата заключения договора» сущности «договор» может

содержать только данные типа «дата», тогда его формат можно определить как «дата».В

этом случае в качестве значения этого атрибута ввести информацию типа «24.24.2004»

будет не возможно, так как строка такого вида не может быть преобразована в дату.

Атрибут «ставка НДС» сущности «товар» может принимать, согласно российскому

законодательству, только значения «0» или «10» или «20», следовательно атрибут можно

описать как «целое число, принимающее значение 0, 10, 20». Ввести значение «15» в это

поле будет не возможно.

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

или схожие атрибуты, могут быть объединены в одну. В нашем примере мы это сделали

для сущностей поставщик, издатель, оптовое предприятие.

Каждая сущность должна быть уникально определена, то есть каждый

экземпляр сущности должен иметь ясное и недвусмысленное определение,

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

идентификатором может быть атрибут или комбинация атрибутов.

Иногда можно использовать естественные уникальные признаки объекта.

Например, ИНН (индивидуальный номер налогоплательщика) является уникальным

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

создании предприятия. «ИНН» можно использовать в качестве уникальной

идентификации организации. Добавим атрибут «ИНН» к сущности «поставщик».

Чаще всего необходимо придумывать уникальные идентификаторы

самостоятельно. Например, для уникальной идентификации товара в базе не всегда

можно использовать его атрибут «ISBN», поскольку некоторым видам печатных изданий

(музыкальная литература, малотиражные издания) его не присваивают. Чаще всего, для

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

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

новому экземпляру сущности.

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

идентификаторы каждой сущности, обозначаются буквами «РК» перед именем атрибута.

Заметим, что сущность может иметь несколько наборов уникальных

идентификаторов.

Связь (отношение) – это то, что объединяет несколько сущностей. Каждой связи

присваивается имя, которая описывает ее функцию. Именно связь определяет то, в каком

отношении находятся две сущности. Связь осуществляется с использованием атрибутов,

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

один-к-одному (1:1), один-ко-многим (1:N) и многие-ко-многим (М:N).

На диаграмме «сущность-связь» связи между сущностями обозначаются в виде

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

экземпляров, обычно рисуется, так называемая «лапка» (рис. 2).

При связи один-к-одному каждому экземпляру одной сущности соответствует не

более одного экземпляра другой. Этот вид связи встречается довольно редко.

Наиболее распространенный тип связи − один-ко-многим. При таком типе связи

каждому экземпляру одной сущности соответствует несколько экземпляров в другой

связанной сущности.

В нашем примере сущность «поставщик» и «договор» объединены связью типа

«один-ко-многим». В терминах информационной модели обозначает, что каждый

поставщик (экземпляр сущности «поставщик») может иметь один или несколько

договоров (экземпляров в сущности «договор»), которые относятся к этому поставщику.

А в терминах предметной области это обозначает, что с каждым поставщиком книжный

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

организована связь «один-к-одному», то это бы обозначало, что с каждым поставщиком в

базе данных договоров может быть связано не более одного договора. Общим полем для

сущности «поставщик» и «договор» является атрибут «ИНН поставщика», который

однозначно идентифицирует каждый экземпляр поставщика.

При использовании связи многие-ко-многим множеству экземпляров сущности в

одной таблице соответствует множество экземпляров в другой связанной сущности.

Например, каждый поставщик может поставлять в книжный магазин один или

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

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

друг с другом связью типа «многие-ко-многим».

Большинство современных СУБД непосредственно не поддерживают такой тип

связи. Для его реализации такая связь разбивается на две связи типа «один-ко-многим».

Соответственно для хранения информации потребуется уже три таблицы: две со стороны

«много» и одна со стороны «один». Связь между этими тремя таблицами также

осуществляется по общим полям.

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

«товар» на две. Поскольку, каждый поставщик поставляет товар по своей цене, то можно

использовать сущность «прайс-лист» в качестве естественного разбиения связи типа

«многие-ко-многим» на две связи типа «один-ко-многим». В нашем примере (рис.2)

каждый поставщик в «прайс-листе» предлагает один или несколько товаров по некоторой

цене. Атрибут «цена» является частью сущности «прайс-лист». Общим атрибутом

является атрибут «ИНН поставщика». С другой стороны, прайс-лист содержит не менее

одного товара. Таким образом, сущности «товар» и «прайс-лист» связаны отношением

«один-ко-многим» по общему полю «Код товара». Таким образом, связь «многие-ко-

многим» между сущностями «поставщик» и «товар» разбита на две. Сущность прайс-лист

уникально идентифицируется атрибутами «ИНН поставщика» и «Код товара».

Очень часто для осуществления электронного обмена документами возникает

необходимость хранить в базе данных идентификатор товара, который уникально

характеризует товар в базе данных поставщика, так называемый, «артикул товара».

Очевидно, что данных атрибут нельзя разместить ни в сущности «поставщик», так как

поставщик поставляет много товаров, ни в сущности «товар», так как у каждого

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

целей лучше всего подходит сущность «прайс-лист», которая определяет список товаров,

предлагаемых каждым поставщиком.

Заметим, что для сущности «договор» в качестве уникального ключа выбран набор

атрибутов «номер договора» и «дата заключения договора». Для объяснения такого

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

предприятий. Чаще всего договора заключаются ежегодно, при этом, нумерация

договоров обычно начинается с цифры 1. Если выбрать в качестве первичного ключа

номер договора, то через год в систему невозможно будет внести договор с номером 1,

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

идентификатора выбран набор атрибутов «номер договора» и «дата заключения

договора». Если в организации используется другая система нумерации договоров,

например, если номер договора с поставщиком содержит год заключения договора, то

выбор уникального идентификатора может быть иным.

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

Описание базы данных, выделение сущностей и атрибутов в реальных базах данных

может быть несколько другим. Окончательная модель «сущность связь» представлена на

рис. 2.

Модели данных

После построения концептуальной схемы данных, определяющей всю

информацию, которую необходимо хранить в базе данных и требования к ней можно

переходить к проектированию логической модели данных.

Модель данных имеет схему, в которой отражается структура ее данных, имена

записей, имена и форматы полей.

По способу установления связей между данными и способу манипуляции ими

различают три основных модели данных:

реляционную

иерархическую

сетевую.

В настоящее время наиболее широкое использование получило реляционное

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

Реляционная модель данных считается простейшей и наиболее привычной для

пользователя формой представления данных в виде двумерных таблиц. Каждая

реляционная таблица представляет собой двумерный массив и обладает следующими

свойствами:

Один элемент таблицы соответствует одному элементу данных;

Элементы одного столбцы имеют одинаковый тип;

Каждый столбец идентифицируется по имени, которое должно быть уникально в пределах

таблицы;

Каждый элемент данных идентифицируется по уникальному ключу, то есть одинаковые

строки в таблице отсутствуют;

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

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

(рисунок 3).

имя поля 1

имя поля 2 имя поля 3 имя поля 4

Рис. 3. Основные понятия реляционной базы данных.

Таблица − совокупность экземпляров записей одной структуры. Каждая сущность

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

дается имя, представляющее собой множественную форму имени сущности. Например,

сущности «поставщик» нашего примера соответствует таблица «Поставщики»

реляционной базы данных.

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

«Поставщики» может являться информация о каждом конкретном поставщике.

Поле − элементарная единица логической организации данных, которая

соответствует неделимой единице информации − реквизиту. Каждый атрибут сущности

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

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

использовать для функционирования базы данных.

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

может состоять из одного, нескольких или даже всех столбцов таблицы. Они

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

записи обычно образуют первичный ключ таблицы.

В процессе построения логической модели данных осуществляется процедура

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

сущностей так, что бы устранить дублирование и обеспечить непротиворечивость

хранимых в системе данных. Алгоритмы нормализации данных описаны в литературе

[11, 6].

После получения логической модели данных осуществляется переход к

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

СУБД, имеющиеся возможности выбранной СУБД по обеспечению целостности данных,

их безопасности и пр.

Построение физической модели данных − задача программистов и

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

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

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

выбор СУБД.

Выбор СУБД для информационной системы — это отдельный этап разработки

информационной системы. Выбранный программный продукт должен удовлетворять как

текущим, так и будущим потребностям предприятия, при этом следует учитывать

финансовые затраты на приобретение необходимого оборудования, самой СУБД,

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

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

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

требования к СУБД могут быть различны. Основными характеристиками СУБД

являются:

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

обеспечение целостности данных на уровне базы данных;

обеспечение безопасности данных, которая достигается за счет шифрования данных и

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

элементам;

обеспечение многопользовательского доступа к данным;

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

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

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

возможность импорта и экспорта данных.

Архитектура многопользовательских СУБД

Среди наиболее часто встречающихся аппаратных организаций СУБД можно

назвать три наиболее распространенные архитектуры.

Терминальный доступ. Пользовательские компьютеры при помощи специальной

программы терминального доступа запускают пользовательское приложение на

центральном компьютере. Центральный компьютер выполняет все действия,

определенные пользователем, при этом пользовательские терминалы только отображают

информацию. Достоинством такого способа организации работы являются низкие

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

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

соответственно, большие требования к его производительности и отказоустойчивости.

Файловый сервер, который фактически представляет собой совместно

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

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

рабочих станций. Файлы базы данных в соответствии с пользовательскими запросами

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

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

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

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

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

Клиент-сервер (рис. 4). Поскольку эта модель стала фактически стандартом для

современных СУБД рассмотрим ее более подробно.

Архитектура «клиент-сервер» - это сетевая среда, в которой компьютер-клиент

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

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

Клиенту возвращается по сети результат запроса. Среда «клиент-сервер» содержит 2

основных компонента:

Приложение, которое называют клиентом или интерфейсной частью

Сервер базы данных, который называют сервером или прикладной частью