Новая методичка кур раб по БД (1). Методические указания к курсовой работе по дисциплине Базы данных Составитель А. Б. Градусов
 Скачать 239.4 Kb.
|
1.4. Примеры построения моделей «сущность – связь»Рассмотрим пример модели данных банка. Сущностями для банка являются СБЕРЕГАТЕЛЬНЫЙ СЧЕТ, ТЕКУЩИЙ СЧЕТ, КЛИЕНТ. Клиент может иметь как текущий, так и сберегательный счет. В общем случае клиент может иметь несколько счетов, а каждым счетом могут пользоваться несколько клиентов. Таким образом, отношения ИМЕЕТ СБЕРЕГАТЕЛЬНЫЙ СЧЕТ и ИМЕЕТ ТЕКУЩИЙ СЧЕТ являются отношениями вида много-ко-многим, причем если существует счет, то он должен принадлежать хотя бы одному клиенту (класс принадлежности со стороны клиента – обязательный, со стороны счета - необязательный). Клиентом банка может быть как физическое, так и юридическое лицо. Добавив к каждой сущности атрибуты, получим модель, представленную на рис. 3.  Рисунок 3. Модель «сущность – связь» структуры данных банка Модель данных «сущность – связь» может строиться как на основе опроса руководителей и специалистов отделов предприятия, так и на основе существующих отчетов. При разработке БД на основе документации, принятой на предприятии, сущности, атрибуты и связи между ними будут отражать существующую систему учета. Если необходимо учитывать и какие-либо другие данные, не отраженные в документах, то после разработки модели ее нужно будет корректировать и дополнять с учетом пожеланий заказчиков. Рассмотрим пример построения модели «сущность – связь» торговой фирмы на основе накладной. Пример накладной приведен в таблице 2. Таблица 2
Из приведенного документа можно вывести следующие сущности: НАКЛАДНАЯ, ПОЛУЧАТЕЛЬ, ТОВАР. Отношение между сущностями ПОЛУЧАТЕЛЬ и НАКЛАДНАЯ имеет показатель кардинальности один-ко-многим, так как каждая накладная оформляется одному получателю, но данному получателю могут быть оформлены несколько накладных. Класс принадлежности сущностей ПОЛУЧАТЕЛЬ и НАКЛАДНАЯ обязательный, т.к. в накладной обязательно указывается получатель товара. Отношение ВКЛЮЧАЕТ между объектами ТОВАР и НАКЛАДНАЯ имеет показатель кардинальности много-ко-многим, так как накладная может содержать несколько товаров, а товар может встречаться в нескольких накладных, при этом одной накладной должен соответствовать хотя бы один товар (т.е. со стороны товара класс принадлежности обязательный, со стороны накладной - необязательный). Если необходимо контролировать оплату поставленного по накладным товара, то необходимо добавить сущность ОПЛАТА с атрибутами НОМЕР ДОКУМЕНТА, ВИД ОПЛАТЫ и ДАТА. Показатель кардинальности отношения ОПЛАЧЕНА между объектами НАКЛАДНАЯ и ОПЛАТА равна один-к-одному и класс принадлежности является обязательной (подразумевается, что при выписке накладной должны также оформляться документы об оплате). Модель данных приведена на рис. 4.  Рисунок 4. Модель «сущность – связь» торговой фирмы на основе накладной 1.5 Выбор СУБД и других программных средств Выбор СУБД осуществляется на основании таких критериев, как тип модели данных и её адекватность потребностям рассматриваемой предметной области; характеристики производительности; набор функциональных возможностей; удобство и надежность СУБД в эксплуатации; стоимость СУБД и дополнительного программного обеспечения [1]. 1.6 Логическое проектирование БД 1.6.1 Разработка логической структуры БД На этапе логического проектирования разрабатывается логическая структура БД. Для реляционной модели существуют формальные правила, которые позволяют преобразовать инфологическую модель в виде модели «сущность-связь) в логическую схему базы данных. Основные 6 правил генерации таблиц: Правило 1. Если показатель кардинальности бинарной связи равен 1 : 1 и класс принадлежностей обеих сущностей является обязательным, то требуется только одна таблица. Первичным ключом этой таблицы может быть ключ любой из двух сущностей. Правило 2. Если показатель кардинальности бинарной связи равен 1 : 1 и класс принадлежности одной сущности является обязательным, а другой ‑ необязательным, то необходимо построение двух таблиц. Под каждую сущность нужно выделить по одной таблице, при этом ключ сущности должен служить первичным ключом для соответствующей таблицы. Кроме того, ключ сущности, для которой класс принадлежности является необязательным, добавляется в качестве атрибута в таблицу, выделенную для сущности с обязательным классом принадлежности. Правило 3.Если показатель кардинальности бинарной связи равен 1 : 1 и класс принадлежности ни одной сущности не является обязательным, то необходимо использовать три таблицы: по одной для каждой сущности, ключи которых служат в качестве первичных в соответствующих таблицах, и одна таблица для связи. Среди своих атрибутов таблица связи будет иметь по одному ключу каждой сущности. Правило 4. Если показатель кардинальности бинарной связи равен 1 : М и класс принадлежности n-связной сущности является обязательным, то достаточным является использование двух таблиц, по одной на каждую сущность, при условии, что ключ каждой сущности служит в качестве первичного ключа для соответствующей таблицы. Дополнительно ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, отводимую для n-связной сущности. Правило 5. Если показатель кардинальности бинарной связи равен 1 : М и класс принадлежности n-связной сущности является необязательным, то необходимо формирование трех таблиц: по одной для каждой сущности, причем ключ каждой сущности служит первичным ключом соответствующей таблицы, и одной таблицы для связи. Таблица связи должна иметь среди своих атрибутов ключ каждой сущности. Правило 6. Если показатель кардинальности бинарной связи равен М : М, то для хранения данных необходимо три таблицы: по одной для каждой сущности, причем ключ каждой сущности используется в качестве первичного ключа соответствующей таблицы, и одной таблицы для связи. Таблица связи должна иметь в числе своих атрибутов ключ каждой сущности. Рассмотрим преобразование ранее созданной модели «сущность-связь» торговой фирмы (рис. 4). Связь ОФОРМЛЕНА между сущностями ПОЛУЧАТЕЛЬ и НАКЛАДНАЯ имеет показатель кардинальности один-ко-многим и класс принадлежности обеих сущностей обязательный. Поэтому для преобразования этой связи воспользуемся правилом 4. В соответствии с этим правилом надо построить только две таблицы: по одной на каждую сущность. Причём ключ односвязной сущности добавляется как неключевой атрибут в таблицу, отводимую n-связной сущности (Код). В результате получим следующие таблицы: ПОЛУЧАТЕЛЬ (Код, Адрес, Название); НАКЛАДНАЯ (Номер, Налог, Итого, Код). Сущности ТОВАР и НАКЛАДНАЯ соединены связью типа М:М. Для преобразования модели «сущность-связь» потребуется правило 6, при этом класс принадлежности обеих сущностей не играет никакой роли. В этом случае требуется 3 таблицы: по 1 для каждой сущности и 1 таблица связи, которая будет иметь по одному ключу от каждой сущности, а первичным ключом таблицы связи будет составной ключ: ТОВАР (Ном.номер, Наименование, Цена, Количество, Сумма); НАКЛАДНАЯ (Номер, Налог, Итого, Код); ВКЛЮЧАЕТ (Ном.номер, Номер). Между сущностями НАКЛАДНАЯ и ОПЛАТА связь типа один-к одному и класс принадлежности обеих сущностей обязательный. Следовательно, для преобразования надо воспользоваться правилом 1, т.е. потребуется только одна таблица НАКЛАДНАЯ (Номер, Налог, Итого, Код, Номер_документа, Дата, Вид). Таким образом, в итоге была получена следующая реляционная модель: ПОЛУЧАТЕЛЬ (Код, Адрес, Название); НАКЛАДНАЯ (Номер, Налог, Итого, Код, Номер_документа, Дата, Вид); ТОВАР (Ном.номер, Наименование, Цена, Количество, Сумма); ВКЛЮЧАЕТ (Ном.номер, Номер). 1.6.2 Нормализация базы данных Проектирование схемы БД должно решать задачи минимизации дублирования данных и упрощения процедур их обработки и обновления. При неправильно спроектированной схеме БД могут возникнуть аномалии модификации данных. Для решения подобных проблем проводится нормализация таблиц. Нормализация – это разбиение таблицы на две или более таблицы, обладающих лучшими свойствами при вставки, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных. Первая нормальная форма (1НФ) Таблица находится в первой нормальной форме тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения. Вторая нормальная форма (2НФ). Вторая нормальная форма основана на понятии функциональной зависимости. Пусть X и Y – атрибуты некоторой таблицы. Если в любой момент времени каждому значению X соответствует единственное значение Y, то говорят, что Y функционально зависит от X (X→Y). Атрибут X в функциональной зависимости X→Y называется детерминантом отношения. В нормализованной таблице все неключевые атрибуты функционально зависят от ключа таблицы. Неключевой атрибут функционально полно зависит от составного ключа, если он функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа. Таблица находится во 2НФ, если она приведена к 1НФ и каждый неключевой атрибут функционально полно зависит от составного первичного ключа. Таким образом, если таблица в 1НФ имеет простой первичный ключ, она сразу находится во второй нормальной форме. Для того чтобы привести таблицу ко 2НФ, нужно: В исходной таблице выявить атрибуты, зависящие от части ключа и создать новую таблицу без атрибутов исходной таблицы, находящихся в частичной функциональной зависимости от первичного ключа. Создать таблицу, атрибутами которой являются части составного ключа и атрибуты, зависящие от этих частей. Третья нормальная форма (3НФ). Третья нормальная форма основана на понятии транзитивной зависимости. Пусть X, Y, Z – атрибуты некоторой таблицы. При этом X→Y и Y→Z, но обратное соответствие отсутствует, т.е. Z не зависит от Y или Y не зависит от X. Тогда говорят, что Z транзитивно зависит от X (X→→Z). Таблица находится в 3НФ, если она находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Для того чтобы привести отношение к 3НФ, нужно: В исходной таблице выявить транзитивно зависящие атрибуты (X→Y и Y→Z), и создать новую таблицу, исключив из исходной таблицы атрибуты, транзитивно зависящие от ключа (атрибут Z). Построить новую таблицу, атрибутами которой являются части транзитивной зависимости (атрибуты Y и Z). Четвертая нормальная форма (4НФ) Четвертая нормальная форма основана на понятии многозначной зависимости. Многозначная зависимость существует, если заданным значениям атрибута X соответствует множество значений атрибута Y (X–»Y). Таблица находится в 4НФ в том и только в том случае, если она находится в 3НФ и в случае существования многозначной зависимости А -» В все остальные атрибуты таблицы функционально зависят от А. Для того чтобы привести отношение к 4НФ, нужно построить две или более проекции исходного отношения, каждая из которых содержит ключ и одну из многозначных зависимостей. 1.7 Программная реализация базы данных Программная реализация базы данных заключается в описании ее схемы на языке определения данных (DDL, Data Definition Language) выбранной СУБД. Принятые на этом этапе решения оказывают огромное влияние на производительность системы. Важнейшими составляющими проекта базы данных являются разработка декларативных и процедурных средств поддержки целостности данных, а так же реализация операций над данными (поиск, вставка, удаление, обновление). Не менее важным вопросом разработки базы данных является защита БД от несанкционированного доступа. Для защиты от несанкционированного доступа каждому пользователю доступ к данным предоставляется только в соответствии с его правами доступа, набор которых также является составной частью проекта БД. | ||||||||||||||||||||||||||||||