2. Приведение ко второй нормальной форме
3. Следующий важный шаг в процессе нормализации состоит в удалении всех неключевых атрибутов, которые зависят только от части первичного ключа. Такие атрибуты называются частично зависимыми. Неключевые атрибуты заключают в себе информацию о данной сущности предметной области, но не идентифицируют ее уникальным образом. Например, предположим, что мы хотим распределить работников по проектам, ведущимся на предприятии. Для этого создадим таблицу ПРОЕКТ с составным первичным ключом, включающим номер работника и идентификатор проекта (Номер_работника+ИД_проекта, в табл. c выделены курсивом).
Табл. C: ПРОЕКТ
Номер_ | ИД_проекта | Фамилия | Назв_проекта | Описание_ | Продукт |
28 | БРЖ | Иванов | Биржа | <blob> | программа |
17 | ДОК | Петров | Документы | <blob> | программа |
06 | УПР | Сидоров | Управление | <blob> | адм.меры |
В этой таблице возникает следующая проблема. Атрибуты Назв_проекта, Описание_проекта и Продукт относятся к проекту как сущности и, следовательно, зависят от атрибута ИД_проекта (являющегося частью первичного ключа), но не от атрибута Номер_работника. Следовательно, они являются частично зависимыми от составного первичного ключа. То же самое можно сказать и об атрибуте Фамилия, который зависит от атрибута Номер_работника, но не зависит от атрибута ИД_проекта. Для нормализации этой таблицы (приведения ее в 2НФ) удалим из нее атрибуты Номер_работника и Фамилия и создадим другую таблицу (назовем ее РАБОТНИК_В_ПРОЕКТЕ), которая будет содержать только эти два атрибута, и они же будут составлять ее первичный ключ.
4. Приведение к третьей нормальной форме
Третий этап процесса приведения таблиц к нормальной форме состоит в удалении всех неключевых атрибутов, которые зависят от других неключевых атрибутов. Каждый неключевой атрибут должен быть логически связан с атрибутом (атрибутами), являющимся первичным ключом. Предположим, например, что мы добавили поля Номер_руководителя и Телефон в таблицу ПРОЕКТ, находящуюся в 2НФ (первичным ключом является поле ИД_проекта). Атрибут Телефон логически связан с атрибутом Номер_руководителя, неключевым полем, но не с атрибутом ИД_проекта, являющимся первичным ключом (табл. d).
Табл. D: ПРОЕКТ
ИД_проекта | Номер_ | Телефон | Назв_ | Описание_ | Продукт |
БРЖ | 02 | 2-21 | Биржа | <blob> | программа |
ДОК | 12 | 2-43 | Документы | <blob> | программа |
УПР | 08 | 2-56 | Управление | <blob> | адм.меры |
Для нормализации этой таблицы (приведения ее в 3НФ) удалим атрибут Телефон, изменим Номер_руководителя на Руководитель и сделаем атрибут Руководитель внешним ключом, ссылающимся на атрибут Номер_работника (первичный ключ) в таблице РАБОТНИКИ. После этого таблицы ПРОЕКТ и РАБОТНИКИ будут выглядеть следующим образом:
Табл. E: ПРОЕКТ
ИД_проекта | Руководитель | Назв_ | Описание_ | Продукт |
БРЖ | 02 | Биржа | <blob> | программа |
ДОК | 12 | Документы | <blob> | программа |
УПР | 08 | Управление | <blob> | адм.меры |
Табл. F: РАБОТНИКИ
Номер_ | Фамилия | Имя | Отчество | Номер_ | Код_ | Телефон | Зарплата | |
04 | Иванов | Иван | Иванович | 100 | инж | 2-69 | 500 | |
08 | Петров | Петр | Петрович | 200 | мндж | 2-56 | 1000 | |
23 | Сидоров | Иван | Петрович | 200 | мндж | 2-45 | 800 | |
Теперь, когда мы научились проводить нормализацию таблиц с целью устранения избыточного дублирования данных и группирования информации в логически связанных единицах, необходимо сделать ряд замечаний по вопросам проектирования баз данных. Необходимо четко понимать, что разбиение информации на более мелкие единицы с одной стороны, способствует повышению надежности и непротиворечивости базы данных, а с другой стороны, снижает ее производительность, так как требуются дополнительные затраты процессорного времени (серверного или машины пользователя) на обратное “соединение” таблиц при представлении информации на экране. Иногда для достижения требуемой производительности нужно сделать отход от канонической нормализации, при этом ясно осознавая, что необходимо обеспечить меры по предотвращению противоречивости в данных. Поэтому всякое решение о необходимости того или иного действия по нормализации можно принимать только тщательно проанализировав предметную область и класс поставленной задачи. Может потребоваться несколько итераций для достижения состояния, которое будет желаемым компромиссом между четкостью представления и реальными возможностями техники. Здесь уже начинается искусство...
VII. Седьмой шаг является последним в нашем списке, но не последним по важности в процессе проектирования базы данных. На этом шаге мы должны спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации. Для этого необходимо ответить на следующие вопросы:
· кто будет иметь права (и какие) на использование базы данных
· кто будет иметь права на модификацию, вставку и удаление данных
· нужно ли делать различие в правах доступа
· каким образом обеспечить общий режим защиты информации и т.п.
1. Заключение
На данном уроке мы познакомились с основами теории реляционных баз данных, изучили требования к базам данных, а также основные шаги по проектированию баз данных. Кроме того, рассмотрели очень важный для проектирования баз данных вопрос нормализации таблиц и проблемы, связанные с этим процессом. Теперь мы можем осознанно приступать к созданию приложений, работающих с базами данных.
... . В Delphi многие действия требуют гораздо меньше времени и выполняются более интуитивно. Безусловно, что для быстрого создания приложений необходим иной взгляд на программирование вообще. Для этого основой Delphi стал объектно-ориентированный Pascal (который так и называется Object Pascal и сильно отличается от стандарта языка). Теперь программист не пишет стандартный код, а оперирует с более ...
... мире. Внутренняя схема - это сама база данных. Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы: Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия: обследование предметной области, изучение ее информационной структуры выявление всех фрагментов, каждый ...
... по авансовому отчету. Перерасход выдается подотчетному лицу по расходному кассовому ордеру через кассу предприятия. 2.3 Выбор инструментов и средств программирования Для разработки приложения выбрана визуальная среда программирования Borland Delphi 7. Базы данных считаются основным плюсом Delphi. Это действительно так. Хотя этот язык не создавался специально под данную сферу, реализация ...
... данных, подключает библиотеку Borland Database Engine (BDE), которая, в свою очередь, использует конфигурационный файл, содержащий информацию о всех зарегистрированных в системе псевдонимах. Псевдоним базы данных может быть создан (зарегистрирован) при помощи утилиты BDE Administrator. Эта же утилита позволяет изменить каталог, связанный с псевдонимом. База данных — это набор файлов (таблиц), в ...
0 комментариев