Иптышев А.А. Курс лекций по дисциплине базы данных

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

Рис.17.Нормализованная ER – диаграмма.

Идентификационный номер

Фамилия

Семестр

Форма отчетности

Имя

Количество часов

Отчество

Номер группы

Домашний адрес

Телефон

Наименование дисциплины

Дисциплина учеб-

ного класса

Студент

Сводная

ведомость

Читает

Преподаватель

Отчество

Кафедра

Должность

Домашний ад.

Телефон

Имя

Фамилия

Идентификаци-

онный номер

Оценка

Дата сдачи

4.5.2 Построение реляционной схемы

Следующий этап проектирования – построение датологической моде-

ли. В рассматриваемом случае задача этого этапа – преобразование ER-

диаграммы в реляционную схему.

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

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

другой – более простые способы хранения и обновления.

Первые шаги преобразования состоят в превращении каждой сущности

в отношение (таблицу). Связь типа М: М, которую называют «сущность –

связь», тоже превращается в отдельное отношение. Каждое свойство стано-

вится атрибутом – столбцом соответствующей таблицы. После реализации

этих шагов получаем реляционную схему, изображенную на рис. 18, где

представлены таблицы «Студенты», «Сводная ведомость», «Учебный

план» и «Кадровый состав», отображающие соответственно сущности

«Студент», «Сводная ведомость», «Дисциплина учебного плана» и «Пре-

подаватель».

Рис. 18. Реляционная схема после первого этапа преобразования.

Далее необходимо преобразовать связи во внешние ключи. Связь

«Многие ко многим», реализуемая отношением «Сводная ведомость»,

должна содержать уникальнве идентификаторы сущностей – участников свя-

зи. При этом, если для однозначной идентификации студента достаточно до-

Оценка

Дата сдачи

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

Семестр

Количество часов

Форма отчетности

ID_Студент

Фамилия

Отчество

Имя

Номер группы

Телефон

Адрес

Студенты

Сводная ведомость

Учебный план

ID_Преподаватель

Фамилия

Имя

Отчество

Кафедра

Должность

Адрес

Кадровый состав

бавить в таблицу столбец ID_Студент, то однозначная идентификация дис-

циплины потребует добавления в таблицу столбцов Наименование, Семестр

и Форма отчетности. Хранение всей этой информации явно приведет к из-

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

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

цы «Учебный план», то содержимое таблицы «Сводная ведомость» станет

неактуальным).

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

данных добавим в таблицу «Учебный план» столбец ID_План, содержимое

которого будет однозначно идентифицировать каждую строку таблицы. Те-

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

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

Связь «Читает» предполагает добавление в таблицу «Учебный план»

столбца ID_Преподаватель. Реляционная схема со связями представлена на

рис.19.

Рис. 19. Реляционная схема со связями.

ID_Студент

Фамилия

Отчество

Имя

Номер группы

Телефон

Адрес

Студенты

Сводная ведомость

Оценка

Дата сдачи

ID_Студент (FK)

ID_План (FK)

ID_Преподаватель

Фамилия

Имя

Отчество

Кафедра

Должность

Адрес

Кадровый состав

ID_План

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

Семестр

Количество часов

Форма отчетности

ID_Преподаватель (FK)

Учебный план

4.5.3 Нормализация таблиц

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

как каждый столбец таблицы неделим и в рамках одной таблицы нет столб-

цов с одинаковыми по смыслу значениями.

Таблица «Сводная ведомость» через столбцы ID_Студент и ID_План

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

и фиксирует оценку, полученную студентом. Оценка и дата сдачи экзамена

(зачета) однозначно зависят то содержимого столбцов ID_Студент и

ID_План, которые представляют собой составной первичный ключ. Таким

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

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

во второй нормальной форме.

Рассмотрим подробнее таблицу «Учебный план», которая содержит

перечень дисциплин текущего учебного плана. Первичным ключом таблицы

служит столбец ID_План, который характеризует каждую дисциплину учеб-

ного плана с точностью до семестра, т.е. для дисциплин, протяженность изу-

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

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

именований дисциплин в таблице «Учебный_план» становится избыточ-

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

наименование «Английский язык» будет повторно в шести записях и есть

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

наименования.

Чтобы избежать этого, приведем декомпозицию отношения «Учебный

план», выделив наименования дисциплин в отдельное отношение. В резуль-

тате получим дополнительную таблицу «Дисциплины» со столбцами

ID_Дисциплина и Наименование, а столбец Наименование в таблице

