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

сылает запрос серверу — программе, управляющей ведением БД, на специальном универсальном языке запросов. Сервер пересылает про­грамме данные, являющиеся результатом поиска в БД по ее запросу. Этот способ удобен тем, что программа — клиент не обязана содер­жать все функции поддержания и ведения БД, этим занимается сер­вер. В результате упрощается написание программ — клиентов. Кро­ме того, к серверу может обращаться любое количество клиентов.

4,4,3, МоЗели Зонным

Для реализации основных функций в ИС используются различ­ные принципы описания данных. Ядром любой БД является модель представления данных. Подробному описанию различных моделей посвящена следующая глава. Пока же рассмотрим реляционную мо­дель данных, ориентированную на организацию данных в виде дву­мерных таблиц. Реляционная модель данных является наиболее уни­версальной, к ней могут быть сведены другие модели.

Важнейшим понятием реляционных моделей данных является сущность. Сущность — это объект любой природы, данные о кото­ром хранятся в БД. Данные о сущности хранятся в двумерных таб­лицах, которые называют реляционными.

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

• один элемент таблицы — один элемент данных;

• все столбцы таблицы содержат однородные по типу данные (це­
лочисленный, числовой, текстовый, и т.д.);

• каждый столбец имеет уникальное имя;

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

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

• записи не должны повторяться;

• количество записей в отношении не ограничено.

Объекты, их взаимосвязи и отношения представлены в виде таб­лиц. Формальное построение таблиц связано с фундаментальным понятием отношение (термин реляционная исходит от английского слова геШюп — отношение).

Для заданных произвольных конечных множеств М,, М₂,..., множество всевозможных наборов вида (ц,, |1₂,..., |1_М), где (и^е |1₂еМ₂,..., |1_ыеМ_1Ч называют их декартовым произведением

_1Ч. Отношением К, определенным на множествах называется подмножество декартова произведения М,х М₂х...> х М_ы. При этом множества М,, М₂,..., М_м называются доменами отношения, а элементы декартова произведения — корте­жами отношения. Число N определяет степень отношения, количе­ство кортежей — его мощность.

В реляционной таблице каждый столбец есть домен (его альтер­нативное название поле), а совокупность элементов каждой строки — кортеж (или запись).

Строка заголовков называется схемой отношения. Например, схе­ма отношения СТУДЕНТ может быть следующей:

СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ФАКУЛЬТЕТ, КУРС, ГРУППА), здесь СТУДЕНТ - отношение, а ФАМИЛИЯ, ИМЯ и т.д. — атрибуты.

В отношении каждый конкретный экземпляр сущности пред­ставляется строкой, которая называется кортежем (или записью).

Следующая таблица представляет отношение СТУДЕНТ (рис. 4.13).

Отношение СТУДЕНТ (вся) таблица

Схема отношения (строка заголовков)

Атрибуты (поля) (отдельные заголовки)

Строка (запись, кортеж)

Рис. 4.13. Отношение СТУДЕНТ

Первичным ключом отношения называется поле или группа по­лей, однозначно определяющие запись. В отношении СТУДЕНТ пер­вичным ключом может быть поле ФАМИЛИЯ, если во всем списке нет однофамильцев — это будет простой ключ. Если есть однофа­мильцы, то совокупность полей — фамилия, имя, отчество — созда­дут составной первичный ключ. На практике обычно в качестве клю­чевого выбирают поле, в котором совпадения заведомо исключены.

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

Свойства первичного ключа:

• уникальность — в таблице может быть назначен только один пер­
вичный ключ, у составного ключа поля могут повторяться, но
не все;

• неизбыточность — не должно быть полей, которые, будучи уда­
ленными из первичного ключа, не нарушат его уникальность;

• в состав первичного ключа не должны входить поля типа, ком­
ментарий и графическое.

Чтобы избежать повторяющихся записей, приходят к связыва­нию таблиц. Например, если в отношении СТУДЕНТ надо описать вуз, в котором он обучается, то, на первый взгляд, можно было бы включить в отношение следующие поля СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ФАКУЛЬТЕТ, КУРС, ГРУППА, НАЗВАНИЕ вуза, АДРЕС). Но при заполнении такой таблицы для каждого сту­дента придется указывать довольно длинное наименование вуза и его адрес, что неудобно. Более того, любая незначительная ошибка во вводе этих полей приведет к нарушению непротиворечивости базы данных. Например, ошибка в адресе вуза приведет к тому, что в БД появятся два вуза с одинаковым наименованием и разными адреса­ми. Поступают в таком случае так: в отношение СТУДЕНТ вводят поле «код вуза» (целое число) и добавляют еще одно отношение ВУЗ (код вуза, название, адрес). СТУДЕНТ и ВУЗ при этом будут связа­ны по полю «код вуза».

СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ФАКУЛЬТЕТ, КУРС, ГРУППА, КОД вуза)
________________________________________________ I

ВУЗ (КОД вуза, НАЗВАНИЕ, АДРЕС, ТЕЛЕФОН)

При работе с такими таблицами повторяться могут только дан­ные в поле «КОД вуза», а все необходимые сведения о вузе можно взять из отношения ВУЗ. Заметим при этом, что ввод в поле «КОД вуза» целого числа, вместо длинного названия, принесет гораздо меньше ошибок. В отношении ВУЗ поле «КОД вуза» будет первич­ным ключом, а в отношении СТУДЕНТ поле «КОД вуза» будет вне­шним ключом.

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

записями обеих таблиц. Связи бывают нескольких типов «один к од­ному», «один ко многим», «многие ко многим». В вышеприведенном примере была установлена связь «один ко многим», т.е. одной записи в таблице ВУЗ соответствуют многие записи в таблице СТУДЕНТ.

4,4,4, Проектирование 603 Зонным

Проектирование базы данных является одним из этапов жизнен­ного цикла ИС. Ввиду сложности этот этап выполняется, как пра­вило, коллективом разработчиков и включает следующие работы:

• анализ предметной области;

• проектирование и непосредственно кодирование (создание зап­
росов и приложений);

• тестирование и сопровождение.

Онолиз предметной области

Проектирование баз данных начинается с анализа предметной области, в которой будет работать ИС. Как правило, этот этап вы­полняется разработчиками ИС совместно с заказчиком. Обычным языком описываются информационные объекты, их свойства, их вза­имосвязи, описываются пожелания будущих пользователей. Резуль­татом такой работы является техническое задание на разработку ИС.

В техническом задании более строго указывается список исход­ных данных, список запросов к ИС, список выходных данных, ого­варивается интерфейс, определяющий переход от представления дан­ных в БД к представлению, принятому среди пользователей, и обратно. В общем случае пользователи представляют данные в виде документов различных видов, от произвольных текстов до справок и таблиц фиксированного формата. Затем собственно и начинается проектирование базы данных.

Проектирование баз данных осуществляется на двух уровнях — физическом и логическом. На физическом уровне решаются вопросы размещения данных на внешних носителях. Во многом эта работа выполняется СУБД автоматически без участия разработчика.

На логическом уровне составляется общий список полей, кото­рый может насчитывать от единиц до тысяч. Описывают каждое поле по типу данных. Общий список полей разбивается на основные таб-

лицы. Дальнейшее рассмотрение информационной структуры при­водит к разбиению — нормализации — основных таблиц на более мел­кие с целью избежания многократно повторяющихся данных в за­писях, что уменьшает объем памяти, занимаемый базой данных на диске, и обеспечивает непротиворечивость данных в БД.

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

Первая нормальная форма. Отношение называется приведенным к первой нормальной форме, если все его атрибуты неделимы. На­пример, отношение, содержащее поле ФИО, не приведено к первой нормальной форме, если в запросах БД требуется выделить отдель­но фамилию или имя. Разработчики БД изначально строят так исход­ное отношение, чтобы оно было в первой нормальной форме.

Вторая нормальная форма. Для приведения отношений ко второй нормальной форме введем понятие функциональной зависимости.

Функциональная зависимость полей — это зависимость, при кото­рой в строке определенному значению ключевого поля соответству­ет только одно значение не ключевого поля. Функционально не клю­чевое поле зависит от составного ключа, но не зависит от любого поля, входящего в составной ключ.

Например, в отношении СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕ­СТВО, ФАКУЛЬТЕТ, КУРС, ГРУППА) первичным ключом являет­ся совокупность полей ФАМИЛИЯ + ИМЯ + ОТЧЕСТВО. Поля ФАКУЛЬТЕТ, КУРС, ГРУППА функционально полно зависят от со­ставного ключа.

Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме, и каждое не ключевое поле функционально полно зависит от составного ключа. Например, в отношении УСПЕВАЕМОСТЬ (НОМЕР ЗАЧЕТКИ, ФАМИЛИЯ, ДИСЦИПЛИНА, ОЦЕНКА) составным ключом является совокуп­ность НОМЕР ЗАЧЕТКИ + ДИСЦИПЛИНА. Это отношение нахо­дится в первой нормальной форме, но оно не находится во второй нормальной форме, так как поле ФАМИЛИЯ не имеет полной фун-

