• Основные классы субд. Реляционная субд

    В начало

    Базы данных и СУБД

    Информационные системы

    Одним из важнейших условий обеспечения эффективного функционирования любой организации является наличие развитой информационной системы. Информационная система реализует автоматизированный сбор, обработку и манипулирование данными, содержит технические средства обработки данных, программное обеспечение и обслуживающий персонал.

    Современной формой информационных систем являются банки данных, которые включают в свой состав вычислительную систему, одну или несколько баз данных (БД), систему управления базами данных (СУБД) и набор прикладных программ (ПП). Основными функциями банков данных являются:

    Хранение данных и их защита;

    Изменение (обновление, добавление и удаление) хранимых данных;

    Поиск и отбор данных по запросам пользователей;

    Обработка данных и вывод результатов.

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

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

    Прикладные программы (приложения) в составе банков данных служат для обработки данных, вычислений и формирования выходных документов по заданной форме.

    Приложение представляет собой программу или комплекс программ, использующих БД и обеспечивающих автоматизацию обработки информации из некоторой предметной области. Приложения могут создаваться как в среде СУБД, так и вне СУБД - с помощью системы программирования, к примеру, Delphi или C++ Builder , использующей средства доступа к БД.

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

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

    Такая независимость достигается поддерживаемым СУБД многоуровневым представлением данных в БД на логическом (пользовательском) и физическом уровнях.

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

    Средства для создания баз данных

    Файловые системы

    Развитие основных понятий представления данных

    Любой вычислительный процесс представляет собой отображение некоторых входных данных в выходные.

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

    - вычислительные задачи – достаточно простое представление данных и сложный процесс вычислений;

    - задачи обработки данных (невычислительные задачи) – простой алгоритм обработки данных и сложное представление обрабатываемых данных.

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

    Начиная с конца 60-х годов компьютеры начинают интенсивно использоваться для решения так называемых невычислительных задач, связанных с обработкой различного рода документов. При использовании файловых систем данные хранятся в файле, предназначенном только для решения этой задачи. В этом случае описание данных включено в прикладную программу. При изменении формата записей файла необходимо изменение прикладной программы. Таким образом, программная система, решающая поставленную задачу, определяет свои собственные данные и управляет ими.

    Недостатки файловых систем

    1. Структура записи файла известна только программе, в которой он создан. Изменение структуры требует изменения программ, использующих этот файл с данными. Таким образом, программы зависят от данных .

    2. Проблемы с авторизацией доступа. Можно использовать средства ОС по разграничению доступа. Такое решение возможно, но неудобно. Нужны централизованные методы доступа к информации.

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

    В прикладной программе, использующей при решении задачи один или несколько отдельных файлов, за сохранность и достоверность данных отвечал программист, работающий с этой задачей. Использование базы данных предполагает работу с ней нескольких прикладных программ, решающих задачи разных пользователей.

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

    Системы управления базами данных

    Роль интерфейса между прикладными программами и базой данных, обеспечивающего их независимость, играет программный комплекс – система управления базами данных (СУБД).

    СУБД – программный комплекс поддержки интегрированной совокупности данных, предназначенный для создания, ведения и использования базы данных многими пользователями (прикладными программами).

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

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

    2. Предоставление пользователям возможности манипулирования данными (выборка необходимых данных, выполнение вычислений, разработка интерфейса ввода/вывода, визуализация).

    3. Обеспечение независимости прикладных программ и (логической и физической независимости).

    4. Защита логической целостности базы данных.

    5. Защита физической целостности.

    6. Управление полномочиями пользователей на доступ к базе данных.

    7. Синхронизация работы нескольких пользователей.

    8. Управление ресурсами среды хранения.

    9. Поддержка деятельности системного персонала.

    1. Определение структуры создаваемой базы данных, ее инициализация и проведение начальной загрузки . В большинстве современных СУБД база данных представляется в виде совокупности таблиц.

    2. Предоставление пользователям возможности манипулирования данными (выборка необходимых данных, выполнение вычислений, разработка интерфейса ввода/вывода, визуализация). Такие возможности в СУБД представляются либо на основе использования специального языка программирования, входящего в состав СУБД, либо с помощью графического интерфейса.

    3. Обеспечение независимости прикладных программ и данных (логической и физической независимости). Важнейшим свойством СУБД является возможность поддерживать два независимых взгляда на базу данных – «взгляд пользователя», воплощаемый в логическом представлении данных, и его отражения в прикладных программах; и «взгляд системы» – физическое представление данных в памяти ЭВМ. Обеспечение логической независимости данных предоставляет возможность изменения (в определенных пределах) логического представления базы данных без необходимости изменения физических структур хранения данных. Таким образом, изменение логического представления данных в прикладных программах не приводит к изменению структур хранения данных. Обеспечение физической независимости данных предоставляет возможность изменять (в определенных пределах) способы организации базы данных в памяти ЭВМ не вызывая необходимости изменения «логического» представления данных. Таким образом, изменение способов организации базы данных не приводит к изменению прикладных программ.

    4. Защита логической целостности базы данных.

    Основной целью реализации этой функции является повышение достоверности данных в базе данных. Достоверность данных может быть нарушена при их вводе в БД или при неправомерных действиях процедур обработки данных, получающих и заносящих в БД неправильные данные. Для повышения достоверности данных в системе объявляются так называемые ограничения целостности, которые в определенных случаях «отлавливают» неверные данные. Так, во всех современных СУБД проверяется соответствие вводимых данных их типу, описанному при создании структуры. Система не позволит ввести символ в поле числового типа, не позволит ввести недопустимую дату и т.п. В развитых системах ограничения целостности описывает программист, исходя из содержательного смысла задачи, и их проверка осуществляется при каждом обновлении данных. Более подробно

    5. Защита физической целостности . При работе ЭВМ возможны сбои в работе (например, из-за отключения электропитания), повреждение машинных носителей данных. При этом могут быть нарушены связи между данными, что приводит к невозможности дальнейшей работы. Развитые СУБД имеют средства восстановления базы данных. Важнейшим используемым понятием является понятие «транзакции». Транзакция – это единица действий, производимых с базой данных. В состав транзакции может входить несколько операторов изменения базы данных, но либо выполняются все эти операторы, либо не выполняется ни один. СУБД, кроме ведения собственно базы данных, ведет также журнал транзакций.

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

    Предположим также, что после выполнения первого из действий (уменьшения суммы денег на счете первого клиента) произошел сбой. Например, могла прерваться связь клиентского компьютера с базой данных или на клиентском компьютере мог произойти системный сбой, что привело к перезагрузке операционной системы. Что в этом случае стало с базой данных? Команда на уменьшение денег на счете первого клиента была выполнена, а вторая команда – на увеличение денег на другом счете – нет, что привело бы к противоречивому, неактуальному состоянию базы данных.

    Использование механизма транзакций позволяет находить решение в этом и подобных случаях. Перед выполнением первого действия выдается команда начала транзакции. В транзакцию включается операция снятия денег на одном счете и увеличения суммы на другом счете. Оператор завершения транзакций обычно называется COMMIT. Поскольку после выполнения первого действия транзакция не была завершена, изменения не будут внесены в базу данных. Изменения вносятся (фиксируются) только после завершения транзакции. До выдачи данного оператора сохранения данных в базе не произойдет. В нашем примере, поскольку оператор фиксации транзакции не был выдан, база данных «откатится» в первоначальное состояние – иными словами, суммы на счетах клиентов останутся те же, что и были до начала транзакции. Администратор базы данных может отслеживать состояние транзакций и в необходимых случаях вручную «откатывать» транзакции.

    Кроме того, в очевидных случаях СУБД самостоятельно принимает решение об «откате» транзакции.

    Транзакции не обязательно могут быть короткими. Бывают транзакции, которые длятся несколько часов или даже несколько дней. Увеличение количества действий в рамках одной транзакции требует увеличения занимаемых системных ресурсов. Поэтому желательно делать транзакции по возможности короткими. В журнал транзакций заносятся все транзакции – и зафиксированные, и завершившиеся «откатом». Ведение журнала транзакций совместно с созданием резервных копий базы данных позволяет достичь высокой надежности базы данных.

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

    6. Управление полномочиями пользователей на доступ к базе данных .

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

    7. Синхронизация работы нескольких пользователей .

    Достаточно часто может иметь место ситуация, когда несколько пользователей одновременно выполняют операцию обновления одних и тех же данных. Такие коллизии могут привести к нарушению логической целостности данных, поэтому система должна предусматривать меры, не допускающие обновление данных другим пользователям, пока работающий с этими данными пользователь полностью не закончит с ними работать. Основным используемым здесь понятием является «блокировка». Блокировки необходимы для того, чтобы запретить различным пользователям возможность одновременно работать с базой данных, поскольку это может привести к ошибкам.

    Для реализации этого запрета СУБД устанавливает блокировку на объекты, которые использует транзакция. Существуют разные типы блокировок – табличные, страничные, строчные и другие, которые отличаются друг от друга количеством заблокированных записей.

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

    Таким образом, процесс внесения изменений в базу данных состоит из следующей последовательности действий: выдается оператор начала транзакции, выдается оператор изменения данных, СУБД анализирует оператор и пытается установить блокировки, необходимые для его выполнения, в случае успешной блокировки оператор выполняется, затем процесс повторяется для следующего оператора транзакции. После успешного выполнения всех операторов внутри транзакции выполняется оператор фиксации транзакции. СУБД фиксирует изменения, сделанные транзакцией, и снимает блокировки. В случае неуспеха выполнения какого-либо из операторов транзакция «откатывается», данные получают прежние значения, блокировки снимаются.

    8. Управление ресурсами среды хранения .

    БД располагается во внешней памяти ЭВМ. При работе в БД заносятся новые данные (занимается память) и удаляются данные (освобождается память). СУБД выделяет ресурсы памяти для новых данных, перераспределяет освободившуюся память, организует ведение очереди запросов к внешней памяти и т.п.

    9. Поддержка деятельности системного персонала .

    При эксплуатации базы данных может возникать необходимость изменения параметров СУБД, выбора новых методов доступа, изменения (в определенных пределах) структуры хранимых данных, а также выполнения ряда других общесистемных действий. СУБД предоставляет возможность выполнения этих и других действий для поддержки деятельности БД обслуживающему БД системному персоналу, называемому администратором БД.

    Классификация СУБД

    СУБД, как правило, разделяют по используемой модели данных (как и базы данных) на следующие типы: иерархические, сетевые, реляционные и объектно-ориентированные.

    По характеру использования СУБД делят на персональные (СУБДП) и многопользовательские (СУБДМ).

    К персональным СУБД относятся Visual FoxPro , Paradox , Clipper , dBase , Access и др. К многопользовательским СУБД относятся, например, СУБД Oracle и Informix . Многопользовательские СУБД включают в себя сервер БД и клиентскую часть, работают в неоднородной вычислительной среде - допускаются разные типы ЭВМ и различные операционные системы. Поэтому на базе СУБДМ можно создать информационную систему, функционирующую по технологии клиент-сервер. Универсальность многопользовательских СУБД отражается соответственно на высокой цене и компьютерных ресурсах, требуемых для их поддержки.

    СУБДП представляет собой совокупность языковых и программных средств, предназначенных для создания, ведения и использования БД.

    Персональные СУБД обеспечивают возможность создания персональных БД и недорогих приложений, работающих с ними, и при необходимости создания приложений, работающих с сервером БД.

    Управляющим компонентом многих СУБД является ядро, выполняющее следующие функции:

    - управление данными во внешней памяти;

    - управление буферами оперативной памяти (рабочими областями, в которые осуществляется подкачка данных из базы для повышения скорости работы);

    - управление транзакциями.

    Транзакция - это последовательность операций над БД, рассматриваемая СУБД как единое целое. Под транзакцией понимается воздействие на БД, переводящее ее из одного целостного состояния в другое. Воздействие выражается в изменении данных в таблицах базы.

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

    При выполнении транзакция может быть либо успешно завершена, и СУБД зафиксирует произведенные изменения во внешней памяти. При сбое в аппаратной части ПК, ни одно из изменений не отразится в БД. Понятие транзакции необходимо для поддержания логической целостности БД.

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

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

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

    Поддержка функционирования в сети обеспечивается:

    средствами управления доступом пользователей к совместно используемым данным, т. е. средствами блокировки файлов (таблиц), записей, полей, которые в разной степени реализованы в разных СУБДП;

    средствами механизма транзакций, обеспечивающими целостность БД при функционировании в сети.

    Поддержка взаимодействия с Windows-приложениями позволяет СУБДП внедрять в отчет сведения, хранящиеся в файлах, созданных с помощью других приложений, например, в документе Word или в рабочей книге Excel , включая графику и звук. Для этого в СУБДП поддерживаются механизмы, разработанные для среды Windows , такие как: DDE { Dynamic Data Exchange - динамический обмен данными) и OLE { Object Linking and Embedding - связывание и внедрение объектов).

    Уровни представления данных

    Современные подходы к созданию БД предполагают их трёхуровневую организацию. Этот способ организации БД был предложен American National Standards Institute (ANSI ) и используется повсеместно.

    На самом верхнем (внешнем) уровне может быть множество моделей. Этот уровень определяет точку зрения на БД отдельных пользователей (приложений). Каждое приложение видит и обрабатывает только те данные, которые необходимы именно ему.

    На концептуальном уровне БД представлена в наиболее общем виде, который объединяет все внешние представления предметной области. На концептуальном уровне имеем обобщённую модель предметной области, для которой создавалась БД. Концептуальное представление только одно. При разработке концептуальной модели усилия направлены на структуризацию данных и выявление взаимосвязей, без рассмотрения особенностей реализации и эффективности разработки.

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

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

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

    Классификация моделей данных

    Модель данных – это набор правил, по которым организуются данные.

    Это очень простое определение можно уточнить. Модель данных – это некоторая абстракция, которая, будучи приложена к конкретным данным, позволяет пользователям и разработчикам трактовать их как информацию, то есть сведения, содержащие не только данные, но и взаимосвязи между ними.

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

    Рис.1 Модели данных

    Инфологическая (семантическая) модель – это обобщённое, не привязанное к какой-либо ЭВМ и СУБД описание предметной области. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств объединяет частные представления о содержимом базы данных, полученные в результате опроса пользователей, и представления разработчиков о данных, которые могут потребоваться в будущих приложениях.

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

    Даталогические модели являются компьютерно-ориентированными, они поддерживаются конкретными СУБД. С их помощью СУБД даёт возможность пользователям осуществлять доступ к хранимым данным не заботясь об их физическом расположении. Так как доступ к данным осуществляется с помощью конкретной СУБД, то даталогические модели описываются на языке описания данных используемой СУБД.

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

    Даталогические модели

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

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

    Теоретико-графовые модели отражают совокупность объектов реального мира в виде графа. В зависимости от типа графа различают иерархическую и сетевую модели. Иерархическая и сетевая модели данных стали применяться в СУБД в начале 60-х годов 20 века. В настоящее время они используются реже, чем реляционная модель данных.

    Для работы со сложными наборами данных математики разработали иерархическую модель данных. Эта модель появилась раньше других даталогических моделей. Именно эта модель данных использована в первой официально признанной промышленной СУБД фирмы IBM.

    Иерархическая модель предполагает хранение данных в виде, похожем на организацию каталогов в MS DOS: все каталоги начинаются с корневого и ветвятся подобно дереву. К каждому файлу есть только один путь, то есть файлу соответствует одно имя каталога.

    В реальном мире некоторые объекты по своей сути составляют иерархические структуры: одни объекты являются родительскими, другие – дочерними. Иерархия проста и естественна для отображения взаимосвязей между объектами. Достаточно вспомнить многочисленные классификации, используемые в разных областях знаний, например, приведённую выше классификацию моделей данных. В качестве другого примера можно привести структуру данных предприятия.

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

    Главное достоинство иерархической модели – скорость. Поскольку все отношения между таблицами предопределены и являются статическими, поисковые и другие операции над набором данных выполняются очень быстро.

    Наиболее существенный недостаток – негибкость. Поскольку отношения хранятся внутри каждой записи, данные имеют смысл только в определённом контексте. Другой недостаток – трудность переноса данных с компьютера на компьютер. Третий недостаток заключается в том, что глобальные изменения данных практически невозможны. При изменении требуется, чтобы каждая запись, включая родительские и дочерние, была модифицирована индивидуально.

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

    Сетевая модель предложена для обеспечения гибкости в управлении данными. На разработку этой модели большое влияние оказал американский ученый Ч.Бахман.

    Основные принципы сетевой модели данных были сформулированы в середине 60-х годов. Эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных CODASYL (COnference on DAta SYstem Languages) в середине 70-х годов.

    Сетевая модель отличается от иерархической тем, что позволяет определять для записи более чем одно групповое отношение. Эта модели состоит из множества записей, которые могут быть владельцами или членами групповых отношений. Сетевая модель позволяет производить поиск в различных структурах и поддерживает для записей отношение «одна ко многим».

    Как и в иерархической БД, информация о связях хранится в записях и должна быть предопределена. Поэтому сетевая модель данных имеет те же ограничения, что и иерархическая.

    Реляционная модель данных

    Основные понятия и определения реляционной модели

    Реляционная модель

    В 1970 году Е.Ф. Кодд (E . F . Codd ) представил реляционную модель БД. Концепция этой модели основана на том, что организация данных в базе должна быть гибкой, динамичной, легко используемой. Пользователь должен работать только с логическим представлением данных, а уж система управления БД позаботится о физической структуре данных. Кодд сформулировал основные положения реляционных баз данных.

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

    · база данных должна состоять из таблиц и только из таблиц. Только содержимое таблиц определяет операции БД;

    · описание данных и манипуляции над ними должны быть независимыми от способа хранения данных на нижнем уровне. Другими словами, системы управления реляционными базами данных (СУРБД) должны обеспечивать свою собственную систему управления, основанную только на логическом представлении данных.

    В своём документе Кодд описал язык для оперирования с реляционными структурами. Со временем этот язык превратился в то, что сейчас называют структурированным языком запросов SQL (Structured Query Language ).

    Кодд вывел набор базовых правил, которым должна соответствовать СУБД реляционной модели. Всего их 12. Реально существующие базы данных не удовлетворяют полностью всем правилам Кодда. Каждый разработчик реализует реляционную модель по-своему. В результате свойства реляционных БД сильно варьируются.

    В правилах Кодда можно выделить 4 категории:

    1) базовые возможности – описание данных и язык программирования;

    2) доступ к данным – правила доступа, хранения и поиска,

    3) гибкость – правила изменения (модификации) данных;

    4) целостность – правила для обеспечения качества и защищённости данных.

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

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

    Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.) Наименьшая единица данных реляционной модели – это отдельное атомарное (неразложимое) для данной модели значение данных. Так, в одной предметной области фамилия, имя и отчество могут рассматриваться как единое значение, а в другой – как три различных значения.

    Доменом называется множество атомарных значений одного и того же типа. Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из одного и того же домена, то, вероятно, имеют смысл сравнения, использующие эти два атрибута Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла.

    Отношение на доменах D1, D2, ..., Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела.

    Заголовок состоит из такого фиксированного множества атрибутов A1, A2, ..., An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,...,n).

    Тело состоит из меняющегося во времени множества кортежей , где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Ai:Vi), (i=1,2,...,n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.

    Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, ..., а степени n – n-арным. Степень отношения

    Кардинальное число или мощность отношения – это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени.

    Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами A1, A2, ..., An. Говорят, что множество атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия:

    1. Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak.
    2. Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K без нарушения уникальности.

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

    Вышеупомянутые и некоторые другие математические понятия явились теоретической базой для создания реляционных СУБД, разработки соответствующих языковых средств и программных систем, обеспечивающих их высокую производительность, и создания основ теории проектирования баз данных. Однако для массового пользователя реляционных СУБД можно с успехом использовать неформальные эквиваленты этих понятий:

    Отношение – Таблица (иногда Файл),
    Кортеж – Строка (иногда Запись),
    Атрибут – Столбец, Поле.

    При этом принимается, что «запись» означает «экземпляр записи», а «поле» означает «имя и тип поля».

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

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

    3. Строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку такой таблицы.

    4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы).

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

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

    Ключи

    Реляционная теория требует, чтобы данные унифицировались уникально по трём критериям:

    · таблицей, где хранится этот элемент данных;

    · названием поля в этой таблице;

    · значением первичного ключа для записи.

    Первичный ключ – это поле или группа полей, которые гарантируют уникальность записи.

    При разработке таблицы в качестве первичного ключа следует выбирать столько полей, сколько требуется для того, чтобы каждая запись таблицы была уникальной. Одни таблицы содержат одно поле, уникально идентифицирующее каждую запись. Другие таблицы могут потребовать составного ключа (composite key ), то есть первичного ключа, состоящего из комбинации полей. Даже если таблица имеет составной первичный ключ, он может быть только один.

    Построение первичного ключа является обязательным. Данные часто имеют естественный ключ (natural key ). Например, номер социального страхования идентифицирует любого налогоплательщика США; банки выдают номера счетов своим клиентам; больницы присваивают пациентам номера в картотеке. Всё это – номер социального страхования, счёт в банке, номер в картотеке – лучшие кандидаты на роль первичного ключа, поскольку они уникально идентифицируют налогоплательщиков, клиентов и пациентов соответственно.

    При выборе ключа надо проявлять осторожность, так как некоторые данные только кажутся уникальными. Например, фамилия и имя, наименование фирмы и дата заказа.

    Если данные не содержат естественного первичного ключа, то он должен быть создан. Существуют две школы, которые предлагают разные способы создания искусственного ключа (artifical key ).

    Первая школа утверждает, что ключ должен быть максимально приближен к данным. Например, записи в таблицах Paradox по умолчанию автоматически сортируют и отображаются в порядке, определённом первичным ключом. Если построить ключ по четырём буквам от фамилии плюс две буквы имени, плюс последовательно присвоенное число, то сортировка будет показывать записи в алфавитном порядке. Но у такого ключа есть и неудобства, например, при изменении фамилии придётся обновлять ссылки.

    Вторая школа считает, что ключ не должен иметь ничего общего с данными, так называемый суррогатный ключ (surrogate key ).

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

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

    Первичный ключ - это атрибут или группа атрибутов, которые единственным образом идентифицируют каждую строку таблицы.

    Альтернативный (вторичный) ключ - это атрибут или группа атрибутов, не совпадающих с первичным ключом и уникально идентифицирующих экземпляр объекта.

    Индексы

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

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

    В качестве примера поиска в таблице представим себе телефонный справочник, где все абоненты расположены по алфавиту. Очевидно, что в таком справочнике очень легко найти номер телефона, если известна фамилия абонента. С другой стороны, найти фамилию абонента по номеру его телефона чрезвычайно сложно, т.к. справочник не упорядочен по номерам телефона, придется искать нужный телефон методом простого перебора. Таким образом, упорядоченность информации значительно облегчает поиск. Этот принцип положен в основу системы индексов.

    На рисунке показан телефонный справочник с записями, не упорядоченными по номеру телефона, и индекс, сформированный для этого справочника. Из рисунка видно, что индекс представляет собой массив целых чисел, куда помещены номера записей справочника в порядке возрастания номера телефона. Благодаря этому, записи становятся упорядоченными по номеру телефона, и вместо поиска методом полного перебора можно применить метод половинного деления или метод двоичного дерева.


    Рис. 3. Пример индекса по полю «номер телефона».

    Связи

    Связь – это функциональная зависимость между сущностями. Если между некоторыми сущностями существует связь, то факты из одной сущности ссылаются или некоторым образом связаны с фактами из другой сущности. Поддержание непротиворечивости функциональных зависимостей между сущностями называется ссылочной целостностью. Поскольку связи находятся «внутри» реляционной модели, реализация ссылочной целостности может выполняться как приложением, так и самой СУБД (с помощью механизмов декларативной ссылочной целостности и триггеров).

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

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

    Наиболее распространён тип связи одна-ко-многим . Например, клиент и заказы: один клиент может сделать много заказов. Поля, по которым осуществляются связи, не являются свободными, то есть не могут иметь произвольные значения. Например, в заказе должен быть упомянут клиент, который есть в таблице «Клиенты». С точки зрения таблицы «Клиенты» поле «ФИО клиента» может быть произвольным, так как не зависит от полей других таблиц.

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

    Тип связи много-ко-многим возникает, если связаны поля, частично входящие в первичный ключ одной и другой таблицы. Например, поле «Наименование продукта» в таблице «Заказы» и поле «Наименование продукта» в таблице «Отчисления». Продукт может быть заказан несколькими клиентами, а отчисления по продукту идут разным специалистам за каждую продажу продукта (если таблица «Отчисления» имеет два поля в первичном ключе – название продукта и специалист или название продута и менеджер).

    Выше рассмотрены способы связывания таблиц при помощи полей, входящих в первичный ключ. Однако существует другой способ связывания таблиц, в связи с одной стороны могут участвовать поля, не входящие в первичный ключ, а с другой стороны – поля входящие в первичный ключ. Это делается при помощи вторичных или внешних ключей (foreign key ). Вторичный ключ строится по полям, не входящим в первичный ключ.

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

    В отличие от отношений, основанных только на первичном ключе, отношения, построенные на использовании вторичного ключа, называются потенциальными. Разработчик БД сам решает, использовать такое связывание или нет.

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

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

    Хранимая процедура - это программа, объединяющая запросы, процедурную логику (операторы присваивания, ветвления и т.д.) и хранящиеся в базе данные. Этот механизм позволяет содержать вместе с данными достаточно сложные программы, выполняющие большой объём работ по обработке данных без передачи данных по сети и без взаимодействия с клиентом. В этом случае база данных может представлять собой функционально самостоятельный уровень приложения, который взаимодействует с другими уровнями для получения запросов и обновления данных.

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

    Триггер – это предварительно определённое действие или последовательность действий, автоматически осуществляемых при выполнении операций обновления, добавления или удаления данных. Триггер является мощным инструментом контроля за изменением данных в БД, помогает программисту автоматизировать операции, которые должны выполняться в этом случае. Триггер выполняется после проверки правил обновления данных. Ни пользователь, ни приложение не могут активизировать триггер, он запускается автоматически, когда пользователь или приложение выполняют с БД определённые действия. Триггер включает в себя следующие компоненты:

    * ограничения, для реализации которых созда1тся триггер;

    * событие, которое будет характеризовать возникновение ситуации, требующей проверки ограничений. События чаще всего связаны с изменением состояния БД (например, добавление записи в таблицу), но могут учитываться и дополнительные условия (например, добавление записи только с отрицательным значением);

    Использование триггеров при проектировании БД даёт следующие преимущества:

    * триггеры всегда выполняются при совершении соответствующих действий. Разработчик продумывает использование триггеров при проектировании БД и может больше не вспоминать о них при разработке приложения для доступа к данным;

    * при необходимости триггеры можно изменять централизованно непосредственно в БД. Пользовательские программы, работающие с этой БД не потребуют модернизации;

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

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

    Основные функции СУБД Прикладное программное обеспечение ППО, пользователи Система управления базами данных Операционная система База данных Обеспечение доступа ППО к базе данных Управление базой данных «железо»

    СУБД Программные составляющие СУБД включают в себя ядро и сервисные средства (утилиты). ØЯдро СУБД – это набор программных модулей, необходимый и достаточный для создания и поддержания БД, то есть универсальная часть, решающая стандартные задачи по информационному обслуживанию пользователей. ØСервисные программы предоставляют пользователям ряд дополнительных возможностей и услуг, зависящих от описываемой предметной области и потребностей конкретного пользователя. Системой управления базами данных называют программную систему, предназначенную для создания на ЭВМ общей базы данных для множества приложений, поддержания её в актуальном состоянии и обеспечения эффективного доступа пользователей к содержащимся в ней данным в рамках предоставленных им полномочий.

    Классификация СУБД По степени универсальности СУБД делят на два класса: 1. СУБД общего назначения (СУБД ОН) 2. специализированные СУБД (Сп. СУБД). Специализированные СУБД создаются в тех случаях, когда ни одна из существующих СУБД общего назначения не может удовлетворительно решить задачи, стоящие перед разработчиками. Причин может быть несколько: не достигается требуемого быстродействия обработки данных; необходима работа СУБД в условиях жёстких аппаратных ограничений; требуется поддержка специфических функций обработки данных. Сп. СУБД предназначены для решения конкретной задачи, а приемлемые параметры этого решения достигаются следующим образом: 1. за счёт знания особенностей конкретной предметной области, 2. путём сокращения функциональной полноты системы.

    Классификация СУБД По методам организации хранения и обработки данных СУБД делят на Ø Централизованные Ø Распределённые. Первые работают с БД, которая физически хранится в одном месте (на одном компьютере). Это не означает, что пользователь может работать с БД только за этим же компьютером: доступ может быть удалённым (в режиме клиент–сервер). Большинство централизованных СУБД перекладывает задачу организации удалённого доступа к данным на сетевое обеспечение, выполняя только свои стандартные функции, которые усложняются за счёт одновременности доступа многих пользователей к данным. По модели данных различают иерархические, сетевые, реляционные, объектно-реляционные и объектно-ориентированные СУБД.

    Требования к реляционным СУБД (по Кодду) 1. 2. 3. Явное представление данных (The Information Rule). Информация должна быть представлена в виде данных, хранящихся в ячейках. Данные, хранящиеся в ячейках, должны быть атомарны. Порядок строк в реляционной таблице не должен влиять на смысл данных. Гарантированный доступ к данным (Guaranteed Access Rule). К каждому элементу данных должен быть гарантирован доступ с помощью комбинации имени таблицы, первичного ключа строки и имени столбца. Полная обработка неизвестных значений (Systematic Treatment of Null Values). Неизвестные значения (NULL), отличные от любого известного значения, должны поддерживаться для всех типов данных при выполнении любых операций.

    Требования к реляционным СУБД (по Кодду) 4. 5. Доступ к словарю данных в терминах реляционной модели (Dynamic On-Line Catalog Based on the Relational Model). Словарь данных должен сохраняться в форме реляционных таблиц, и СУБД должна поддерживать доступ к нему при помощи стандартных языковых средств. Полнота подмножества языка (Comprehensive Data Sublanguage Rule). Система управления реляционными базами данных должна поддерживать единственный язык запросов, который позволяет выполнять все операции работы к данным: операции определения данных, операции манипулирования данными, управление доступом к данным, управление транзакциями.

    Требования к реляционным СУБД (по Кодду) 6. 7. Поддержка обновляемых представлений (View Updating Rule). Обновляемое представление должно поддерживать все операции манипулирования данными, которые поддерживают реляционные таблицы: операции выборки, вставки, модификации и удаления данных. Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete). Операции вставки, модификации и удаления данных должны поддерживаться не только по отношению к одной строке реляционной таблицы, но по отношению к любому множеству строк.

    Требования к реляционным СУБД (по Кодду) 8. Физическая независимость данных (Physical Data Independence). Приложения не должны зависеть от используемых способов хранения данных на носителях, от аппаратного обеспечения компьютеров, на которых находится реляционная база данных. 9. Логическая независимость данных (Logical Data Independence). Представление данных в приложении не должно зависеть от структуры реляционных таблиц.

    Требования к реляционным СУБД (по Кодду) 10. Независимость контроля целостности (Integrity Independence). Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. СУБД должна выполнять проверку заданных ограничений целостности и автоматически поддерживать целостность данных. 11. Независимость от распределенности (Distribution Independence). База данных может быть распределенной, может находиться на нескольких компьютерах, и это не должно оказывать влияние на приложения. 12. Согласование языковых уровней (Non-Subversion Rule). Не должно быть иного средства доступа к данным, отличного от стандартного языка работы с данными. Если используется низкоуровневый язык доступа к данным, он не должен игнорировать правила безопасности и целостности, которые поддерживаются языком более высокого уровня.

    Требования к составу и функциям СУБД 1. Хранение, извлечение и обновление данных. 2. Каталог (ССД), доступный конечным пользователям. Обычно в системном каталоге хранятся следующие сведения: имена, типы и размеры элементов данных; имена связей; накладываемые на данные ограничения поддержки целостности; имена пользователей, которым предоставлено право доступа к данным; внешняя, концептуальная и внутренняя схемы и отображения между ними; статистические данные, например частота транзакций и счетчики обращений к объектам базы данных.

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

    Системный словарь данных Oracle Хранит всю информацию о структуре, информационных объектах и отношениях в конкретной базе данных. Словарь данных представляет собой набор таблиц и вспомогательных объектов (индексов, кластеров, синонимов, представлений, последовательностей), информация о которых также хранится в таблицах словаря. Логически словарь данных разделяется на: üбазовые таблицы; üпредставления базовых таблиц; üдинамические таблицы и их представления. Всего словарь данных включает более 100 базовых таблиц, которые расположены в табличном пространстве SYSTEM и нигде более. Их имена включают символ "$" (поэтому его не рекомендуется использовать в названиях небазовых объектов), например: AUD$ – таблица audit-информации; FILE$ – таблица файлов; USER$ – таблица пользователей; IND$ – таблица индексов; OBJ$ – таблица объектов; SEG$ – таблица сегментов; SYN$ – таблица синонимов; TAB$ – таблица таблиц; TS$ – таблица табличных областей; VIEW$ – таблица представлений.

    Работа с системным словарём Для получения информации из словаря данных пользователям предоставлены представления базовых таблиц. Они разбиты на три группы: DBA – представления, предназначенные пользователям, являющимися АБД, то есть которым присвоена роль DBA. По этим представлениям предоставляется наиболее полная информация из словаря данных; USER – представления, по которым каждый пользователь получает информацию о тех объектах, которыми владеет; ALL – представления, дающие каждому пользователю всю информацию об объектах, к которым ему разрешен доступ. Например: DBA/ALL/USER_INDEXES – все/доступные/пользовательские индексы; DBA/ALL/USER_IND_COLUMNS – все/доступные/пользовательские колонки индексов; DBA/ALL/USER_OBJECTS – все/доступные/пользовательские объекты; DBA/ALL/USER_SYNONYMS – все/доступные/пользовательские синонимы; DBA/ALL/USER_TABLES – все/доступные/пользовательские таблицы; DBA/ALL/USER_TAB_COLUMNS – все/доступные/пользовательские колонки таблиц; DBA/ALL/USER_TAB_PRIVS – все/доступные/пользовательские привилегии на таблицы; DBA/ALL/USER_VIEWS – все/доступные/пользовательские представления.

    Работа с системным словарём Некоторые представления (по смыслу их применения) присутствуют только в одной или двух группах. Наиболее характерно это для DBA-представлений, например: DBA_DATA_FILES – данные о физических файлах базы и журналов; DBA/USER_FREE_SPACE – свободная память в табличных пространствах (вся и доступная конкретному пользователю); DBA_PROFILES – перечень вариантов "стоимости" системных ресурсов; DBA_ROLES – перечень определенных в базе данных ролей. Примеры извлечения данных из ССД: select table_name from user_tables; select * from all_views; select view_name from dba_views;

    Работа с системным словарём Важное значение имеет синоним DICT к представлению DICTIONARY. По нему выбираются имена таблиц, представлений, синонимов словаря данных с описаниями, если таковые есть в базе данных. Приведем небольшой фрагмент: select * from dict; ALL_CATALOG Все таблицы, представления, синонимы, последовательности, доступные пользователю ALL_DB_LINKS Связи базы данных, доступные пользователю DBA_OBJECTS Все объекты в базе данных DBA_ROLES Все роли, которые существуют в БД USER_EXTENTS Экстенты, принадлежащие пользователю USER_VIEWS Определения представлений, принадлежащих пользователю DUAL Специальная таблица, содержащая один столбец DUMMY и одну строку DICT Синоним для DICTIONARY TABS Синоним для USER_TABLES

    Работа с системным словарём АБД открыт доступ к этим таблицам, но работать на этом уровне, за исключением случаев КРАЙНЕЙ необходимости, НИКОГДА НЕ рекомендуется: вся информация словаря данных доступна через представления базовых таблиц; данные в базовых таблицах представлены без дублирования по правилам внутри системной упорядоченности, без расшифровки; количество, названия, размеры столбцов таблиц сделаны без учета достаточной наглядности; случайная, намеренная или еще по какой-либо причине КОРРЕКТИРОВКА содержимого базовых таблиц (даже в очевидных случаях, например, хранение данных о давно удаленных табличных пространствах), как правило, приводит к ПОВРЕЖДЕНИЮ словаря данных, то есть к ПОТЕРЕ всей базы данных. Редчайшее исключение представляет AUD$ (таблица аудиторской информации), из которой следует периодически удалять ненужные записи, поскольку при включенном audit-режиме эта таблица быстро наполняется и может переполнить табличное пространство SYSTEM.

    Требования к составу и функциям СУБД 3. 4. 5. 6. 7. 8. 9. Поддержка транзакций. Служба управления параллельной работой. Службы восстановления. Службы контроля доступа к данным. Службы поддержки целостности данных. Службы поддержки независимости от данных. Вспомогательные службы.

    Вспомогательные службы Обычно предназначены для оказания помощи АБД в эффективном администрировании базы данных. Некоторые примеры подобных утилит. Утилиты импортирования, предназначенные для загрузки базы данных из плоских файлов, а также утилиты экспортирования, которые служат для выгрузки базы данных в плоские файлы. Средства мониторинга, предназначенные для отслеживания характеристик функционирования и использования базы данных. Программы статистического анализа, позволяющие оценить производительность или степень использования базы данных. Инструменты реорганизации индексов, предназначенные для перестройки индексов в случае их переполнения. Инструменты сборки мусора и перераспределения памяти для физического устранения удаленных записей с запоминающих устройств, объединения освобожденного пространства и перераспределения памяти по мере необходимости.

    Основные программные компоненты СУБД Процессор запросов. Преобразует запросы в последовательность низкоуровневых команд для диспетчера базы данных. Диспетчер базы данных. Принимает запросы и проверяет внешние и концептуальные схемы для определения тех концептуальных записей, которые необходимы для удовлетворения требований запроса. Затем вызывает диспетчер файлов для выполнения поступившего запроса. Диспетчер файлов. Манипулирует предназначенными для хранения данных файлами и отвечает за распределение доступного дискового пространства. Он создает и поддерживает список структур и индексов, определенных во внутренней схеме. Если используются хешированные файлы, то в его обязанности входит и вызов функций хеширования для генерации адресов записей.

    Основные программные компоненты СУБД Препроцессор языка DML. Этот модуль преобразует внедренные в прикладные программы DML-операторы в вызовы стандартных функций базового языка. Для генерации соответствующего кода препроцессор языка DML должен взаимодействовать с процессором запросов. Компилятор языка DDL. Преобразует DDL-команды в набор таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге, а управляющая информация - в заголовках файлов с данными. Диспетчер словаря. Управляет доступом к системному каталогу и обеспечивает работу с ним. Системный каталог доступен большинству компонентов СУБД.

    Основные программные компоненты СУБД Модуль контроля прав доступа. Этот модуль проверяет наличие у данного пользователя полномочий для выполнения затребованной операции. Процессор команд. После проверки полномочий пользователя для выполнения затребованной операции управление передается процессору команд. Средства контроля целостности. В случае операций, которые изменяют содержимое базы данных, средства контроля целостности выполняют проверку того, удовлетворяет ли затребованная операция всем установленным ограничениям поддержки целостности данных (например, требованиям, установленным для ключей). Оптимизатор запросов. Этот модуль определяет оптимальную стратегию выполнения запроса.

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

    Основные объекты Oracle База данных (DATABASE) – объект, который находится на самом верхнем уровне физической организации базы данных Oracle находится объект, который так и называется: база данных (database). База данных состоит из словаря-справочника данных, собственно данных и различных вспомогательных объектов: файла параметров инициализации, управляющего файла, файла сегментов отката и двух файлов журнала транзакций. (Этот перечень может быть расширен, например, за счет копий управляющего файла). База данных может быть создана автоматически при инсталляции СУБД Oracle или вручную с помощью команды CREATE DATABASE. Табличная область (TABLESPACE) – область памяти, предназначенная для хранения всех объектов БД. Табличная область имеет имя и занимает один или более файлов операционной системы. Создается командой CREATE TABLESPACE. Иногда табличную область называют табличным пространством.

    Основные объекты Oracle Пользователь (USER) – объект, обладающий возможностью создавать и использовать другие объекты Oracle, а также запрашивать выполнение функций сервера. К числу таких функций относятся организация сессии, изменение состояния сервера и базы данных, создание других объектов БД, запросы на выполнение операторов SQL и проч. В СУБД Oracle имя пользователя совпадает с именем схемы. Создается командой CREATE USER. Каждый объект БД принадлежит тому пользователю, который его создал, и находится в его схеме. Полное имя любого объекта БД (кроме базы данных, табличных областей и пользователей) состоит из имени схемы, в которой он создан, и собственно имени объекта, например: scott. emp Здесь scott – имя пользователя (схемы), emp – имя объекта (таблицы "Сотрудники"), а точка – это т. н. квалифицированная ссылка, разделяющая уровни определения.

    Основные объекты Oracle Кластер (CLUSTER) – объект, задающий способ совместного хранения данных нескольких таблиц, содержащих информацию, обычно обрабатываемую совместно. Кластеризация таблиц позволяет уменьшить время выполнения выборки. Создается командой CREATE CLUSTER. Включает таблицы с данными. Таблица (TABLE) является базовой структурой реляционной модели. Как известно, вся информация в базе данных хранится в таблицах. Таблицы состоят из множества поименованных столбцов или атрибутов. Множество значений столбца определено с помощью ограничений целостности, то есть поддерживается ограниченная концепция домена (множества допустимых значений). Таблица может быть пустой или состоять из одной или более строк значений атрибутов. Строки значений атрибутов таблицы называют также записями или кортежами. Создается командой CREATE TABLE, может быть создана в кластере.

    Основные объекты Oracle Индекс (INDEX) – это объект базы данных, создаваемый для повышения производительности выборки данных. Индекс создается для столбца (столбцов) таблицы и обеспечивает более быстрый доступ к данным этой таблицы за счет упорядочения данных столбца (столбцов) по значению. Создается командой CREATE INDEX. Кластеры, таблицы и индексы называются объектами, занимающими память, т. к. в них хранятся фактографические данные. Им при создании выделяется определенный объем памяти (один или несколько экстентов), который может быть увеличен при добавлении в них данных. Экстент (extent) – это непрерывная область памяти в табличном пространстве. Все экстенты, относящиеся к одному объекту, образуют сегмент (segment). Кластер Таблица Индекс

    Основные объекты Oracle Представление (VIEW) – это поименованная, динамически поддерживаемая сервером выборка данных из одной или нескольких таблиц. В основе представления лежит оператор SELECT, который называется базовым запросом представления. Базовый запрос определяет видимые пользователем данные. Представление позволяет ограничить данные, которые пользователь может модифицировать. Данные в представлении не хранятся: сервер формирует представление каждый раз при обращении к нему (это называется материализация представления). Используя представления, администратор безопасности может ограничить доступную пользователям часть базы данных только теми данными, которые реально необходимы им для выполнения работы. Создается командой CREATE VIEW. Последовательность (SEQUENCE) – это объект, обеспечивающий генерацию уникальных номеров в условиях многопользовательского асинхронного доступа. Обычно элементы последовательности используются для вставки уникальных идентификационных номеров для элементов таблиц базы данных. Создается командой CREATE SEQUENCE.

    Основные объекты Oracle Синоним (SYNONYM) – это альтернативное имя или псевдоним объекта Oracle, который позволяет пользователям базы данных иметь доступ к данному объекту. Синоним может быть частным и общим. Общий (public) синоним позволяет всем пользователям базы данных обращаться к соответствующему объекту по альтернативному имени. При этом имя схемы для обращения к объекту не надо указывать, даже если Вы подключились не как владелец объекта, а из другой схемы. Создается командой CREATE SYNONYM. Роль (ROLE) – именованная совокупность привилегий, которые могут быть предоставлены пользователям или другим ролям. Используется для эффективного управления разграничением доступа к данным. Oracle поддерживает несколько стандартных или предопределенных ролей (DBA, CONNECT, RESOURCE и др.). Создается командой CREATE ROLE.

    Основные объекты Oracle Специфичными для распределенных систем являются такие объекты Oracle как снимок и связь базы данных. Снимок (SNAPSHOT) – локальная копия таблицы удаленной базы данных, которая используется либо для тиражирования (копирования) всей или части таблицы, либо для тиражирования результата запроса данных из нескольких таблиц. Снимки могут быть модифицируемыми или предназначенными только для чтения. Снимки только для чтения возможно периодически обновлять, отражая изменения основной таблицы. Изменения, сделанные в модифицируемом снимке, распространяются на основную таблицу и другие копии. Создается командой CREATE SNAPSHOT. Связь базы данных (DATABASE LINK) – это объект базы данных, который позволяет обратиться к объектам удаленной базы данных. Имя связи базы данных можно рассматривать как ссылку на параметры механизма доступа к удаленной базе данных (имя узла, протокол и т. п.). Использование одного имени упрощает работу с объектами удаленной базы данных. Создается командой CREATE DATABASE LINK.

    Основные объекты Oracle Для программирования алгоритмов обработки данных, поддержки сложных правил целостности данных Oracle использует процедурные объекты: Процедура (PROCEDURE) – это подпрограмма на языке PL/SQL, предназначенная для решения конкретной задачи обработки данных. Создается командой CREATE PROCEDURE. Функция (FUNCTION) – это подпрограмма на языке PL/SQL, предназначенная для решения конкретной задачи и возвращающая конкретное значение. Создается командой CREATE FUNCTION. Пакет (PACKAGE) – это поименованный, структурированный набор переменных, процедур и функций, связанных единым функциональным замыслом. Пакет состоит из спецификации и тела пакета. Спецификация содержит описания внешних переменных, констант, типов и подпрограмм, а тело пакета – реализацию подпрограмм и описание внутренних переменных, констант и типов, которые доступны только внутри пакета. Спецификация пакета создается командой CREATE PACKAGE, а тело пакета – CREATE PACKAGE BODY. Триггер (TRIGGER) – это хранимая процедура, которая автоматически запускается тогда, когда происходит связанное с триггером событие. Обычно события связаны с выполнением операторов INSERT, UPDATE или DELETE в некоторой таблице. Создается командой CREATE TRIGGER.

    Физическая структура базы данных Oracle Параметры среды: $ORACLE_HOME – имя домашней директории Oracle. $ORACLE_SID – имя базы данных Oracle. База данных Oracle включает: Управляющие файлы (ctrl 1$ORACLE_SID. ctl, ctrl 2$ORACLE_SID. ctl, . .) Файл параметров запуска экземпляра init$ORACLE_SID. ora Файл параметров конфигурации базы config$ORACLE_SID. ora Журнальные файлы регистрации изменений (log 1$ORACLE_SID. dbf, log 2$ORACLE_SID. dbf, . .) Системное табличное пространство (SYSTEM, system$ORACLE_SID. dbf) Временное табличное пространство (TEMP, temp$ORACLE_SID. dbf) Табличное пространство для данных пользователей (USER, user$ORACLE_SID. dbf)

    Структуры оперативной памяти Oracle SGA – это память, используемая всеми процессами экземпляра. Существует всего одна SGA для экземпляра. Изменения, сделанные в элементах SGA для одного процесса, немедленно становятся доступными для всех процессов, функционирующих в составе этого экземпляра. Создаваемая при запуске экземпляра Oracle, SGA имеет фиксированный размер. Она существует до тех пор, пока экземпляр не будет завершен вручную, или случится перезагрузка операционной системы, или произойдет аварийное завершение (крах) собственно Oracle. Основными внутренними структурами SGA являются: кеш буферов данных (Database Buffer Cache), то есть набор свободных, считанных и модифицированных блоков данных, в которых размещается информация из базы; буфер журнала транзакций (Redo Log Buffer); разделяемый (общий) буферный пул (Shared Buffer Pool).

    Структуры оперативной памяти Oracle. SGA Кеш буферов данных содержит два списка: список наименее используемых в данный момент блоков (LRU – least_recently_used), куда входят считанные с диска, но еще не модифицированные блоки, а также свободные буферы данных; список модифицированных (dirty – "грязный"), но еще не записанных на диск блоков. Обратите внимание: обмен "диск-память" всегда производится блоками вне зависимости от их заполненности записями данных и от количества измененных при обработке записей; при обращении к данным Oracle сначала проверяет, имеются ли требуемые данные в кеше буферов, и, только если их нет, обращается к диску; считанные с диска блоки данных попадают в начало списка LRU. Если они затем модифицируются, то Oracle их переводит в список "грязных" блоков для последующей записи на диск; при недостатке в кеше свободных буферов для выполнения очередного запроса Oracle удаляет блоки с "хвоста" списка LRU, как наименее активно используемые, и на их место считывает с диска требуемые блоки данных.

    Структуры оперативной памяти Oracle. SGA Буфер журнала регистрации изменений представляет собой циклически используемую память. В этот буфер поступают все изменения, происходящие в базе с пользовательскими, системными, служебными данными. Поскольку журнал регистрации изменений предназначен для восстановления состояния базы данных после аварийных ситуаций, записи журнала несут в себе "старое" и "новое" значения изменившихся элементов, в частности целиком записи данных после операций вставки их в базу или удаления из БД. Если обработка данных производится так интенсивно, что буфер журнала переполняется, то есть если процесс LGWR (процесс записи в журнал) не успевает переносить данные из буфера на диск, Oracle начинает сдерживать пользовательские процессы. Разделяемый (общий) буферный пул включает в себя: 1. кеш словаря (Dictionary Cache): хранит в себе наиболее часто (в текущей работе) используемые сведения из системного словаря данных, а именно: названия таблиц и представлений, имена столбцов и типы данных, привилегии и роли пользователей, права доступа к объектам базы данных и др. 2. разделяемую (общую) область SQL и PL/SQL (Shared SQL and PL/SQL), которая известна также как "библиотечный кеш" (library cache): включает в себя набор курсоров, то есть структур памяти, в которых хранятся результаты синтаксический разбора и планы выполнения SQL-предложений и блоков PL/SQL.

    Структуры оперативной памяти Oracle. PGA представляет собой область оперативной памяти, выделяемую для обеспечения функционирования отдельного процесса. Имеет место одна и только одна целиком выделяемая процессу и независимая от других процессов PGA для каждого процесса экземпляра. Размер PGA может динамически увеличиваться в процессе функционирования. PGA часто называют глобальной областью процесса (Process Global Area). Когда процесс Oracle нормально завершается, вся память PGA возвращается операционной системе. PGA процесса Oracle-сервера включает в себя: область стека, содержащую переменные и служебную информацию о сеансе; частную SQL-область, которую иногда называют "Глобальной областью пользователя" (UGA – User Global Area), в которой производится синтаксический разбор SQL-предложений и блоков PL/SQL. Эта область физически располагается в SGA (вариант архитектуры MTS) или в PGA (архитектура с выделенными серверами). Важно то, что рекурсивные сессии не получают свои собственные UGA, а разделяют UGA породившей их сессии; необязательная область сортировки (размером sort_area_size), которая как временная память требуется для хранения промежуточных результатов сортировки данных. Если выделенной памяти недостаточно для проведения сортировки, процесс использует временный сегмент соответствующего табличного пространства.

    Процессы экземпляра Oracle Набор работающих с базой данных фоновых процессов и порожденная при запуске экземпляра SGA (Системная Глобальная Область) составляют экземпляр Oracle. Все процессы экземпляра функционируют на едином программном ядре ($ORACLE_HOME/bin/oracle) СУБД. Обычно процессы экземпляра определяют как фоновые (обслуживающие, вспомогательные, дополнительные) и серверные (содержательная обработка запросов). Минимально необходимым для функционирования Oracle является набор из следующих четырех фоновых процессов: ora_pmon_ – процесс мониторинга внутреннего состояния системы ora_dbwr_ – процесс записи данных в базу данных Oracle ora_lgwr_ – процесс записи в журнал регистрации изменений ora_smon_ – процесс системного мониторинга.

    Процессы экземпляра Oracle 1. pmon – фоновый процесс-монитор. Он следит: за состоянием процессов в системе (в частности, он отслеживает обращение к серверу со стороны пользователей (connect) и запускает сервер-процессы); обнаруживает аварийные ситуации и "мертвые" блокировки сервер-процессов; освобождает ресурсы, то есть снимает блокировки; завершает транзакции, удаляет процессы из списка активных; восстанавливает состояние (rollback – откат) базы данных после ненормальных ситуаций завершения пользовательских процессов. 2. dbwr – фоновый процесс записи блоков данных в базу из списка модифицированных блоков в SGA. dbwr "пробуждается" к работе, если: длина списка модифицированных блоков превысила пороговое значение; в списке свободных буферов не хватает памяти для чтения новых блоков; истек очередной 3 -х секундный интервал времени; фоновый процесс записи в журнал lgwr сигнализирует о начале формирования очередной контрольной точки.

    Процессы экземпляра Oracle 3. lgwr – фоновый процесс записи в журнал регистрации изменений в базе данных. Регистрация транзакций осуществляется следующим образом: по мере выполнения транзакции создаются небольшие записи, называемые элементами повтора (redo entries), в которых содержится информация, достаточная для воссоздания изменений, вносимых транзакцией. элементы повтора транзакции временно сохраняются в буфере журнала повтора. когда запрашивается завершение транзакции, процесс lgwr считывает необходимые элементы повтора из буфера журнала транзакций и записывает их в журнал транзакций базы данных. Транзакция считается завершенной, когда процесс lgwr запишет элемент повтора транзакции в журнал транзакций и сделает запись о ее завершении в журнале транзакций. Данные из SGA-буфера переносятся на диск в следующих случаях: выполнена операция COMMIT фиксации изменений очередной транзакции; истек очередной 3 -х секундный интервал времени; буфер журнала в SGA заполнен на одну треть своей емкости; процесс dbwr записал на диск очередную порцию модифицированных буферов.

    Процессы экземпляра Oracle 4. smon – обязательный процесс системного мониторинга выполняет: автоматическое восстановление (roll forward – накат вперед) базы данных, если ее предыдущий запуск завершился ненормально или аварийно; освобождение временных сегментов от ненужных данных; объединение смежных свободных экстентов табличных пространств в непрерывные участки. 5. arch – необязательный фоновый процесс архивирования файлов оперативных журналов регистрации изменений в базе данных. Место копирования (диск, лента, . . .) определяется параметром log_archive_dest в файле init. ora. Если процесс arch не успел заархивировать очередной журнальный файл (например, переполнена файловая система и не хватает места, чтобы разместить файл-архив), а требуется на него переключение, Oracle приостанавливает функционирование, выполняя только транзакции, не связанные с ведением журнала.

    Процессы экземпляра Oracle 6. ckpt – необязательный вспомогательный процесс записи контрольной точки в оперативный журнал фиксации изменений. Обычно контрольные точки записывает lgwr. Процесс ckpt (checkpoint_process = true в файле init. ora) лишь освобождает lgwr от этой функции. 7. reco – (полу) обязательный процесс, ответственный за связи с удаленными базами данных. Процесс reco можно не запускать (в init. ora параметр disributed_transaction = 0), но тогда экземпляр не сможет использовать ни одной "связи между базами данных". 8. snp. X – от одного до десяти процессов автоматического обновления снапшотов локальной базы. Количество задается в init. ora параметром snapshot_refresh_processes, а параметр snapshot_refresh_interval определяет регулярность их включения. Процессы snp. X можно отнести к серверным, поскольку они, связываясь с другими (в частности с той же самой) базами данных, работают с пользовательской информацией в базе данных.

    Процессы экземпляра Oracle 9. db. XX – дополнительные процессы записи в базу данных. Если узким местом производительности базы является ввод/вывод, а база физически размещается на нескольких дисках, рекомендуется запустить несколько дополнительных процессов записи (в среднем, по одному на каждый отдельный диск). Количество дополнительных db. XX определяется параметром db_writers. 10. d. XXX – процессы диспетчеры в варианте архитектуры MTS с разделяемыми серверами. Количество функционирующих в данный момент диспетчеров зависит от напряженности работы Oracle, но не превышает заданного параметром mts_max_dispatchers числа. Каждый диспетчер обслуживает только конкретный сетевой или внутренний протокол. Например: mts_dispatchers="tcp, 1" mts_dispatchers="ipc, 1"

    Процессы экземпляра Oracle 11. s. XXX – процессы серверы в варианте архитектуры MTS с разделяемыми серверами. Количество функционирующих в данный момент серверов зависит от напряженности работы Oracle, но не превышает заданного параметром mts_max_servers числа. Стартуя, Oracle запускает несколько (mts_servers) сервер-процессов, а затем то мере возрастания или снижения нагрузки запускает или завершает дополнительные процессы. 12. oracle – выделенный процесс сервера, индивидуально обслуживающий какой-то пользовательский (в частном случае и процесс snp) процесс, вполне возможно функционирующий на другой машине. 13. loc. X – от одного до десяти процессов блокировок, обеспечивающих взаимное управление ресурсами в среде параллельного сервера.

    Архитектуры серверов Oracle Однопользовательский вариант (пример среды – MS DOS) характеризуется тем, что: происходит объединение пользовательского процесса, процесса сервера и фоновых процессов в рамки одной задачи операционной системы; возможен запуск только одной базы данных и одного экземпляра Oracle; в распределенной базе данных не может функционировать в качестве сервера. Многопользовательский вариант (пример среды – UNIX) характеризуется тем, что: происходит разделение пользовательских, серверных и фоновых процессов на отдельные задачи операционной системы; есть возможность запуска нескольких баз данных и экземпляров Oracle; возможно функционирование в качестве сервера в распределенной БД.

    Архитектуры серверов Oracle Однозадачный вариант (пример среды – Net. Ware) характеризуется тем, что: пользовательский процесс и процесс сервера образуют единую задачу операционной системы, называемую задачей пользователя; в каждый момент времени на сервере может выполняться только одна задача пользователя; возможен доступ многих пользователей через Net 8 (SQL*Net) к базе данных. Двухзадачный вариант (пример среды – UNIX) характеризуется тем, что: пользовательский процесс и процесс обслуживающего сервера представляют собой полностью самостоятельные процессы операционной системы вплоть до того, что могут функционировать на разных машинах и платформах (архитектура "клиент-сервер"); в каждый момент времени на сервере может функционировать несколько (много) пользовательских и серверных процессов; возможен доступ многих пользователей через Net 8 (SQL*Net) к локальным базам данных и локальных пользователей к удаленным базам данных.

    Архитектуры серверов Oracle Однонитевая архитектура, или вариант с выделенными (Dedicated) серверами: жесткое закрепление за каждым пользовательским процессом процесса сервера, который выполняет его и только его запросы к базе данных. Параллельный сервер (среда – кластерные системы, например, RM-1000): на каждом процессоре кластера функционирует свой экземпляр Oracle, включающий отдельную область SGA и набор системных процессов; каждый экземпляр ведет свои собственные журналы регистрации изменений; база данных и управляющие файлы являются общими для всех экземпляров; к каждому экземпляру возможно подключение многих пользователей; каждый экземпляр адресуем отдельно, и может самостоятельно работать как часть распределенной системы.

    Архитектуры серверов Oracle Многонитевая архитектура (MTS – Multi-Tread Server), вариант с разделяемыми серверами характеризуется: наличием процессов-диспетчеров, принимающих запросы от пользовательских процессов и возвращающих им результаты выполненных сервер-процессами запросов; наличием в SGA: одной входной очереди для всех сервер-процессов, в которую диспетчеры помещают заявки на обслуживание от пользователей; нескольких выходных очередей, закрепленных по одной за каждым процессом диспетчером, куда серверы помещают и откуда диспетчеры передают пользователям результаты выполнения запросов к базе данных; переносом в SGA экземпляра Oracle частных SQL-областей, ранее размещавшихся в PGA процессов серверов; динамическим изменением в зависимости от текущей нагрузки системы количества функционирующих диспетчеров и сервер-процессов; ни диспетчеры, ни серверы не закрепляются за какими-либо процессами пользователей: запросы обслуживаются по мере поступления; возможностью одновременного функционирования выделенных и разделяемых серверов.

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

    В состав банка данных входят одна или несколько баз данных, справочник баз данных, система управления базами данных (СУБД), а также библиотеки запросов и прикладных программ.

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

    Создается банк данных в абонентской системе любой производительности — от персонального компьютера до суперкомпьютера. Но даже самый крупный банк данных ограничен в своих возможностях. Поэтому банки в сети специализируются, собирая информацию в определенных областях науки, технологии, продукции. Ядром банка являются базы данных и базы знаний. База данных - это организованная структура, предназначенная для хранения информации. Данные и информация - понятия взаимосвязанные, но не тождественные, должен заметить несоответствие в этом определении. Сегодня большинство систем управления базами данных (СУБД) позволяют размещать в своих структурах не только данные, но и методы (то есть программный код), с помощью которых происходит взаимодействие с потребителем или с другими программно-аппаратными комплексами. Таким образом, можно говорить, что в современных базах данных хранятся отнюдь не только данные, но и информация.

    В БнД имеются специальные средства, облегчающие для пользователей работу с данными (СУБД).

    Централизованное управление данными имеет преимущества по сравнению с обычной файловой системой:

    — сокращение избыточности хранения данных;

    — сокращение трудоемкости разработки, эксплуатации и модернизации ИС;

    Обеспечение удобного доступа к данным как пользователям

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

    Основные требования, предъявляемые к БнД:

    — адекватность отображения предметной области (полнота, целостность и — непротиворечивость данных, актуальность информации;

    — возможность взаимодействия пользователей разных категорий, высокая эффективность доступа к данным;

    — дружелюбность интерфейсов, малое время на обучение;

    — обеспечение секретности и разграничение доступа к данным для разных пользователей;

    — надежность хранения и защита данных.

    Определение термина Банк данных дано во Временном положении о государственном учете и регистрации баз и банков данных, утвержденное постановлением Правительства Российской Федерации от 28.02.96 № 226, п.2 (СЗ РФ, 1996, № 12, ст. 1114)

    Первоначально (начало 60-х годов) использовалась файловая система хранения. Для решения преимущественно инженерных задач, характеризующихся небольшим количеством данных и значительным объемом вычислений, данные хранились непосредственно в программе. Применялся последовательный способ организации данных, имелась их высокая избыточность, идентичность логической и физической структур и полная зависимость данных. С появлением экономико-управленческих задач (информационная система руководства — MIS), отличающихся большими объемами данных и малой долей вычислений, указанная организация данных оказалась неэффективной. Требовалось упорядочение данных, которое, как выяснилось, возможно было проводить по двум критериям: использование (информационные массивы); хранение (базы данных). Первоначально применяли информационные массивы, но вскоре стало ясно превосходство баз данных. Использование файлов для хранения только данных было предложено Мак Гри в 1959 году. Были разработаны методы доступа (в том числе произвольного) к таким файлам, при этом физическая и логическая структуры уже различались, а физическое расположение данных можно было менять без изменения логического представления.

    В 1963 году С. Бахманом была построена первая промышленная база данных IDS с сетевой моделью данных, которая все еще характеризовалась избыточностью данных и их использованием только для одного приложения. Доступ к данным осуществлялся с помощью соответствующего программного обеспечения. В 1969 году сформировалась группа, создавшая набор стандартов CODASYL для сетевой модели данных.

    Фактически начала использоваться современная архитектура базы данных. Под архитектурой понимается разновидность (обобщение) структуры, в которой какой-либо элемент может быть заменен на другой элемент, характеристики входов и выходов которого идентичны первому элементу. Существенный скачок в развитии технологии баз данных дала предложенная М. Коддом в 1970 году парадигма реляционной модели данных. Под парадигмой понимается научная теория, воплощенная в систему понятий, отражающих существенные черты действительности. Теперь логические структуры могли быть получены из одних и тех же физических данных, т.е. доступ к одним и тем же физическим данным мог осуществляться различными приложениями по разным путям. Стало возможным обеспечение целостности и независимости данных.

    В конце 70-х годов появились современные СУБД, обеспечивающие физическую и логическую независимость, безопасность данных, обладающие развитыми языками БД. Последнее десятилетие характеризуется появлением распределенных и объектно-ориентированных баз данных, характеристики которых определяются приложениями средств автоматизации проектирования и интеллектуализации БД.

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

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

    СУБД организует хранение информации таким образом, чтобы ее было удобно:

    просматривать,

    пополнять,

    изменять,

    искать нужные сведения,

    делать любые выборки,

    осуществлять сортировку в любом порядке.

    Классификация баз данных:

    а) по характеру хранимой информации:

    Фактографические (картотеки),

    Документальные (архивы)

    б) по способу хранения данных:

    Централизованные (хранятся на одном компьютере),

    Распределенные (используются в локальных и глобальных компьютерных сетях).

    в) по структуре организации данных:

    Табличные (реляционные),

    Иерархические,

    Современные СУБД дают возможность включать в них не только текстовую и графическую информацию, но и звуковые фрагменты и даже видеоклипы.

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

    Популярные СУБД — FoxPro, Access for Windows, Paradox. Для менее сложных применений вместо СУБД используются информационно-поисковые системы (ИПС), которые выполняют следующие функции:

    хранение большого объема информации;

    быстрый поиск требуемой информации;

    добавление, удаление и изменение хранимой информации;

    вывод ее в удобном для человека виде.

    Информация в базах данных структурирована на отдельные записи, которыми называют группу связанных между собой элементов данных. Характер связи между записями определяет два основных типа организации баз данных: иерархический и реляционный.

    Если в базе нет никаких данных (пустая база), то это все равно полноценная база данных. Этот факт имеет методическое значение. Хотя данных в базе и нет, но информация в ней все-таки есть - это структура базы. Она определяет методы занесения данных и хранения их в базе. Простейший «некомпьютерный» вариант базы данных - деловой ежедневник, в котором каждому календарному дню выделено по странице. Даже если в нем не записано ни строки, он не перестает быть ежедневником, поскольку имеет структуру, четко отличающую его от записных книжек, рабочих тетрадей и прочей писчебумажной продукции.

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

    В настоящее время наблюдается стремительный рост числа систем электронной коммерции (СЭК). Электронная коммерция имеет ряд отличительных особенностей, резко выделяющих её от всех ранее известных способов классической коммерции благодаря исключительным коммуникативным характеристикам Интернета

    Системы электронной коммерции должны обладать способностью координировать бизнес-транзакции в многочисленных бизнес-приложениях, уметь извлекать отдельные части информации из различных источников, своевременно и беспрепятственно доставлять клиенту необходимую информацию, — все по единственному Web-запросу пользователя.

    СЭК обладает набором специфических свойств, которые отличают их от классических систем коммерции (обыкновенные магазины, супермаркеты, биржи и т.п.). В то же время эти свойства необходимо учитывать при построении и анализе моделей процессов в СЭК, поскольку классическая постановка оптимизационной задачи оптимального управления дискретной системой не подходит. Итак, свойства СЭК: Время работы неограниченно в отличие от классических систем, где есть строго регламентированное расписание работы. Можно говорить о том, что поток посетителей распределен равномерно во времени. В отличие от классических систем в СЭК (особенно это характерно для систем класса B2C) посетители приходят не только за покупками, но и за получением некоторой информации: ознакомиться с ассортиментом, ценами, условиями оплаты и доставки товара.

    В то же время для классических систем характерна такая особенность, что посетители с очень большой долей вероятности становятся покупателями. Поэтому возможно рассмотрение различных моделей и способов оценки эффективности функционирования СЭК: соотношение числа покупателей к числу посетителей, влияние работы СЭК и обратной связи на входной поток заявок.

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

    СЭК может обслуживать одновременно достаточно большое число посетителей. Эта характеристика ограничена только программно-аппаратными возможностями СЭК. То есть в случае СЭК с точки зрения пользователя нет очередей ожидания обслуживания. Особенно это характерно для полностью или частично автоматизированных СЭК.

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

    Системы управления базами данных позволяют объединять большие объемы информации и обрабатывать их, сортировать, делать выборки по определённым критериям и т.п.

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

    1.2 Реляционные базы данных

    Реляционная СУБД (РСУБД; иначе Система управления реляционными базами данных, СУРБД) - СУБД, управляющая реляционными базами данных.

    Понятие реляционный (англ. relation - отношение) связано с разработками известного английского специалиста в области систем баз данных Эдгара Кодда (Edgar Codd).

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

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

    – каждый элемент таблицы - один элемент данных;

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

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

    – одинаковые строки в таблице отсутствуют;

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

    Базовыми понятиями реляционных СУБД являются: 1) атрибут; 2) отношения; 3) кортеж.

    База данных, таким образом, это ни что иное, как набор таблиц. RDBS и ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации – Indexed Sequential Access Method (ISAM) и являются стандартными системами, использующимися в большинстве современных программных продуктов. Для обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO (Digital Equipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД.

    Оригинальная версия SQL – это интерпретируемый язык, предназначенный для выполнения операций над базами данных. Язык SQL был создан в начале 70х как интерфейс для взаимодействия с базами данных, основанными на новой для того времени реляционной теории. Реальные приложения обычно написаны на других языках, генерирующих код на языке SQL и передающих их в СУБД в виде текста в формате ASCII. Нужно отметить также, что практически все реальные реляционные (и не только реляционные) системы помимо реализации стандарта ANSI SQL, известного сейчас в последней редакции под именем SQL2 (или SQL-92), включают в себя дополнительные расширения, например, поддержка архитектуры клиент-сервер или средства разработки приложений.

    Строки таблицы составлены из полей, заранее известных базе данных. В большинстве систем нельзя добавлять новые типы данных. Каждая строка в таблице соответствует одной записи. Положение данной строки может изменяться вместе с удалением или вставкой новых строк.

    Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом (primary key) таблицы и часто являются числами. Если одна таблица содержит первичным ключ другой, это позволяет организовать связь между элементами разных таблиц. Это поле называется внешним ключом (foreign key).

    Так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько нибудь сложных взаимосвязей в базе данных. Еще один крупный недостаток реляционных баз данных – это высокая трудоемкость манипулирования информацией и изменения связей.

    Несмотря на рассмотренные недостатки реляционных баз данных, они обладают рядом достоинств:

    разделение таблиц разными программами;

    развернутый «код возврата» при ошибках;

    высокая скорость обработки запросов (команда SELECT языка SQL; результатом выборки является таблица, которая содержит поля, удовлетворяющие заданному критерию);

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

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

    Кроме того, во всем мире значительные средства уже инвестированы в реляционные СУБД. Многие организации не уверены, что затраты, связанные с переходом на объектные базы данных, окупятся.

    Поэтому многие пользователи заинтересованы в комбинированном подходе, который бы им позволил воспользоваться достоинствами объектных баз данных, не отказываясь полностью от своих реляционных БД. Такие решения действительно существуют. Если переход от реляционной базы к объектной обходится слишком дорого, то применение последней в качестве расширения и дополнения реляционных СУБД часто является более экономичной альтернативой. Компромиссные решения позволяют соблюсти баланс между объектами и реляционными таблицами.

    Объектно-реляционные адаптеры – э тот метод предполагает использование так называемого объектно-реляционного адаптера, который автоматически выделяет программные объекты и сохраняет их в реляционных базах данных. Объектно-ориентированные приложение работает как рядовой пользователь СУБД. Несмотря на некоторое снижение производительности, такой вариант позволяет программистам целиком сконцентрироваться на объектно-ориентированной разработке. Кроме того, все имеющиеся на предприятии приложения по-прежнему могут обращаться к данным, хранящимся в реляционной форме.

    Некоторые объектные СУБД, например GemStone компании GemStone Systems, могут сами выполнять роль мощного объектно-реляционного адаптера, позволяя объектно-ориентированным приложениям обращаться к реляционным БД.

    Объектно-реляционные адаптеры, такие как Odapter компании Hewlett-Packard для СУБД Oracle, можно с успехом использовать во многих областях, например в качестве связующего ПО, объединяющего объектно-ориентированные приложения с реляционными СУБД.

    Объектно-реляционные шлюзы – п ри использовании такого метода пользователь взаимодействует с БД при помощи языка ООСУБД, а шлюз заменяет все объектно-ориентированные элементы этого языка на их реляционные компоненты. За это опять приходиться расплачиваться производительностью. Например, шлюз должен преобразовать объекты в набор связей, сгенерировать оригинальные идентификаторы (original identifier – OID) объектов и передать это в реляционную БД. Затем шлюз должен каждый раз, когда используется интерфейс реляционной СУБД, преобразовывать OID, найденный в базе, в соответствующий объект, сохраненный в РСУБД.

    Производительность в рассмотренных двух подходах зависит от способа доступа к реляционной базе данных. Каждая РСУБД состоит из двух уровней: уровня управления данными (data manager layer) и уровня управления носителем (storage manager layer). Первый из них обрабатывает операторы на языке SQL, а второй отображает данные в базу. Шлюз или адаптер могут взаимодействовать как с уровнем данных (то есть обращаться к РСУБД при помощи SQL), так и с уровнем носителя (вызовами процедур низкого уровня). Производительность в первом случае намного ниже (например, система OpenODB фирмы Hewlett-Packard, которая может выполнять роль шлюза, поддерживает только на высоком уровне).

    Гибридные СУБД – е ще одним решением может стать создание гибридных объектно-реляционных СУБД, которые могут хранить и традиционные табличные данные, и объекты. Многие аналитики считают, что будущее за такими гибридными БД. Ведущие поставщики реляционных СУБД начинают (или планируют) добавлять к своим продуктам объектно-ориентированные средства. В частности, Sybase и Informix собираются в следующих версиях СУБД ввести поддержку объектов. Подобные разработки намерены вести и независимые фирмы. Например, компания Shores готовится оснастить объектно-ориентированными средствами СУБД Oracle8, выпуск которой намечен на конец 1996 г.

    С другой стороны, производители объектных СУБД, такие как компания Object Design, сознают, что объектно-ориентированные базы данных в обозримом будущем не заменят реляционные СУБД. Это вынуждает их создавать шлюзы для поддержки реляционных и иерархических баз данных иди различного рода интерфейсы, характерным примером которых является объектно-реляционный интерфейс Ontos Integration Server фирмы Ontos, применяемый в сочетании с ее ООБД Ontos/DB.

    1.3 Многомерные базы данных

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

    В специализированных СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:

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

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

    Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства:

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

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

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

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

    MOLAP могут работать только со своими собственными многомерными БД и основываются на патентованных технологиях для многомерных СУБД, поэтому являются наиболее дорогими. Эти системы обеспечивают полный цикл OLAP-обработки и либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для связи с пользователем внешние программы работы с электронными таблицами. Для обслуживания таких систем требуется специальный штат сотрудников, занимающихся установкой, сопровождением системы, формированием представлений данных для конечных пользователей.

    Еще к недостаткам MOLAP-моделей можно отнести:

    не позволяют работать с большими БД. На сегодняшний день их реальный предел – 10-20 гигабайт. К тому же за счет денормализации и предварительно выполненной агрегации 20 гигабайт в многомерной базе, как правило, соответствуют (по оценке Кодда) в 2.5-100 раз меньшему объему исходных детализированных данных, то есть в лучшем случае нескольким гигабайтам.

    по сравнению с реляционными, очень неэффективно используют внешнюю память. Ячейки гиперкуба хранятся в них в виде логически упорядоченных массивов (блоков фиксированной длины), причем именно такой блок является минимальной индексируемой единицей. Хотя в многомерных СУБД блоки, не содержащие ни одного определенного значения, не хранятся, это решает проблему только частично. Поскольку данные хранятся в упорядоченном виде, неопределенные значения не всегда удаляются полностью, да и то лишь в том случае, когда за счет выбора порядка сортировки данные удается организовать в максимально большие непрерывные группы. Но порядок сортировки, чаще всего используемый в запросах, может не совпадать с порядком, в котором они должны быть отсортированы в целях максимального устранения несуществующих значений. Таким образом, при проектировании многомерной БД часто приходится жертвовать либо быстродействием (а это одно из первых достоинств и главная причина выбора именно многомерной СУБД), либо внешней памятью (хотя, как отмечалось, максимальный размер многомерных БД ограничен)

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

    не поддерживают репликацию данных, часто используемую в качестве механизма загрузки. Следовательно, использование многомерных СУБД оправдано только при следующих условиях:

    объем исходных данных для анализа не слишком велик (не более нескольких гигабайт), то есть уровень агрегации данных достаточно высок.

    набор информационных измерений стабилен (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба).

    время ответа системы на нерегламентированные запросы является наиболее критичным параметром.

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

    2. Практическая часть

    2.1 Постановка задачи

    2.1.1 Цель решения задачи

    Руководство предприятия ООО «Строй-дизайн», осуществляющего деятельность, связанную с выполнением работ по ремонту помещений, желает произвести автоматизацию расчетов по вычислению стоимоти выполняемых работ для оперативного предоставления счета клиенту. Это поможет сократить время расчетов, избежать ошибок, связанных с человеческим фактором и повысить степень удовлетворенности клиента оказанными услугами. Поэтому принято решение вести расчет стоимости выполненных работ и создание счета на их оплату, в которых должны быть наименование работ, объем выполняемых работ, цена за единицу продукции, стоимость работы. Задача, которая будет решаться в программной среде MS Excel ежемесячно, называется «Расчет стоимости выполненных работ».

    Цель решения данной задачи состоит в своевременности расчетов стоимости работ для оперативного предоставления подробно составленного счета клиентам.

    2.1.2 Условие задачи

    Входной оперативной информацией служит документ «Расчет стоимости выполняемых работ», который содержит реквизиты: наименование работы, объем выполняемых работ, цена за единицу продукции (руб.), стоимость работы (руб.), последние два реквизита необходимо вычислить и рассчитать. На его основании создается следующая экранная форма:

    Наименование
    работы

    Единицы
    измерения

    Объем
    выполняемых
    работ

    Стоимость
    работ, руб.

    Q i

    C і

    S i


    Условно-постоянной информацией (справочной) служит прайс-лист организации, содержащий следующие реквизиты (условная форма): наименование работы, цена за единицу продукции (руб). На его основании создается следующая экранная форма:

    Прайс-лист

    Наименование работы

    Цена за единицу продукции, руб.

    Латинские буквы в таблице указывают на элементы соответствующих расчетных формул.

    В результате следует получить счет со следующими реквизитами: наименование работы, цена за единицу продукции (руб.), объем выполняемых работ, стоимость работы (руб.), № счета (заполняется автоматически). ФИО клиента и дата вписываются вручную. Информация выдается в следующих документах:

    Структура результирующего документа «Счет»

    ООО «Стройсервис»

    СЧЕТ №

    Дата

    20__

    ФИО клиента

    №
    п/п

    Наименование
    работы

    Единицы
    измерения

    Объем
    выполняемых
    работ

    Цена за единицу продукции, руб.

    Стоимость
    работ, руб.

    Замена батарей

    шт.

    Наклейка обоев

    м 2

    Замена труб

    Настилка паркета

    м 2

    ИТОГО:

    ΣS i

    НДС:

    N

    СУММА С НДС:

    SN

    Гл. бухгалтер

    Кроме того, информацию, находящуюся в таблицах для анализа, необходимо представить в виде диаграмм.

    В технологии организовать межтабличные связи для автоматического формирования документа «Счет» при помощи функций ВПР или ПРОСМОТР.

    2.2. Компьютерная модель решения задачи

    2.2.1. Информационная модель решения задачи

    Информационная модель, отражающая взаимосвязь исходных и результирующих документов, приведена на рис. 2.

    2.2.2. Аналитическая модель решения задачи

    Для получения документа « Расчет стоимости выполняемых
    работ» необходимо рассчитать следующие показатели:

      стоимость работ, руб.;

      НДС, руб.;

      сумма с НДС, руб..

      Расчеты выполняются по следующим формулам:

      S i = C i ∙Q i ,

      N = ΣS i ∙ 0,18,

      SN = ΣS i + N,

      где S i
      - стоимость i -й работы; C i
      - цена за i -ю единицу продукции; Q i - обїем выполняемой i -й работы; N - НДС; SN - сумма с НДС.

      2.2.3. Технология решения задачи MS Excel

      Решение задачи средствами MS Excel

      Вызовите Excel:

      нажмите кнопку «Пуск»;

      выберите в главном меню команду «Программы»;

      в меню Microsoft Office выберите MS Excel.

      Переименуйте «Лист 1» в «Прайс-лист»:

      выберите в контекстном меню команду «Переименовать» и нажмите левую кнопку мыши;

      нажмите клавишу «Enter».

      Введите заголовок таблицы «Прайс-лист»:

      наберите на клавиатуре «Прайс-лист»;

      4. Отформатируйте заголовок:


      Рис. 2. Пример выделения группы ячеек

      на панели инструментов в закладке «Главная» выберите раздел «Выравнивание» и нажмите кнопку .

      5. Отформатируйте ячейки А2:B2 под ввод длинных заголовков:

      выделите ячейки А2:B2;

      выполните команду «Выравнивание» в разделе «Формат ячеек» меню «Главная» на панели инструментов;

      выберите закладку «Выравнивание»;

      в группе опций «Отображение» установите флажок опции «переносить по словам» (рис. 3);


      Рис. 3. Задание переноса слов при вводе в ячейку длинных

      заголовков

      нажмите кнопку «ОК».

      6. Введите в ячейки А2:B2 информацию, представленную на рис. 4.


      Рис. 4. Имена полей таблицы «Прайс-лист»

      7. Отформатируйте ячейки А3:A8 для ввода текстовых символов:

      выделите ячейки А3:A8;

      на панели инструментов в меню «Главная» выберите «Ячейки», где в пункте «Формат» выполните команду «Формат ячеек»;

      выберите закладку «Число»;

      выберите формат «Текстовый» (рис. 5);

      нажмите кнопку «ОК».


      Рис. 5. Выбор формата ячеек

      8. Повторите п. 9 для диапазона ячеек B3:B8, выбрав формат «Числовой».

      9. Введите исходные данные (рис. 6).


      Рис. 6. Вид таблицы «Прайс-лист»

      10. Присвойте имя группе ячеек:

      выделите ячейки А3:В8;

      выберите команду «Присвоить имя» в разделе «Определенные имена» меню «Формулы» (рис. 7);


      Рис. 7. Вид окна «Создание имени»

      нажмите кнопку «ОК.».

      11. Переименуйте «Лист 2» в «Расчет стоимости работ» (аналогично действиям п. 2).

      12. Создайте таблицу «Расчет стоимости выполняемых работ» (аналогично действиям пунктов 3 — 7, 8) (рис. 8).


      Рис. 8. Вид таблицы «Расчет стоимости работ»

      13. Заполните графы «Наименование работы» и «Цена за единицу продукции, руб.»:

      сделайте ячейку А3 активной;

      в меню «Данные» выберите команду «Проверка данных», в поле «Тип данных» которой выберите «Список»;

      введите значение в поле «Источник», выделив диапазон A3:A8 в «Прайс-лист» (рис. 9);


      Рис. 9. Настройка списка плательщиков

      нажмите кнопку «ОК»;

      для того чтобы ввод наименования работы из списка осуществлялся в каждой ячейке столбца А («Наименование работы»), сделайте ячейку А3 активной и, установив курсор на маркер в правом нижнем углу, щелкните левой клавишей мыши и протяните его до ячейки А6 (рис. 10);


      Рис. 10. Вид листа «Расчет стоимости работ» при настройке списка

      в поле «Выберите функцию» нажмите «ВПР» (рис. 11);


      Рис. 11. Вид первого окна мастера функций

      нажмите кнопку «OK»;

      введите наименование работы в поле «Искомое_значение», щелкнув по ячейке А3;

      нажмите «Enter»;

      введите информацию в поле «Таблица»;

      воспользуйтесь командой «Использовать в формуле» меню «Формулы», выбрав «Вставить имена»;

      выделите «Имя:» «Прайс_лист» (рис. 12);


      Рис. 12. Ввод имени массива в качестве аргумента формулы

      нажмите кнопку «OK»;

      нажмите «Enter»;

      введите информацию — цифру 2 в поле «Номер_столбца»;

      введите информацию — цифру 0 в поле «Интервальный_просмотр» (рис. 13);


      Рис. 13. Вид второго окна мастера функций

      Нажмите кнопку «ОК»;

      14. Заполните графу «Объем выполняемых работ».

      15. Введите наименования работ в ячейки А4:А6:

      Сделайте ячейку А4 активной;

      Щелкните на кнопку рядом с ячейкой А4 и из предложенного списка выберите наименование работ — Замена батарей, шт. Ячейка С4 — «Цена за единицу продукции, руб.» будет заполнена автоматически (рис. 14);


      Рис. 14. Автоматическое заполнение Цены за единицу продукции по ее наименованию

      аналогично заполните ячейки А5:А6, ячейки С5:С6 будут также заполнены автоматически.

      16. Заполнить графу «Стоимость работы, руб»
      таблицы «Расчёт стоимости выполняемых работ».
      Для этого:

      занести в ячейку D3 формулу =B3*C3;

      размножить введённую в ячейку D3 формулу для остальных ячеек D4:D6 данной графы (с помощью функции автозаполнения).

      Таким образом, будет выполнен цикл, управляющим параметром которого является номер строки.

      17. Заполненная таблица выглядит следующим образом (рис. 15).


      Рис. 15. Результат заполнения таблицы «Расчеты стоимости работ»

      18. Переименуйте «Лист 3» в « Счет» (аналогично действиям п. 2).

      19. На рабочем листе «Счет» создайте необходимую таблицу, рукодствуясь предшествующими пунктами.

      20. С помощью функции ПРОСМОТР() создайте межтабличные связи. Однако перед этим отсортируйте значения таблицы «Расчеты стоимости выполняемых работ» в порядке возрастания по столбцу «Наименование работ». Для этого:

      выделите диапазон ячеек А2:D6;

      выберите пункт «Сортировка и фильтр» на Главной, а там «Настраиваемая сортировка»;

      в выпавшем окне выберите «Сортировать по» «Наименованию работ»;

      нажмите кнопку «ОК».

      воспользуйтесь командой «Вставить функцию» меню «Формулы»;

      в поле «Выберите функцию» нажмите «ПРОСМОТР»;

      нажмите кнопку «OK»;

      введите наименование работы в поле «Искомое_значение», щелкнув по ячейке С9;

      нажмите «Enter»;

      введите информацию в поле «Просматриваемый вектор», а именно ‘Расчет стоимости работ’!$A$3:$A$6;

      нажмите «Enter»;

      введите информацию в поле «Искомый вектор», а именно ‘Расчет стоимости работ’!$С$3:$С$6;

      нажмите «Enter» (рис. 16);


      Рис. 16. Вид второго окна мастера функции ПРОСМОТР

      нажмите кнопку «ОК»;

      22. Повторите действия, аналогичные п. 22 для ячеек D9:D12, E9:E12.

      23. Заполнить графу «ИТОГО» таблицы следующим образом:

      занести в ячейку F13 формулу =СУММ(F9:F12) .

      24. Заполните графу «НДС». Для этого занести в ячейку F14 формулу =F13*0,18.

      25. Заполните графу «СУММА С НДС». Для этого занести в ячейку F15 формулу =F13+F14 .

      26. В результате у Вас должна получиться таблица, пркдставленная на рис. 17.

      Рис. 17. Форма счета на оплату выполненных работ

      27. Для анализа информации о стоимости каждого вида работ по полученному заказу:

      сделайте активным лист «Счет»;

      выделите диапазон C9:F12;

      выберите команду «Гистограмма» в разделе «Диаграммы» меню «Вставка»;

      выберите необходимый тип гистограммы;

      переименуйте гистограмму в «Cтоимость каждого вида работ» (рис. 18).


      Рис. 18. Гистограмма «Стоимость каждого вида работ»

      2.3. Результаты компьютерного эксперимента и их анализа

      2.3.1. Результаты компьютерного эксперимента

      Для тестирования правильности решения задачи заполним входные документы, а затем рассчитаем результаты.

      Прайс-лист

      Наименование работы

      Цена за единицу продукции, руб.

      Замена ванны, шт.

      Замена труб, м

      Наклейка обоев, м2

      Настилка паркета, м2

      Побелка потолка, м2

      Расчет стоимости выполняемых работ

      Наименование работы

      Объем выполняемых работ

      Цена за единицу продукции, руб.

      Стоимость работы, руб.

      Замена батарей, шт.

      1000

      Замена труб, м

      Наклейка обоев, м2

      1400

      Настилка паркета, м2

      1200

      ООО «Строй-дизайн»

      СЧЕТ №

      Дата


      .
      .20

      ФИО клиента

      № п/п

      Наименование работы

      Объем выполняемых работ

      Цена за единицу продукции, руб.

      Стоимость работ, руб.

      Замена батарей, шт.

      1000

      Наклейка обоев, м2

      1400

      Замена труб, м

      Настилка паркета, м2

      1200

      ИТОГО:

      4560

      НДС:

      820,8

      СУММА С НДС:

      5380,8

      В результате решения задачи полученные с помощью компьютера ведомости совпадают с тестовыми.

      2.3.2. Анализ полученных результатов

      Таким образом, формирование результирующего документа (таблицы) «Счет» позволяет решить поставленную задачу — сократить время на выполнения расчетов стоимости работ, исключить ошибок, обусловленных с человеческим фактором и повысить степень удовлетворенности клиента. Создание различных диаграмм (гистограмм, графиков) на основе данных таблиц средствами MS Excel позволяет не только наглядно представлять результаты обработки информации для проведения анализа с целью принятия решений, но и достаточно быстро осуществлять манипуляции в области их построения в пользу наиболее удобного представления результатов визуализации по задаваемым пользователем (аналитиком) параметрам.

      Основные идеи современной информационной технологии базируются на концепции, согласно которой данные должны быть организованы в базы данных с целью адекватного отображения изменяющегося реального мира и удовлетворения информационных потребностей пользователей. Эти базы данных создаются и функционируют под управлением специальных программных комплексов, называемых системами управления базами данных (СУБД).

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

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

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

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

      В процессе анализа вышеизложенной информации выявлены следующие недостатки рассмотренной модели баз данных: так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько-нибудь сложных взаимосвязей в базе данных; высокая трудоемкость манипулирования информацией и изменения связей.

      В практической части была решена средства MS Excel 2010 поставленная задача в отношении условного предприятия – фирмы ООО «Строй-дизайн», которая осуществляет деятельность, связанную с выполнением работ по ремонту помещений. Были построены таблицы по приведенным данным в задании. Выполнен расчет стоимости работ по полученному заказу, данные расчета занести в таблицу. Организованы межтабличные связи с использованием функций ВПР или ПРОСМОТР для автоматического формирования счета, выставляемого клиенту для оплаты выполняемых работ. Сформирован и заполнен документ «Cчет на оплату выполненных работ». Приведены результаты расчета стоимости каждого вида работ по полученному заказу представить в графическом виде.

      Компьютерная обучающая программа по дисциплине Информатика» / А.Н. Романов, В.С. Торопцов, Д.Б. Григорович, Л.А. Галкина, А.Ю. Артемьев, Н.И. Лобова, К.Е. Михайлов, Г.А. Жуков, О.Е. Кричевская, С.В. Ясеновский, Л.А. Вдовенко, Б.Е. Одинцов, Г.А. Титоренко, Г.Д. Савичев, В.И. Гусев, С.Е. Смирнов, В.И. Суворова, Г.В. Федорова, Г.Б. Коняшина. – М.: ВЗФЭИ, 2000. Дата обновления 24.11.2010. – Доступ по логину и паролю.

      Компьютерная обучающая программа по дисциплине «Информационные системы в экономике» / А.Н. Романов, В.С. Торопцов, Д.Б. Григорович, Л.А. Галкина, А.В. Мортвичев, Б.Е. Одинцов, Г.А. Титоренко, Л.А. Вдовенко, В.В. Брага, Г.Д. Савичев, В.И. Суворова. – М.: ВЗФЭИ, 2005. Дата обновления 15.10.2010. – URL: . Доступ по логину и паролю.

      СУБД ПОНЯТИЕ И ВИДЫ МОДЕЛЕЙ БАЗ ДАННЫХ СБОР ДАННЫХ СОЦИОЛОГИЧЕСКОГО ХАРАКТЕРА С ИСПОЛЬЗОВАНИЕМ ТЕХНОЛОГИЙ БАЗ ДАННЫХ. СОЗДАНИЕ ТАБЛИЦ И ФОРМ БД 2013-11-05

    Этой статьей мы начинаем новый цикл, посвященный базам данных, современным технологиям доступа к данным и их обработки. На протяжении данного цикла мы планируем рассмотреть наиболее популярные настольные и серверные системы управления базами данных (СУБД), механизмы доступа к данным (OLD DB, ADO, BDE и др.) и утилиты для работы с базами данных (средства администрирования, генераторы отчетов, средства графического представления данных). Кроме того, мы планируем уделить внимание методам публикации данных в Internet, а также таким популярным способам обработки и хранения данных, как OLAP (On-Line Analytical Processing), и созданию хранилищ данных (Data Warehousing).

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

    Основные концепции реляционных баз данных

    Начнем с основных понятий СУБД и краткого введения в теорию реляционных баз данных - наиболее популярного сейчас способа хранения данных.

    Реляционная модель данных

    Реляционная модель данных была предложена Е.Ф.Коддом (Dr. E.F.Codd), известным исследователем в области баз данных, в 1969 году, когда он был сотрудником фирмы IBM. Впервые основные концепции этой модели были опубликованы в 1970 г. «A Relational Model of Data for Large Shared Data Banks», CACM, 1970, 13 N 6).

    Реляционная база данных представляет собой хранилище данных, содержащее набор двухмерных таблиц. Набор средств для управления подобным хранилищем называется реляционной системой управления базами данных (РСУБД) . РСУБД может содержать утилиты, приложения, сервисы, библиотеки, средства создания приложений и другие компоненты.

    Любая таблица реляционной базы данных состоит из строк (называемых также записями ) и столбцов (называемых также полями ). В данном цикле мы будем использовать обе пары терминов.

    Строки таблицы содержат сведения о представленных в ней фактах (или документах, или людях, одним словом, - об однотипных объектах). На пересечении столбца и строки находятся конкретные значения содержащихся в таблице данных.

    Данные в таблицах удовлетворяют следующим принципам:

    1. Каждое значение, содержащееся на пересечении строки и колонки, должно быть атомарным (то есть не расчленяемым на несколько значений).
    2. Значения данных в одной и той же колонке должны принадлежать к одному и тому же типу, доступному для использования в данной СУБД.
    3. Каждая запись в таблице уникальна, то есть в таблице не существует двух записей с полностью совпадающим набором значений ее полей.
    4. Каждое поле имеет уникальное имя.
    5. Последовательность полей в таблице несущественна.
    6. Последовательность записей также несущественна.

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

    Поскольку последовательность колонок в таблице несущественна, обращение к ним производится по имени, и эти имена для данной таблицы уникальны (но не обязаны быть уникальными для всей базы данных).

    Итак, теперь мы знаем, что реляционные базы данных состоят из таблиц. Для иллюстрации некоторых теоретических положений и для создания примеров нам необходимо выбрать какую-нибудь базу данных. Чтобы не «изобретать колесо», мы воспользуемся базой данных NorthWind, входящей в комплект поставки Microsoft SQL Server и Microsoft Access.

    Теперь давайте рассмотрим связи между таблицами.

    Ключи и связи

    Давайте взглянем на фрагмент таблицы Customers (клиенты) из базы данных NorthWind (мы удалили из нее поля, несущественные для иллюстрации связей между таблицами).

    Поскольку строки в таблице неупорядочены, нам нужна колонка (или набор из нескольких колонок) для уникальной идентификации каждой строки. Такая колонка (или набор колонок) называется первичным ключом (primary key ). Первичный ключ любой таблицы обязан содержать уникальные непустые значения для каждой строки.

    Если первичный ключ состоит из более чем одной колонки, он называется составным первичным ключом (composite primary key ).

    Типичная база данных обычно состоит из нескольких связанных таблиц. Фрагмент таблицы Orders (заказы).

    Поле CustomerID этой таблицы содержит идентификатор клиента, разместившего данный заказ. Если нам нужно узнать, как называется компания, разместившая заказ, мы должны поискать это же значение идентификатора клиента в поле CustomerID таблицы Customers и в найденной строке прочесть значение поля CompanyName. Иными словами, нам нужно связать две таблицы, Customers и Orders, по полю CustomerID. Колонка, указывающая на запись в другой таблице, связанную с данной записью, называется внешним ключом (foreign key ). Как видим, в случае таблицы Orders внешним ключом является колонка CustomerID (рис. 1).

    Иными словами, внешний ключ - это колонка или набор колонок, чьи значения совпадают с имеющимися значениями первичного ключа другой таблицы.

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

    Если каждый клиент в таблице Customers может разместить только один заказ, говорят, что эти две таблицы связаны соотношением один-к-одному (one-to-one relationship ). Если же каждый клиент в таблице Customers может разместить ноль, один или много заказов, говорят, что эти две таблицы связаны соотношением один-ко-многим (one-to-many relationship ) или соотношением master-detail . Подобные соотношения между таблицами используются наиболее часто. В этом случае таблица, содержащая внешний ключ, называется detail-таблицей , а таблица, содержащая первичный ключ, определяющий возможные значения внешнего ключа, называется master-таблицей .

    Группа связанных таблиц называется схемой базы данных (database schema ). Информация о таблицах, их колонках (имена, тип данных, длина поля), первичных и внешних ключах, а также иных объектах базы данных, называется метаданными (metadata ).

    Любые манипуляции с данными в базах данных, такие как выбор, вставка, удаление, обновление данных, изменение или выбор метаданных, называются запросом к базе данных (query ). Обычно запросы формулируются на каком-либо языке, который может быть как стандартным для разных СУБД, так и зависящим от конкретной СУБД.

    Ссылочная целостность

    Выше мы уже говорили о том, что первичный ключ любой таблицы должен содержать уникальные непустые значения для данной таблицы. Это утверждение является одним из правил ссылочной целостности (referential integrity ). Некоторые (но далеко не все) СУБД могут контролировать уникальность первичных ключей. Если СУБД контролирует уникальность первичных ключей, то при попытке присвоить первичному ключу значение, уже имеющееся в другой записи, СУБД сгенерирует диагностическое сообщение, обычно содержащее словосочетание primary key violation . Это сообщение в дальнейшем может быть передано в приложение, с помощью которого конечный пользователь манипулирует данными.

    Если две таблицы связаны соотношением master-detail , внешний ключ detail- таблицы должен содержать только те значения, которые уже имеются среди значений первичного ключа master- таблицы. Если корректность значений внешних ключей не контролируется СУБД, можно говорить о нарушении ссылочной целостности. В этом случае, если мы удалим из таблицы Customers запись, имеющую хотя бы одну связанную с ней detail- запись в таблице Orders, это приведет к тому, что в таблице Orders окажутся записи о заказах, размещенных неизвестно кем. Если же СУБД контролирует корректность значений внешних ключей, то при попытке присвоить внешнему ключу значение, отсутствующее среди значений первичных ключей master-таблицы, либо при удалении или модификации записей master-таблицы, приводящих к нарушению ссылочной целостности, СУБД сгенерирует диагностическое сообщение, обычно содержащее словосочетание foreign key violation , которое в дальнейшем может быть передано в пользовательское приложение.

    Большинство современных СУБД, например Microsoft Access 97, Microsoft Access 2000 и Microsoft SQL Server 7.0, способны контролировать соблюдение правил ссылочной целостности, если таковые описаны в базе данных. Для этой цели подобные СУБД используют различные объекты баз данных (мы обсудим их чуть позже). В этом случае все попытки нарушить правила ссылочной целостности будут подавляться с одновременной генерацией диагностических сообщений или исключений (database exceptions ).

    Введение в нормализацию данных

    Процесс проектирования данных представляет собой определение метаданных в соответствии с задачами информационной системы, в которой будет использоваться будущая база данных. Подробности о том, как производить анализ предметной области, создавать диаграммы «сущность-связь» (ERD - entity-relationship diagrams ) и модели данных, выходят за рамки данного цикла. Интересующиеся этими вопросами могут обратиться, например, к книге К.Дж.Дейта «Введение в системы баз данных» («Диалектика», Киев, 1998).

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

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

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

    Первая нормальная форма

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

    Чтобы таблица соответствовала первой нормальной форме, все значения ее полей должны быть атомарными, и

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

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

    • Адрес конкретного клиента может содержаться в базе данных только тогда, когда клиент заказал хотя бы один продукт.
    • При удалении записи о заказанном продукте одновременно удаляются сведения о самом заказе и о клиенте, его разместившем.
    • Если, не дай бог, заказчик сменил адрес, придется обновить все записи о заказанных им продуктах.

    Некоторые из этих проблем могут быть решены путем приведения базы данных ко второй нормальной форме .

    Вторая нормальная форма

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

    Таблица OrderedProducts находится в первой, но не во второй нормальной форме, так как поля CustomerID, Address и OrderDate зависят только от поля OrderID, являющегося частью составного первичного ключа (OrderID, ProductID).

    Чтобы перейти от первой нормальной формы ко второй, нужно выполнить следующие шаги:

    1. Определить, на какие части можно разбить первичный ключ, так чтобы некоторые из неключевых полей зависели от одной из этих частей (эти части не обязаны состоять из одной колонки! ).
    2. Создать новую таблицу для каждой такой части ключа и группы зависящих от нее полей и переместить их в эту таблицу. Часть бывшего первичного ключа станет при этом первичным ключом новой таблицы.
    3. Удалить из исходной таблицы поля, перемещенные в другие таблицы, кроме тех их них, которые станут внешними ключами.

    Например, для приведения таблицы OrderedProducts ко второй нормальной форме, нужно переместить поля CustomerID, Address и OrderDate в новую таблицу (назовем ее OrdersInfo), при этом поле OrderID станет первичным ключом новой таблицы (рис. 3).

    В результате новые таблицы приобретут такой вид. Однако таблицы, находящиеся во второй, но не в третьей нормальной форме, по-прежнему содержат аномалии модификации данных. Вот каковы они, например, для таблицы OrdersInfo:

    • Адрес конкретного клиента по-прежнему может содержаться в базе данных только тогда, когда клиент заказал хотя бы один продукт.
    • Удаление записи о заказе в таблице OrdersInfo приведет к удалению записи о самом клиенте.
    • Если заказчик сменил адрес, придется обновить несколько записей (хотя, как правило, их меньше, чем в предыдущем случае).

    Устранить эти аномалии можно путем перехода к третьей нормальной форме .

    Третья нормальная форма

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

    Таблица OrderDetails уже находится в третьей нормальной форме. Неключевое поле Quantity полностью зависит от составного первичного ключа (OrderID, ProductID). Однако таблица OrdersInfo в третьей нормальной форме не находится, так как содержит зависимость между неключевыми полями (она называется транзитивной зависимостью - transitivedependency ) - поле Address зависит от поля CustomerID.

    Чтобы перейти от второй нормальной формы к третьей, нужно выполнить следующие шаги:

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

    Для приведения таблицы OrdersInfo к третьей нормальной форме создадим новую таблицу Customers и переместим в нее поля CustomerID и Address. Поле Address из исходной таблицы удалим, а поле CustomerID оставим - теперь это внешний ключ (рис. 4).

    Итак, после приведения исходной таблицы к третьей нормальной форме таблиц стало три - Customers, Orders и OrderDetails.

    Преимущества нормализации

    Нормализация устраняет избыточность данных, что позволяет снизить объем хранимых данных и избавиться от описанных выше аномалий их изменения. Например, после приведения рассмотренной выше базы данных к третьей нормальной форме налицо следующие улучшения:

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

    Изменение адреса клиента или даты регистрации заказа теперь требует изменения только одной записи.

    Как проектируют базы данных

    Обычно современные СУБД содержат средства, позволяющие создавать таблицы и ключи. Существуют и утилиты, поставляемые отдельно от СУБД (и даже обслуживающие несколько различных СУБД одновременно), позволяющие создавать таблицы, ключи и связи.

    Еще один способ создать таблицы, ключи и связи в базе данных - это написание так называемого DDL-сценария (DDL - Data Definition Language; о нем мы поговорим чуть позже).

    Наконец, есть еще один способ, который становится все более и более популярным, - это использование специальных средств, называемых CASE-средствами (CASE означает Computer-Aided System Engineering). Существует несколько типов CASE-средств, но для создания баз данных чаще всего используются инструменты для создания диаграмм «сущность-связь» (entity-relationship diagrams, E/R diagrams). С помощью этих инструментов создается так называемая логическая модель данных, описывающая факты и объекты, подлежащие регистрации в ней (в таких моделях прототипы таблиц называются сущностями (entities), а поля - их атрибутами (attributes). После установления связей между сущностями, определения атрибутов и проведения нормализации, создается так называемая физическая модель данных для конкретной СУБД, в которой определяются все таблицы, поля и другие объекты базы данных. После этого можно сгенерировать либо саму базу данных, либо DDL-сценарий для ее создания.

    Список наиболее популярных в настоящее время CASE-средств .

    Таблицы и поля

    Таблицы поддерживаются всеми реляционными СУБД, и в их полях могут храниться данные разных типов. Наиболее часто встречающиеся типы данных .

    Индексы

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

    Мы уже знаем, что записи в реляционных таблицах неупорядочены. Тем не менее любая запись в конкретный момент времени имеет вполне определенное физическое местоположение в файле базы данных, хотя оно и может изменяться в процессе редактирования данных или в результате «внутренней деятельности» самой СУБД.

    Предположим, в какой-то момент времени записи в таблице Customers хранились в таком порядке .

    Допустим, нам нужно получить эти данные упорядоченными по полю CustomerID. Опустив технические детали, мы можем сказать, что индекс по этому полю - это последовательность номеров записей, в соответствии с которой их нужно выводить, то есть:

    1,6,4,2,5,3

    Если же мы хотим упорядочить записи по полю Address, последовательность номеров записей будет другой:

    5,4,1,6,2,3

    Хранение индексов требует существенно меньше места, чем хранение по-разному отсортированных версий самой таблицы.

    Если нам нужно найти данные о клиентах, у которых CustomerID начинается с символов «BO», мы можем найти с помощью индекса местоположение этих записей (в данном случае 2 и 5 (очевидно, что в индексе номера этих записей идут подряд), а затем прочесть именно вторую и пятую записи, вместо того чтобы просматривать всю таблицу. Таким образом, использование индексов снижает время выборки данных.

    Мы уже говорили о том, что физическое местоположение записей может изменяться в процессе редактирования данных пользователями, а также в результате манипуляций с файлами базы данных, проводимых самой СУБД (например, сжатие данных, сборка «мусора» и др.). Если при этом происходят соответствующие изменения и в индексе, он называется поддерживаемым и такие индексы используются в большинстве современных СУБД. Реализация таких индексов приводит к тому, что любое изменение данных в таблице влечет за собой изменение связанных с ней индексов, а это увеличивает время, требующееся СУБД для проведения таких операций. Поэтому при использовании таких СУБД следует создавать только те индексы, которые реально необходимы, и руководствоваться при этом тем, какие запросы будут встречаться наиболее часто.

    Ограничения и правила

    Большинство современных серверных СУБД содержат специальные объекты, называемые ограничениями (constraints), или правилами (rules). Эти объекты содержат сведения об ограничениях, накладываемых на возможные значения полей. Например, с помощью такого объекта можно установить максимальное или минимальное значение для данного поля, и после этого СУБД не позволит сохранить в базе данных запись, не удовлетворяющую данному условию.

    Помимо ограничений, связанных с установкой диапазона изменения данных, существуют также ссылочные ограничения (referential constraints, например связь master-detail между таблицами Customers и Orders может быть реализована как ограничение, содержащее требование, чтобы значение поля CustomerId (внешний ключ) в таблице Orders было равно одному из уже имеющихся значений поля CustomerId таблицы Customers.

    Отметим, что далеко не все СУБД поддерживают ограничения. В этом случае для реализации аналогичной функциональности правил можно либо использовать другие объекты (например, триггеры), либо хранить эти правила в клиентских приложениях, работающих с этой базой данных.

    Представления

    Практически все реляционные СУБД поддерживают представления (views). Этот объект представляет собой виртуальную таблицу, предоставляющую данные из одной или нескольких реальных таблиц. Реально он не содержит никаких данных, а только описывает их источник.

    Нередко такие объекты создаются для хранения в базах данных сложных запросов. Фактически view - это хранимый запрос.

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

    Нередко эти объекты используются для обеспечения безопасности данных, например, путем разрешения просмотра данных с их помощью без предоставления доступа непосредственно к таблицам. Помимо этого некоторые представления объекты могут возвращать разные данные в зависимости, например, от имени пользователя, что позволяет ему получать только интересующие его данные.

    Триггеры и хранимые процедуры

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

    Хранимая процедура - это специальный вид процедуры, который выполняется сервером баз данных. Хранимые процедуры пишутся на процедурном языке, который зависит от конкретной СУБД. Они могут вызывать друг друга, читать и изменять данные в таблицах, и их можно вызвать из клиентского приложения, работающего с базой данных.

    Хранимые процедуры обычно используются при выполнении часто встречающихся задач (например, сведение бухгалтерского баланса). Они могут иметь аргументы, возвращать значения, коды ошибок и иногда наборы строк и колонок (такой набор данных иногда называется термином dataset). Однако последний тип процедур поддерживается не всеми СУБД.

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

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

    Объекты для генерации первичных ключей

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

    В разных СУБД для генерации ключей используются разные объекты. Некоторые из таких объектов хранят целое число и правила, по которым генерируется следующее за ним значение, -обычно это выполняется с помощью триггеров. Такие объекты поддерживаются, например, в Oracle (в этом случае они называются последовательностями - sequences) и в IB Database (в этом случае они называются генераторами - generators).

    Некоторые СУБД поддерживают специальные типы полей для первичных ключей. При добавлении записей такие поля заполняются автоматически последовательными значениями (обычно целыми). В случае Microsoft Access и Microsoft SQL Server такие поля называются Identity fields, а в случае Corel Paradox - автоинкрементными полями (Autoincrement fields).

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

    Предотвращение несанкционированного доступа к данным является серьезной проблемой, которая решается разными способами. Самый простой - это парольная защита либо всей таблицы, либо некоторых ее полей (такой механизм поддерживается, например, в Corel Paradox).

    В настоящее время более популярен другой способ защиты данных - создание списка пользователей (users) с именами (user names) и паролями (passwords). В этом случае любой объект базы данных принадлежит конкретному пользователю, и этот пользователь предоставляет другим пользователям разрешение на чтение или модификацию данных из этого объекта либо на модификацию самого объекта. Этот способ применяется во всех серверных и некоторых настольных СУБД (например, Microsoft Access).

    Некоторые СУБД, в основном серверные, поддерживают не только список пользователей, но и роли (roles). Роль - это набор привилегий. Если конкретный пользователь получает одну или несколько ролей, а вместе с ними - и все привилегии, определенные для данной роли.

    Запросы к базам данных

    Модификация и выбор данных, изменение метаданных и некоторые другие операции осуществляются с помощью запросов (query). Большинство современных СУБД (и некоторые средства разработки приложений) содержат средства для генерации таких запросов.

    Один из способов манипуляции данными называется «queries by example» (QBE) - запрос по образцу. QBE представляет собой средство для визуального связывания таблиц и выбора полей, которые следует отобразить в результате запроса.

    В большинстве СУБД (за исключением некоторых настольных) визуальное построение запроса с помощью QBE приводит к генерации текста запроса с помощью специального языка запросов SQL (Structured Query Language). Можно также написать запрос непосредственно на языке SQL.

    Курсоры

    Нередко результатом запроса является набор из строк и столбцов (dataset). В отличие от реляционной таблицы в таком наборе строки упорядочены, и их порядок определяется исходным запросом (и иногда - наличием индексов). Поэтому мы можем определить текущую строку в таком наборе и указатель на нее, который называется курсором (cursor).

    Большинство современных СУБД поддерживают так называемые двунаправленные курсоры (bi-directional cursors), позволяющие перемещаться по результирующему набору данных как вперед, так и назад. Однако некоторые СУБД поддерживают только однонаправленные курсоры, позволяющие перемещаться по набору данных только вперед.

    Язык SQL

    Structured Query Language (SQL) - это непроцедурный язык, используемый для формулировки запросов к базам данных в большинстве современных СУБД и в настоящий момент являющийся индустриальным стандартом.

    Непроцедурность языка означает, что на нем можно указать, что нужно сделать с базой данных, но нельзя описать алгоритм этого процесса. Все алгоритмы обработки SQL-запросов генерируются самой СУБД и не зависят от пользователя. Язык SQL состоит из набора операторов, которые можно разделить на несколько категорий:

    • Data Definition Language (DDL) - язык определения данных, позволяющий создавать, удалять и изменять объекты в базах данных
    • Data Manipulation Language (DML) - язык управления данными, позволяющий модифицировать, добавлять и удалять данные в имеющихся объектах базы данных
    • Data Control Languages (DCL) - язык, используемый для управления пользовательскими привилегиями
    • Transaction Control Language (TCL) - язык для управления изменениями, сделанными группами операторов
    • Cursor Control Language (CCL) - операторы для определения курсора, подготовки операторов SQL к выполнению и некоторых других операций.

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

    Функции, определяемые пользователем

    Некоторые СУБД позволяют использовать функции, определяемые пользователем (UDF-User-Defined Functions). Эти функции, как правило, хранятся во внешних библиотеках и должны быть зарегистрированы в базе данных, после чего их можно использовать в запросах, триггерах и хранимых процедурах.

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

    Транзакции

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

    Завершение (Commit) транзакции означает, что все операции, входящие в состав транзакции, успешно завершены, и результат их работы сохранен в базе данных.

    Откат (Rollback) транзакции означает, что все уже выполненные операции, входящие в состав транзакции, отменяются и все объекты базы данных, затронутые этими операциями, возвращены в исходное состояние. Для реализации возможности отката транзакций многие СУБД поддерживают запись в log-файлы, позволяющие восстановить исходные данные при откате.

    Транзакция может состоять из нескольких вложенных транзакций.

    Некоторые СУБД поддерживают двухфазное завершение транзакций (two-phase commit) - процесс, позволяющий осуществлять транзакции над несколькими базами данных, относящихся к одной и той же СУБД.

    Для поддержки распределенных транзакций (то есть транзакций над базами данных, управляемых разными СУБД), существуют специальные средства, называемые мониторами транзакций (transaction monitors).

    Заключение

    В данной статье мы обсудили основные концепции построения реляционных СУБД, базовые принципы проектирования данных, а также рассказали о том, какие объекты могут быть созданы в базах данных.

    В следующей статье мы познакомим наших читателей с наиболее популярными настольными СУБД: dBase, Paradox, Access, Visual FoxPro, Works и обсудим их основные возможности.

    КомпьютерПресс 3"2000

    Функции СУБД.

    Функции СУБД бывают высокого и низкого уровня.

    Функции высокого уровня:

    1. Определение данных – с помощью этой функции определяется какая информация будет храниться в БД (тип, свойства данных и как они между собой будут связаны).

    2. Обработка данных. Информация может обрабатываться разными способами: выборка, фильтрация, сортировка, объединение одной информации с другой, вычисление итоговых значений.

    3. Управление данными . С помощью этой функции указывается, кому разрешено знакомиться с данными, корректировать их или добавлять новую информацию, а также определять правила коллективного доступа.

    Функции низкого уровня:

    1. Управление данными во внешней памяти;

    2. Управление буферами оперативной памяти;

    3. Управление транзакциями;

    4. Введение журнала изменений в БД;

    5. Обеспечение целостности и безопасности БД.

    Транзакцией называется неделимая последовательность операций, которая отслеживается СУБД от начала и до завершения, и в которой при невыполнении одной операции отменяется вся последовательность.

    Журнал СУБД – особая БД или часть основной БД, недоступная пользователю и используемая для записи информации обо всех изменениях базы данных.

    Введение журнала СУБД предназначено для обеспечения надёжности хранения в базе данных при наличии аппаратных сбоев и отказов, а так же ошибок в программном обеспечении.

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

    Классификация СУБД.

    СУБД можно классифицировать:

    1. По видам программ:

    a. Серверы БД (например, MS SQL Server, InterBase (Borland)) – предназначены для организации центров обработки данных в сетях ЭВМ и реализуют функции управления базами данных, запрашиваемые клиентскими программами с помощью операторов SQL (т.е. программы, которые отвечают на запросы);

    b. Клиенты БД – программы, которые запрашивают данные. В качестве клиентских программ могут использоваться ПФСУБД, электронные таблицы, текстовые процессоры, программы электронной почты;

    c. Полнофункциональные БД (MS Access, MS Fox Pro) – программа, имеющая развитый интерфейс, позволяющий создавать и модифицировать таблицы, вводить данные, создавать и форматировать запросы, разрабатывать отчёты и выводить их на печать.

    2. По модели данных СУБД (как и БД):

    a. Иерархические – основаны на древовидной структуре хранения информации и напоминают файловую систему компьютера; основной недостаток - невозможность реализовать отношение многие - ко – многим;

    b. Сетевые – которые пришли на смену иерархическим и просуществовали недолго т. к. основной недостаток – сложность разработки серьёзных приложений. Основное отличие сетевой от иерархической в том, что в иерархической структура «запись – потомок» имеет только одного предка, а в сетевой потомок может иметь любое количество предков;

    c. Реляционные – данные которых размещены в таблицах, между которыми существуют определённые связи;

    d. Объектно – ориентированные – в них данные хранятся в виде объектов и основное преимущество при работе с ними в том, что к ним можно применить объектно – ориентированный подход;

    e. Гибридные, т. е. объектно – реляционные – совмещают в себе возможности реляционных и объектно – ориентированных баз данных. Примером такой базы данных является Oracle (ранее она была реляционной).

    3. В зависимости от расположения отдельных частей СУБД различают:

    a. локальные – все части которой располагаются на одном компьютере;

    b. сетевые.

    К сетевым относятся:

    - с организацией файл – сервер ;

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

    - с организацией клиент – сервер;

    Сервер БД принимает запрос от клиента, отыскивает в данных нужную запись и передаёт её клиенту. Запрос к серверу формируется на языке структурированных запросов SQL, поэтому серверы БД называют SQL – серверами.

    - распределённые СУБД содержат несколько десятков и сотен серверов, размещённых на значительной территории.

    Основные положения реляционной модели БД.

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

    Особенности реляционных баз данных:

    1. Данные хранятся в таблицах, состоящих из столбцов и строк;

    2. На пересечении каждого столбца и строки находится одно значение;

    3. У каждого столбца - поля есть своё имя, которое служит его названием - атрибут, и все значения в одном столбце, имеют один тип;

    4. Столбцы располагаются в определённом порядке, который задаётся при создании таблицы, в отличие от строк, которые располагаются в произвольном порядке. В таблице может не быть ни одной строчки, но обязательно должен быть хотя бы один столбец.

    Терминология реляционной базы данных:

    Элемент реляционной БД Форма представления
    1. База данных Набор таблиц
    2. Схема базы данных Набор заголовков таблиц
    3. Отношение Таблица
    4. Схема отношения Строка заголовков столбцов таблицы
    5. Сущность Описание свойств объекта
    6. Атрибут Заголовок столбца
    7. Домен Множество допустимых значений атрибута
    8. Первичный ключ Уникальный идентификатор, однозначно определяющий каждую запись в таблице
    9. Тип данных Тип значений элементов в таблице
    10. Кортеж Строка (запись)
    11. Кардинальность Количество строк в таблице
    12. Степень отношения Количество полей
    13. Тело отношения Множество кортежей отношения

    При проектировании реляционной БД данные размещают в нескольких таблицах. Между таблицами устанавливают связи с помощью ключей. При связывании таблиц выделяют основную и дополнительную (подчинённую) таблицу.

    Существуют следующие виды связей между таблицами:

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

    2. Связь вида 1:М (один ко многим) означает, что каждой записи в основной таблице соответствует несколько записей в дополнительной таблице и, наоборот, каждой записи в дополнительной таблице соответствует только одна запись в основной таблице.

    3. Связь вида М:1 (многим к одному) означает, что одной или нескольким записям в основной таблице соответствует только одна запись в дополнительной таблице.

    4. Связь вида М:М (многим ко многим) – это, когда нескольким записям основной таблицы соответствует несколько записей дополнительной и наоборот.

    5. Основные компоненты MS Access.

    Основными компонентами (объектами) MS Access являются:

    1. Таблицы;

    3. Формы;

    4. Отчёты;

    5. Макросы:

    Модули.

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

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

    Форма – это объект, в котором можно разместить элементы управления, предназначенные для ввода, изображения и изменения данных в полях таблицах.

    Отчёт – это объект, который позволяет представить определённую пользователем информацию в определённом виде, просматривать и распечатывать её.

    Макрос – одна или несколько макрокоманд, которые можно использовать для автоматизации конкретной задачи. Макрокоманда – основной строительный блок макроса; самостоятельная инструкция, которая может быть объединена с другими макрокомандами, чтобы автоматизировать выполнение задачи.

    Модуль – набор описаний, инструкций и процедур, сохранённых под одним именем. В MS Access имеется три вида модулей:модуль формы, отчёта и общий модуль. Модули формы и отчётов содержат локальную программу для форм и отчётов.

    6. Таблицы в MS Access.

    В MS Access существуют следующие методы создания таблиц:

    1. Режим таблицы;

    2. Конструктор;

    3. Мастер таблиц;

    4. Импорт таблиц;

    5. Связь с таблицами.

    В режиме таблицы данные вводятся в пустую таблицу. Для ввода данных предоставляется таблица с 30 полями. После её сохранения MS Access сам решает, какой тип данных присвоить каждому полю.

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

    Для определения поля в режиме Конструктор задаются:

    1. Имя поля , которое в каждой таблице должно иметь уникальное имя, являющееся комбинацией букв, цифр, пробелов и специальных символов, за исключением «.!” “ ». Максимальная длина имени 64 символа.

    2. Тип данных определяет вид и диапазон допустимых значений, а также объём памяти, выделенный для этого поля.

    Типы данных MS Access

    Тип данных Описание
    Текстовый Текст и числа, например, имена и адреса, номера телефонов, почтовые индексы (до 255 символов).
    Поле Memo Длинный текст и числа, например комментарии и пояснения (до 64000 символов).
    Числовой Общий тип данных для числовых данных, допускающих проведение математических расчётов, за исключением денежных расчётов.
    Дата / время Значения даты и времени. Пользователь может выбирать стандартные формы или создавать специальный формат.
    Денежный Денежные значения. Для денежных расчётов не рекомендуется использовать числовые типы данных, т.к. они могут округляться при расчётах. Значения типа «денежный» всегда выводятся с указанным числом десятичных знаков после запятой.
    Счётчик Автоматически выставляющиеся последовательные номера. Нумерация начинается с 1. Поле счётчика удобно для создания ключа. Это поле является совместимым с полем числового типа, для которого в свойстве Размер указано значение «Длинное целое».
    Логический Значения «Да / Нет», «Истинно / Ложь», «Вкл / Выкл», одно из двух возможных значений.
    Поле объекта OLE Объекты, созданные в других программах, поддерживающие протокол OLE.

    3. Наиболее важные свойства полей:

    - Размер поля задаёт максимальный размер данных, сохраняемых в поле.

    - Формат поля является форматом отображения заданного типа данных и задаёт правила представления данных при выводе их на экран или печать.

    - Подпись поля задаёт текст, который выводится в таблицах, формах, отчётах.

    - Условие на значение позволяет осуществлять контроль ввода, задаёт ограничения на вводимые значения, при нарушении условий запрещает ввод и выводит текст, заданный свойством Сообщение об ошибке;

    - Сообщение об ошибке задаёт текст сообщения, выводимый на экран при нарушении ограничений, заданных Условием на значение.

    Тип элемента управления – свойство, которое задаётся на закладке Подстановка в окне конструктора таблиц. Это свойство определяет, будет ли отображаться поле в таблице и в какой форме – в виде поля или поля со списком.

    Уникальный (первичный) ключ таблицы может быть простым или составным, включающим несколько полей.

    Для определения ключа выделяются поля, составляющие ключ, и на панели инструментов нажимается кнопка ключевое поле или выполняется команда Правка / ключевое поле .


    ©2015-2019 сайт
    Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
    Дата создания страницы: 2016-02-16

    Читать еще: