ТИПЫ ТАБЛИЦ И КЛЮЧЕЙ В РЕЛЯЦИОННЫХ БАЗАХ ДАННЫХ
МИНИСТЕРСТВО ВНУТРЕННИХ ДЕЛ
ПРИДНЕСТРОВСКОЙ МОЛДАВСКОЙ РЕСПУБЛИКИ
ТИРАСПОЛЬСКИЙ ЮРИДИЧЕСКИЙ ИНСТИТУТ
Им. М.И. КУТУЗОВА
Кафедра оперативно-розыскной деятельности
ЛЕКЦИЯ
по дисциплине «Информатика и информационные технологиив профессиональной деятельности»
специальность 031001.65 - «Правоохранительная деятельность»
ТЕМА №9:«Понятия базы и банка данных,
система управления базами данных (СУБД).
Обработка взаимосвязанных структурированных данных используя СУБД MS Access»
Г. Тирасполь, 2014 г.
ТЕМА №9:«Понятия базы и банка данных,
система управления базами данных (СУБД). Обработка взаимосвязанных структурированных данных используя СУБД MS Access.»
ПЛАН:
Введение
1. Базы данных
2. Свойства и функции СУБД
3. Введение в базы данных MicrosoftAccess
3.1 Свойства таблицы
3.2 Типы таблиц и ключей в реляционных базах данных
3.3 Взаимосвязи таблиц
4. Информационный центр
5. Автоматизированные рабочие места в информационном обеспечении деятельности ОВД
Литература:
1. Информатика и математика для юристов: учебник / под ред. С. Я. Казанцева, Н. М. Дубининой – М.: ЮНИТИ-ДАНА, 2012.
2. Информатика базовый курс. 2-е изд. / Под ред. С.В. Симоновича СПб.: Питер, 2011
3. Информационные технологии в юридической деятельности. / Под редакцией профессора П.У. Кузнецова – М.: Юрайт, 2013.
4. Информационные технологии: учебник для вузов. Б.Я. Советов, В.В. Целиховский. – М.: Высшая школа, 2009.
|
|
|
5. Основы правовой информатики (юридические и математические основы информатики): учебное пособие / С. Г. Чубукова, В. Д. Элькин; под ред. М. М. Рассолова. - Изд. 2-е, испр. и доп. - М.: Контракт: ИНФРА-М, 2009.
6. Могилев, А. В. Практикум по информатике: (учебное пособие) / А. В. Могилев, Н. И. Пак, Е.К. Хеннер; под ред. Е. К. Хеннера.- 4-е изд., стер. — М.: Академия, 2008.
7. Информационные технологии в юридической деятельности. / Згадзай О.Э. и др. - М.: Юнити-Дана, 2014.
ВВЕДЕНИЕ
Потоки информации, циркулирующие в мире, который нас окружает, огромны. Во времени они имеют тенденцию к увеличению. Поэтому в любой организации, как большой, так и маленькой, возникает проблема такой организации управления данными, которая обеспечила бы наиболее эффективную работу. Некоторые организации используют для этого шкафы с папками, но большинство предпочитают компьютеризированные способы – базы данных, позволяющие эффективно хранить, структурировать и систематизировать большие объемы данных. И уже сегодня без баз данных невозможно представить работу большинства финансовых, промышленных, торговых и прочих организаций. Не будь баз данных, они бы просто захлебнулись в информационной лавине.
|
|
|
Существует много веских причин перевода существующей информации на компьютерную основу. Сейчас стоимость хранения информации в файлах ЭВМ дешевле, чем на бумаге. Базы данных позволяют хранить, структурировать информацию и извлекать оптимальным для пользователя образом. Использование клиент/серверных технологий позволяют сберечь значительные средства, а главное и время для получения необходимой информации, а также упрощают доступ и ведение, поскольку они основываются на комплексной обработке данных и централизации их хранения. Кроме того ЭВМ позволяет хранить любые форматы данных, текст, чертежи, данные в рукописной форме, фотографии, записи голоса и т.д.
1.БАЗЫ ДАННЫХ
В компьютерныхсистемах информация представляется в виде данных. Точнее: данные (data) — это информация, представленная в форме, необходимой для ввода ее в компьютер, хранения, обработки и выдачи потребителям.
База данных (БД)-это хранящая во внешней памяти ЭВМ совокупность взаимосвязанных данных, организованных по определенным правилам, предусматривающим общие принципы описания, хранения и обработки данных.
Базы данных главным образом ориентированы на хранение, выбор и модификацию постоянно существующей информации. Структура информации зачастую очень сложна, и хотя структуры данных различны в разных информационных системах, между ними часто бывает много общего.
|
|
|
Под базой данных понимается структурированный организованный набор данных, описывающих характеристики какой-либо физической или виртуальной системы.
База данных - совокупность взаимосвязанных данных, совместно хранимых в одном или нескольких компьютерных файлах.
Современные базы данных характеризуются чрезвычайно большими объемами и сложностью обрабатываемой информации (данными), обеспечивают возможность коллективного доступа к различным элементам данных. Это предопределило необходимость разработки специальных технических и программных средств для современных баз данных.
Центральную роль в управлении процессами в базах данных играет специально разработанный комплекс, получивший название системы управления базами данных (СУБД).
СУБД - это совокупность программных средств и организационных приемов, предназначенных для описания баз данных, коллективного их создания, ведения и дифференцированного использования многими пользователями.
|
|
|
Иногда «Базой данных» часто упрощённо или ошибочно называют системы управления базами данных (СУБД).
Виды концептуальных и логических моделей БД — сетевая модель, иерархическая модель, реляционная модель (ER-модель), многомерная модель, объектная модель.
На уровне физической модели электронная БД представляет собой файл или их набор в формате TXT, CSV, Excel, DBF, XML либо в специализированном формате конкретной СУБД. Также в СУБД в понятие физической модели включают специализированные виртуальные понятия, существующие в ёё рамках — таблица, табличное пространство, сегмент, куб, кластер и т.д.
В настоящее время наибольшее распространение получили реляционные базы данных. Сетевые и иерархические базы данных считаются устаревшими, объектно-ориентированные пока никак не стандартизированы и не получили широкого распространения. Некоторое возрождение получили иерархические базы данных в связи с появлением и распространением формата XML.
По виду модели БД разделяются:
Иерархические БД
Рис. Схема иерархической модели данных
В основе иерархических СУБД лежит довольно простая модель данных, которую можно представить себе в виде дерева ациклического ориентированного графа особого вида.
Дерево состоит из вершин, каждая из которых, кроме одной, имеет единственную родительскую вершину и несколько (в том числе ни одной) дочерних.
Вершина, не имеющая родительской, называется корнем дерева. Вершины, не имеющие дочерних, называются листьями. Остальные вершины являются ветвями.
Иерархические базы данных наиболее пригодны для моделирования структур, по своей природе являющихся иерархическими. В качестве примеров можно привести воинские подразделения или сложные механизмы, состоящие из более простых узлов, которые в свою очередь тоже можно подвергнуть декомпозиции.
Тем не менее существует значительное количество структур, не сводящихся к простой иерархии. Например, всем известное генеалогическое дерево, которое на самом деле не является деревом в строгом смысле, поскольку у большинства людей по два родителя. О более сложных структурах и говорить не приходится.
Иерархические СУБД быстро прошли пик популярности, которая обусловливалась их простотой в использовании и ранним появлением на рынке, когда основные конкуренты еще не дозрели для коммерческого использования. Затем их многочисленные недостатки сделали их неконкурентоспособными, и в настоящее время иерархическая модель представляет исключительно исторический интерес.
2) Сетевые БД
Рис. Схема сетевой модели данных
Подобно иерархической, сетевую модель также можно представить себе в виде ориентированного графа. Но в этом случае граф может содержать циклы, т.е. вершина может иметь несколько родительских.
Такая структура намного гибче и выразительнее предыдущей и пригодна для моделирования гораздо более широкого класса задач. В этой модели вершины представляют собой сущности, а соединяющие их ребра отношения между ними.
Сетевые БД имели гораздо больший успех и долго господствовали на рынке СУБД. В немалой степени их успеху способствовала энергичная деятельность DataBaseTaskGroup (DBTG) Комитета по языкам программирования ConferenceonDataSystemsLanguages (CODASYL). Эта организация тщательно проработала спецификации сетевой модели и ее архитектуру, что позволило создать ряд успешных коммерческих продуктов, не последнее место среди которых занимал некогда весьма популярный COBOL.
70-е годы XX века фактически стали эпохой расцвета сетевой модели. Сетевые СУБД весьма прочно укрепились на рынке, и реляционной модели пришлось с боем завоевывать свое место под солнцем. В истории информатики навечно останется Великий Спор, который на самом деле явился решающим сражением сетевой и реляционной моделей. В рядах сторонников сетевой архитектуры был сам великий Чарльз Бахман, и только гений Эдгара Кодда позволил реляционной модели одержать победу.
3) Реляционные БД
Реляционные БД являются в настоящий момент самыми распространенными. Их реализации существуют на всех мало-мальски пригодных для этого платформах (от персональных компьютеров до мэйнфреймов), для всех операционных систем и для всех применений отпростейших продуктов, предназначенных для ведения картотек индивидуального пользования, до сложнейших распределенных многопользовательских систем.
Рис. Схема реляционной модели данных
Несмотря на такое пестрое разнообразие, все эти СУБД имеют в основе общую основу реляционную модель данных, разработанную Коддом в 70-х годах XX столетия. С виду эта модель довольно проста: база данных выглядит как простой набор взаимосвязанных таблиц. Но за внешней простотой кроется мощный и вместе с тем изящный математический аппарат реляционной алгебры, которая в свою очередь базируется на целом ряде математических дисциплин, среди которых логика, исчисление предикатов, теория множеств.
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
• каждый элемент таблицы - один элемент данных;
• все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьной и т.д.) и длину;
• каждый столбец имеет уникальное имя;
Немалую роль в успехе реляционных СУБД играет также язык SQL, разработанный специально для запросов к реляционным БД. Это достаточно простой и в то же время выразительный язык, при помощи которого можно выполнять достаточно изощренные запросы к базе.
4) Объектно-ориентированные базы данных, в которой данные оформлены в виде моделей объектов, включающих прикладные программы, которые управляются внешними событиями.
В наиболее общей и классической постановке объектно-ориентированный подход базируется на концепциях:
· объекта и идентификатора объекта;
· атрибутов и методов;
· классов;
· иерархии и наследования классов.
5) Многомерные
Программное обеспечение OLAP используется при обработке данных из различных источников. Эти программные продукты позволяют реализовать множество различных представлений данных и характеризуются тремя основными чертами: многомерное представление данных; сложные вычисления над данными; вычисления, связанные с изменением данных во времени.
СВОЙСТВА И ФУНКЦИИ СУБД
Системы управления базами данных можно классифицировать по способу установления связей между данными, характеру выполняемых ими функций, сфере применения, числу поддерживаемых моделей данных, характеру используемого языка общения с базой данных и другим параметрам.
Классификация СУБД:
· по выполняемым функциям СУБД подразделяются на операционные и информационные;
· по сфере применения СУБД подразделяются на универсальные и проблемно-ориентированные;
· по используемому языку общения СУБД подразделяются на замкнутые, имеющие собственные самостоятельные языки общения пользователей с базами данных, и открытые, в которых для общения с базой данных используется язык программирования, расширенный операторами языка манипулирования данными;
· по числу поддерживаемых уровней моделей данных СУБД подразделяются на одно-, двух-, трехуровневые системы;
· по способу установления связей между данными различают реляционные, иерархические и сетевые базы данных;
· по способу организации хранения данных и выполнения функций обработки базы данных подразделяются на централизованные и распределенные.
Системы централизованных баз данных с сетевым доступом предполагают две основные архитектуры – файл-сервер или клиент-сервер.
Архитектура файл-сервер. Предполагает выделение одной из машин сети в качестве центральной (главный сервер файлов), где хранится совместно используемая централизованная база данных. Все другие машины исполняют роль рабочих станций. Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где в основном и производится их обработка. При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает.
Архитектура клиент-сервер. Эта модель взаимодействия компьютеров в сети для современных СУБД фактически стала стандартом. Каждый из подключенных к сети и составляющих эту архитектуру компьютеров играет свою роль: сервер владеет и распоряжается информационными ресурсами системы, клиент имеет возможность пользоваться ими. Помимо хранения централизованной базы данных сервер базы данных обеспечивает выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные транспортируются по сети от сервера к клиенту.
Основные функции СУБД:
1. Непосредственное управление данными во внешней памяти
Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрениядоступа к данным в некоторых случаях. В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти.
2. Управление буферами оперативной памяти
СУБД обычно работают с БД значительного размера; по крайней мере этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов.
Заметим, что существует отдельное направление СУБД, которое ориентировано на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований.
3. Управление транзакциями
Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое.
Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.
То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (на самом деле, это несколько идеализированное представление, поскольку в некоторых случаях пользователи многопользовательских СУБД могут ощутить присутствие своих коллег).
4. Журнализация
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.
Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода.
Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локальногожурнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.
5. Поддержка языков БД
Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - SchemaDefinitionLanguage) и язык манипулирования данными (DML - DataManipulationLanguage). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям.DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. Мы рассмотрим более подробно языки ранних СУБД в следующей лекции. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (StructuredQueryLanguage)
Прежде всего, язык SQL сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.
Язык SQL содержит специальные средства определения ограничений целостности БД. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности БД производится на языковом уровне, т.е. при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код.
Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне.
6. Авторизация доступа к объектам БД
Производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.
3.ВВЕДЕНИЕ В БАЗЫ ДАННЫХ MICROSOFTACCESS
СУБД Access входит в состав MicrosoftOffice и предназначена для работы с реляционными БД, т.е. представленными в табличной форме. В отличие от табличного процессора Excel, Access имеет более развитые средства для отбора данных из взаимосвязанных таблиц, формирования новых таблиц и отчетов.
Характерной особенностью баз данных, созданных в Access, является хранение создаваемых таблиц и средств для обработки данных в одном файле, имеющем расширение .mdb.
Достоинством Access является возможность создания СУБД (т.е. программы управления) без программирования. Однако, для сложных СУБД применение программирования на встроенном языке VisualBasicforApplications (VBA) позволяет повысить эффективность системы управления.
Основные объекты окна БД имеют следующее назначение:
· таблица — основное средство для хранения информации в БД;
· запрос — это инструмент для извлечения необходимой информации из исходных таблиц и представления ее в удобной форме.
· форма — это основное средство для ввода данных, управления СУБД и вывода результатов на экран монитора;
· отчет — это специальное средство для формирования выходных документов и вывода их на принтер;
· макросы в Access представляют собой совокупность внутренних команд, предназначенных для автоматизации работы с БД;
· модули являются программами, создаваемыми средствами языка VBA, и похожи на макросы в Word и Excel.
Таблицы и запросы связываются между собой с помощью схемы данных.
Таблицы, запросы, формы и отчеты БД можно создавать в двух режимах: вручную с помощью конструктора или при помощи Мастера. Выбор средства определяется конкретными обстоятельствами, однако следует заметить, что мастер быстро создает заготовку объекта, которую обычно требуется "дорабатывать" вручную.
Технология разработки СУБД содержит несколько этапов, основными из которых являются:
· проектирование структуры БД и связей между таблицами;
· разработка структуры отдельных таблиц и ввод данных в таблицы;
· разработка запросов;
· разработка схемы данных, реализующей запроектированные связи между таблицами и запросами;
· разработка макросов и программных модулей для управления БД;
· разработка форм для реализации интерфейса управления БД;
· разработка отчетов для печати документов.
Приведенная последовательность этапов не является жесткой. Обычно разработчику СУБД приходится многократно возвращаться к одним и тем же этапам, постепенно уточняя проект.
СВОЙСТВА ТАБЛИЦЫ
Основным элементом БД является таблица. Столбцы таблицы БД называются полями, а строки — записями. Первым этапом создания таблицы БД является задание ее структуры, т.е. определение количества и типа полей. Вторым этапом является ввод и редактирование записей в таблицу. БД считается созданной, даже если она пустая.
Поля таблицы просто определяют ее структуру и групповые свойства данных, записываемых в ячейках.
Рассмотрим основные свойства полей БД.
Имя поля — определяет как надо обращаться к данным поля (имена используются как заголовки таблиц). Каждое поле в таблице должно иметь уникальное имя, удовлетворяющее соглашениям об именах объектов в Access. Оно является комбинацией из букв, цифр, пробелов и специальныхсимволов, за исключением специальных и разделительных символов. Имя не может начинаться с пробела исодержать управляющие символы с кодами ASCII от 00 до 31. Максимальная длина имени 64 символа.
Тип данных (DataType). Тип данных определяется значениями, которые предполагается вводить в поле, и операциями, которые будут выполняется с этими значениями. В Access допускается использование девяти типов данных. Список возможных типов данных вызывается нажатием кнопки списка при выборе типа данных каждого поля:
Текстовый (Тех) - тип данных по умолчанию. Текст или цифры, не участвующие в расчетах. Число символов в поле не должно превышать 255. Максимальное число символов, которое можно ввести в поле, задается в свойстве Размер поля (FieldSize). Пустые символы в неиспользуемой части поля не сохраняются
Поле МЕМО (Меmо). Длительный текст, например, некоторое описание или примечание. Максимальная длина 64 000 символов
Числовой (Number). Числовые данные, используемые в математических вычислениях.
Конкретные варианты числового типа и их длина задаются в свойстве Размер поля (FieldSize). Для проведения денежных расчетов определен другой тип данных - Денежный (Currency)
Денежный (Currency). Денежные значения и числовые данные, используемые в расчетах, проводящихся с точностью до 15 знаков в целой и до 4 знаков в дробной части. Длина поля 8 байт. При обработке числовых значений из денежных полей выполняются вычисления с фиксированной точкой более быстрые, чем вычисления для полей с плавающей точкой, кроме того, при вычислениях предотвращается округление. Учитывая эти обстоятельства, рекомендуется для полей, в которых планируется хранить числовые значения с указанной точностью, использовать денежный тип данных
Дата/время (Data/Time). Значения даты или времени, относящиеся к годам с 100 по 9999 включительно.
Счетчик (AutoNumber). Тип данных поля, в которое для каждой новой записи автоматически вводятся уникальные целые, последовательно возрастающие (на 1), или случайные числа. Значения этого поля нельзя изменить или удалить. По умолчанию в поле вводятся последовательные значения. В таблице не может быть более одного поля этого типа. Используется для определения уникального ключа таблицы.
Логический (Yes/No). Логические данные, которые могут иметь одно из двух возможных значений Да/Нет; Истина/Ложь; Вкл./Выкл. (Yes/No; True/False; On/Off).
ПолеобъектаOLE (OLEObject). Объект (например, электронная таблица MicrosoftЕхсеl, документ MicrosoftWord, рисунок; звукозапись или другие данные в двоичном формате), связанный или внедренный в таблицу Access. Длина поля - до 1 Г игабайта (ограничивается объемом диска). Для полей типа ОLЕ и МЕМО не допускается сортировка и индексирование Гиперссылка (Hyperlink). В качестве гиперссылки можно указывать путь к файлу на жестком диске, путь UNC или адрес URL. Если щелкнуть мышью на поле гиперссылки, Access выполнит переход на соответствующий объект, документ, страницу Web или другое место назначения. Максимальная длина 64 000 символов
Мастер подстановок...(LookupWizard...). Выбор этого типа данных запускает мастера подстановок. Мастер строит для поля список значений на основе полей из другой таблицы. Значения в такое поле будут вводиться из одного из полей списка. Соответственно, фактически тип данных поля определяется типом данных поля списка. Возможно также определение поля со списком постоянных значений.
ТИПЫ ТАБЛИЦ И КЛЮЧЕЙ В РЕЛЯЦИОННЫХ БАЗАХ ДАННЫХ
Реляционные базы данных характеризуются наличием некоторых типов таблиц и ключей, позволяющих определить отношения между таблицами. Для того чтобы понять принципы разработки реляционных баз данных, требуется дать определения различных типов реляционных ключей и таблиц:
Базовая таблица. В реляционной базе данных базовой таблицей называется таблица, которая включает один или несколько столбцов свойств объекта и содержит первичный ключ, который однозначно определяет этот объект. Более того, базовая таблица должна содержать первичный ключ. Базовые таблицы часто называют первичными, поскольку они имеют первичный ключ. Промежуточная таблица. Таблица, не являющаяся базовой (т. к. она не объединяет свойства объекта или не содержит поле первичного ключа), которая используется для обеспечения связей между другими таблицами, называется таблицей отношений. Ключевые поля в таблицах отношений должны быть внешними ключами, связанными с первичными ключами базовой таблицы. Проще говоря, таблица отношений состоит только из внешних ключей и не содержит независимых элементов данных.
Определение первичного ключа
Каждая таблица в реляционной базе данных должна иметь уникальный (первичный) ключ, который может быть простым или составным, включающим несколько полей (до 10). Для определения ключа выделяются поля, составляющие ключ, и на панели инструментов Конструктор таблиц (TableDesign) нажимается кнопка Ключевое поле (РrimaryКеу) или выполняется команда меню Правка| Ключевое поле (Edit| PrimaryКеу).
Первичный ключ. Первичный ключ состоит из набора значений, которые однозначно определяют запись базовой таблицы. Любому значению первичного ключа должна соответствовать одна и только одна строка таблицы. Первичный ключ включает одно поле только в том случае, если это поле не содержит повторяющихся значений.
Составные ключи. Если для выполнения условий, накладываемых на значения первичного ключа, заданный ключ включает несколько полей таблицы, то тогда он называется составным. Внешние ключи. Внешний ключ — это столбец, значения которого соответствуют значениям первичного ключа другой связанной таблицы.
Индексы
В большинстве реляционных баз данных реализация ключей требует создания специальных объектов базы данных, именуемых индексами. Индекс (index) представляет собой список позиций записей, который показывает порядок их следования. Записи в реляционной таблице могут быть неупорядоченными. Тем не менее, любая запись имеет физическую позицию (положение) в файле базы данных. Эта позиция может меняться СУБД в процессе обработки данных, однако, в каждый конкретный момент времени она уникальна для каждой записи. Физическое положение (позиция) записи может измениться в процессе вставки, обновления или удаления данных, а также при выполнении некоторых манипуляций, осуществляемых сервером базы данных (таких, как компрессия файлов базы данных). Однако большинство современных настольных СУБД и все СУБД типа клиент/сервер поддерживают сопровождаемые индексы (maintainedindexes), т. е. индексы меняются при изменении положения записей и значений полей. В этом случае любая вставка, обновление или удаление записей приводит к тому, что производится запись самой таблицы и всех индексов, связанных с этой таблицей. Из-за этого увеличивается время, необходимое для модификации данных.
Необходимо отметить, что некоторые типы полей, например memo-и BLOB-ПОЛЯ, не могут быть проиндексированы.
Для ключевого поля автоматически строится индекс. В этом можно убедиться, просмотрев информацию об индексах таблицы. Окно Индексы (Indexes) вызывается щелчком на кнопке просмотра и редактирования индексов Индексы (Indexes) на панели инструментов или выполнением команды меню Вид| Индексы (View| Indexes).
В этом окне индексу первичного ключа присвоено имя РrimaryКеу, в столбце Поле (FieldName) перечисляются имена полей, составляющие индекс. Индекс ключевого поля всегда уникален и не допускает пустых полей в записях. Если первичный ключ не установлен пользователем до сохранения вновь созданной таблицы, Access спросит о необходимости создания первичного ключа. При ответе "Да" Access создаст первичный ключ с типом данных Счетчик (AuttoNumber).
ВЗАИМОСВЯЗИ ТАБЛИЦ
При создании в Access схемы данных в ней определяются и запоминаются связи между таблицами. Это позволяет системе автоматически использовать связи, один раз определенные в схеме данных, при создании форм, запросов, отчетов на основе взаимосвязанных таблиц, а пользователь освобождается от необходимости указывать эти связи при конструировании этих объектов. Схема данных базы графически отображается в своем окне, где таблицы представлены списками полей, а связи - линиями между полями разных таблиц.
Создание схемы данных
Создание схемы данных начинается в окне Базы данных (Database) с выполнения команды Сервис|Схема данных (Tools|Relationships) или нажатия кнопки Схема данных (Relationships) на панели инструментов базы данных.
Одно-многозначные (1:М) или одно-однозначные (1:1) связи. Схема данных прежде всего ориентирована на работу с таблицами, отвечающими требованиям нормализации, между которыми могут быть установлены одно-многозначные (1:М) или одно-однозначные (1:1) связи, для которых может автоматически поддерживаться связная целостность. Поэтому схему данных целесообразно строить в соответствии с информационно-логической моделью.
При построении схемы данных Access автоматически определяет по выбранному полю связи тип отношения между таблицами. Если поле, по которому нужно установить связь, является уникальным ключом как в одной таблице, так и в другой, Access выявляет отношение один-к- одному. Если поле связи является уникальным ключом в одной таблице (главной таблицы связи), а в другой таблице (подчиненной таблице связи) является не ключевым или входит в составной ключ, то есть значения его могут повторяться, Access выявляет отношение один-ко-многим между записями главной таблицы к подчиненной. В этом случае можно задать автоматическое поддержание целостности связей.
Отношение многие-ко-многим. Отношение многие-ко-многим предполагает, что каждой записи в одной таблице соответствует несколько записей в другой. При этом каждая сторона отношения выглядит как отношение один-ко-многим.
Однако если рассматривать взаимосвязь таблиц с двух сторон, становится очевидным, что ни одна из таблиц не может быть главной и для их связывания необходима третья таблица.
Связующая таблица представляет собой промежуточную таблицу, которая служит мостом между двумя таблицами в отношении многие-ко-многим. Ее ключ состоит из ключевых полей этих таблиц, с каждой из которых она связана отношением один-ко-многим. Помимо ключевых полей, связующая таблица должна содержать хотя бы одно поле, которого нет в связываемых таблицах, но которое имеет значение для каждой из них. Таким образом, отношение многие-ко-многим складывается из отношений многие-к-одному и один-ко-многим.
Связи-объединения.
Между двумя таблицами может быть установлена связь-объединение по некоторому полю связи. Для связи-объединения может быть выбран один из трех способов объединения записей:
Способ 1 - объединение только тех записей, в которых связанные поля обеих таблиц совпадают (производится по умолчанию);
Способ 2 - объединение тех записей, в которых связанные поля обеих таблиц совпадают, а также объединение всех записей из первой таблицы, для которых нет связанных во второй, с пустой записью второй таблицы;
Способ 3 - объединение тех записей, в которых связанные поля обеих таблиц совпадают, а также объединение всех записей из второй таблицы, для которых нет связанных в первой, с пустой записью первой таблицы.
Такой тип связи может быть определен, если связь характеризуется отношением 1:1 или 1:М, а также если тип отношения не может быть определен системой, то есть если не выполняются условия для этих отношений. Например, при выборе в главной таблице в качестве поля связи неключевого поля или поля, входящего в составной ключ, Access сообщает, что тип отношения не может быть определен. В этом случае между таблицами возможно установление только связи- объединения.
Связь-объединение обеспечивает объединение записей таблиц, имеющих одинаковые значения в поле связи. Причем производится объединение каждой записи из одной таблицы с каждой записью из другой таблицы при условии равенства значений в поле связи. Кроме того, если выбран второй или третий вариант в результат объединения могут быть добавлены записи из таблицы, для которых нет логически связанных записей в другой таблице. Последние два варианта часто необходимы при решении практических задач.
Примером такой задачи можетбыть формирование записей студентов с результатами успеваемости как в случае полученной оценки по предмету, так и при отсутствии оценки. При отсутствии оценки соответствующее поле будет пустым.
Создание связей между таблицами.
При определении связей в схеме данных удобно использовать информационно-логическую модель в каноническом виде, по которой легко определить главную и подчиненную таблицу каждой одно-многозначной связи, поскольку в такой модели главные объекты всегда размещены выше подчиненных. Эти связи являются основными в реляционных базах данных, т. к. одно-однозначные связи используются лишь в редких случаях, когда приходится разделять большое количество полей, определяемых одним и тем же ключом, по разным таблицам, имеющим разный регламент обслуживания.
Устанавливая в окне схемы данных связи типа 1 :М между парой таблиц, надо выделить в главной таблице уникальное ключевое поле, по которому устанавливается связь. Далее, при нажатой кнопке мыши, протащить курсор в соответствующее поле подчиненной таблицы.
Дата добавления: 2018-04-15; просмотров: 1837; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!