кциональной зависимости от составного ключа. Для перевода этого отношения во вторую нормальную форму необходимо исключить из него поле ФАМИЛИЯ, так как оно функционально зависит от НО­МЕРА ЗАЧЕТКИ. Т.е. исходное отношение необходимо разбить на два связанных отношения УСПЕВАЕМОСТЬ (НОМЕР ЗАЧЕТКИ, ДИСЦИПЛИНА, ОЦЕНКА) и СПИСОК (НОМЕР ЗАЧЕТКИ, ФА­МИЛИЯ). Связь здесь осуществляется по полю НОМЕР ЗАЧЕТКИ.

Третья нормальная форма. Третья нормальная форма позволяет устранить транзитивную зависимость. Транзитивная зависимость су­ществует в отношении, если существуют два описательных поля, в которых первое зависит от ключа, а второе зависит от первого. От­ношение находится в третьей нормальной форме, если оно находит­ся во второй нормальной форме, и каждое не ключевое поле не тран-зитивно зависит от ключа.

Например, в отношении СТУДЕНТ (ФАМИЛИЯ, ФАКУЛЬТЕТ, НАЗВАНИЕ вуза, АДРЕС) поле АДРЕС транзитивно (через поле НАЗВАНИЕ вуза) зависит от ключа ФАМИЛИЯ. При заполнении экземплярами такого отношения поле Адрес будет многократно по­вторяться. Для устранения транзитивной зависимости в классе ис­пользуется расщепление отношения на несколько. Например, отно­шение СТУДЕНТ расщепляется на два:

СТУДЕНТ (ФАМИЛИЯ, ФАКУЛЬТЕТ, НАЗВАНИЕ вуза),

ВУЗ (НАЗВАНИЕ вуза, АДРЕС) связь по полю НАЗВАНИЕ вуза.

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

Проектирование

Дальнейшая работа над проектом связана с конкретной СУБД, поэтому, предварительно учитывая требования заказчика и намечен­ную архитектуру ИС, выбирают СУБД. Мы рассмотрим эту часть на примере СУБД М5 Ассе§8 (разработка Мюгозой).

СУБД Ассезз является системой управления базами данных ре­ляционного типа. Всю базу данных по умолчанию Ассезз хранит на диске в виде одного файла с расширением *.тс!Ъ, а вообще Ассезз поддерживает ряд стандартов БД (сШазе, Рагайох и др). Данные хра­нятся в виде таблиц, строки которых состоят из наборов полей оп­ределенных типов. С каждой таблицей могут быть связаны индексы

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

Типичными операциями над базами данных являются:

• работа с таблицами (создание, модификация, удаление таблиц,
создание и модификация схем взаимосвязи существующих таб­
лиц);

• ввод данных в таблицы непосредственно или с помощью фор­
мы, проверку вводимых данных;

• поиск данных в таблицах по определенным критериям (выпол­
нение запросов);

• создание отчетов о содержимом базы данных.

Таблицы. Работа в Ассе88 начинается с определения реляционных таблиц и их полей, которые будут содержать данные, т.е. создания макета таблицы. Вид рабочего окна Ассе88 представлен на рис. 4.14.

Рис. 4.14. Вид рабочего окна М5Ассе§8

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

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

Рис. 4.15. Создание таблиц в режиме конструктора

тор свойств полей, где указываются свойства (если поле текстовое — его длина, числовое - тип целый или вещественный). Редактор свойств полей имеет скрытые элементы управления. Например, щел­чок по полю ввода «размер поля» приведет к появлению элемента

списка

, в результате нажатия на который появляется раскрываю-

щийся список выбора свойств. В завершении создания таблицы при

записи задается имя таблицы. Схема отношения может быть отредак­тирована путем повторного открытия ее в режиме конструктора. Далее определяются реляционные связи между таблицами, для

чего открывается окно «Схема данных» нажатием кнопки Д"1 в окне

Ассе88. В окне «Добавление таблицы» выбираем таблицы, которые следует связать. Затем методом перетаскивания указываем связывае­мые поля, после чего появляется окно «Изменение связей» (рис. 4.16.), в котором указываем тип обеспечения целостности. Заверша­ется этот этап нажатием кнопки «Создать».

Поиск по сайту: