Глава 2 Логический уровень проектирования базы данных
Разработка логической структуры базы данных
Логическое проектирование базы данных состоит в создании логической модели данных. В процессе разработки логическая модель должна постоянно проверяться на удобность пользования как клиентами агенства, так и их работниками. Также данный этап включает в себя доработку локальной концептуальной модели для удаления нежелательных элементов и преобразование полученной модели в локальную логическую модель данных (рис.10).
рис.10 – Логическая структура реляционной базы
Разработка реляционной модели
Почти все современные системы основаны на реляционной (relational) модели управления базами данных. Название реляционная связано с тем, что каждая запись в такой базе данных содержит информацию, относящуюся только к одному конкретному объекту.
В реляционной СУБД все обрабатываемые данные представляются в виде плоских таблиц. Информация об объектах определенного вида представляется в табличном виде: в столбцах таблицы сосредоточены различные атрибуты объектов, а строки предназначены для сведения описаний всех атрибутов к отдельным экземплярам объектов.
Модель, созданная на этапе инфологического моделирования, в наибольшей степени удовлетворяет принципам реляционности. Однако для приведения этой модели к реляционной необходимо выполнить процедуру, называемую нормализацией.
Теория нормализации оперирует с пятью нормальными формами. Эти формы предназначены для уменьшения избыточности информации, поэтому каждая последующая нормальная форма должна удовлетворять требованиям предыдущей и некоторым дополнительным условиям. При практическом проектировании баз данных четвертая и пятая формы, как правило, не используются. Мы ограничились рассмотрением первых четырех нормальных форм.
Введем понятия, необходимые для понимания процесса приведения модели к реляционной схеме.
Отношение - абстракция описываемого объекта как совокупность его свойств. Проводя инфологический этап проектирования, мы говорили об абстракции объектов и приписывали им некоторые свойства. Теперь же, проводя концептуальное проектирование, мы переходим к следующему уровню абстракции. На данном этапе объектов, как таковых, уже не существует. Мы оперируем совокупностью свойств, которые и определяют объект.
Экземпляр отношения - совокупность значений свойств конкретного объекта.
Первичный ключ - идентифицирующая совокупность атрибутов, т.е. значение этих атрибутов уникально в данном отношении. Не существует двух экземпляров отношения содержащих одинаковые значения в первичном ключе.
Простой атрибут - атрибут, значения которого неделимы.
Сложный атрибут - атрибут, значением которого является совокупность значений нескольких различных свойств объекта или несколько значений одного свойства.
Требования к реляционным моделям
Рациональные варианты концептуальной схемы базы данных должны удовлетворять третьей нормальной форме, а также следующим требованиям:
Выбранный перечень отношений должен быть минимален. Отношение используется, если только его необходимость обусловлена задачами.
Выбранный перечень атрибутов должен быть минимален. Атрибут включается в отношение только в том случае, если он будет использоваться.
Первичный ключ отношения должен быть минимальным. То есть невозможно исключить ни один атрибут из идентифицирующей совокупности атрибутов, не нарушив при этом однозначной идентификации.
При выполнении операций над данными не должно возникать трудностей.
Реляционная модель проектируемой базы данных:
Клиент - продавец (код продавца, код адреса, дом – квартира, фамилия, имя, отчество, телефон, паспорт серия, паспорт номер, кем выдан). Первичный ключ: код продавца. Внешний ключ: код адреса.
Квартира (код квартиры, код покупателя, код продавца, код дом – квартира, код района, дом квартира, этаж, тип дома, тип планировки, тип сан.узла, площадь квартиры,жилая площадь, площадь кухни, наличие телефона,наличие приватизации, документ на право собственности). Первичный ключ: код квартиры.
Покупатель (код покупателя, фамилия, имя, отчество, паспорт серия, паспорт номер,кем выдан, телефон). Первичный ключ: код покупателя.
Район (код района, район). Первичный ключ: код района.
Улица (код улицы, улица). Первичный ключ: код улицы.
Договор (код договора, код квартиры, код покупателя, начало действия договора, окончание действия договора, продление договора, стоимость квартиры, заработок агенства). Первичный ключ: код договора. Внешние ключи: код покупателя, код адреса, код района, код договора.
Далее определяем типы данных форматов данных.
Таблица «Клиент» содержит информацию о продавцах (см.табл.10).
Таблица 10 – Структура таблицы данных «Клиент (продавец)»
Наименование поля |
Тип поля |
Размер поля |
Обязательное поле |
Ключевое поле |
Код продавца |
Числовой |
длинное целое |
нет |
да |
Код адреса |
Числовой |
длинное целое |
нет |
нет |
Дом - вкартира |
Текстовый |
25 |
да |
нет |
Фамилия |
Текстовый |
25 |
да |
нет |
Имя |
Текстовый |
25 |
да |
нет |
Отчество |
Текстовый |
25 |
да |
нет |
Телефон |
Числовой |
30 |
нет |
нет |
Таблица «Данные о таблице» содержит информацию о квартире, которую приобретают или продают (см.табл.11).
Таблица 11 – Структура таблицы данных «Данные о квартире»
Наименование поля |
Тип поля |
Размер поля |
Обязательное поле |
Ключевое поле |
||
Код квартиры |
Числовой |
Длинное целое |
нет |
да |
||
Код покупателя |
Числовой |
Длинное целое |
нет |
нет |
||
Код продавца |
Числовой |
Длинное целое |
да |
нет |
||
Код дом - квартира |
Числовой |
Динное целое |
|
|
||
Код района |
Чисовой |
Длинное целое |
|
|
||
Дом - квартира |
Числовой |
35 |
|
|
||
Тип дома |
|
|
|
|
Тип планировки |
|
|
|
|
Тип санузла |
|
|
|
|
Площадь квартиры |
|
|
|
|
Жилая площадь |
|
|
|
|
|
|
|
|
|
Таблица «Производитель» содержит информацию о производителях товаров продуктового склада (см.табл.12).
Таблица 12 – Структура таблицы данных «Производитель»
Наименование поля |
Тип поля |
Размер поля |
Обязательное поле |
Ключевое поле |
код производителя |
счетчик |
целое |
да |
да |
наименование производителя |
текстовое |
30 |
нет |
нет |
Таблица «Поставщик» содержит информацию о поставщиках товаров продуктового склада (см.табл.13).
Таблица 13 – Структура таблицы данных «Поставщик»
Наименование поля |
Тип поля |
Размер поля |
Обязательное поле |
Ключевое поле |
код поставщика |
счетчик |
целое |
да |
да |
название поставщика |
текстовое |
30 |
нет |
нет |
адрес |
текстовое |
30 |
нет |
нет |
телефон |
текстовое |
10 |
нет |
нет |
признак посредника |
логический |
длинное целое |
нет |
нет |
Таблица «Покупатель» содержит информацию о покупателях товаров продуктового склада (см.табл.14).
Таблица 14 – Структура таблицы данных «Покупатель»
Наименование поля |
Тип поля |
Размер поля |
Обязательное поле |
Ключевое поле |
код покупателя |
счетчик |
целое |
да |
да |
название покупателя |
текстовое |
60 |
нет |
нет |
адрес |
текстовое |
30 |
нет |
нет |
телефон |
текстовое |
10 |
нет |
нет |
Таблица «Выдавший накладную/счет-фактуру» содержит информацию о работниках складах (см.табл.15).
Таблица 15 – Структура таблицы данных «Выдавший накладную/счет-фактуру»
Наименование поля |
Тип поля |
Размер поля |
Обязательное поле |
Ключевое поле |
код работника склада |
счетчик |
целое |
да |
да |
работник склада |
текстовое |
60 |
нет |
нет |
Таблица «Накладная ведомость» содержит информацию о накладных ведомостях на товар (см.табл.16).
Таблица 16 – Структура таблицы данных «Накладная ведомость»
Наименование поля |
Тип поля |
Размер поля |
Обязательное поле |
Ключевое поле |
код накладной |
счетчик |
целое |
да |
да |
код товара |
числовое |
длинное целое |
да |
нет |
код работника склада |
числовое |
длинное целое |
да |
нет |
номер накладной |
числовое |
длинное целое |
да |
нет |
дата поступления на склад |
дата/время |
- |
нет |
нет |
количество |
числовое |
длинное целое |
нет |
нет |
мера |
текстовое |
длинное целое |
нет |
нет |
цена закупки |
денежное |
- |
нет |
нет |
Таблица «Счет-фактура» содержит информацию о счет-фактурах на товар (см.табл.17).
Таблица 17 – Структура таблицы данных «Счет-фактура»
Наименование поля |
Тип поля |
Размер поля |
Обязательное поле |
Ключевое поле |
код накладной |
счетчик |
целое |
да |
да |
код товара |
числовое |
длинное целое |
да |
нет |
код работника склада |
числовое |
длинное целое |
да |
нет |
номер накладной |
числовое |
длинное целое |
да |
нет |
дата поступления на склад |
дата/время |
- |
нет |
нет |
количество |
числовое |
длинное целое |
нет |
нет |
мера |
текстовое |
длинное целое |
нет |
нет |
цена закупки |
денежное |
- |
нет |
нет |
Связи между таблицами позволяют выполнить объединение данных различных таблиц, необходимое для решения большинства задач ввода, просмотра и корректировки данных, получения информации по запросам и вывода отчетов.
Связи между таблицами устанавливаются в соответствии с проектом логической структуры базы данных и запоминаются в схеме данных
Схема данных является не только средством графического отображения логической структуры базы данных, она активно используется системой в процессе обработки данных. Создание схемы данных позволяет упростить конструирование многотабличных форм, запросов, отчетов, а также обеспечить поддержание целостности взаимосвязанных данных при вводе и корректировке данных в таблицах (см. Приложение А).
Ссылочная целостность – это ограничение базы данных, гарантирующее, что ссылки между данными являются действительно правомерными и неповрежденными. Ссылочная целостность является фундаментальным принципом теории баз данных и проистекает из той идеи, что база данных должна не только сохранять данные, но и активно содействовать обеспечению их качества. Вот несколько дополнительных определений, найденных в Интернет:
«Ссылочная целостность в реляционной базе данных – это согласованность между связанными таблицами. Ссылочная целостность обычно поддерживается путем комбинирования первичного ключа и внешнего ключа. Для соблюдения ссылочной целостности требуется, чтобы любое поле в таблице, объявленное внешним ключом, могло содержать только значения из поля первичного ключа родительской таблицы …» [5]
«[Ссылочная целостность – это] свойство, обеспечиваемое реляционными системами управления базами данных (РСУБД), которое предотвращает ввод несогласованных данных пользователями или приложениями. В большинстве РСУБД имеются различные правила ссылочной целостности, которые можно применить при создании связи между двумя таблицами» .
«[Ссылочная целостность – это] предохранительное устройство системы управления базами данных, гарантирующее, что каждый внешний ключ соответствует первичному ключу. Например, номера заказчиков являются первичными ключами в файле заказчиков и внешними ключами в файле заказов. При удалении записи заказчика должны быть удалены соответствующие записи заказов; в противном случае они останутся без исходной связи. Если СУБД не проверяет этого, соответствующий механизм должен программироваться в приложении».
Поддержка ссылочной целостности в базе данных обеспечивает много преимуществ.
Улучшенное качество данных. Очевидным преимуществом является поддержка качества данных, хранимых в базе данных. Ошибки могут по-прежнему существовать, но, по крайней мере, ссылки будут подлинными и неповрежденными.
Убыстрение разработки. Ссылочная целостность объявляется. Это гораздо продуктивнее (на один или два порядка), чем написание специального программного кода.
Меньшее число ошибок. Объявления ссылочной целостности являются гораздо более лаконичными, чем эквивалентный программный код. По существу, такие объявления приводят к повторному использованию проверенного и оттестированного кода общего назначения в сервере баз данных, а не к новой реализации одной и той же логики от случая к случаю.
Согласованность между приложениями. Ссылочная целостность обеспечивает качество данных для нескольких прикладных программ, которые могут обращаться к базе данных.