«Учебный план» заменим столбцом ID_Дисциплина, сформировав тем са-

мым вторичный ключ, связывающий новую таблицу с таблицей «Учебный

план».

Теперь можно говорить о базе данных «Сессия», реляционная схема

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

1.«Студенты» - содержит по одной строке для каждого из студентов;

2.«Учебный_план» - содержит по одной строке для отдельной дисци-

плины отдельного семестра;

3.«Дисциплины» - содержит по одной строке для наименования дис-

циплины;

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

зультата сдачи отдельным студентом отдельной дисциплины;

5.«Кадровый_состав» - содержит по одной строке для каждого из пре-

подавателей.

6.В графической форме (рис. 20) изображены перечисленные таблицы,

их столбцы, первичные и внешние ключи. Задание первичных и внешних

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

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

7.Все таблицы данных «Сессия» находятся в третьей нормальной фор-

ме.

8.Каждый столбец таблицы неделим, и в рамках одной таблицы нет

столбцов с одинаковыми по смыслу значениями (1НФ).

9.Первичные ключи однозначно определяют запись и неизбыточны, все

поля каждой из таблиц зависят от ее первичного ключа (2НФ).

10.Значение любого поля, не входящего в первичный ключ, не зависит

от значения другого поля, тоже не входящего а первичный ключ (3НФ).

Следующий этап проектирования – определение доменов (типов) дан-

ных, хранящихся в столбцах таблиц. Параллельно с заданием типа необхо-

димо сформулировать ограничения целостности связанные с типом, - пере-

чень допустимых значений типа.

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

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

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

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

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

ния, то достаточно будет целого типа данных длиной 1 байт, так как диапа-

зон возможных значений – от 0 до 255; если для данных столбца выбирается

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

столбца и т.п.)

Далее, в каждой таблице должны быть выделены столбцы, которые

обязательно должны быть заполнены при создании отдельной строки табли-

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

таблицу «Студенты» строку, в которой не указан номер группы. Если по-

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

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

данных: появление в таблице «Студенты» строки без номера группы приве-

дет к ошибке при форматировании ведомости.

Следующий важный момент – задание для столбцов значений по умол-

чанию. Значение по умолчанию впоследствии будет автоматически, вводится

в указанный столбец для каждой строки таблицы. Например, в столбец Да-

та_сдачи таблицы «Сводная ведомость» при заполнении очередной строки

может автоматически заноситься текущая дата.

Ниже, на рис.20 представлены таблицы базы данных «Сессия» с типа-

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

Все примеры использования языка SQL (Structured Query Language),

рассматриваемые в следующей главе, будут построены на основе этой учеб-

ной базы данных «Сессия»

Таблица. 7

”Студенты”

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

столбца

Тип данных Ограничения

ID_Студент Целое число Значение уникально

Фамилия Строка символов размером 30 Значение не должно быть пустым

Имя Строка символов размером 15 Значение не должно быть пустым

Отчество Строка символов размером 20 Значение не должно быть пустым

Номер группы Целое число Значение не должно быть пустым

Адрес Строка символов размером 30

Телефон Строка символов размером 8

Таблица. 8

”Дисциплины”

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

столбца

Тип данных Ограничения

ID_Дисциплина Целое число Значение уникально

Наименование ID_Дисциплина Значение уникально

Таблица. 9

”Кадровый состав”

Наименование столбца Тип данных Ограничения

ID_Преподаватель Целое число Значение уникально

Фамилия Строка символов размером 30 Значение не должно быть

пустым

Имя Строка символов размером 15 Значение не должно быть

пустым

Отчество Строка символов размером 20 Значение не должно быть

пустым

Должность Строка символов размером 20 Значение не должно быть

пустым

Кафедра Строка символов размером 3 Значение не должно быть

пустым

Адрес Строка символов размером 30

Телефон Строка символов размером 8

Таблица. 10

”Учебный план”

Наименование столбца Тип данных Ограничения

ID_План Целое число Значение уникально

ID_Дисциплина Целое число Значение не должно быть пустым

Семестр Целое число Значение не должно быть пустым и

должно находиться в интервале от 1 до 10

Количество часов Целое число

ID_Преподаватель Целое число

Таблица. 11

Сводная ведомость”

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

столбца

Тип данных Ограничения

ID_Студент Целое число Значение не должно быть пустым

ID_План Целое число Значение не должно быть пустым

Оценка Целое число Значение не должно быть пустым и должно на-

ходиться в интервале от 0 до 5

Дата сдачи Дата - время Значение не должно быть пустым, по умолчанию

– текущая дата.

Рис. 20.Таблицы базы данных ”Сессия”

МОДУЛЬ 2. ПРОГРАММИРОВАНИЕ ЛОКАЛЬНЫХ БАЗ

ДАННЫХ.

РАЗДЕЛ 2 ВИЗУАЛИЗАЦИЯ И ОБРАБОТКА ДАННЫХ

Тема 5 Доступ к локальным базам данных, таблицам,

записям

5.1 Организация связи с базами данных в Delphi.

Основной работы Delphi с базами данных является Borland Database

Engine (BDE) - процессор баз данных фирмы Borland. BDE служит посредни-

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

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

реализации базы данных и берёт на себя подавляющее большинство стан-

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

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

жение Delphi никогда не обращается непосредственно к базе данных, а толь-

ко к BDE. Таким образом, общение с базами данных соответствует схеме,

приведенной на рис.21.

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

щается к BDE и сообщает обычно псевдоним базы данных и необходимую

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

лиотек к DLL (файлы IDAPI01.DLL, IDAPI32.DLL). Они, как и любые биб-

лиотеки, снабжены API (Application Program Interfase - интерфейсом при-

кладных программ), названным IDAPI (Integrated Database Application Pro-

gram Interfase). Это список процедур и функций для работы с базами данных,

которым и пользуется приложение.

BDE по псевдониму находит подходящий для указанной базы данных

драйвер. Драйвер - это вспомогательная программа, которая понимает, как

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

венный драйвер соответствующий СУБД, то BDE связывается через него с

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

и возвращает в приложение результаты обработки. BDE поддерживает есте-

ственный доступ к таким базам данных, как Microsoft Access, FoxPro, Paradox

и dBase.

Если собственного драйвера нужной СУБД в BDE нет, то используется

драйвер ODBC. ODBC (Open Database Connectivity) – DLL, аналогичная

функциям BDE, но разработанная фирмой Microsoft. Она хранится в файле

ODBC. DLL. Поскольку Microsoft включила поддержку ODBC в свои офис-

ные продукты и для ODBC созданы драйверы практически к любым СУБД,

фирма Borland включила в BDE драйвер, позволяющий использовать ODBC.

BDE поддерживает SQL- стандартизованный язык запросов, позво-

ляющий обмениваться данными с SQL – серверами, такими, как Sybase, Mi-

crosoft SQL, Oracle, Interbase. Эта возможность используется особенно широ-

ко при работе на платформе клиент/ сервер.

Рис.21 Схема связи приложения Delphi с базами данных

Компонент TTable представляет структуру и данные, содержащиеся в

таблице базы данных, а компонент TQuery — набор данных, содержащий

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

BDE

Файлы BD, TBD

Пользователь

Элементы управления

(DataControls)

Элементы связи

(DataSourse)

DataSet -наборы данных

(Query, Table)

нент TStoredProc инкапсулирует хранимые процедуры на SQL-сервере. В

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

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

рассматривается несколько позже.

5.2 Кэширование изменений

По умолчанию все изменения в наборе данных, завершаемые методами

Post, Insert, Delete и т.п., заносятся в базу данных. Однако, возможен и дру-

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

записи, кэшируются — т.е. сохраняются в памяти локально. В этом случае

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

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

базу данных.

Режим кэширования определяется свойством CachedUpdates компо-

нента Table. По умолчанию это свойство равно false и кэширование не про-

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

кэшироваться. Они передаются в базу данных только после выполнения ме-

тода Apply -Updates. Если же после множества изменений выполнить метод

CancelUpdates, то все изменения, произведенные после последнего выпол-

нения ApplyUpdates, отменяются.

Метод CommitUpdates очищает буфер кэша, после чего он готов для

приема новой порции информации.

Проверьте это, построив простое приложение, вид которого показан на

рис. 9.43. Индикатор Кэширование переключает режим кэширования. Кнопка

Фиксация фиксирует все сделанные изменения в базе данных. Кнопка Отме-

на отменяет сделанные изменения. Когда приложение закрывается, надо про-

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

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

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

ответе зафиксировать изменения.

Коды этого приложения очень простые. Для таблицы Tablel свойство

CachedUpdates первоначально надо задать равным true. В приложение мож-

но ввести переменную modif, которая будет фиксировать наличие не сохра-

ненных изменений. Ее можно объявить как типизированную константу: