|
Диплом Программная система Аттестации ИТ-специалистовзапросы ведут себя в соответствии с правилами для локальных запросов, что означает режим автоматической фиксации транзакций, если только не установлено явное управление транзакциями или режим группового выполнения; SHARED NOAUTOCOMMIT разрешает совместное использование, но режим неявной фиксации транзакций не используется. Поведение прямых запросов зависит от типа сервера. Предопределенное значение для серверов Informix — SHARED AUTOCOMMIT, для остальных серверов SQL — NOT SHARED. Режимы SHARED AUTOCOMMIT и SHARED NOAUTOCOMMIT не поддерживаются некоторыми предложениями прямых запросов, в этом случае следует использовать явное управление транзакциями через функции приложения. SQLQRYMODE — определяет режим выполнения запросов, возможные значения приведены в таблице. Таблица 1.1 Режимы выполнения запросов. |Значение |Режим |Комментарий | |NULL |Сервер-локальный |Запрос направляется сначала на сервер, | | | |затем, при невозможности выполнения, | | | |выполняется локально | |SERVER |Только сервер |Запрос направляется только на сервер, в | | | |случае невозможности выполнения, отменяется| |LOCAL |Только локальный |Запрос выполняется исключительно локально | Значение по умолчанию — NULL. На получаемый результат запросов может влиять установленный языковый драйвер, если локальные базы данных и базы SQL имеют различные кодовые страницы (см. выше). Для устранения подобных ошибок необходимо установить для параметра значение SERVER, блокируя таким образом, выполнение запросов в локальных базах данных. Type определяет тип используемого сервера. Значение SERVER определяет использование SQL-сервера. Значение FILE определяет использование обычных серверов, основанных на файловой системе. User Name — задает имя пользователя для доступа к серверу. Version — версия драйвера SQL Links. Для доступа к серверу SQL необходимо иметь соответствующий псевдоним. Базовый псевдоним для каждого используемого драйвера SQL Links создается автоматически при первом изменении параметров драйвера после инсталляции. 1.5 Использование SQL В этом разделе будут рассмотрены различные аспекты применения запросов SQL в приложениях, использующих базы данных. Для реализации запросов в Delphi 7.0 существует специальный компонент — TQuery, расположенный на странице Data Access Палитры компонентов. Он имеет много общих свойств с TTable и тоже используется для открытия наборов данных. В то же время TQuery обладает рядом свойств и методов, которые позволяют использовать все преимущества запросов SQL для работы с данными. Так, применение TQuery дает возможность работать с данными нескольких таблиц в одном запросе, отбирать данные сразу по нескольким критериям. Однако следует помнить, что использование SQL ведет к некоторому усложнению программного кода приложения. Кроме того, создание эффективного запроса — дело далеко не простое и требует наличия определенного опыта в этой области. Запросы SQL бывают статическими и динамическими. Статические запросы полностью создаются при отладке приложения, а динамические могут изменять свои параметры при выполнении приложения. Приложения Delphi 7.0 при помощи механизма запросов SQL могут использовать данные: • таблиц Paradox и dBase, используя синтаксис локального SQL; • локального сервера Interbase, синтаксис языка поддерживается полностью; • удаленных серверов SQL через драйверы SQL Links. 1.6 Особенности создания систем клиент/сервер Возможность создания приложений для работы в составе систем клиент/сервер, бесспорно, стала большим преимуществом Delphi 7.0. Инструментарий для разработки таких приложений интегрирован в составе среды разработчика. Приложения Delphi 7.0, функционирующие на станции-клиенте, используя возможности BDE и драйверов SQL Links и ODBC, могут получать доступ к данным удаленных SQL-серверов. В качестве серверов могут быть использованы Informix, Interbase, Microsoft SQL Server, Oracle, Sybase. Кроме этого, через BDE и установленный драйвер ODBC возможен доступ к таким базам, как DB2, Btrieve, Microsoft Access и другим, для которых существует соответствующий драйвер ODBC. Приложение, функционирующее на станции-клиенте, обычно создается отдельно и для уже работающих серверов баз данных. Поэтому, для создания работоспособной системы клиент/сервер необходимо решить ряд проблем связывания рабочих станций, совместимости данных при работе одного приложения-клиента с различными типами серверов, оптимизации производительности. 1.7 Совместимость / эффективность Как известно, при создании приложений для систем клиент/сервер всегда приходится решать проблему выбора между универсальностью и производительностью. С одной стороны, чем большее количество типов серверов поддерживается приложением, тем лучше. Но в этом случае значительно понижается производительность. Впрочем, способ решения этой проблемы зависит от предназначения создаваемого приложения. Иногда можно пожертвовать совместимостью, а иногда оказывается не так уж и важна производительность. Совместимость по данным в значительной степени зависит от используемых приложением компонентов. При применении ТТаblе проблем практически не возникает, а вот при использовании TQuery приходится накладывать ограничения на синтаксис предложений SQL в зависимости от диалекта SQL, используемого сервером. Производительность приложения-клиента может быть повышена при использовании хранимых процедур сервера, однако это приводит к дополнительной специализации программы. В зависимости от типа оборудования, на котором работает приложение, может возникнуть необходимость в поддержке нескольких коммуникационных протоколов. Эта проблема решается инсталляцией соответствующего программного обеспечения на станции-клиенте и сервере, однако, это решение должно быть предусмотрено еще на этапе проектирования системы клиент/сервер. Информацию об инсталлированном протоколе необходимо включить в драйве SQL Links. В дальнейшем реализация архитектуры "клиент-сервер" будет рассматриваться для сервера Borland Interbase. Объяснить такой выбор нетрудно. Во-первых, Interbase - "родной" сервер для Delphi 7.0 (поэтому для доступа к нему не нужно устанавливать дополнительных драйверов SQL Links, что необходимо при работе из приложений, написанных на Delphi 7.0, с Oracle, Sybase и другими СУБД). Во вторых, в поставку Delphi входит локальный (однопользовательский, на 2 одновременных подключения) сервер Local Borland Interbase. Доступен также и Interbase для Windows 95 на 4 пользователя. Локальный Interbase может использоваться для отладочных целей. После того, как приложение отлажено на локальной версии SQL-сервера, происходит масштабирование приложения (upsizing). БД переносится на сетевой сервер, а изменения в клиентских приложениях при этом минимальны - необходимо изменить псевдоним БД и, может быть, скорректировать некоторые параметры соединения приложения с сервером. 1.8 Перенос данных При переносе приложений, ранее разработанных для применения в архитектуре "файл-сервер", требуется не только частично или полностью переписывать приложения клиентов, но и преобразовывать локальную БД в серверную. Для этого под управлением серверной СУБД (например, Interbase) создают БД на сервере, куда затем "перекачивают" данные из локальных СУБД реализованных, например, с помощью Paradox. Основная проблема, встающая в этом случае - несовместимость некоторых форматов данных или их отсутствие. Например, Interbase не поддерживает поля типа Boolean (Logical), и их необходимо реализовывать при помощи столбцов типа CHAR(1); Interbase не поддерживает автоинкрементные поля Paradox - для обеспечения уникальности значений в числовых полях в БД Interbase используют генераторы и т.д. При возникновении подобных проблем следует изучить вопросы совместимости типов данных локальной СУБД и выбранной серверной СУБД. Преобразование делится на два этапа: • • модернизация баз данных до уровня сервера; • преобразование приложений в приложения-клиенты. Преобразование позволяет поднять систему приложение-база данных на качественно новый уровень, так как архитектура клиент/сервер имеет ряд важных преимуществ. Среди них многопользовательский доступ, возможность работы с множествами, а не с отдельными записями, использование доступа ко всем данным, а не к отдельным таблицам. Преобразование базы данных в сервер содержит ряд этапов. 1. Создание метаданных, основанных на структуре базы данных. 2. Перенос данных на сервер. 3. Разделение данных по типам. 4. Создание паролей и интеграция данных. 5. Контроль транзакций. 6. Управление доступом к данным. 7. Проверка данных. Delphi обеспечивает два способа преобразования баз данных: • использование возможностей утилиты Database Desktop для преобразования таблиц в формат SQL; • использование при создании приложения компонента TBatchMove. Оба эти способа копируют структуру данных и переносят сами данные в формат SQL-сервера. В новую структуру метаданных могут быть добавлены новые элементы: индексы, хранимые процедуры, триггеры и т. д. Для некоторых типов серверов более эффективным может стать ручное создание структуры метаданных с дальнейшим переносом данных, как предлагается выше. Приложения, созданные для работы с локальными базами данных, могут быть приспособлены для систем клиент/сервер только путем внесения ряда исправлений в исходный код. В простейшем случае, при полном совпадении структуры преобразованных и исходных данных необходимо лишь изменить параметры свойств DatabaseName используемых компонентов TTable и TQuery и добавить в приложение компонент TDatabase. Однако такое бывает не часто. Локальные приложения используют, в основном, компоненты TTable, реже TQuery. Однако, в зависимости от особенностей конкретного приложения, более эффективным может стать переход на использование TQuery, особенно при использовании таблиц с большим числом записей. Если приложение использует арифметические или логические функции, то желательно заменить их соответствующими хранимыми процедурами сервера. Этим достигается повышение производительности, так как сервер обладает большей мощностью, чем станция-клиент, и разгружаются сетевые каналы связи. Часто бывает необходимым включить в исходный код приложения метода поддержки транзакций, так как в большинстве однопользовательских систем они не используются. Также, нередко возникает необходимость в создании кода для регистрации пользователя на сервере. 1.9 Применение локального сервера InterBase Локальный Interbase Server является версией сервера Borland Interbase 6.0 для Windows и содержит полный набор функций для локального однопользовательского применения. При разработке приложений клиент/сервер локальный Interbase Server может использоваться в качестве модели сервера или для преобразования баз данных в серверы SQL (см. "Перенос данных"), кроме этого, он может применяться в качестве процессора базы данных в работ локальных приложений. Его использование позволит разработчику повысит надежность разрабатываемого приложения и избежать возможной потери данных при тестировании "сырых" приложений. Если база данных, для работы с которой предназначено разрабатываемое приложение, уже существует, то Interbase Server может быть использован для решения ряда других вопросов: 1. Для поиска и преобразования нестандартного синтаксиса запросов SQL и неиспользуемых типов данных; 2. Для создания приложений, использующих Interbase в качестве сервера; 3. Применение Windows ISQL возможно для создания базы Interbase, предложения SQL которой могут быть использованы в базе сервера приложения 4. В качестве проверочной базы перед последующим соединением приложения с настоящим сервером. Для этого необходимо только изменить псевдоним, используемый компонентом TDatabase приложения. Если настоящая база данных еще не существует, то Interbase Server может использоваться для создания прототипа используемых данных, на котором будет проверяться работоспособность приложения. Если приложение разрабатывается для уже существующей базы функционирующей на сервере Interbase: • перед проверкой работоспособности приложения на реальных данных может использоваться утилита локального сервера Interbase для создания резервных копий данных; • желательно перенести на локальный сервер небольшую, но представительную выборку данных и отлаживать работу приложения на ней. При проведении преобразования локальной базы данных до уровня систем клиент/сервер, локальный сервер Interbase используется в качестве промежуточного сервера, на котором проверяется новая структура данных. После про верки данные переносятся на целевой сервер. 1.10 Локальный сервер InterBase Локальный сервер Interbase представляет собой версию Borland Interbase Workgroup Server 6.0 для одного пользователя, работающую под управлением Windows. Этот сервер содержит в своем составе утилиты Windows ISQL и Server Manager, которые также могут использоваться с полномасштабным сервером Interbase. Доступ к базам данных, управляемым локальным сервером Interbase, осуществляется через Windows ISQL или само приложение. Сервер может использоваться в среде разработчика Delphi для решения ряда задач создания приложений и наборов данных: 1. Под управлением локального сервера Interbase могут создаваться полноценные базы данных. 2. Проводится тестирование приложений клиент/сервер, причем Interbase используется в качестве модели реального сервера. 3. При преобразовании локальных СУБД до уровня возможностей сервера SQL, локальный Interbase может использоваться как промежуточная ступень (см. раздел "Особенности построения приложений для архитектуры клиент/сервер"). Доступ к данным сервера осуществляется через BDE и SQL Links. Сервер поддерживает стандарт языка ANSI SQL 92, доступ к предложениям которого осуществляется через Windows ISQL или приложение. Некоторые расширения SQL, поддерживаемые сервером, конфликтуют с диалектом SQL3, среди них хранимые процедуры, триггеры и данные типа BLOB. Используемые локальным сервером Interbase форматы данных представлены в таблице. Таблица 1.2 Основные форматы данных Interbase. |Формат данных|Типы данных | | | | |Числовой |Smallint, Integer, Float, Double Precision, Numeric, | | |Decimal | |Символьный |Char, VarChar | |Календарный |Data | |BLOB |BLOB | Естественно, что локальный Interbase Server уступает полномасштабному варианту. Среди важнейших отличий можно отметить отсутствие следующих возможностей: • BLOB фильтров; • массивов данных; • отслеживания событий; • функций, определяемых пользователем; • ограничена поддержка записи через журнал (WAL). В локальном сервере реализована система защиты данных. Предусматривается возможность регистрации пользователя с использованием паролей. Анализ существующей системы. Обзор литературы Поиск информации о существующих системах аттестации ИТ-специалистов привёл к выводу, что доминирующая часть таких систем работает через Web- интерфейс, вот примеры таких систем: 1. Сертификация Microsoft Office User Specialist (MOUS) - всемирно признанный стандарт для оценки навыков работы с бизнес приложениями Microsoft Office [8] http://www.specialist.ru/MOUS/ 2. Сервера - профессиональной оценки знаний в области информационных технологий http://tests.specialist.ru/ 3. А+ сертификация – программа тестирования, предоставленная компьютерной ассоциацией CompTIA, которая подтверждает компетенцию начинающих специалистов по обслуживанию компьютерной техники с опытом работы 6 месяцев или прошедших подготовку на соответствующих курсах. Любой, кто хочет получить признанное во всем мире удостоверение компетентного профессионала, может сдать экзамены А+. Программа сертификации поддерживается основными производителями и продавцами аппаратного и программного обеспечения. Тесты, впервые стали доступны в 1993 г., были пересмотрены к 31 июля 1998 г и последний раз обновлены в 2001 году. Наличие у человека сертификата означает, что он обладает достаточными знаниями, навыками (включая навыки общения с клиентами) для успешной работы в качестве технического специалиста в вычислительных центрах, что подтверждается экспертами ведущих компаний в области компьютерных технологий. Экзамен охватывает широкий диапазон аппаратных и программных технологий, но не привязан к конкретным программам или производителям http://www.specialist.ru/aplus/aplus.asp 4. Фирма Virtual University Enterprises образована 10 апреля 1997 года для проведения электронных сертификационных экзаменов. Главные офисы фирмы расположены в Миннеаполисе, Нидерландах и Сиднее. Фирма имеет центры тестирования по всему миру. Процесс сдачи экзамена одинаков для всех центров тестирования VUE. Необходимо произвести регистрацию на экзамен, используя форму, расположенную на сайте или лично приехать в Центр Компьютерного Обучения, далее оплатить экзамен, после чего Вы будете записаны на сдачу экзамена. После оплаты регистрации система тестирования пересылает экзамен из банка данных VUE. По окончании тестирования происходит автоматическая печать отчета с результатами. При успешной сдаче экзамена кандидат получает по почте соответствующий сертификат от вендора (Microsoft и пр.). Сертификация Microsoft, CompTIA, Novell, PTC, Sybase, LPI, Ericsson, CIW, Informix является объективным критерием оценки компетентности компьютерных специалистов, признаваемым во всем мире. http://www.specialist.ru/VUE/vue.asp 5. Cертификация ECDL (European Computer Driving Licence). Главная задача обеспечить международный стандарт оценки навыков работы с персональным компьютером. Фонд ECDL-F, осуществляющий проведение и контроль сертификации по всему миру, был создан в 1997 году при поддержке Европейского компьютерного общества CEPIS. Сертификат (документ, подтверждающий квалификацию), который получает пользователь после успешной сдачи экзаменов, называется ECDL - European Computer Driving Licence (за пределами Европы сертификат называется ICDL - International Computer Driving Licence). Сертификат признан более чем в 50 странах мира, включая Великобританию, Германию, Норвегию, Швецию, Финляндию, Канаду, Австралию, Египет и многие другие. ECDL-F гарантирует качество и соблюдение единых требований к работе центров тестирования. Наличие у человека сертификата означает, что он обладает достаточными знаниями, навыками (включая навыки общения с клиентами) для успешной работы в качестве технического специалиста в вычислительных центрах, что подтверждается экспертами ведущих компаний в области компьютерных технологий. Экзамен охватывает широкий диапазон аппаратных и программных технологий, но не привязан к конкретным программам или производителям. Сертификация считается пройденной, если Вы успешно сдали 1 теоретический и 6 практических модулей: - Основные положения информатики (Basic Concepts of Information Technology) (теоретический) - Применение компьютера и управление файлами (Using the Computer and Managing Files) - Обработка текстов (Word Processing) - Электронные таблицы (spreadsheets) - Базы данных (Databases/Filing Systems) - Презентации (Presentation) - Обмен информацией (Information and Communication) http://www.specialist.ru/ECDL/ http://www.brainbench.com/xml/bb/homepage.xml Другой распространённый вариант – это интервью – как метод аттестации с привлечением сторонних экспертов и комиссии по оценке результатов аттестации.[1] Задачей настоящего дипломного проекта является решение «локальной», для конкретного предприятия проблемы аттестации ИТ-специалистов, как можно более приблизив тематику вопросов к задачам, выполняемым на этом, отдельно – взятом предприятии ОАО «Троицкая ГРЭС». Архитектура программной системы Архитектура программной системы представлена на рисунке 3.1 и рисунке 3.1а. 4 Разработка структуры баз данных i.Общая характеристика реляционной модели данных Основы реляционной модели данных были впервые изложены в статье Е.Кодда [3] в 1970 г. Эта работа послужила стимулом для большого количества статей и книг, в которых реляционная модель получила дальнейшее развитие. Наиболее распространенная трактовка реляционной модели данных принадлежит К.Дейту[4]. Согласно Дейту [4], реляционная модель состоит из трех частей: . Структурной части. . Целостной части. . Манипуляционной части. Структурная часть описывает, какие объекты рассматриваются реляционной моделью. Постулируется, что единственной структурой данных, используемой в реляционной модели, являются нормализованные n-арные отношения. Целостная часть описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных базах данных. Это целостность сущностей и целостность внешних ключей. Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными - реляционную алгебру и реляционное исчисление. В данной главе рассматривается структурная часть реляционной модели. Типы данных Любые данные, используемые в программировании, имеют свои типы данных. Важно! Реляционная модель требует, чтобы типы используемых данных были простыми. Для уточнения этого утверждения рассмотрим, какие вообще типы данных обычно рассматриваются в программировании. Как правило, типы данных делятся на три группы: - Простые типы данных. - Структурированные типы данных. - Ссылочные типы данных. Простые типы данных Простые, или атомарные, типы данных не обладают внутренней структурой. Данные такого типа называют скалярами. К простым типам данных относятся следующие типы: - Логический. - Строковый. - Численный. Различные языки программирования могут расширять и уточнять этот список, добавляя такие типы как: - Целый. - Вещественный. - Дата. - Время. - Денежный. - Перечислимый. - Интервальный. - И т.д.… Конечно, понятие атомарности довольно относительно. Так, строковый тип данных можно рассматривать как одномерный массив символов, а целый тип данных - как набор битов. Важно лишь то, что при переходе на такой низкий уровень теряется семантика (смысл) данных. Если строку, выражающую, например, фамилию сотрудника, разложить в массив символов, то при этом теряется смысл такой строки как единого целого. Структурированные типы данных Структурированные типы данных предназначены для задания сложных структур данных. Структурированные типы данных конструируются из составляющих элементов, называемых компонентами, которые, в свою очередь, могут обладать структурой. В качестве структурированных типов данных можно привести следующие типы данных: - Массивы - Записи (Структуры) С математической точки зрения массив представляет собой функцию с конечной областью определения. Например, рассмотрим конечное множество натуральных чисел [pic] называемое множеством индексов. Отображение [pic] из множества [pic]во множество вещественных чисел [pic]задает одномерный вещественный массив. Значение этой функции для некоторого значения индекса [pic]называется элементом массива, соответствующим [pic]. Аналогично можно задавать многомерные массивы. Запись (или структура) представляет собой кортеж из некоторого декартового произведения множеств. Действительно, запись представляет собой именованный упорядоченный набор элементов [pic], каждый из которых принадлежит типу [pic]. Таким образом, запись [pic]есть элемент множества [pic]. Объявляя новые типы записей на основе уже имеющихся типов, пользователь может конструировать сколь угодно сложные типы данных. Общим для структурированных типов данных является то, что они имеют внутреннюю структуру, используемую на том же уровне абстракции, что и сами типы данных. Поясним это следующим образом. При работе с массивами или записями можно манипулировать массивом или записью и как с единым целым (создавать, удалять, копировать целые массивы или записи), так и поэлементно. Для структурированных типов данных есть специальные функции - конструкторы типов, позволяющие создавать массивы или записи из элементов более простых типов. Работая же с простыми типами данных, например с числовыми, мы манипулируем ими как неделимыми целыми объектами. Чтобы "увидеть", что числовой тип данных на самом деле сложен (является набором битов), нужно перейти на более низкий уровень абстракции. На уровне программного кода это будет выглядеть как ассемблерные вставки в код на языке высокого уровня или использование специальных побитных операций. Ссылочные типы данных Ссылочный тип данных (указатели) предназначен для обеспечения возможности указания на другие данные. Указатели характерны для языков процедурного типа, в которых есть понятие области памяти для хранения данных. Ссылочный тип данных предназначен для обработки сложных изменяющихся структур, например деревьев, графов, рекурсивных структур. Типы данных, используемые в реляционной модели Собственно, для реляционной модели данных тип используемых данных не важен. Требование, чтобы тип данных был простым, нужно понимать так, что в реляционных операциях не должна учитываться внутренняя структура данных. Конечно, должны быть описаны действия, которые можно производить с данными как с единым целым, например, данные числового типа можно складывать, для строк возможна операция конкатенации и т.д. С этой точки зрения, если рассматривать массив, например, как единое целое и не использовать поэлементных операций, то массив можно считать простым типом данных. Более того, можно создать свой, сколь угодно сложных тип данных, описать возможные действия с этим типом данных, и, если в операциях не требуется знание внутренней структуры данных, то такой тип данных также будет простым с точки зрения реляционной теории. Например, можно создать новый тип - комплексные числа как запись вида [pic], где [pic]. Можно описать функции сложения, умножения, вычитания и деления, и все действия с компонентами [pic]и [pic]выполнять только внутри этих операций. Тогда, если в действиях с этим типом использовать только описанные операции, то внутренняя структура не играет роли, и тип данных извне выглядит как атомарный. Именно так в некоторых пост реляционных СУБД реализована работа со сколь угодно сложными типами данных, создаваемых пользователями. Домены В реляционной модели данных с понятием тип данных тесно связано понятие домена, которое можно считать уточнением типа данных. Домен - это семантическое понятие. Домен можно рассматривать как подмножество значений некоторого типа данных имеющих определенный смысл. Домен характеризуется следующими свойствами: . Домен имеет уникальное имя (в пределах базы данных). . Домен определен на некотором простом типе данных или на другом домене. . Домен может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для данного домена. . Домен несет определенную смысловую нагрузку. Например, домен [pic], имеющий смысл "возраст сотрудника" можно описать как следующее подмножество множества натуральных чисел: [pic] Если тип данных можно считать множеством всех возможных значений данного типа, то домен напоминает подмножество в этом множестве. Отличие домена от понятия подмножества состоит именно в том, что домен отражает семантику, определенную предметной областью. Может быть несколько доменов, совпадающих как подмножества, но несущие различный смысл. Например, домены "Вес детали" и "Имеющееся количество" можно одинаково описать как множество неотрицательных целых чисел, но смысл этих доменов будет различным, и это будут различные домены. Основное значение доменов состоит в том, что домены ограничивают сравнения. Некорректно, с логической точки зрения, сравнивать значения из различных доменов, даже если они имеют одинаковый тип. В этом проявляется смысловое ограничение доменов. Синтаксически правильный запрос "выдать список всех деталей, у которых вес детали больше имеющегося количества" не соответствует смыслу понятий "количество" и "вес". Замечание. Понятие домена помогает правильно моделировать предметную область. При работе с реальной системой в принципе возможна ситуация когда требуется ответить на запрос, приведенный выше. Система даст ответ, но, вероятно, он будет бессмысленным. Замечание. Не все домены обладают логическим условием, ограничивающим возможные значения домена. В таком случае множество возможных значений домена совпадает с множеством возможных значений типа данных. Отношения, атрибуты, кортежи отношения Определения и примеры Фундаментальным понятием реляционной модели данных является понятие отношения. В определении понятия отношения будем следовать книге К. Дейта Определение 1. Атрибут отношения есть пара вида . Имена атрибутов должны быть уникальны в пределах отношения. Часто имена атрибутов отношения совпадают с именами соответствующих доменов. Определение 2. Отношение [pic], определенное на множестве доменов [pic](не обязательно различных), содержит две части: заголовок и тело. Заголовок отношения содержит фиксированное количество атрибутов отношения: [pic] Тело отношения содержит множество кортежей отношения. Каждый кортеж отношения представляет собой множество пар вида : [pic] таких что значение [pic]атрибута [pic]принадлежит домену [pic] Отношение обычно записывается в виде: [pic], или короче [pic], или просто [pic]. Число атрибутов в отношении называют степенью отношения. Мощность множества кортежей отношения называют мощностью отношения. Возвращаясь к математическому понятию отношения, введенному в предыдущей главе, можно сделать следующие выводы: Вывод 1. Заголовок отношения описывает декартово произведение доменов, на котором задано отношение. Заголовок статичен, он не меняется во время работы с базой данных. Если в отношении изменены, добавлены или удалены атрибуты, то в результате получим уже другое отношение (пусть даже с прежним именем). Вывод 2. Тело отношения представляет собой набор кортежей, т.е. подмножество декартового произведения доменов. Таким образом, тело отношения собственно и является отношением в математическом смысле слова. Тело отношения может изменяться во время работы с базой данных - кортежи могут изменяться, добавляться и удаляться. 2 Предварительная структура базы данных, нормализация Прежде чем начать проектирование базы данных, необходимо определиться какие данных нам необходимо хранить и их взаимосвязь. Таблица 4.1 Поля таблицы QUESTIONS |QUESTIONS – список вопросов | |ID |Integer |Идентификатор вопроса | |Q_TEXT |BLOB |Текст вопроса | |QPICTURE |BLOB |Граф. часть к вопросу | |CID |INTEGER |Категория вопроса | |Q1 |SMALLINT |Балл за вариант ответа | |Q2 |SMALLINT |Балл за вариант ответа | |Q3 |SMALLINT |Балл за вариант ответа | |Q4 |SMALLINT |Балл за вариант ответа | |Q5 |SMALLINT |Балл за вариант ответа | |Q6 |SMALLINT |Балл за вариант ответа | |Q7 |SMALLINT |Балл за вариант ответа | |Q8 |SMALLINT |Балл за вариант ответа | |Q9 |SMALLINT |Балл за вариант ответа | Таблица 4.2 Поля таблицы USERS |USERS – список специалистов | |ID |INTEGER |Идентификатор специалиста | |GID |INTEGER |Принадлежность пользователя к | | | |группе | |TID |INTEGER |Принадлежность пользователя к типу| |LOGIN |VARCHAR |Ф.И.О специалиста | |PWD |VARCHAR |Пароль специалиста | Таблица 4.3 Поля таблицы STORE |STORE – данные специалиста | |ID |INTEGER |Идентификатор специалиста | |UID |INTEGER |Отвечавший пользователь | |CID |INTEGER |Категория вопросов | |DATED |VARCHAR |Дата аттестации | |PERCS | SMALLINT |Результат в % | Таблица 4.4 Поля таблицы TYPES |TYPES – Типы пользователя | |ID |INTEGER |Идентификатор пользователя | |FLAGS |INTEGER |Признак ответа | |NAME |VARCHAR |Название типа | Таблица 4.5 Поля таблицы QGROUPS |QGROUPS – Категории вопросов | |ID |INTEGER |Идентификатор пользователя | |NAME |VARCHAR |Категория вопроса | Таблица 4.6 Поля таблицы GROUPS |QGROUPS – Группы пользователей | |ID |INTEGER |Идентификатор пользователя | |NAME |VARCHAR |Категория группы | Таблица 4.7 Поля таблицы ASESSIONS |ASESSIONS – Активные сессии | |
|
